@Markusam

Как деплоить php приложение вместе с docker?

Помогите разобраться в вопросе деплоя php приложения которое работает в dockere. Есть например php приложение, есть его код в каком нибудь version control system, приложение имеет n инстансов, которые могут размещаться на разных серверах. Имеется какой-то свой docker image в котором устанавливается php-fpm определенной версии, различные php extension необходимые для функционирование приложения. И если мы хотим настроить автодеплой при помощи какого либо CI\CD tools(Jenkins, Gitlab CI\CD etc), правильно ли я понимаю алгоритм и процесс как это должно происходить?

В нашем CI\CD pipeline, который сперва делает checkout нужной нам ветки из VCS, далее мы билдим контейнер с php(код php в контейнер попадает путем COPY команды), далее выполняем composer install(так как vendor папку не храним в VCS), далее запускаем тесты\анализаторы кода и тд, если проверки прошли успешно делаем docker push в какой либо registry(docker, gitlab etc), правильно ли понимаю что в registry пушим образ в котором кроме самого php-fpm и его extension, должен присутствовать код приложения (с vendor и тд)? Далее на целевых серверах делаем docker pull только что созданного образа и docker run.
  • Вопрос задан
  • 274 просмотра
Пригласить эксперта
Ответы на вопрос 2
Vamp
@Vamp
Это типичный вариант развёртывания приложения в докере. Единственный его минус - некоторое время даунтайма между моментом когда опустился старый контейнер и поднялся новый. Для решения этой проблемы есть разные техники. Например, blue-green deployment. Это когда есть два контейнера, условно называемые green и blue. И трафик льётся только на один. Скажем, на green. В момент деплоя обновляется blue контейнер и после того как он полностью будет готов - переключаем трафик на blue. В следующий раз деплой начнётся с обновления green.

Переключение трафика делается разными способами. Самый безопасный - переписать конфиг nginx и релоаднуть его. Или менее безопасный, зато без необходимости править конфиг, - добавить оба конейнера в одну upstream группу и опустить green контейнер после обновления blue.

Довольно муторное дело. Но в оркестраторах типа openshift и kubernetes такой деплоймент процесс уже встроен из коробки. Но вот сами оркестраторы довольно тяжелая штука. Для них нужен отдельный выделенный человек, который будет заниматься только ими. Так что я советую начинать присматриваться к оркестраторам только когда количество серваков перевалит за 50. С меньшим количеством это просто нерентабельно.

Другой вариант развёртывания - контейнер с пхп поднят постоянно, но код проекта монтируется в контейнер через volume. Далее ci джоба по sftp заливает новый код в соседнюю папку и переключает симлинк. Симлинк переключается атомарно и контейнер сразу начинает работать с новым кодом. Ничего больше делать не надо. Я рекомендую такой подход когда на проекте менее 50 серверов.
Ответ написан
@vitaly_il1
DevOps Consulting
В целом все правильно.
Насчет деплоя - есть нюансы
- как CD pipeline знает адреса серверов? В современном "облачном" окружении они часто меняются, нужен какой-то метод для их динамического получения
- как обеспечить бесперебойную работу приложения во время деплоя?

В облаках (AWS/GCP/ наверно и Yandex) есть managed services, которые сами умеют решать эти и другие (autoscaling) проблемы. В AWS это ECS, Elastic Beanstalk, AWS App Runner, managed K8S.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы