Комментарии 62
Автор, неправильно делаешь. Такие вещи нельзя конфигурировать руками. Нужно использовать какой-нибудь ansible, puppet или типа того.
Один раз написать bash и больше не париться.
Потом с помощью Git разворачивается проект.
Ставить лишнюю прослойку в виде Docker — лишнее.
Да и вообще принято использовать идентичное ПО локально и на боевом сервере
Баш скрипт может не сработать, сработать не так, или вообще сделать что-то левое, в зависимости от окружения. Докерфайл (конфигурация для докер-контейнера) это по сути тот же самый баш-скрипт (различия — минимальны, правда) только вот он работает всегда одинаково, на всех машинах, под любой ОС. Собирается контейнер который будет работать одинаково и на проде и на тесте и на «ноуте разработчика». Точно так же храните свой докерфайл в том же самом git с исходниками проекта, и ваш проект будет всегда и у всех собираться ровно точно так же как вы и задумали.
Поверьте я тут вам рассказываю всё это не потому что я какой-то злобный буратино и пытаюсь вас заставить делать бесполезную работу. То что вы описываете — так я и сам когда-то работал, и вот сейчас у меня лежит по докерфайлу в каждом проекте, (а на самом деле минимум 2-3, отдельные контейнеры на php-fpm, nginx, nodejs… но это мои замарочки, так делать не обязательно) там же лежат конфиги от системы орестрации и всё это работает у меня на компе, на компе моих сотрудников, на тесте и проде, на нескольких проектах. Попробуйте преодолеть это ваше «лишнюю прослойку в виде Docker», тем более что у вас итак линукс, потом скажете нам спасибо.
Спасибо за информацию, я попробую развернуть окружение с помощью Docker буквально на днях, правда. Вы меня заинтриговали. Свое мнение отпишу сюда.
Пока только единственный вопрос, если докер контейнер везде идентичный, соответственно и клнфиги в нем. То как разруливать такую ситуацию, когда на бое у меня в конфигах подключен ssl, а в локально директивы отвечающие за ssl придется закомментировать, то есть уже контейнер не идентичный получается. Или эти моменты как-то по-другому решаются?
Но это все в теории. А на практике, в продакшене у вас, скорее всего, будет отдельный контейнер для шифрования трафика. В локальном окружении вам этот контейнер не нужен, ходите напрямую.
Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
Кстати, если кто-то предпочитает Windows, то можно использовать Vagrant, это довольно удобно и целесообразно для такого случая. То есть мы работаем в IDE под Windows, но проект у нас на виртуальной машине например под Ubuntu Server, а IDE в него смотрит (общий каталог).
Конечно есть под Windows Open Server, но у него проблемы есть с правкой конфигов nginx и некоторые ограничения. Так же под Windows нет официальной поддержки Redis, в Open Server Redis — сборка энтузиастов. А Redis нужен всегда, по крайней мере мне.
include fcgi_params должен быть в начале.
Всегда найдется идиот, который скопирует ваш конфиг в production не глядя.add_header Access-Control-Allow-Origin *;
Про
include
уже написали выше.Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04
и следом
aptitude install nginx
aptitude install php-fpm
Далее конфиги из гугла… елы палы.
Я расчитывал увидеть вот такое про php 7.1 и сборку nginx с какими-нить кастомными плагинами (хотя бы ngx_http_substitutions_filter_module, от которого пользы вагон).
Но самое страшное:
На этом установка и настройка php-fpm закончена. Правда, это все.
Не хочу ругаться, так как вас спасает лишь
как подготовить почву для локальной веб-разработки проектов, ибо на сервер такое не проканает. Дефолтные конфиги php-fpm без настройки юзеров, это классная дырка, даже не отверстие. И локально все равно надо пользователей настраивать, так как когда будет перенос на сервер, под урезанной учеткой могут начаться сюрпризы, которых не было на локальной анархии.
Для продакшина это не годится, но и статья не о настройках на продакшине.
И конфиги не из гугла.
Хедеры разрешающие обращение аяксом с других доменов.
add_header Access-Control-Allow-Origin *;
Я вам написал про косяк, что анархия на дев тачке может попросту на завестись на продакшене, так как юзер на продакшине сидит в железной клетке или еще фиг знает где (как его злобный буратино огородил). Да и, ей богу, установку PHP7 из репы… когда я 2 недели назад ставил 7.1 (который работает отлично!) на новую виртуалку для инет магаза… это нехорошо. Можно было и 5й поставить, все равно репо ж.
зачем лишние движения и лишние строки в конфигах?
Обращаю внимание на две бессмысленные директивы fastcgi_split_path_info
и fastcgi_index
в location ~* \.php$
. Это либо ошибка, либо копипаста.
Это не тема для статьи, это твит максимум. Статья — это как в том примере по ссылке, когда чем качает исходник PHP (самый последний, а не 7й), конфигурирует его как хочет, затем добавляет в системы и сервисы и докидывает пачку модов к нему. Вот это статья.
LAMP/LEMP опять же не годится, без понимания основ, если вы конечно не мини-проекты разрабатываете.
Да и вообще принято использовать идентичное ПО локально и на боевом сервере. Если учитывать ваше недовольство, то можно и на продакшине LAMP развернуть.
docker run -d -p 80:80 -v /tmp/html:/var/www/html --name php7 richarvey/nginx-php-fpm:php7 && sudo chmod 777 /tmp/html
~1.5 минуты и можно начинать разработку.
Но повторюсь, что я хотел рассказать именно про нативную настройку.
Контейнеров масса, но все не дотягивает до специфичности проекта.По вашим комментариям можно заключить, что что такое Docker, вы не знаете.
Хотя я сам не являюсь сторонником использования контейнеров в production, но вам однозначно следует почитать что-нибудь на эту тему, чтобы понять, что это вообще такое и перестать приводить аргументы «не в тему».
По умолчанию его можно опускать, даже нужно, лишняя писанина.
Если у вас интерпретатор настроен специфично, то это уже другой вопрос.
Это лет 5 назад его рекомендовалось оставлять.
RFC от IETF тоже de jure не стандарты, но многие de facto таковыми являются.
HTTP/1.1, которым вы, скорее всего, пользовались для отправки этого сообщения, описан в пачке RFC (2616 и другие). TCP, поверх которого это работает, — тоже (rfc 793 и другие). Далее продолжать или таки осилите вбить что-нибудь в гугл?
От того что что-то где-то написано, стандартом оно не становится.
Видимо, вам не очень понятно что такое de facto. Просвещайтесь, я вас покину.
Влезу в ваш диалог. Стандарты были в СССР в виде ГОСТ-ов и были обязательны к исполнению. RFC и иже с ними де юре не законы и к исполнению не обязательны. Де факто их используют как некие инструкции при этом вендоры их реализуют как считают нужным. Многие из этих документов вообще по многу лет не выходят из черновиков.
А сейчас ГОСТ и ГОСТ Р тоже стандарты, но не обязательны к исполнению. Например, используя openssl в качестве библиотеки для сервера с https, я полагаюсь на корректную имлементацию пачки стандартов de facto (начиная от C calling conventions для linux до rfc, описывающих TLSv1.x, всяких стандартов из группы pkcs 1, 7, 11 и т. п.), но не использую при этом ГОСТ Р 34.10-2001, являющийся стандартом криптографической подписи в РФ. Не нужен он мне, и всё.
Говорить про, скажем RFC 793, что это не стандарт de facto несколько странно, учитывая, что, в процессе написания этого комментария, TCP-пакеты, описанные этим стандартом, прошли оборудование десятка различных вендоров и близкое количество различных сетевых стеков, которые только благодаря наличию коллективных рекомендаций под эгидой IETF корректно работают совместно.
Рекомендую почитать историю зари интернета и успешного захвата мира sendmail'ом. Там довольно много про становление стандартов de facto, которые сейчас известны как rfc822 плюс его соседи и наследники (smtp: 821/2821/5321, email/imf: 822/2822/5322 и куча других).
Некоторая свобода в реализации RFC естественно закладывается каждым конкретным стандартом (всякие SHOULD и MAY в тексте соответствующего стандарта), но это абсолютно нормально. ГОСТы многие вещи тоже дают на откуп "пользователю" стандарта.
Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.
Если вы используете пакетный менеджер aptitude, то команда sudo aptitude remove nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.
remove — Remove packages.
purge — Remove packages and their configuration files.
sudo nginx -t
, если всё ок, запускать
sudo service nginx reload
вместо
sudo service nginx restart
, о чём в статье не упоминается.
Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04