Вечно живующие стенды в gitlab environments

Если мы используем интеграцию k8s и gitlab-ci, то мы можем создавать окружения в gitlab а следовательно и удалять их из k8s через их удаление в gitlab.

Примерно так может выглядить конфиг деплоя некоторого микросервиса:

deploy:
  stage: deploy
  needs: ["some_dependencies"]
  extends: [".some_deploy_job"]
  variables:
    VAR: some_var
  environment:
    name: '<you_stage_name>/${CI_COMMIT_REF_NAME}-${CI_PROJECT_NAME}'
    kubernetes: { namespace: "$KUBE_NAMESPACE" }
    url: "https://${CI_PROJECT_NAME}-${CI_COMMIT_REF_SLUG}.domain"
    deployment_tier: staging
    on_stop: "uninstall_job"
    auto_stop_in: 3 days
  rules:
    - { when: on_success, if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH' }
    - { when: manual }

Давайте разберем, что тут есть интересного.

1. environment. Вот тут начинаются параметры для создание нашего окружения в gitlab.
2. name. Собственно имя нашего окружения. Стоит сказать, что если использовать конструкцию <name>/<name>, все то, что идет до «/» будет в gitlab-ci в виде директории. Обычно выбирается имя контура, например «stage» или «prod». Дабы названия окружений в директории контура не пересекались, они формируются динамически из переменных gitlab-ci.
3. url. Этот УРЛ проекта, обычно должен совпадать с урл ингресса. Например в МР мы можем нажать кнопку «View app» и перейти по этому адреса на наше приложение.
4. deployment_tier. Переменная определенная гитлабом и принимающая несколько значений типа «staging», «production». Довольно удобно с помощью нее унифицировать CD часть, строя логику деплоя на этом.
5. on_stop. Говорит нам о том, что мы будет использовать отдельный джоб для остановки окружения (о нем чуть ниже).
6. auto_stop_in. Задает то, сколько наше окружение будет жить времени, прежде чем gitlab удалит его автоматически.

Мы разбрали пример возможного конфига деплоя. Теперь давайте разберем пример возможного конфига остановки окружения.

uninstall_job:
  stage: uninstall
  extends: [".some_extends_job"]
  rules:
    - { when: manual }

Тут все предельно просто на первый взгял. Мы расширяем некую джобу для удаления окружения. В правилах видим, что хотим удалить окружения только руками. И как раз в этом кроется подвох.

Такой конфиг все равно автоматически удалит ваше окружение через 3 дня из последнего pipline.

Чтобы окружение жило вечно, например это актуально для master|release|develop веток. Нам нужно использовать такую конструкцию

rules:
  - { when: never, if: 'CI_COMMIT_REF_SLUG == <branch_name>' }
  - { when: manual }

Только с использованием «never» в правилах, мы гарантируем, что указанные нами ветки и их окружения соответственно будут жить. Все что попадает под «manual» будет автоматически удаляться gitlab из последнего комита после истечения заданного в auto_stop_in периода.

• LinkedIn
• Телеграмм канал сайта
• GitHub