Позвольте использовать инструменты CI / CD для автоматизации создания образов Docker



Dockerizing Rails Applications Part 1: Writing Dockerfile
Давайте приступим к dockerizing Rails-приложениям и написанию оптимизированных Dockerfiles medium.com





Dockerizing Rails Applications Part 2: Automation
Упростите сборку докеров для ваших приложений Rails с помощью Makefiles medium.com



В частях 1 и 2 этой серии я объяснил, как Dockerize rails-приложениям, написав файлы Docker для приложений, и рассмотрел некоторые из лучших практик для создания образов Docker. Кроме того, я объяснил, как реализовать или создать простой, согласованный и легкий в использовании интерфейс для создания образов Docker для нескольких приложений.

В этом посте я расскажу, как мы можем интегрировать процесс создания образов Docker и их отправку в реестр докеров с помощью трех различных инструментов CI / CD: jenkins, travis и Github Actions.

Дженкинс

Jenkins - это бесплатный сервер автоматизации с открытым исходным кодом для автоматизации выполняемых задач, таких как развертывание программного обеспечения, компиляция исходного кода или выполнение модульных тестов. С Jenkins Pipelines легко определять задачи автоматизации. Я буду использовать эту функцию, чтобы определить конвейер, который можно использовать для создания образов Docker.

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

Следующий участок конвейера - этап этапов. Здесь мы определяем этапы, которые принадлежат конвейеру, и порядок, в котором эти этапы будут выполняться.

Для конвейера сборки Docker нам понадобятся следующие четыре этапа

  • Checkout SCM: конвейер извлекает репозиторий приложения из git и переключается на выбранную ветвь.
  • Предварительные требования для установки: выполняем команду make config, чтобы подготовить рабочий каталог для создания образа Docker.
  • Создайте образ: конвейер создает образ Docker для приложений, используя make build.
  • Отправка образа: make push отправляет созданные образы Docker в реестр Docker.

Участок post - это последний участок конвейера. Здесь мы запускаем действия, которые могут иметь место после выполнения этапов конвейера. Мы можем выполнить команду make clean, чтобы удалить все сгенерированные файлы или образы докеров.

Вот полная реализация предложенного конвейера Jenkins:

Указанный выше конвейер Jenkins необходимо запустить вручную. Если есть необходимость запустить этот конвейер с помощью push-уведомлений Github, вы можете выполнить действия, описанные в этом сообщении.

Трэвис К.И.

Travis CI - это размещенная служба непрерывной интеграции, используемая для выполнения заданий непрерывной интеграции для приложений, размещенных на GitHub. Услуга бесплатна для проектов с открытым исходным кодом. Давайте посмотрим, как мы можем заставить Travis CI создавать образы Docker всякий раз, когда новая фиксация отправляется в основную ветвь или создается запрос на вытягивание.

Интеграция Travis CI может быть достигнута просто путем включения travis ci в проекте GitHub и добавления файла Travis в корень репозитория проекта. Файл Travis - это файл YAML, содержащий все задачи, которые необходимо выполнить, а также конфигурации интеграции, например, когда задачи запускаются. Полное описание интерфейса Трэвиса можно найти на сайте Трэвиса здесь. Наш .travis.yml файл включает следующие разделы конфигурации:

  • Язык программирования и версия проекта.
  • Ветви Git, в которых включена задача. Мы ограничим это только для ветки master.
  • Действия, которые необходимо выполнить перед скриптом. Для этой задачи нам нужно убедиться, что travis ci worker может отправлять образы Docker в реестр Docker. Следовательно, нам нужно выполнить команду docker login перед построением и отправкой образа в реестр. К счастью, Travis предоставляет способ хранить защищенные переменные как переменные среды и передавать их ci workers - нет необходимости хранить пароли или какие-либо конфиденциальные данные в виде простого текста в .travis.yml. Мы можем добавить эти переменные среды со страницы конфигураций проекта, как показано:

В .travis.yml мы можем ссылаться на эти переменные среды, не рискуя раскрыть конфигурации секретов:

echo $DOCKER_TOKEN | docker login -u $DOCKER_NAMESPACE  --password-stdin

В следующем разделе travis.yml выполняются команды, которые фактически выполняют работу. Здесь мы собираемся использовать команду make release для создания и публикации образа Docker.

Последний раздел - это раздел уведомлений. Это необязательный шаг, но его полезно иметь. Это позволяет нам отслеживать статус задания - когда оно запускается, мы получаем уведомление Slack о статусе сборки.

Вот полная реализация .travis.yml, которая позволит достичь пунктов, описанных выше:

Секретное значение Slack можно сгенерировать с помощью следующей команды:

travis encrypt "${slack_room_token}" --add notifications.slack

Действия Github

GitHub Actions - это сервис, предлагаемый GitHub для автоматизации задач и заданий CI / CD. С помощью действий Github мы можем определить задачи CI / CD, которые будут выполняться при запуске события Github. Список поддерживаемых событий можно найти здесь.

Чтобы интегрировать задачу выпуска образа Docker в качестве действия Github, нам нужно написать рабочий процесс для нашей работы. Этот рабочий процесс представляет собой просто файл YAML, который хранится по следующему пути в (.github/workflows), корневом пути репозитория GitHub. Файл рабочего процесса содержит необходимую информацию для выполнения рабочего процесса и список действий, которые необходимо выполнить. GitHub предоставляет торговую площадку для действий, которые могут выполняться над рабочими процессами. С другой стороны, вы можете разработать собственное действие и опубликовать его на рынке, чтобы его могли использовать и другие.

Чтобы автоматизировать и интегрировать процесс создания образов докеров с помощью действий GitHub, я представлю два рабочих процесса.

Рабочий процесс первый

Первый рабочий процесс выполняется после того, как мы создаем пул-реквест для ветви master или если новая фиксация передается в ветвь master. Этот рабочий процесс будет выполнять только команду make build, чтобы убедиться, что наша сборка Docker с изображениями не повреждена (эти действия предназначены для демонстрационных целей и могут быть изменены в соответствии с потребностями).

Рабочий процесс начинается с определения, когда действия должны быть запущены, а затем перечисляются шаги, которые необходимо выполнить. Последний шаг - отправить уведомление Slack в зависимости от статуса задания.

Обратите внимание, что секрет SLACK_WEBHOOK_URL должен быть создан и добавлен в соответствующий репозиторий GitHub. Сделать это можно, выполнив эти шаги.

Второй рабочий процесс

Второй рабочий процесс выполняется только в том случае, если новый выпуск публикуется на GitHub. Он позаботится о создании образов докеров для этого выпуска и отправит их в реестр Docker.

Первое отличие этого рабочего процесса от первого - это триггерное событие. В первом он запускается при каждом нажатии на master или каждом PR в отношении основной ветви, но этот рабочий процесс запускается только в случае публикации нового выпуска на GitHub. Как уже упоминалось, push-события - не единственное событие, предоставляемое GitHub. Фактически, существует длинный список событий, которые могут использоваться рабочими процессами.

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

Тег образа Docker также извлекается из полезной нагрузки действия GitHub и передается в качестве Environment переменной команде make следующим образом: IMAGE_TAG=${{ github.ref}} make release.

Вот полная реализация второго рабочего процесса. Добавление этих файлов рабочего процесса в путь рабочего процесса Github автоматически активирует действия GitHub в соответствующем репозитории:

Заключение

Докеризация и автоматизация процесса создания образов Docker относительно просты. Чтобы полностью построить конвейер интеграции CI / CD для автоматизации процесса, выполните следующие действия:

  • Напишите Dockerfile dockerize приложение.
  • Используйте Makefiles, чтобы предоставить простые команды для создания образов докеров.
  • Используйте один или несколько инструментов CI / CD (Jenkins, Travis и Github Actions и т. Д.) Для автоматизации конвейера.