CI / CD для проекта laravel, как сделать его стабильным

Question

Я бы хотел использовать jenkins для моего проекта Laravel.

Я использую конвейер для этого.Как вы знаете, Laravel не нуждается в шаге сборки.Я также не использую тесты.Я просто хочу иметь stage('deploy'). При отправке в репозиторий хост jenkins получает уведомление, извлекает проект и запускает конвейер jenkins, находящийся в проекте laravel.Поскольку у меня хосты jenkins host и laravel api отличаются друг от друга, здесь я сталкиваюсь с проблемами.

Как я уже сказал, у меня нет стадий build и test.так что только deploy в pipeline.но чтобы запустить проект laravel, перед использованием jenkins у меня был скрипт bash, в котором было 10 строк кода.например, (changing permissions, making current user as my user, running composer install, running docker-compose and so on). Поскольку у меня есть другой хост для Laravel, у меня есть 2 варианта:

1) в stage('deploy') Я могу перенести файл build.sh с хоста jenkins на хост laravel api.а затем сделав ssh на хосте laravel api и запустив там этот файл.Что мне не нравится в этом, так это то, что если настройки прав доступа или другие вещи, которые у меня есть в этом файле build.sh, пойдут не так на полпути, что приведет мой проект в нежелательное состояние, и я даже не получу уведомление, и яу меня будет сломанный проект в производстве.

2) Я могу сделать все, что в stage('build') работает 'composer install and other stuff, после этого сделать из него dockerfile (включая папку поставщика), а затем после получения изображения(который также содержит поставщика), загружая этот образ докера в dockerhub, затем на этапе ('deploy') я могу уведомить об этом удаленный хост и передать файл сценария от jenkins на те удаленные хосты laravel, которые содержат код, который извлекает последний образот dockerhub и запустить его.таким образом, у меня не будет нежелательного состояния, поскольку это изображение уже содержит папку поставщика, оно уже получило разрешения и все такое.Проблема в том, что создание образа займет много жесткого диска.и представьте, что вы создаете образы для каждого нажатия на хранилище.

Что вы предлагаете мне сделать?

Answer 1

Стандартная практика - ваш вариант 2, чтобы создать новый образ для каждой сборки. Обычно в Docker вы вообще не копируете исходный код самостоятельно; Вы строите изображения и имеете дело только с этими изображениями. (Шаблон построения и образа Docker для разработки, а затем замена всего его содержимого на локальное дерево исходных кодов совсем не то, как Docker обычно используется в производственной среде.)

Вы должны убедиться, что вы присваиваете каждому изображению уникальный идентификатор, такой как метка времени сборки или какой-либо идентификатор подтверждения управления исходным кодом. Это почти все, что требуется для некоторых систем автоматизации более высокого уровня (например, Kubernetes), и это позволяет легко откатить поврежденную сборку.

В описанном вами рабочем процессе вы можете упаковать практически любые файлы в изображение и отправить их для запуска. Очень важно иметь какую-то фазу проверки, чтобы убедиться, что смущающая опечатка не приводит к изображению, которое никогда не запускается вообще. Под этим я подразумеваю ... написать тесты: -)