Comments 28
UFO just landed and posted this here
особенно с учётом того что условно-стандартный ondrej репозиторий как раз так и сделан чтобы несколько версий php друг другу не мешали; плюс будет чуть быстрее из за того что для fastcgi_pass будет использоваться не сетевой а файловый socket
Например: у TimeWeb в /opt установлены версии от 5.3 до 7.2 и вполне нормально живут себе.
> без чрезмерного использования аппаратных ресурсов и излишней траты времени на разворачивание рабочего окружения.
Познакомьтесь уже с lxc и чем-то вроде ansible.
Но вообще справедливо говорят, что ondrej-евские пакеты (а он, если что, мейнтейнер php-пакетов в debian) ставятся скопом всех версий, а потом (даже если говорить про самый сложный вариант — апачевый модуль) переключаются в одну команду. Ну а fpm просто вешается на разные порты.
Единственный вариант, когда есть смысл морочиться с описанной вами схемой — когда нужно тестить код под, например, php5.2 и php7+. Зачем — другой вопрос, но банально понадобятся разные версии дистрибутивов, если не хочется морочиться со сборкой руками.
Познакомьтесь уже с lxc и чем-то вроде ansible.
Но вообще справедливо говорят, что ondrej-евские пакеты (а он, если что, мейнтейнер php-пакетов в debian) ставятся скопом всех версий, а потом (даже если говорить про самый сложный вариант — апачевый модуль) переключаются в одну команду. Ну а fpm просто вешается на разные порты.
Единственный вариант, когда есть смысл морочиться с описанной вами схемой — когда нужно тестить код под, например, php5.2 и php7+. Зачем — другой вопрос, но банально понадобятся разные версии дистрибутивов, если не хочется морочиться со сборкой руками.
Познакомьтесь уже с lxc и чем-то вроде ansible.
Разве конфигурирование этой связки сравнится с элегантностью решения, которое предоставляет Docker: одна консольная команда в Docker — run (ну или 3 что у меня) против N команд связки lxc+ansible?
Это только при условии, что есть готовые image в registry (и при условии, что задача позволяет доверять им). Такое случается крайне редко, а писать докерфайлы — не шибко быстрее, чем дернуть пару команд (создать контейнер, запустить на нём ansible — вот уж для него-то плейбуков есть на любой случай жизни).
А ещё и остаются вопросы с различным statefull-содержимым (а у PHP его исторически много — от сессий, до привычки на любой чих писать в локальные каталоги).
Более того, конкретно php-ные image в публичном registry — дерьмо. Люди там больше выпендривались «смотрите как я могу!», чем создавали production-ready образ.
А ещё и остаются вопросы с различным statefull-содержимым (а у PHP его исторически много — от сессий, до привычки на любой чих писать в локальные каталоги).
Более того, конкретно php-ные image в публичном registry — дерьмо. Люди там больше выпендривались «смотрите как я могу!», чем создавали production-ready образ.
Очень красиво заминусовали ВОПРОС!!!
А вам не кажется, что минусовать вопрос глупо, при этом даже не приведя ссылки на какой-нибудь мануал в пользу других решений хотя бы с минимальным анализом затраченных ресурсов (как железных, так и временных на разворачивание)?
А вам не кажется, что минусовать вопрос глупо, при этом даже не приведя ссылки на какой-нибудь мануал в пользу других решений хотя бы с минимальным анализом затраченных ресурсов (как железных, так и временных на разворачивание)?
> А вам не кажется, что минусовать вопрос глупо
Мне? Мне вообще лениво в эти стрелочки целиться.
> ри этом даже не приведя ссылки на какой-нибудь мануал
мануал к чему? Поставить 2 мета-пакета и написать 4 конфига?
И вы вообще смотрели в dockerfile, который вы советуете всем использовать?
Мне? Мне вообще лениво в эти стрелочки целиться.
> ри этом даже не приведя ссылки на какой-нибудь мануал
мануал к чему? Поставить 2 мета-пакета и написать 4 конфига?
И вы вообще смотрели в dockerfile, который вы советуете всем использовать?
Более того, оно превосходит по элегатности решение с докером :)
Не говоря уже о том, что можно и даже нужно использовать разные апстримы (/etc/nginx/conf.d), хотя вот разные пулы, на мой взгляд, подключаются неудобно (или я не умею их правильно и удобно подключать?)
Не говоря уже о том, что можно и даже нужно использовать разные апстримы (/etc/nginx/conf.d), хотя вот разные пулы, на мой взгляд, подключаются неудобно (или я не умею их правильно и удобно подключать?)
Под 5.2 наверняка еще особо древние вебсерверы потребуются для тестов, и там скорее всего будет полноценная виртуалка с ядром типа 2.6.27
Nginx тогда уж тоже в Докер положить. А то какая-то мешанина.
И важный минус, такая конфигурация при перезапуске сервера перестанет работать. Докер не поднимаем простые контейнеры автоматически.
И важный минус, такая конфигурация при перезапуске сервера перестанет работать. Докер не поднимаем простые контейнеры автоматически.
В такой конфигурации все вируальные хосты будут работать под одним пользователем, что небезопасно.
От www-data? o.O
Что в этом небезопасного?
Что в этом небезопасного?
Один юзер хостинга сможет лазить по файлам другого юзера хостинга. Действительно, что там небезопасного то.
Откуда юзеры хостинга на рабочей станции разработчика? Поясните, из какой фразы можно сделать вывод, что речь в статье про продакшн?
Не вижу в статье ничего про личный комп разработчика.
А если мы говорим про некий тестовый/отладочный/staging сервер, то там почти наверняка больше 1 проекта, в этих проектах наверняка есть баги и этот сервер почти наверняка смотрит в инет. Найдя уязвимость каком-нибудь в одном всеми забытом проекте, кулхацкер получит доступ ко всем проектам через файловую систему. Так что такую конфигурацию однозначно фтопку.
А если мы говорим про некий тестовый/отладочный/staging сервер, то там почти наверняка больше 1 проекта, в этих проектах наверняка есть баги и этот сервер почти наверняка смотрит в инет. Найдя уязвимость каком-нибудь в одном всеми забытом проекте, кулхацкер получит доступ ко всем проектам через файловую систему. Так что такую конфигурацию однозначно фтопку.
Описанное в статье как раз и годиться только для машины разработчика или тестировщика. Тащить это на сервер (любой) плохая идея и не только из-за возможных проблем с безопасностью. Описаное в принципе не является хорошим примером работы с контейнерами.
Описанное в статье вообще ни для чего не годится. dev-окружение в принципе сильно отличается от продакшена. Как минимум будет отладчик с логгером, какой-нибудь упаковщик с хотрелоадом, будут другие настройки (memory limit и т.п.), будет куча dev-пакетов типа того же бабеля. Тащить туда ещё и докер ради докера, а потом скакать с ним по граблям как минимум глупо.
Так Docker как раз и решает проблему разницы между продом и дев окружением. И не только эту. Но взамен требует изменить подход к разработке достаточно сильно, что судя по всему часто вызывает непонимание того, зачем вообще он нужен разработчикам, если и без него всё работает.
Нет такой проблемы как «разница между продом и девом», это не проблема, а возможность. Возможность юзать отладчики, сборщики и прочие тулы для разработки, а не для прода.
Да, перед выкатыванием на прод код нужно проверить в «обстановке, максимально приближенной к боевой». Для этого есть staging сервера, самые разные тесты от юнит до интеграционных и прочее прочее. И это должен быть именно отдельный сервер, а не так что разработчик сообщает что «мамой клянусь, я в докере протестил».
Я понимаю, зачем нужен докер девопсам и тестировщикам. Я понимаю, как получить от него пользу разработчику — ну, хочешь там попробовать какой-нибудь эластик, установил, попробовал, снёс. Но для описанной в статье задачи докеру места нет.
Да, перед выкатыванием на прод код нужно проверить в «обстановке, максимально приближенной к боевой». Для этого есть staging сервера, самые разные тесты от юнит до интеграционных и прочее прочее. И это должен быть именно отдельный сервер, а не так что разработчик сообщает что «мамой клянусь, я в докере протестил».
Я понимаю, зачем нужен докер девопсам и тестировщикам. Я понимаю, как получить от него пользу разработчику — ну, хочешь там попробовать какой-нибудь эластик, установил, попробовал, снёс. Но для описанной в статье задачи докеру места нет.
Ну, если в один из проектов получится залить эксплоит. Но это уже разговор о другом будет.
А так там всё разграничено локациями в nginx и сокетами в php-fpm.
А так там всё разграничено локациями в nginx и сокетами в php-fpm.
отмечу, что еще не рассмотрен вопрос изоляции разных проектов друг от друга. а часто это имеет значение. :-)
Благодаря статьям подобного рода, среди новичков распространяется мнение, что решение всех задач — это docker.
Потом, прочитавшего эту статью новичка другой новичок спросит «А как поставить php7.1?», а тот скажет «А разверни docker-контейнер!» и кинет ссылку на эту статью.
По сути, докер нужен для весьма специфичных задач, не надо его пихать куда попало. Пожалуйста.
Лучше изучите внимательней документацию.
Потом, прочитавшего эту статью новичка другой новичок спросит «А как поставить php7.1?», а тот скажет «А разверни docker-контейнер!» и кинет ссылку на эту статью.
По сути, докер нужен для весьма специфичных задач, не надо его пихать куда попало. Пожалуйста.
Лучше изучите внимательней документацию.
почему нельзя через nix установить несколько версий PHP, без всяких виртуальных машин и конфликтов библиотек?
Sign up to leave a comment.
Несколько версий PHP на хосте с помощью Docker