Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04

[776166]

Неофитская пятница началась.

Автор, неправильно делаешь. Такие вещи нельзя конфигурировать руками. Нужно использовать какой-нибудь ansible, puppet или типа того.

[Stavanger]

Я приветствую конструктивную критику. Статья о том как настраивать определенный софт, а не о системах централизованного управления конфигурациями.

Иногда лишние надстройки только усложняют понимание. Для крупных компаний несомненно удобно и необходимо использовать ПО о котором вы говорите.

[ZoomLS]

Есть же Docker.

[Stavanger]

Есть много чего интересного. Но если не понимать азов, то Docker не спасет. Не понимаю к чему такой комментарий.

[Caravus]

Так верстают только м Не понимаете, потому и нет у вас докера. Когда вам с вашей локалки надо будет перенести всё на тест, а потом на прод — вы что будете делать?

[Stavanger]

Bash, который разворачивает конфигурацию на продакшине/тестовом сервере — все. Я не видел ни разу Docker-контейнера с тем ПО, которое было бы актуально для моих проектов, все приходится до настраивать и вся «прелесть» Docker уходит на нет.

Один раз написать bash и больше не париться.
Потом с помощью Git разворачивается проект.
Ставить лишнюю прослойку в виде Docker — лишнее.

[Caravus]

Какая-то странная логика. Докер придуман вовсе не для того чтоб какие-то левые парни написали вам докерфайлы на все случаи жизни, под ваш любимый софт с нужными вам версиями. Он нужен для переносимости окружения, как раз то о чём вы пишите ниже:

Да и вообще принято использовать идентичное ПО локально и на боевом сервере

Баш скрипт может не сработать, сработать не так, или вообще сделать что-то левое, в зависимости от окружения. Докерфайл (конфигурация для докер-контейнера) это по сути тот же самый баш-скрипт (различия — минимальны, правда) только вот он работает всегда одинаково, на всех машинах, под любой ОС. Собирается контейнер который будет работать одинаково и на проде и на тесте и на «ноуте разработчика». Точно так же храните свой докерфайл в том же самом git с исходниками проекта, и ваш проект будет всегда и у всех собираться ровно точно так же как вы и задумали.
Поверьте я тут вам рассказываю всё это не потому что я какой-то злобный буратино и пытаюсь вас заставить делать бесполезную работу. То что вы описываете — так я и сам когда-то работал, и вот сейчас у меня лежит по докерфайлу в каждом проекте, (а на самом деле минимум 2-3, отдельные контейнеры на php-fpm, nginx, nodejs… но это мои замарочки, так делать не обязательно) там же лежат конфиги от системы орестрации и всё это работает у меня на компе, на компе моих сотрудников, на тесте и проде, на нескольких проектах. Попробуйте преодолеть это ваше «лишнюю прослойку в виде Docker», тем более что у вас итак линукс, потом скажете нам спасибо.

[Stavanger]

Спасибо за информацию, я попробую развернуть окружение с помощью Docker буквально на днях, правда. Вы меня заинтриговали. Свое мнение отпишу сюда.

[Caravus]

По любым вопросам — пишите в личные сообщения, постараюсь помочь.

[Stavanger]

Спасибо Вам.

[Stavanger]

Пока только единственный вопрос, если докер контейнер везде идентичный, соответственно и клнфиги в нем. То как разруливать такую ситуацию, когда на бое у меня в конфигах подключен ssl, а в локально директивы отвечающие за ssl придется закомментировать, то есть уже контейнер не идентичный получается. Или эти моменты как-то по-другому решаются?

[Caravus]

Ну во первых вам никто не мешает на локалке подключать папку с нужынми локальными сертификатами в контейнер, поверх продуктовых сертификатов. Во вторых — на локалке можно просто игнорировать ошубку сертификата и нажимать «продалжить».

[kafeman]

Это уже часть конфигурации, а не сборки. Положите свои сертификаты в какой-нибудь etcd или consul. Класть их в сам контейнер неправильно, поскольку вы наверняка будете передавать этот контейнер другим разработчикам, например, из своей команды. А ключи вещь такая, что чем меньше человек имеет к ним доступ, тем лучше.

Но это все в теории. А на практике, в продакшене у вас, скорее всего, будет отдельный контейнер для шифрования трафика. В локальном окружении вам этот контейнер не нужен, ходите напрямую.

[Stavanger]

Спасибо за наводку.

[zurapa]

