Непрерывная интеграция и развертывание на примере GitLab CI + Docker + Swarm

Непрерывная интеграция и развертывание на примере GitLab CI + Docker + Swarm.

Общая информация

ОС — ubuntu server 16.04.4 LTS

git.itc-life.ru — запущен на внешнем сервере

gitlab runner запущен в локальной сети через докер контейнер на хосте 192.168.88.10

docker swarm manager — 192.168.88.250. Доменное имя manager.swarm.itc-life.ru. При пинге manager.swarm.itc-life.ru получаем адресс 192.168.88.250

Шаг 1. Подключаем docker runnet к gitlab
Конфиг запуска докер раннера в докере. Смотрим тут
Шаг 2. Создание ssl сертификата для взаимодействия со swarm и создание возможности деплоя в swarm

Все это делаем на ноде, которая будет у нас manager. Предполагается что вы уже сделали

Обратите внимание на —advertise-addr 192.168.88.250 — по нему будет доступен api для деплоя.
В рабочей Swarm-среде необходимо защищенное соединение между GitLab Runner и сервисом Docker, запущенном на сервере Manager.

Для этого необходимо использовать единый сертификационный центр для клиента (GitLab Runner) и сервиса Docker (Manager). После создания сертификата и ключа для клиента, их можно использовать для удаленного подключения к сервису Docker и выполнения различных операций. Следует быть максимально осторожными с хранением клиентских сертификатов и ключей, поскольку они дают полное управление надо сервисом Docker.
Итак приступим к генерации ключей.

Для начала нужно создать приватный и публичный RSA-ключ для CA (потребуется придумать кодовое слово длиной не меньше 4 символов):

Придумываем пароль — мин символа.
Идем далее.
Приступим к созданию локального сертификационного центра. Будут запрошены данные связанные с идентификацией центра. На этапе ввода полного квалифицированного доменного имени (FQDN) требуется ввести доменное имя хоста, по которому доступен сервер manager.swarm.itc-life.ru. Важно чтобы он был доступен по доменному имени внутри той сети, из которой gitlab runnet будет совершать дествия по разворачиванию приложений. Для этого можете поднять свой локальный dns сервер или прописать глобально

в поле где запросят FQDN вводим

Или можем ввести ip адресс

Теперь создадим приватный ключ для сервера:

Теперь, когда у нас есть сертификационный центр мы можем создать запрос на подпись SSL сертификата (CSR). Поле CN (Common Name) должно совпадать с использованным на предыдущем шаге значением FQDN:

или

Дополнительно требуется указать IP-адрес сервера Manager (машина, в которой мы сейчас работаем):

Создадим подписанный ключ для сервера:

Теперь создадим клиентский сертификат и ключ.

Удалим запросы на создание ключей

Применим права

Настроим докер на manager node на работу с ключами

Теперь создадим новый конфигурационный файл(отредактируем) и запишем следующий текст, определяющим использование протокола TLS для доступа к сервису Docker, а также расположение серверного ключа и сертификата:

По-умолчанию доступ к сервису Docker имеет только пользователь-владелец процесса. Для выполнения операций по развертыванию приложения с удаленного хоста, нам необходимо разрешить подключение извне, при этом использовать TLS-протокол. Мы уже получили необходимые сертификаты и ключи, теперь осталось настроить Docker для работы с ними.

Мы создадим отдельный конфигурационный файл явно прописывающий хосты, по которым будет доступен Docker, поэтому для начала нам нужно удалить стандартный параметр -H, прописывающий хост. Для этого создадим новую директорию docker.service.d, в которой переопределим параметры запуска сервиса:

Вставляем туда следующее содержимое.

Рестартуем докер на manager ноде

Сейчас у нас есть всё необходимое для настройки защищенного доступа между GitLab Runner и рабочей Swarm-средой.

Для добавления нод worker в swarm нам необходимо

Токен берем на ноде manager

Настройка секретных переменных в GitLab CI
Мы не будем хранить данные клиентских ключей на машине Runner из соображений безопасности. Для таких задач в GitLab CI реализована функция секретных переменных среды.

Заходим в наш проект

Нам необходимо добавить и сохранить три переменные со следующими названиями и значениями файлов, которые мы создали на предыдущем шаге:


переменная TLSCACERT >> cat ca.pem;
переменная TLSCERT >> cat cert.pem;
переменная TLSKEY >> cat key.pem.
переменная CI_REGISTRY_USER >> пользователь gitlab
переменная CI_REGISTRY_PASSWORD >> пароль пользователя gitlab
переменная CI_REGISTRY >> registry-gitlab.itc-life.ru:4567

Шаг 3.Подключение Docker Registry в GitLab
gitlab у меня запущен в докер. Отредактируем файл настроек

И перенастроим

так же сделаем жизни время токена авторизации для регистри 60 минут — чтобы пушить большие образы. Заходим в админку в настройки.

или просто рестрартанем докер c gitlab.

Шаг 4.Создание приложения

Создадим тестовый проект

т.е. проект в группе itc-life с именем itc-deploy.
Проект будет представлять собой простой nginx — proxy. Далее склонируем репу.

Создадим файл из которго мы будем делать деплой дальше

блок services включает в себя описание всех создаваемых сервисов;
в каждом сервисе есть раздел image, который определяет используемый образ для создания контейнеров на его основе. Подобный формат записи позволяет получать образы с хранилища, доступного по адресу registry-gitlab.itc-life.ru:4567. Последний аргумент ${CI_COMMIT_SHA} — переменная окружения, связанная с значением хеша текущего коммита, которую мы используем для различия сборок друг от друга в данном руководстве.
В секции placement мы указали чтобы будем запускать его на manager.

Далее создадим nginx докер из которого будем делать сборку

Save and exit

Здесь я просто создам файлик c проксирование на kibana — для примера

Управление GitLab CI осуществляется через файл конфигурации:

Пробуем

Теперь, если на предыдущих шагах не было совершенно ошибки произойдет “пуш” в наш репозиторий GitLab, пройдут все тесты и сборка образов Docker, а затем развертывание в Docker Swarm.

Для отслеживания процессов перейдем в GitLab в раздел Pipelines и откроем последний:

Если ваш результат отличается от приведенного, перейдите в раздел Jobs и посмотрите логи по неудавшейся операции, часто это бывают опечатки или неверные адреса серверов.

Перейдем в раздел Environments:

Здесь происходит управление развернутыми средами для различных целей. Сейчас мы используем только среду master, но это не мешает вам настроить их под свои процессы.

Если было произведено уже несколько коммитов в одну среду, можно использовать функцию откатывания на предыдущую версию — для этого раскройте среду master, нажатием на название среды:

Для отката на предыдущую версию достаточно нажать кнопку Rollback, которая запустит стадию deploy для выбранного коммита.

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

Готово

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

 

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.