TeamCity, Docker и два бранча!

TeamCity, Docker и два бранча!

Для многих контейнеризация стала стандартом распространения сервисов. TeamCity же один из лучших инструментов для организации CI\CD. Что же, давайте сольем все в одну емкость и получим прекрасный коктейль, который будет помогать и радовать нас. По пути разберемся, как использовать параметры и шаблоны конфигураций. Для реализации данных сценариев я буду использовать проект движка блога (вы сейчас его читаете). Что мы имеем и что хотим в итоге получить: сборка asp.net core проекта в docker образ, публикация образа в репозиторий, запуск сценария обновления на удаленном сервере. Опционально можно так же добавить проставление тега на последний коммит обработанных изменений. На уровне "Root project" добавляем проект:

Стартовая страница TeamCity

В репозитории имеется две ветки - master и develop, давайте сделаем публикацию develop на тестовый домашний сервер. Позже добавим публикацию master на production сервер. Настроим как первый источник ветку develop. В настройках проекта раздел "Version Control Settings":

Настройка контроля версий проекта

Теперь TeamCity мониторит все изменения ветки develop и можно настроить тригер для запуска всего цикла обработки на изменения кода. Так же можно указать более сложные правила для срабатывания тригера, тут есть широкий вариант настроек. Например, можно указать маску директории и тригер будет срабатывать только если изменения были в файлах этой директории.

Триггеры проекта

Для более простого понимания устройства TeamCity: все проекты — это дерево с общим корнем в виде "Root project" и дочерние проекты, которые наследуют все параметры у родителей. Таким образом можно описывать в родительских проектах общие параметры конфигурации и расширять конфигурацию собственными параметрами в дочерних проектах. Каждый проект состоит из конфигураций, от одной и более. Конфигурация состоит из build step’ов, которые описывают действия и выстраиваются в определенный порядок – цепочка действий, которая приводит к результату конфигурации. Создадим первый build step для построения docker образа проекта:

Docker build step

После получения образа, нам необходимо его опубликовать в репозитории. Для этого нам необходимо залогиниться в нем, добавим новый build step:

Docker login step

Внимательный читатель обратит внимание, что указаны переменные конфигурации (%dockerLogin% и %dockerPassword%), а мы их еще не добавляли. Давайте же сделаем это. Так, как я уже описывал, TeamCity – дерево, и мы можем добавлять параметры конфигурации, которые будут доступны для всех дочерних уровней от корневого. Если у вас используется какой-то конкретный аккаунт для проекта, то можно указать его в параметрах проекта, если же параметры будут общими и для других проектов, то можем их указать на уровне "Root project" и они будут доступны везде.

TeamCity добавление параметра

Помечая параметры как hidden + password мы обеспечиваем защиту и скрытие отображения значений этих параметров в логах при билде проекта. После того как мы залогинились, мы можем публиковать наш образ, для этого добавим еще один build step:

TeamCity docker push

И остается финальный build step, который будет запускать цикл обновления нашего сервиса на удаленном сервере. Путей решения этого вопроса просто уйма, я же буду запускать скрипт на сервере через SSH:

TeamCity ssh exec

Готово! Теперь мы получили полностью готовый цикл, который будет обновлять сервис при изменениях в ветке develop. "Хорошо, для master ветки копируем и все работает, все понятно, мы читать дальше не будем" – так могли подумать вы...  и это может быть нормальный вариант. Но я предложу чуточку шагнуть дальше и создать шаблон конфигурации. Шаблон конфигурации используется, если у вас есть разные конфигурации по параметрам, но одинаковые по сути. И редактирование множества конфигураций сводится к редактированию шаблона. К примеру, у вас поменялся сценарий публикации приложения, необходимо добавить еще один build step, но если конфигурации копировались отдельно, то отдельно придется и настраивать дополнительный шаг везде. Шаблон же позволяет сделать это в одном месте, конфигурация унаследует шаблон, наполняя его только своими параметрами.

Для того, чтоб добавить шаблон у нас сейчас есть два варианта: сгенерировать шаблон из конфигурации develop и потом только выделить параметры, либо создать все с нуля и привязать к конфигурациям. Я сгенерирую шаблон и вычленю наши ключевые конфигурации в переменные:

TeamCity добавление параметра

Так же необходимо будет убрать из шаблона привязку к vcs root, да бы независимо настраивать это в конфигурациях. Теперь давайте добавим новую конфигурацию на основе шаблона для обновления сервиса на продакшн сервере из ветки master:

TeamCity добавление новой конфигурации на основе шаблона

Вот так мы можем настроить TeamCity для тесного содружества с docker и обновлять сервера без проблем. И да, опциональное проставление тегов на последний коммит в изменениях. Для чего нужно - если у вас идет очень много изменений, то да бы иметь историю версий прямо в гите, рекомендуется проставлять теги. Мы можем сделать это автоматически, для этого нам необходимо зайти в конфигурацию и в настройках Build Features добавить VCS labeling:

Добавление тега к коммиту

Теперь точно все, если у вас есть вопросы, замечания, велкам в комменты!

d2funlife | Даниил Павлов 2015-2024
Powered by ASP.NET Core 2.2, Entity Framework Core 2.2. Web + UI