Это всё классно, когда вы изучили Docker, когда вы его каждый день настраиваете и это у вас в памяти.
Возьмём обычного новичка. Он вчера только закончил устанавливать бунту в виртуалу, на своей винде, сегодня ему нужно установить какие-то базовые компоненты типа php, phpfpm и прочей дребедени. У него есть инструкция, которая декларирует ему, что можно поставить из этой убунты какими командами. И всё это в летает легко, быстро, потом он переходит к конфигурации, конфигурационным файлам, настраивает это, пробует, не взлетает, он разбирается, что не так, и через какое-то время у него всё получается. Что будет, если он последует вашему совету знаете? Его инсталляция отодвинется на две недели, и возможно он даже забудет, что он хотел с делать. А в сухом остатке он и в том и в другом случае получит один конечный результат. Только если он с этим докером не будет упражняться часто, то он и профит не увидит.
Понятное дело, что в промышленных масштабах docker может ему и нужен. Но сейчас речь не об этом. Ребёнка учат с азбуки, а не сразу ему даю компьютер и предлагают разобраться в буквах, слепой печати и где хранить файлы...
Для каждого случая есть свои рекомендации.
Я это говорю не понаслышке. Имею большой опыт администрирования. И был опыт перевода проекта на docker. Т.к. докер я не знал на тот момент, мне нужно было этот проект собрать на виртуозке, чтобы он заработал, и иметь эталонный рабочий вариант, к которому приводить Docker-проект нужно. Так вот в виртуалке собрать проект из компонентов требуемых мне заняло недолго времени, а с докером разбираться - две недели. Да, после этих двух недель я, быть может ещё и вас поучу, что там да как в написании и проектировании docker-composer файлов. Но.. Речь у нас о каком-то проекте на php который нам нужно запустить и попробовать, и есть инструкция по установке на какую-то ОС. Докер тут явно не в тему. Если же вы так обучаете всех своих коллег, или может у вас в подчинении есть Джуны и вы проделываете с ними историю с docker... то удачи вам ваших начинаниях - она вам понадобится.

И ещё один прикладной случай. Почтовый сервер нужно было поднять. Для организации. Выбор был за мной. Docker я уже знал. Выбрал я iredmail проект. Установка скриптом заняла минут 15, и ещё конфигурирование... Где-то за час управился. Установка docker, на систему и прочее всё с ним связанное в том числе и про подсети, которые могут пересекаться и это что вы предлагаете наовичку постичь, или не постигать, а просто упереться в этот конфликт и недоумевать, почему вдруг у него не отвечает в локальной сети какой-то докер контейнер. И это у меня заняло сильно-сильно больше времени. Т.к. опять же я не постоянно всё держу в докерах и не разворачиваю его каждый день на серверах.

Понятно дело, что можно написать скрипачки, о чём пишет здесь автор, но это блин bash скрипки, которые вы хаете, или вы ещё предлагаете подключить сюда новичку технологию ansible, или chef или pappeи?! Опять же, речь о том, чтобы не усложнять и не добавлять прослоек.

Весь IT сейчас погряз в прослойках. Ещё не придумали прослойку между ОС и docker?.. Чувствую, что не хватает... (сарказм)
Если хочется козырнут своими навыками и поумничать, то вы можете предложить свою статью на публику, и на критику, и потом почитать нечто подобное. Зачем же вносить сумбур такими предложениями, как докер. И ОС и докер требуют инсталляции и настройки, имеют свои нюансы. Авто выбрал как платформу чистую Ubuntu. Всё! Это наше ограничение. Docker тут не к месту и не к обсуждению. Это совершенно другая статья, коих полно в том числе и на этой платформе (Хабр), и там вы можете успешно хвастать своими познаниями docker.

[afiskon]

Статья хорошая. С комментариями выше про Docker и Ansible не соглашусь, я бы лично просто завернул это в виртуалку, притом желательно VirtualBox, потому что он есть у всех.

Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.

[Stavanger]

Спасибо.

Кстати, если кто-то предпочитает Windows, то можно использовать Vagrant, это довольно удобно и целесообразно для такого случая. То есть мы работаем в IDE под Windows, но проект у нас на виртуальной машине например под Ubuntu Server, а IDE в него смотрит (общий каталог).

Конечно есть под Windows Open Server, но у него проблемы есть с правкой конфигов nginx и некоторые ограничения. Так же под Windows нет официальной поддержки Redis, в Open Server Redis — сборка энтузиастов. А Redis нужен всегда, по крайней мере мне.

