Файлы, упомянутые в главе
- .gitlab-ci.yml
После того, как мы разобрались, как делать сборку и деплой «вручную», пора заняться автоматизацией.
Для этого предлагается простой рабочий процесс, который мы называем fast and furious. Он позволит осуществлять быструю доставку изменений в production и содержать два окружения: production и staging.
Начнем с того, что добавим сборку в CI с помощью .gitlab-ci.yml, который находится в корне проекта, и опишем там заготовки для всех стадий и общий код, обеспечивающий работу werf:
before_script:
- type multiwerf && source <(multiwerf use 1.1 stable)
- type werf && source <(werf ci-env gitlab --verbose)
Build:
stage: build
script:
- echo "todo build"
tags:
- werf
Deploy to staging:
script:
- echo "todo deploy to staging"
environment:
name: staging
url: http://staging.mydomain.io
only:
- merge_requests
when: manual
Deploy to production:
script:
- echo "todo deploy to production"
environment:
name: production
url: http://mydomain.io
only:
- master
Сборка в GitLab CI
Укажем в стадии сборки уже знакомую команду:
Build:
stage: build
script:
- werf build-and-publish
Теперь при коммите кода в GitLab будет происходить сборка:
Деплой в GitLab CI
Опишем деплой приложения в Kubernetes. Деплой будет осуществляться в два окружения: staging и production.
Выкат на два стенда отличается только параметрами, поэтому воспользуемся шаблонами. Начнем с базового деплоя, который потом будем кастомизировать под стенды:
.base_deploy: &base_deploy
stage: deploy
script:
- werf deploy
dependencies:
- Build
tags:
- werf
В результате мы можем делать деплой, например, на staging с использованием базового шаблона:
Deploy to staging:
extends: .base_deploy
environment:
name: staging
url: http://staging.mydomain.io
only:
- merge_requests
when: manual
Аналогичным образом — настраиваем production-окружение.
После описания стадий выката при создании Merge Request будет доступна кнопка «Deploy» для Staging контура:
Посмотреть статус выполнения пайплайна можно в интерфейсе GitLab (CI / CD → Pipelines):
Очистка образов
При активной разработке в скором времени образы начнут занимать все больше и больше места в нашем registry. Если ничего не предпринять, то registry может разрастись до неприличных размеров. Для решения этой проблемы в werf реализован эффективный многоуровневый алгоритм очистки образов.
Автоматическая очистка реестра контейнеров в werf работает по определенным правилам: политикам очистки. Эти политики определяют, какие образы можно удалять, а какие — нет.
Существуют 3 основные политики очистки:
По веткам
werf удаляет образ из реестра в случае отсутствия в Git-репозитории соответствующей ветки. Образ никогда не удаляется, пока существует соответствующая ветка в Git-репозитории.
По коммитам
werf удаляет образ из реестра в случае отсутствия в Git-репозитории соответствующего коммита. Для остальных образов применяется следующая политика:
Оставлять образы в registry не старше указанного количества дней с момента их публикации или же оставлять в registry не более, чем указанное количество образов.
По тегам
werf удаляет образ из registry в случае отсутствия в Git-репозитории соответствующего тега. Для остальных образов применяется политика, аналогичная случаю с коммитами, что описан выше.
При этом из registry никогда не удаляются образы, пока в кластере Kubernetes существуют объекты, использующие их (например, все значения image в Deployment’ах). Другими словами, если вы запустили что-то в кластере Kubernetes, то используемые образы ни при каких условиях не будут удалены. Подробнее об очистке можно прочитать здесь.
Чтобы автоматизировать очистку, добавим новую стадию cleanup в gitlab-ci.yml:
Cleanup:
stage: cleanup
script:
- type multiwerf && source <(multiwerf use 1.1 stable)
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
- werf cleanup --stages-storage :local
only:
- schedules
После этого добавим новую задачу в планировщик, чтобы GitLab автоматически запускал cleanup (раздел CI/CD → Schedules):
В настройках указываем необходимое нам время запуска и ветку. Например, 4 утра:
После этого каждый день в 4 утра будет запускаться автоматическая очистка образов.