Это интересный план, но делать нужно всё с точностью наоборот :)
Для прода нужно чтобы не было статических ссылок на другие контейнеры в конфиг файлах nginx.conf и т.д.
Значение хоста и порта в инструкциях типа SetHandler «proxy:fcgi://php:9000» должны приходить из ENV: SetHandler "${PHP_UPSTREAM}"
В чём проблема с такими ссылками? И докер-композ и кубернетес спокойно работают с именами контейнеров. Запихивая их через ENV вы добавляете ещё одно место где может накосячить человек (человеческий фактор). Лишнее нарушение изоляции. В ENV вообще ничего ценного быть не должно.
Конфиги и все файлы из src должны «запекаться» в image при помощи ADD/COPY инструкций Dockerfile.
Конфиги как раз таки должы пробрасываться снаружи. Делается это для того чтобы эти конфиги не появились в ваших репозиториях (гит, докер). Для разного окружения — разные конфиги, потому засунуть их все в докерфайл — создать место с неопределённостью в работе (какой конфиг сейчас подгружен, какие значения?). Простой способ (не рекомендую) через ENV, чуть сложнее — через секреты. Можно записывать в райнтайм, опять же, зависит от того для кого.
Программа должна работать без «volumes» в docker-compose
Volumes могут быть не только для связи контейнер-дев машина, но и для связи контейнер-контейнер.
Далее надо использовать Rancher или Kubernetes чтобы это все дело оркестрировать на проде.
Насколько я понял — ранчер сейчас сам переходит на кубернетес, так что скоро это будет одно и тоже, просто у ранчера будет морда поудобней.
Контейнер должен быть один и тот же. Как вариант вашего предложения — запускать с нужными переменными. То есть на деве «ENV=DEV» на проде «ENV=PROD» и т.д.
По данному вопросу к сожалению я ничего сказать не могу
(орфография и пунктуация — авторская)
Весь смысл использовать докер — переносимость окружения. Если вы не знаете как это всё запустить на проде — ценность статьи стремится к нулю.
Я не просто так это пишу, это серьёзная проблема. Как выкатить это всё с дева на тест/прод, как дать понять программе что она теперь на проде (и не надо выводить отладочную информацию), как монтировать статику из php контейнера в apache/nginx контейнеры минуя хост (какой хост на проде-то?), как это всё масштабировать и т.д. и т.п.
Если мы не знаем как это всё будет запущено на проде — как тестировать? Как убедиться что на проде наш код не превратится в тыкву?
При обновлении пхп в системе вам нужно будет и модули обновлять, так что одно и тоже.
Тут разговор не о том что что-то заменяет что-то другое, тут скорее про «я написал конфиг и теперь по этому конфигу могу создать себе окружение». На примере тех же модулей — чтобы обновить в докере версию пхп — надо всего лишь поменять циферку в FROM, пакеты будут собираться точно также как и в предыдущей версии. Так что я просто запущу сборку и пойду чайку выпью…
О, тут уже подключается какой-нибудь CI/CD, например gitlab CI, в случае работы с кодом. По коммиту в репозиторий нужного проекта всё пересобирается, тестируется, обновляется.
Смысл как раз в том чтобы не париться сколько у вас систем и каких. Вы один раз всё это настраиваете, а потом просто жмёте кнопки по необходимости.
Вопрос только в том что это уже слабо связано с докером. Для меня лично докер это способ упаковать кучку файлов в некий более-менее стандартный объект, который потом можно закинуть на сервер со словами «ну запусти это с таким-то конфигом и в таком-то количестве».
Про docker-compose уже написали, но пожалуй уточню — сам по себе докер мало для чего пригоден, толком работать не удобно, но вот если подключить какую-то систему оркестрации (тот же docker-compose, сварм, кубернетес, месос или что там ещё придумали) тогда совсем другое дело. Например в кубернетес минимальная единица системы — под, который в свою очередь состоит из нескольких контейнеров, объединённых своей сетью. Дико удобно для развёртывания многосервисных систем (например — сложные сайты), каждый сервис в отдельном контейнере (или даже нескольких) и они между собой могут нормально общаться… Добавляется лёгкое горизонтальное и вертикальное масштабирование и ещё куча всяких плюшек…
Про «Ну или почти тоже самое, без красивой обёртки» это мягко говоря перегиб. Докер, собственно говоря, только и делает что готовые системы собирает в кучу и предоставляет вменяемый апи.
Ну а по сути: я очень надеюсь что вся эта движуха с контейнеризацией не потухнет вместе с докером. Может быть есть какие-то ссылки на проекты, скажем гитхаб хотя бы, которые можно было бы отслеживать?
Одно дело «apt install ...» и фигачить код, другое дело «Написать своего клиента». Слабо себе представляю как я прихожу к начальнику и говорю «слушай, давай на пару месяцев забьём на бизнес и будем писать клиент для containerd, там не сложно, у него говорят весьма юзабельный АПИ»… А потом ещё обучим наших разработчиков пользоваться нашей поделкой, а потом будем прикручивать репозитории и CI к этому делу, а потом…
Сложно, но можно. Основная проблема, как мне кажется, будет с образами. Так что если планируете где-то в бункере поднимать свой докер — запаситесь ещё и docker registry.
Не знаю как там с людьми, но про тех. проблемы я писал ещё в середине (прошлого) года, и ещё тогда отметил про
Радует что докер выдал пинка всей этой индустрии, печалит что похоже докеру придётся умереть, освободить место для более открытых к изменениям технологий…
В чём проблема с такими ссылками? И докер-композ и кубернетес спокойно работают с именами контейнеров. Запихивая их через ENV вы добавляете ещё одно место где может накосячить человек (человеческий фактор). Лишнее нарушение изоляции. В ENV вообще ничего ценного быть не должно.
Конфиги как раз таки должы пробрасываться снаружи. Делается это для того чтобы эти конфиги не появились в ваших репозиториях (гит, докер). Для разного окружения — разные конфиги, потому засунуть их все в докерфайл — создать место с неопределённостью в работе (какой конфиг сейчас подгружен, какие значения?). Простой способ (не рекомендую) через ENV, чуть сложнее — через секреты. Можно записывать в райнтайм, опять же, зависит от того для кого.
Volumes могут быть не только для связи контейнер-дев машина, но и для связи контейнер-контейнер.
Насколько я понял — ранчер сейчас сам переходит на кубернетес, так что скоро это будет одно и тоже, просто у ранчера будет морда поудобней.
(орфография и пунктуация — авторская)
Весь смысл использовать докер — переносимость окружения. Если вы не знаете как это всё запустить на проде — ценность статьи стремится к нулю.
Я не просто так это пишу, это серьёзная проблема. Как выкатить это всё с дева на тест/прод, как дать понять программе что она теперь на проде (и не надо выводить отладочную информацию), как монтировать статику из php контейнера в apache/nginx контейнеры минуя хост (какой хост на проде-то?), как это всё масштабировать и т.д. и т.п.
Если мы не знаем как это всё будет запущено на проде — как тестировать? Как убедиться что на проде наш код не превратится в тыкву?
Тут разговор не о том что что-то заменяет что-то другое, тут скорее про «я написал конфиг и теперь по этому конфигу могу создать себе окружение». На примере тех же модулей — чтобы обновить в докере версию пхп — надо всего лишь поменять циферку в FROM, пакеты будут собираться точно также как и в предыдущей версии. Так что я просто запущу сборку и пойду чайку выпью…
Смысл как раз в том чтобы не париться сколько у вас систем и каких. Вы один раз всё это настраиваете, а потом просто жмёте кнопки по необходимости.
Вопрос только в том что это уже слабо связано с докером. Для меня лично докер это способ упаковать кучку файлов в некий более-менее стандартный объект, который потом можно закинуть на сервер со словами «ну запусти это с таким-то конфигом и в таком-то количестве».
простых смертныхмаленькие команды, про локальные среды разработки. Буду ждать новостей!О каких пару недель идёт речь?
Ну а по сути: я очень надеюсь что вся эта движуха с контейнеризацией не потухнет вместе с докером. Может быть есть какие-то ссылки на проекты, скажем гитхаб хотя бы, которые можно было бы отслеживать?
Строго говоря PSR — рекомендации, не стандарты.
Говорить «стандарты PSR» тоже самое что говорить «стандарты рекомендации по стандарту PHP».