[FFunk]

Под windows можно использовать docker и виртуализацию hyper-v.

[alekciy]

include fcgi_params должен быть в начале.

[kafeman]

add_header Access-Control-Allow-Origin *;

Всегда найдется идиот, который скопирует ваш конфиг в production не глядя.

Про include уже написали выше.

[Stavanger]

Хедеры разрешающие обращение аяксом с других доменов.

add_header Access-Control-Allow-Origin *;

[kafeman]

Спасибо, я знаю, зачем нужен CORS. А вот многие из тех, кто будет использовать ваш конфиг — нет.

Так что лучше закомментируйте эту строку. Кому надо, тот сознательно раскомментирует.

[Stavanger]

Поправил этот момент.

[kafeman]

Порядок include так и не исправили. Загляните в файл, который вы инклудите. Не он должен переопределять ваши переменные, а вы его. Иначе действительно возникает впечатление, что вы надергали куски каких-то левых конфигов из Интенета, не понимая их сути.

[nikitasius]

Статья начитается с

Установка и базовая настройка 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 без настройки юзеров, это классная дырка, даже не отверстие. И локально все равно надо пользователей настраивать, так как когда будет перенос на сервер, под урезанной учеткой могут начаться сюрпризы, которых не было на локальной анархии.

[Stavanger]

Статья исключительно для разработки локально, не больше. Локально этого с головой хватит, локально мы не думаем о безопасности, зачем лишние движения и лишние строки в конфигах?

Для продакшина это не годится, но и статья не о настройках на продакшине.

И конфиги не из гугла.

Хедеры разрешающие обращение аяксом с других доменов.

add_header Access-Control-Allow-Origin *;

[nikitasius]

Это вы про аналогию с китайским Абибасом или 2-3 линейным найком? Ну… добавить одну линию и уже, вроде как, свое.

Я вам написал про косяк, что анархия на дев тачке может попросту на завестись на продакшене, так как юзер на продакшине сидит в железной клетке или еще фиг знает где (как его злобный буратино огородил). Да и, ей богу, установку PHP7 из репы… когда я 2 недели назад ставил 7.1 (который работает отлично!) на новую виртуалку для инет магаза… это нехорошо. Можно было и 5й поставить, все равно репо ж.

[VBart]

зачем лишние движения и лишние строки в конфигах?

Обращаю внимание на две бессмысленные директивы fastcgi_split_path_info и fastcgi_index в location ~* \.php$. Это либо ошибка, либо копипаста.

[Stavanger]

ISPConfig (конкретно про это не могу сказать, не пробовал), а вот ISPManager я принципиально не использую, так как кучу гемора можно получить, был уже опыт с ним.

[nikitasius]

Речь не про ISPConfig и прочие свистоперделки. Речь о том, что поставить софт через пакет менеджер это пара команд + первый конфиг из гугла, если дефолтные (у вас тут микс из дефолтных и чутьчуть изменений).

Это не тема для статьи, это твит максимум. Статья — это как в том примере по ссылке, когда чем качает исходник PHP (самый последний, а не 7й), конфигурирует его как хочет, затем добавляет в системы и сервисы и докидывает пачку модов к нему. Вот это статья.

[GarretUA]

В поиске Хабра можно найти тучу статей конфигурации LAMP/LEMP стэка под кучу разных осей, зачем еще одна? Ну и во времена docker/vagrant это уже странно смотрится. Если хотите донести азы установки пакетов в убунте, то это прекрасно можно сделать и в виде vagrant + bash скрипт для провиженинга.

[Stavanger]

Чтобы настраивать doker/vagrant нужно их понять. Дайте настроить их новичку и посмотрите как он встанет в ступор. Например подготовка бокса для распространения в команде, чтобы его настроить, нужно понимать азы, инчане все это бестолку.

LAMP/LEMP опять же не годится, без понимания основ, если вы конечно не мини-проекты разрабатываете.

Да и вообще принято использовать идентичное ПО локально и на боевом сервере. Если учитывать ваше недовольство, то можно и на продакшине LAMP развернуть.

[GarretUA]

Ну полнейшего новичка что угодно поставит в ступор. Может тогда начать с базовых юникс команд вообще?

LAMP = Linux/Apache/MySQL/PHP, LEMP=Linux/Nginx/MySQL/PHP если что. А то не совсем пойму о чем вы.

[Stavanger]

Да, это безусловно круто.

Но повторюсь, что я хотел рассказать именно про нативную настройку.

