Как деплоить Laravel + Vue приложение в Docker?

Question

[Сергей Соколов]

Нет пока системного понимания правильного devops'инга, всё на коленке и не вовремя. Книгу "Docker in Practice" (2nd edition) только что скачал и полистал. Посему быстрый вопрос тем, у кого лыжи на ходу.

Веб-приложение на Laravel и с фронтом на VueJS, который надо билдить webpack'ом. Завернул всё в контейнеры:

• Redis
  
• MySQL
  
• php-fpm
  
• nginx
  

и вспомогательные

1. git для git pull origin master
   
2. Composer для composer update
   
3. NodeJS для npm run build
   
4. phpMyAdmin
   
5. Certbot для обновления сертификатов Let's Encrypt

Файлы в docker volume'ах. Приложение управляется через docker-compose.

Всё работает, но после внесения дополнений в репо, приходится ребилдить webpack, возможно, обновлять composer'ом пакеты прямо на живом.

Есть смутные подозрения, что это не так должно делаться, не повторять лишний раз на prod сервере «билд» composer'а b webpack'а — а, возможно, надо выкатывать уже готовые Docker-образы, где все сбилдено заранее и проверено тестами. И на продакшене просто производить подмену контейнеров, или переключать стрелку nginx'а или фронтального (дополнительного, сейчас его нет) load-balancer.

Если вам понятна ситуация и очевиден ответ, объясните, пожалуйста, как правильно поступить, не сильно усложняя процесс относительно нынешнего.

Answer 1

[Владимир Куц]

Всё работает, но после внесения дополнений в репо, приходится ребилдить webpack, возможно, обновлять composer'ом пакеты прямо на живом

Есть смутные подозрения, что это не так должно делаться, а, возможно, надо выкатывать уже готовые Docker-образы, где все сбилдено

А вы что - данные в докер-контейнерах храните?
Обычный кейс к примеру для сборки фронта - изменили что-то в репо - сработал хук, который запускает автодеплой.
Автодеплой принимает изменения из репа и запускает контейнер с нодой или чего у вас там, который монтирует в себя директорию с исходниками и делает билд проекта. После успешного билда контейнер с нодой завершает работу, и скрипт автодеплоя дергает далее контейнер с нгинксом для применения изменений.
Вот собственно все.
Образы используются сбилденные один раз. Как правило во время автодеплоя ничего дополнительно в них не вносится.

Comments

[Сергей Соколов]

Данные в docker volume'ах: www_data, mysql_data, letsencrypt.
Сомнение вызывает сам процесс «билда» на прод-коробочке. Тот же composer бывает жаден до памяти сверх меры.

Вроде бы лишние действия происходят: и composer install / update, и npm run build уже делались и на dev и на staging. Так может дальше просто передавать замороженные-проверенные образы/файлы?

[Сергей Соколов]

обновление версий софта (например, PHP) тоже выполнять-повторять на prod независимо от dev/staging, просто получив из git новые версии Dockerfile / docker-compose.yml ?

Или, убедившись, что всё работает на dev, делать docker export и тащить на prod и разворачивать там?

[Дмитрий]

Билдить на тестовом окружении, проверять. Если тесты прошли - пушить новые контейнеры в приватный репо.
Прод нацелить на приватный репо, на проде тупо сделать pull для обновления контейнеров и up -d.

[Владимир Куц]

Сергей Соколов, Обычно процесс деплоя поставлен так, что сначала это все отрабатывает на тестовом инстансе. И прогоняются автотесты. Если автотесты прошли успешно - то запускается деплой на проде. Образы что на тесте, что на проде - одинаковые (они вначале билдятся с нужными параметрами)

Answer 2

[zohan1993]

1. Переезжаем на Docker swarm с одной нодой, появиться возможность "rolling updates" + появиться возможность быстрого маштабирования до N нод, для надежности или при разрастании проекта.
2. На деплой сервере делаем всю работу, обновляем код/зависимости, ребилдим webpack, собираем все в докер образ, если нужно тестим, заливаем а свой докер регистри.
3. На prod сервере просто обновляем сервис (обновляем версию image), Docker swarm разрулит обновление без простоя.

Comments

[Сергей Соколов]

Спасибо, это то, что нужно, пожалуй!
Если не Swarm а Kubernetes, а точнее MiniKube – в маленьком же есть аналогия Rolling updates?

[zohan1993]

Minikube позволяет запускать одно-нодовый Kubernetes кластер внутри виртуальной машины.
Rolling updates будут работать.
Эта схема подходит только для тестов.