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

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

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

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

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

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

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

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

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

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

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

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

Конечно есть под Windows Open Server, но у него проблемы есть с правкой конфигов nginx и некоторые ограничения. Так же под Windows нет официальной поддержки Redis, в Open Server Redis — сборка энтузиастов. А Redis нужен всегда, по крайней мере мне.
add_header Access-Control-Allow-Origin *;
Всегда найдется идиот, который скопирует ваш конфиг в production не глядя.

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

add_header Access-Control-Allow-Origin *;
Спасибо, я знаю, зачем нужен CORS. А вот многие из тех, кто будет использовать ваш конфиг — нет.

Так что лучше закомментируйте эту строку. Кому надо, тот сознательно раскомментирует.
Порядок 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 *;
Это вы про аналогию с китайским Абибасом или 2-3 линейным найком? Ну… добавить одну линию и уже, вроде как, свое.

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

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

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

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

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

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

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

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, но вам однозначно следует почитать что-нибудь на эту тему, чтобы понять, что это вообще такое и перестать приводить аргументы «не в тему».
Написали бы лучше гуевину, чтобы возня с sites-available и /etc/hosts находилась под капотом
Зачем там закрывающий тег?
По умолчанию его можно опускать, даже нужно, лишняя писанина.
Если у вас интерпретатор настроен специфично, то это уже другой вопрос.
Это лет 5 назад его рекомендовалось оставлять.

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

Отличный аргумент и очень в тему обсуждения. Если кто-то пользуется RFC как стандартами, это не значит что они «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.
Спасибо, вы действительно правы.
Проверил, тут моя ошибка, у меня не верная информация, поправлю.
Мда… прочитал ветку, только укрепился в желании, что когда разрабы пытаются дотянутся рученьками до серверов их им надо нежно обламывать и посылать обратно код писать, а не пытаться админить :)

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

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

, если всё ок, запускать
sudo service nginx reload

вместо
sudo service nginx restart

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

явно єто решается через кнфигурацию и владельца, а не через 777

Only those users with full accounts are able to leave comments. Log in, please.