[Stavanger]

Я не уверено что там будет весь стек технологий, который мне потребуется и с теми настройками, которые мне нужны. Контейнеров масса, но все не дотягивает до специфичности проекта.

[kafeman]

Контейнеров масса, но все не дотягивает до специфичности проекта.

По вашим комментариям можно заключить, что что такое Docker, вы не знаете.

Хотя я сам не являюсь сторонником использования контейнеров в production, но вам однозначно следует почитать что-нибудь на эту тему, чтобы понять, что это вообще такое и перестать приводить аргументы «не в тему».

[maniacscientist]

Написали бы лучше гуевину, чтобы возня с sites-available и /etc/hosts находилась под капотом

[alexey-m-ukolov]

Современный стандарт рекомендует его не ставить.

[alexey-m-ukolov]

http://www.php-fig.org/psr/psr-2/#files

[Stavanger]

Зачем там закрывающий тег?
По умолчанию его можно опускать, даже нужно, лишняя писанина.
Если у вас интерпретатор настроен специфично, то это уже другой вопрос.
Это лет 5 назад его рекомендовалось оставлять.

[Stavanger]

Почитайте про стандарты PSR

[Caravus]

PSR это не стандарты, это «PHP Standards Recommendations», рекомендации.

[grossws]

RFC от IETF тоже de jure не стандарты, но многие de facto таковыми являются.

[Caravus]

Отличный аргумент и очень в тему обсуждения. Если кто-то пользуется RFC как стандартами, это не значит что они «de facto таковыми являются», это значит что кто-то не хочет думать своей головой.

[grossws]

HTTP/1.1, которым вы, скорее всего, пользовались для отправки этого сообщения, описан в пачке RFC (2616 и другие). TCP, поверх которого это работает, — тоже (rfc 793 и другие). Далее продолжать или таки осилите вбить что-нибудь в гугл?

[Caravus]

На заборе тоже написано, а там дрова лежат (с)
От того что что-то где-то написано, стандартом оно не становится.

[grossws]

Видимо, вам не очень понятно что такое de facto. Просвещайтесь, я вас покину.

[alekciy]

Влезу в ваш диалог. Стандарты были в СССР в виде ГОСТ-ов и были обязательны к исполнению. RFC и иже с ними де юре не законы и к исполнению не обязательны. Де факто их используют как некие инструкции при этом вендоры их реализуют как считают нужным. Многие из этих документов вообще по многу лет не выходят из черновиков.

[grossws]

А сейчас ГОСТ и ГОСТ Р тоже стандарты, но не обязательны к исполнению. Например, используя 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 в тексте соответствующего стандарта), но это абсолютно нормально. ГОСТы многие вещи тоже дают на откуп "пользователю" стандарта.

[VBart]

Стандарты пишутся точно такими же людьми. И помимо того, что людям в принципе свойственно ошибаться, авторы стандартов не всегда умнее разработчиков, которые по этим стандартам что-то реализовывают. Иногда, ради безопасности или эффективности, где-то приходится отступать от стандарта и думать своей головой.

[nikitasius]

Если вы используете пакетный менеджер aptitude, то команда sudo aptitude remove nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.

remove — Remove packages.
purge — Remove packages and their configuration files.

[Stavanger]

Спасибо, вы действительно правы.
Проверил, тут моя ошибка, у меня не верная информация, поправлю.

[Merkat0r]

Мда… прочитал ветку, только укрепился в желании, что когда разрабы пытаются дотянутся рученьками до серверов их им надо нежно обламывать и посылать обратно код писать, а не пытаться админить :)

[grossws]

Разработчики разные бывают. Не говоря уж про ныне модное направление devops.

[steff]

Чтобы попросить nginx использовать свежую конфигурацию без перезагрузки сервиса, рекомендую после

sudo nginx -t

, если всё ок, запускать

sudo service nginx reload

вместо

sudo service nginx restart

, о чём в статье не упоминается.

[Stavanger]

Да, безусловно.
Добавлю в статью.
Спасибо.

[Aytuar]

chmod -R 777 гениально! Особенно не забудьте сделать это на проде.

[Stavanger]

Очевидно же что на проде так делать не надо.

[nikolayvaganov]

без 777 в проде у вас php не сможет писать в свои же каталоги, потому как каталог создан от одного пользователя, а fpm пускается от nginx/www-data/apache, а стандартная маска запрещает other писать в каталог. надо либо в конфиге пула fpm менять user/group либо chown делать на каталоге.