Как настроить Docker для deployment-а?

Question

[Evgeny Svirsky]

Всем привет.
Подскажите как настроить Docker для deployment-а.
Имеется - сервер на Linux - RedHat, репозиторий на github с PHP проектом на Symfony.
Хочу настроить деплоймент с помощью docker. Контейнеры - nginx, phpfpm, mysql, redis.
Поясните плз вкратце в 2х словах архитектуру. Что будет куда закидываться. Нужен ли дженкинс, или можно обойтись без него.
Ссылки с похожими кейсами приветствуются.

UPD:
Где хранить скрипты деплоймента? В папке самого проекта? Или лучше в отдельную репу поместить...
Как это всё работает? Опишите процесс словами схематично.

Спасибо!

Comments

[sirs]

что ж Вы то поиском ленитесь пользоваться? например тут Как подружить Docker nginx и PHP-FPM? и тут Docker — архитектурные вопросы о деплое и не тольно?

[Evgeny Svirsky]

Хочется более толкового развёрнутого ответа. По ссылкам вашим - не всё понятно. Может кто-то сможет расписать для конкретной задачи. Или какую правильную ссылку на готовый гайд...

[sirs]

Evgeny Svirsky: Это работает не так. Вы делаете что можете, а потом если что-то не получилось - приходите с конкретной проблемой, примером вашего кода, логами, ошибками и задаете конкретный вопрос.

[Evgeny Svirsky]

Я уже столько перебрал вариантов при развёртке на локали с помощью докера. У всех всё по разному. Кто-то пишет всё в одном конфиге docker-compose, кто-то выносит его за пределы основного конфига. Кто-то использует готовые image-ы, кто-то использует базовые... Кароче хрен пойми. Толи тут свободное поле для деятельности, то ли у каждого своё видение. Поэтому я вопрос задал про схематичность. Чтобы понять направление - куда лучше двигаться.

Answer 1

[Константин Грачев]

У меня следующая схема.
В репозитории проект в корне лежит Dockerfile, который умеет собирать как прод так и дев версию контейнера.
Для каждого сервиса отдельно в гите свои репозитории. Например у nginx в репе Dockerfile, в котором по сути одна команда - скопировать конфиг.
Redis у меня работает с конфигами по дефолту, так что для него репы нет.
Так же в каждой репе лежит конфиг для Drone, который при отправке коммитов запускает сборку, тестирование и последующий деплой на прод сервер.
Деплоем контейнеров на сервере у меня сейчас занимается Rancher. Но в ближайшее время планирую перейти на Docker Swarm.

Конфиги сборок лежат в гите, кроме параметров.
Параметры для Symfony я передаю через environment при старте контейнеров.
Параметры для сборки зашифрованы в .drone.sec файле. Но в версии 0.5 они будут лежать сразу на сервере.

Docker-compose для прода я не использую, через него поднимается окружение исключительно для дев версии.

Прокидывать папки с хостовой машины не рекомендуется, поэтому для персистентных данных нужно создавать volume и прокидывать их.

При данной схеме на сервер вообще не захожу. Сделал пуш, код протестировался и задеплоился.

Примеры моих конфигов: Dockerfile, drone.yml

Comments

[Evgeny Svirsky]

т.е. каждый пуш сопровождается деплоем на сервер?
А если тест не пройдёт? Деплоймент продолжится или нет?
А если вам нужно фикс внести мелкий и сейчас деплоить не нужно, так как пик нагрузок, но вы сделаете пуш и начнётся процесс. Я про то, что как по мне нужно разделять эти 2 процесса. Врядли они должны быть связаны.

[Константин Грачев]

В .drone.yml можно задать условия. К примеру как минимум на прод деплоится только мастер ветка.
Если тест не пройдёт билд завершится с ошибкой, до этапа деплоя он соответственно не дойдёт.
Деплой происходит без остановки работы сайта, не вижу причин не фиксить ошибки в "пик нагрузок".
При коммите можно в комментарий написать [skip ci], тогда дрон не запустит сборку.
Прочитайте про continuous Integration и continuous delivery.

[Evgeny Svirsky]

про CI и CD знаком. про "не вижу причин не фиксить ошибки в "пик нагрузок"." - всегда может что-то пойти не так, и тогда пользователи будут врядил довольны что не смогут воспользоваться сервисом, если вдруг (ну всякое бывает) что-то ляжет. Поэтому всё же деплоймент лучше делать когда нагрузки минимальны. Только если это не хот фикс. По поводу условий - в принципе да, это удобно, что можно пропустить деплой.

[Константин Грачев]

Нужно максимально покрывать код тестами, тогда что-то пойти не так не сможет.
Разрабатывать новые фичи нужно в отдельные ветки. Дрон будет тестировать каждый коммит, но не деплоить. Когда фича закончена, ветка мержится в мастер.
Если вы не уверены в своём коде, можете ветку слить в мастер когда нет пика нагрузок.

[ANtlord]

Как Вы чистите кэш после установки зависимостей для production?

[Константин Грачев]

ANtlord: о каком кеше речь?

[ANtlord]

У Вас в Dockerfile есть строка `composer install --no-scripts --no-interaction --no-autoloader --no-progress --prefer-dist`. --no-scripts означает, что не будет чистится кэш, не установятся ассеты. А --no-autoloader означает, что не будет сгенерирован autoload.php. В какой момент Вы это делаете?

[Константин Грачев]

ANtlord: при старте контейнера в docker-entrypoint.sh

[ANtlord]

Константин Грачев: Спасибо

Answer 2

[Евгений Власенко]

Ещё к вышесказанному можно перейти на GitLab и запускать скрипты развертывания как GitLab CI задачи. Также можно использовать GitLab Container Registry, но это выходит за скоуп вашего вопроса.