Комментарии 47
Docker prodaction
По данному вопросу к сожалению я ничего сказать не могу
(орфография и пунктуация — авторская)
Весь смысл использовать докер — переносимость окружения. Если вы не знаете как это всё запустить на проде — ценность статьи стремится к нулю.
Я не просто так это пишу, это серьёзная проблема. Как выкатить это всё с дева на тест/прод, как дать понять программе что она теперь на проде (и не надо выводить отладочную информацию), как монтировать статику из php контейнера в apache/nginx контейнеры минуя хост (какой хост на проде-то?), как это всё масштабировать и т.д. и т.п.
Если мы не знаем как это всё будет запущено на проде — как тестировать? Как убедиться что на проде наш код не превратится в тыкву?
export ENV=production?
Пример: зависимости которые вытягиваются через npm(майтейнер что-то обновил/удалил/недоступен репозиторий). И вуаля — у вас не консистентный прод контейнер.
Если npm стягивает не ту версию, на которой разрабатывался проект, то выкинуть на свалку этот менеджер пакетов.
Несомненно, контейнер проходит все стадии QA. Но опять же, уберем npm — почему-то мне встречалось когда один и тот же пакет/билд фейлился каким-то образом при установке, чисто исходя из состояния звезд. rpm — может криво заехать из вашего нексуса и т.д.
Так и настраивая окружение для прода иначе, чем для дева вы рискуете, что оно будет работать иначе (это вообще ожидаемое поведение) или работать не будет вообще.
Для прода нужно чтобы не было статических ссылок на другие контейнеры в конфиг файлах nginx.conf и т.д.
Значение хоста и порта в инструкциях типа SetHandler "proxy:fcgi://php:9000" должны приходить из ENV: SetHandler "${PHP_UPSTREAM}"
Конфиги и все файлы из src должны "запекаться" в image при помощи ADD/COPY инструкций Dockerfile.
Процесс надо разделить на 2 этапа. Сначала билдим все images, потом в docker-compose.yml ссылаемся на эти собранные image.
docker build -t my-php:dev-SNAPSHOT ./php
image: my-php:dev-SNAPSHOTПрограмма должна работать без "volumes" в docker-compose (Их можно опционально добавлять при девепоменте, чтобы изменения в файлах хоста автоматически переносились в запущенный контейнер и не надо было билдить и запускать новый image каждый раз когда надо увидеть внесенные в код изменнения)
Далее надо использовать Rancher или Kubernetes чтобы это все дело оркестрировать на проде.
Программа должна работать без «volumes» в docker-compose (Их можно опционально добавлять при девепоменте, чтобы изменения в файлах хоста автоматически переносились в запущенный контейнер и не надо было билдить и запускать новый image каждый раз когда надо увидеть внесенные в код изменнения)
Но тогда получатся разные конфиги для prod и для dev, по моему это вообще не огонь, или альтернативного решения нет?
Конфиги и все файлы из src должны «запекаться» в image при помощи ADD/COPY инструкций Dockerfile.
А почему нельзя так оставить, обязательно в образ пихать?
По факту тоже самое получается, или в чем тонкость?
Docker отслеживает изменения docker-compose.yml или только изменения Dockerfile?
А почему нельзя так оставить, обязательно в образ пихать?
потому что намного удобнее дистрибьютить исходники вместе с инфраструктурой а не порознь.
По факту тоже самое получается, или в чем тонкость?
Ну вот когда доберетесь до продакшена и деплоев посерьезнее, тогда может быть разберетесь в тонкостях.
Docker отслеживает изменения docker-compose.yml или только изменения Dockerfile?
докер ничего не отслеживает. Если вы поменяли Dockerfile вы должны попросить его собрать новый образ. Если образ вдруг ничем не отличается (включая файлы которые вы копируете) он просто возьмет все слои из кэша.
Что до изменений в docker-compose — вы меняете не compose файлы а конфигурацию контейнера. Так что при запуске сервиса докер сравнит параметры контейнера и пересоздаст его если нужно (новый образ, другие параметры, новые переменные).
Но тогда получатся разные конфиги для prod и для dev, по моему это вообще не огонь, или альтернативного решения нет?
На проде вообще не будет docker-compose. Там будет окрестрация, так что конфиги все равно разные. Запекая файлы в образе мы гарантируем что все равно как этот контейнер запускается — он будет работать одинаково.
Фактически образ это исполняемый файл приложения. Исполняемый файл + переменные окружения = все что нужно для выполнения программы. Один из пунктов The Twelve-Factor App.
Для прода нужно чтобы не было статических ссылок на другие контейнеры в конфиг файлах 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 чтобы это все дело оркестрировать на проде.
Насколько я понял — ранчер сейчас сам переходит на кубернетес, так что скоро это будет одно и тоже, просто у ранчера будет морда поудобней.
Это инструмент для оркестрации контейнерами.
Всё нет времени разобраться с кубернейтс. Скажите, как вам этот инструмент? Намного сложней сварма при реальной эксплуатации? Хочется простоты и полного понимания того, что происходит с кластером. Поэтому изначально был выбран сварм. Но вижу много хороших отзывов о кубернейтс и всё не могу для себя решить, стоит ли присмотреться.
Я, например, как раз таки не работал со свармом, так как когда искал систему для развёртывания натыкался на кучу негатива в сторону сварма, потому прошёл мимо, в сторону кубернетес.
Скажем так — для простых и средних приложений можно заюзать просто докер или докер композ, для чего-то серьёзного — кубернетес. Он большой, сложный, огромная куча функционала, но для мелких проектов это overkill.
Получилась интересная вещь:
project/standartUrl — редиректил на проект.
project/jenkinsUrl — на Jenkins.
project/sonarqube — на Sonarqube.
Потратил почти неделю на проблему: Nginx редиректил на проект и нормально его загружал, но при редиректе на SonarQube и Jenkins(далее tools) упрямо не хотел загружать css и js файлы. Перепробовал все (сначало проблема была в сабдомене для tools). Решив проблему
prefix=/specifyUrl для Jenkins
Но нет.
Пришлось перебилдить images тулзов с указанием вшупмнтх сетингов.
с сабдоменом, загрузка всеравно не происходила хотя сss&js стучались куда надо.
Озарило меня случайно
Может кому поможет, или будет информативно)
Хотел научиться работать с Docker, но не разобрался, как делать без особого труда виртуальные домены.
Он слушает 80 порт и посылает трафик в нужный контейнер. Как он узнает в какой контейнер слать? — для этого в контейнере прописываете параметр VIRTUAL_HOST=domainname.local
С ним очень удобно и просто управлять многодоменностью
Тема интересная и новым людям моск иногда взрывает. Ибо репликаций одного контейнера может быть много, а может это и глобальный контейнер. И как это провернуть если система работает на 20 физических машинах например? В общем, неплохо было бы статью про то как сделать это сначала на compose, а потом безболезненно перенести на swarm.
Как же контейнерам подключать данные?
докер предоставляет вам абстракцию — волумы. Это что-то типа mount хостовой файловой системы. Причем как и в случае с mount, замаунтить можно хоть NFS хоть еще что.
Но вот какого-то простого how to нет.
маунтить волумы через NFS не сказать что распространенная задача. Как правило все же данные либо хранятся в пределах хоста, либо напрямую контейнер к ним доступа не имеет (s3 какой). Ну и еще вариант с репликацией по сети (базы данных).
- для волумов существуют плагины, коих великое множество под самые разные файловые системы. В случае с NFS это к примеру вот такой вот плагин.
А как же это сделать на docker swarm примеров мало.
потому что все (ну как все, те кто хотят удобненько и быстро) используют кубернетис. Он это умеет.
Ибо репликаций одного контейнера может быть много
потому контейнеры по возможности должны быть stateless. Такие контейнеры по определению проще скейлить.
Технология, позволяющая легко (во всех смыслах) разворачивать необходимое рабочее окружение.
GIT для инфраструктуры — самое простое определение.
Пакетный менеджер (по аналогии с composer и npm, только у docker — контейнеры),
docker-compose, как предполагает его название (compose — композиция), это инструмент для оркестрацией контейнерами. Задача docker-compose удобно описывать сервисы (контейнера) и их конфигурацию а так же запускать это дело. За скачку образов отвечает сам докер.
Для начала определимся со структурой проектов:
судя по приведенному листенингу вы не определились.
Параметр build используется для того, чтобы заставить compose пересоздавать контейнеры.
типичная путаница в терминах, не "контейнеры" а "образы". Лучше бы потратили один-два абзаца что бы хотя бы самому для себя разобрать в чем разница.
Схематично это выглядит таким образом:
nginx отправляет запрос на php-fpm, а по вашей диаграмме они типа независимо обрабатывают запросы.
Как видите необязательно знать принцип работы docker, чтобы успешно с ним работать.
а потом толпы лемингов атакуют чаты с глупыми вопросами, которые устраняются вечером чтения документации/чтения статей.
Ну вот когда доберетесь до продакшена и деплоев посерьезнее, тогда может быть разберетесь в тонкостях.
Вам лень поделиться? Или вы не знаете?
судя по приведенному листенингу вы не определились.
Эээ и в чем же неопределенность? Для каждого образа есть своя директория в нужными параметрами, в каждом примере структура сохраняется.
типичная путаница в терминах, не «контейнеры» а «образы». Лучше бы потратили один-два абзаца что бы хотя бы самому для себя разобрать в чем разница.
Это не путаница, я не посчитал нужным вводить очередной термин, т.к. когда начинаешь читать про докер, на тебя сразу вываливается контейнеры, volume, образы, слои и др. Не вижу смысла забивать статью терминологией, если по контексту это не особо важно и критично.
Повторюсь, что статья в большей степени для начинающих, чтобы не особо вдаваясь в термины docker научиться с ним работать (с docker-compose). Чтобы узнать что такое докер в конце статьи ссылки приложены.
nginx отправляет запрос на php-fpm, а по вашей диаграмме они типа независимо обрабатывают запросы.
Это блок-схема, а не диаграмма активности или коммуникации.
а потом толпы лемингов атакуют чаты с глупыми вопросами, которые устраняются вечером чтения документации/чтения статей.
А следующий абзац лень прочитать? «Да, конечно, для тонкой настройки или сложных задач, необходимо уже углубляться в дебри docker, но в средне-статистическом случае — это не нужно.»
Вам лень поделиться? Или вы не знаете?
Лень если честно. В прочем делиться мне не жалко — https://github.com/fesor/project-skeleton.
Это не путаница
то есть вы сознательно вводите людей в заблуждение, ну ок.
Повторюсь, что статья в большей степени для начинающих
Начинающие должны сразу понять что такое образы, что такое слои и т.д. Лучше бы опустили в статье "как настроить apache" или php-fpm и указали бы ссылку на отдельную статью.
научиться с ним работать (с docker-compose)
но они же не научатся, в этом и проблема.
но в средне-статистическом случае — это не нужно
То что docker-compose не является менеджером пакетов знать нужно. То что есть образы и контейнеры из них разворачиваются знать нужно. То что можно зайти в контейнер, сделать commit и получить новый образ, знать нужно (что бы проще было объяснять как работает Dockerfile, как организовать деплоймент и т.д. и людям было бы проще когда они столкнутся с проблемами).
Вот вам скрипт для деплоя проекта. Самый примитивный, без zero downtime и т.д. но так как даунтайм при деплое минимален меня такой вариант устраивает.
eval $(docker-machine env your-remote-host)
docker-compose pull
# скрипты которые необходимо запустить перед деплоем на новом образе
docker-compose run app bin/console doctrine:migrations:migrate -n
# подменяем контейнеры
docker-compose up -dНа проекта посерьезнее уже кубернетис за все отвечает, для которого масса готовых стратегий деплоя.
Чтобы в данной ситуации уничтожить контейнер, необходимо его остановить и удалить, но для начала, нужно узнать его ID:
Вместо этого можно использовать docker-compose stop для остановки всех контейнеров, либо docker-compose down для остановки и последующего удаления всех контейнеров.
Случилась правда у меня ошибка в контейнере апача
$ docker logs f7b8485a20b3
AH00534: httpd: Configuration error: No MPM loaded.
подключил модуль
LoadModule mpm_event_module modules/mod_mpm_event.so
заработал )
Для php мы добавили директиву build (подробнее), в которой указали директорию php, где хранится Dockerfile со следующим содержанием:
FROM php:7.2-apache
…
похоже всё же имели ввиду ввиду FROM php:7.2-fpm или я чего-то не понимаю?
httpd: Syntax error on line 66 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/lib/apache2/modules/mod_mpm_event.so into server: /usr/lib/apache2/modules/mod_mpm_event.so: cannot open shared object file: No such file or directory
хотя библиотека имеется:
docker exec -it app_php_1 ls /usr/lib/apache2/modules/mod_mpm_event.so
/usr/lib/apache2/modules/mod_mpm_event.so
apachectl -MСейчас уже не помню, может быть его просто подрубить нужно, как сделал я:
LoadModule mpm_event_module modules/mod_mpm_event.so
AH00534: httpd: Configuration error: No MPM loaded.
чтобы это проверить
LoadModule mpm_event_module modules/mod_mpm_event.so
И перезагрузите контейнер
#LoadModule mpm_event_module modules/mod_mpm_event.so
Если включаю:
docker logs php
httpd: Syntax error on line 66 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_mpm_event.so into server: /var/www/html/modules/mod_mpm_event.so: cannot open shared object file: No such file or directory
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6bcc8358705 httpd:2.4 «httpd-foreground» 31 seconds ago Restarting (1) 6 seconds ago php
d2defb0ed449 app_php «docker-php-entrypoi…» 31 seconds ago Up 26 seconds 80/tcp app_php_1
LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
Мне кажется у вас где-то есть расхождение с инструкцией. Попробуйте пройтись еще раз по статье и вашему проекту.
httpd: Syntax error on line 66 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/lib/apache2/modules/mod_mpm_event.so into server: /usr/lib/apache2/modules/mod_mpm_event.so: cannot open shared object file: No such file or directory
пробую все переделать с нуля…
Docker-compose: идеальное рабочее окружение