Конвейер Continuous Integration и Continuous Delivery или CI/CD-пайплайн представляет собой целую цепочку процессов. В нее последовательно включено несколько сервисов — Portainer, Jenkins, Docker Swarm, Ansible. Как это удалось осуществить на практике? В статье мы рассмотрим реализацию такой цепочки на проекте IT-команды Уральской Дирекции.
Как определяются цели?
Чтобы эффективно реализовать проект, первоначально нужно разобраться, чего ожидают от него заинтересованные стороны – бизнесмен-заказчик и IT-команда. Не секрет, что деловые люди стараются заработать как можно больше в максимально короткие сроки, поэтому ждут быстрого вывода готового продукта на рынок. Исполнители – это команда из двух разработчиков и одного админа, видят перед собой иные цели. У разработчиков на первом месте не финансы, а творческий подход, подтвержденный реальным результатом. Админ же, в свою очередь, стремится обеспечить качественный сервис, придерживаясь методологии DevOps в соответствии с принципами CI/CD (как заявлено в этом проекте). Вывод: поможет организация пайплайна, который охватит все этапы работы вплоть до запуска продукта для завершающего тестирования.
Командная работа началась с обсуждения выбора системной архитектуры. Определились на двух ее основных составляющих:
- бекэнд на Java (реализация с помощью фреймворка Spring Boot);
- фронтенд на NodeJS (с NGINX-сервером, который распределяет между приложением и инфраструктурными составляющими системы запросы) + ReactJS.
Техническая задача IT-команды на начальном этапе – подготовить оборудование для эффективного пайплайна CI/CD, поэтому конвейер будет выглядеть, как цепочка определенных операций:
публикация разработчика коммита в git →
тестирование git полученного коммита (наличие верного формата, сопоставимые стили оформления и т.д.) →
web-hook механизм сервера git задействует Jenkins, за тем последует скачивание исходников для запуска конвейера.
Здесь свой порядок действий:
компиляция →
тестирование исходников →
сборка очередного варианта Docker-образов →
их публикация в специальной системе Artifactory →
перезапуск полученного варианта продукта на сервере.
При неудачном обновлении всегда можно выполнить откат до предыдущей версии.
Описанное решение в виде цепочек последовательных действий подходит для веб-ориентированных приложений. Оно отличается простотой и легкостью, понятно каждому из исполнителей.
Об установке и базовых настройках на хост-системе
В ходе реализации поставленных задач IT-команда решила воспользоваться Ansible. Это позволило добиться автоматизации всего конвейера хост-системы по максимуму, ее качественного функционирования всего в три этапа.
Начальный — ssh HostKeyChecking. Нужен для проверки ssh-отпечатка удаленного конфигурируемого хоста. В этом режиме отключается авторизация с помощью пароля, поэтому предполагается несколько вариантов решений:
- в local cash добавляется ssh-отпечаток (например, в ansible.cfg дописать host_key_checking, чтобы отключить проверку полностью, либо выполнить определение специальной переменной окружения – для приостановления проверки).
- отключение HostKeyChecking.
Второй этап – Inventory. Предполагает описание тех хостов, конфигурациями которых нужно управлять. Для этого предлагается два формата – либо yml, либо ini. Выбрали формат yml.
Третий – Playbook. Из Inventory описывается декларативно итоговое состояние хостов в начальном формате (здесь yml) и полная настройка базовой системы, предполагающая создание пользователей, установку Docker.
Какие сервисы можно использовать?
Одним из полезных сервисов оказался Jenkins CI. Он необходим для деплоймента и Continuous Integration. Необходимо обратить внимание на ряд ключевых моментов:
- каждый образ получает свою метку-тег (очень помогает при откате неудавшегося приложения);
- таски-пайпланы – декларативные, скриптованые (на Groovy Script — задачи, в git — код с исходниками);
- в Docker-контейнере Jenkins запускает playbook-код Ansible, а на local-машине временно сохраняется пароль (файл для этой операции — initialJenkinsAdminPassword.txt).
Еще один нужный сервис – Portainer. Он отличается легким развертыванием и высокой производительностью. Но в нашем случае использовался Docker Compose, который по своим функциям и оркестрации подходит для 1 хоста. Так, сервисы запускались с помощью docker-compose.yml, но со своими особенностями.
1 особенность — отсутствие упоминаний о бекэнде и фронтенде.
2 особенность — есть на внешнюю сеть int-ссылка (здесь под внешними ресурсами понимают те, которые нигде не упоминаются).
Описываемая цепочка требовала рестарта сервисов, чтобы обновлялись варианты образов в репозитроии Docker – Artifactory. Такие функции уже встроены в Docker Swarm. Это и позволяет изменять отобранные образы. Рестарт автоматически запустится, если в репозитории будет новая версия продукта. В противном случае, продолжится выполнение прописанного сценария.
Для сохранности сетевой связанности компонентов Docker Swarm с сервером NGINX создали кластерную сеть-Overlay. В нее включены не только перечисленные сервисы, но и компоненты приложений.
Выводы
На первом этапе IT-команда исполнителей планировала добиться всех выгод от DevOps. Для этого требовалось организовать цепь операций по непрерывной доставке кода от git до сервера. В результате запущенного пайплайна и продуманных действий системная архитектура была реализована в течение двух недель.
Грамотно продумать и реализовать каждый этап CI/CD-пайплайна вам помогут здесь.