В этом руководстве рассмотрим вариант настройки непрерывной интеграции и развертывания Flask приложения на Docker Swarm через GitLab CI.
Сначала мы рассмотрим настройку рабочей среды, включая создание серверов для нодов Docker Swarm. Затем создадим простое приложение Flask с Redis и подготовим GitLab CI для непрерывной доставки.
Управление контейнерами и управление нагрузкой — нетривиальная тема и требует значительной подготовки, особенно если планируется самостоятельная настройка системы оркестрации (например, с помощью Kubernetes). Однако, существуют такие инструменты как Docker Swarm или Rancher, которые берут на себя управление контейнерами, внутренними сетями и распределение нагрузок и дают возможность развернуть масштабируемую систему на собственных серверах.
Кроме того, GitLab хорошо поддерживает Docker и позволяет подключать собственные системы хранения образов (GitLab Registry) в несколько простых шагов. А также отслеживать статус выполнения работ по проекту и управлять развернутыми версиями приложения, позволяя при необходимости откатиться на прошлую в один клик.
Перед началом необходимо удостовериться в выполнении следующих условий:
Официальное руководство по настройке HTTPS в GitLab.
Для настройки и запуска приложения в режиме Swarm нам понадобится 2 типа серверов — менеджер и подчиненный. Кроме того, дополнительно один сервер будет выделен под GitLab Runner для выполнения задачи сборки и запуска контейнеров.
Виртуальные сервера мы будем создавать на платформе Vscale, однако, если вы пользователь другого сервиса, например, DigitalOcean, то действия будут аналогичны изложенным далее.
Создадим три новых сервера из образа Docker:
Полученные IP-адреса мы будем использовать далее.
Примечание. Использование TLS и управление центром сертификации — тема, требующая значительной подготовки. Желательно ознакомиться с технологиями OpenSSL, x509 и TLS перед использованием их в реальных проектах.
На финальном этапе развертывания приложения в рабочей Swarm-среде необходимо защищенное соединение между GitLab Runner и сервисом Docker, запущенном на сервере Manager, что видно на схеме ниже:
Процесс развертывания приложения в рабочей среде.
Для этого необходимо использовать единый сертификационный центр для клиента (GitLab Runner) и сервиса Docker (Manager). После создания сертификата и ключа для клиента, их можно использовать для удаленного подключения к сервису Docker и выполнения различных операций. Следует быть максимально осторожными с хранением клиентских сертификатов и ключей, поскольку они дают полное управление надо сервисом Docker.
Подключимся по SSH к серверу Manager и обновим Docker, поскольку в дальнейшем нам потребуются дополнительные возможности, доступные в старшей версии Docker API. Добавим репозиторий от разработчиков Docker для получения последней версии:
Установим последнюю версию Docker:
Для проверки установки выполним команду:
Вывод команды может отличаться, главное, чтобы обе версии API клиента и сервера были больше 1.24:
Оставаясь в сервере Manager, приступим к созданию сертификационного центра (CA). Перейдем в новую директорию:
Для начала нужно создать приватный и публичный RSA-ключ для CA (потребуется придумать кодовое слово длиной не меньше 4 символов):
Приступим к созданию локального сертификационного центра. Будут запрошены данные связанные с идентификацией центра. На этапе ввода полного квалифицированного доменного имени (FQDN) требуется ввести доменное имя хоста, по которому доступен сервер Manager, но в целях примера (не используйте подобный метод в рабочих машинах!) используем слово manager для обозначения сервера:
Далее создадим приватный ключ для сервера:
Теперь у нас есть сертификационный центр и мы можем создать запрос на подпись SSL сертификата (CSR). Поле CN (Common Name) должно совпадать с использованным на предыдущем шаге значением FQDN:
Дополнительно требуется указать IP-адрес сервера Manager (машина, в которой мы сейчас работаем):
Создадим подписанный ключ для сервера:
Создадим клиентский ключ, который будем использовать для доступа к сервису Docker:
Создадим запрос на подпись и дополнительно укажем тип использования ключа — для авторизации:
Получим подписанный клиентский ключ:
Теперь можно удалить файлы запросов:
В итоге, мы получили следующие файлы:
Оставим терминал с сессией на сервере Manager открытым, поскольку он понадобится нам далее.
Сейчас у нас есть всё необходимое для настройки защищенного доступа между GitLab Runner и рабочей Swarm-средой.
Мы не будем хранить данные клиентских ключей на машине Runner из соображений безопасности. Для таких задач в GitLab CI реализована функция секретных переменных среды.
Создадим новый проект в GitLab:
После создания проекта перейдем в настройки CI / CD:
Откроем область секретных переменных (Secret variables) и будем работать с ней:
Нам необходимо добавить и сохранить три переменные со следующими названиями и значениями файлов, которые мы создали на предыдущем шаге:
Вернёмся к терминалу с сессией на сервере Manager и выполним команду:
Скопируем это значение и добавим новую секретную переменную в GitLab:
Теперь по этому примеру добавим оставшиеся значения cert.pem и key.pem.
По-умолчанию доступ к сервису Docker имеет только пользователь-владелец процесса. Для выполнения операций по развертыванию приложения с удаленного хоста, нам необходимо разрешить подключение извне, при этом использовать TLS-протокол. Мы уже получили необходимые сертификаты и ключи, осталось настроить Docker для работы с ними.
Мы создадим отдельный конфигурационный файл явно прописывающий хосты, по которым будет доступен Docker, поэтому для начала нам нужно удалить стандартный параметр -H, прописывающий хост. Для этого создадим новую директорию docker.service.d, в которой переопределим параметры запуска сервиса:
Создадим файл настройки:
Добавим следующую секцию, для параметра ExecStart требуется сначала очистить предыдущие значения и затем указать новые:
Создадим новый конфигурационный файл:
И запишем следующий текст, определяющим использование протокола TLS для доступа к сервису Docker, а также расположение серверного ключа и сертификата:
Для вступления изменений в силу, перезапустим сервис Docker:
Теперь мы можем подключиться по TLS к нашему сервису Docker по адресу
Для начала рекомендуем изучить материалы на тему режима Swarm, например, на официальном сайте Docker. Swarm — это кластер сервисов Docker, расположенных на различных физических или виртуальных машинах и ведущих себя как единое целое.
Распределение запросов между имеющимися сервисами Docker осуществляется по схеме ingress load balancing, суть которой в том, что любой запрос проходит через внутренний механизм балансировки, а затем перенаправляется на тот сервис, который в данный момент может обслужить запрос.
Масштабирование осуществляется за счет указания количества реплик внутренних сервисов, с которыми мы столкнемся позднее.
Мы активируем режим Docker Swarm на сервере Manager, на котором будет располагаться менеджер этого кластера. Затем мы добавим подчиненный сервис Docker с машины Node1.
В терминале с открытой сессией на сервере Manager выполним команду:
Как видно из сообщения, текущий сервис Docker стал менеджером и готов к добавлению подчиненных хостов через выполнение указанной команды. Скопируем эту команду и подключимся к серверу Node1 по SSH, для добавления его добавления в Swarm:
Результатом успешного выполнения команды должно стать сообщение:
Следующем шагом станет настройка рабочего сервера, который будет выполнять все работы от GitLab CI.
Финальным этапом настройки среды непрерывной интеграции и развертывания с Docker является подключение рабочего сервиса GitLab CI, на котором будут выполняться все работы по сборке и тестированию приложения.
Можно использовать совместные сервисы выполнения работ, но в данном руководстве рассмотрим создание собственного сервиса на созданном ранее сервере Runner.
Подключимся по SSH к серверу Runner. Сперва необходимо установить GitLab Runner и соединить этот сервер с GitLab.
Добавим репозиторий разработчиков GitLab:
Вернемся к веб-интерфейсу GitLab для получения URL и registration-token. Снова зайдем в настройки проекта в раздел CI / CD, где мы остановились в прошлый раз. Откроем секцию Runner settings:
В разделе Runner settings есть информация по подключенным рабочим хостам: приватным и открытым:
В блоке Specific Runners есть необходимые значения URL и registration token.
Вернемся в терминал с сессией на сервере Runner и заменив значения на свои выполним команду:
Теперь у нас зарегистрирован рабочий хост, который будет выполнять все работы, посылаемые GitLab CI.
Осталось настроить SSH доступ для Git-репозитория проекта на GitLab.
Создадим приватный и публичный ключи, заменив свой email-адрес и оставив все запрашиваемые значения по-умолчанию:
Далее нужно добавить информацию о сервере GitLab, на котором расположен Git-репозиторий в список известных хостов для предотвращения ошибок во время подключения (IP адрес нужно заменить на IP адрес сервера GitLab, доступный в панели управления):
Затем необходимо добавить публичный ключ в GitLab, чтобы разрешить подключение с сервера Runner. Скопируем значение ключа:
И добавим его в GitLab:
Перейдем к созданию и докеризации простого Flask приложения, использующего два дополнительных сервиса: Nginx для маршрутизации запросов и Redis для хранения счетчика посещений страницы.
Перед созданием приложения нам необходимо активировать функцию хранения образов Docker в нашем приложении GitLab для эффективного управления развернутыми версиями приложения и обеспечения возможности отката на предыдущие версии.
Подключимся по SSH к серверу GitLab и откроем конфигурационный файл:
Далее добавим с новой строки адрес, по которому будет доступно хранилище Docker, заменив example.com на имя своего хоста:
Добавим ещё две строки с указанием места хранения сертификата и ключа. Поскольку мы используем такое же доменное имя, что и для основного приложения GitLab (если вы ещё не настроили HTTPS для GitLab, можно это сделать сейчас):
Перезагрузим сервис GitLab для активации хранилища:
Перейдем к созданному ранее проекту flask-docker-swarm в GitLab. В случае успешной активации хранилища, в меню проекта станет доступен раздел Registry:
Для дальнейшей работы с внутренним хранилищем образов нам понадобится использовать связку логин-пароль для подключения к нему. Используем возможность добавления секретных переменных в GitLab для добавления пароля. Для этого перейдем в раздел Settings и выберем блок CI / CD:
Раскроем раздел Runner settings и добавим новую переменную HUB_REGISTRY_PASSWORD, значением которой является пароль от учетной записи пользователя GitLab:
Программа будет представлять собой простое веб-приложение, считающее количество посещений и отображающее информацию о контейнере, в котором оно запущено. Для этого нам необходимо создать несколько Dockerfile (файлов конфигурации образа Docker), для каждого используемого сервиса (Nginx, Redis, Flask) и указать, как они должны взаимодействовать между собой.
Откроем страницу проекта, созданного ранее:
Выполним следующую команду для клонирования репозитория и перехода в рабочую директорию, заменив доменное имя:
Создадим внутри три директории для каждого сервиса:
Для сервиса Nginx нам понадобится создать три файла — Dockerfile и два файла настроек. Создадим и запишем общие настройки для всего веб-сервера:
И запишем следующий текст:
Следующий файл определяет параметры для виртуального сервера, непосредственно здесь указывается связь на сервис web, в котором будет выполняться наше приложение:
И запишем текст:
Блок со статическим контентом закомментирован, поскольку в нашем приложении не будет дополнительных файлов, но в дальнейшем можно добавить директорию static в сервисе web и открыть этот блок для эффективной передачи статических файлов.
Создадим Dockerfile, в котором используем готовый образ Nginx в DockerHub и модифицируем его для использования своих файлов настройки:
И запишем следующий текст:
Для сервиса Redis создадим Dockerfile:
С простым содержанием:
Мы не вносим дополнительных изменений, но в будущем они вполне возможны, поэтому создадим отдельный сервис.
Сервис с приложением Flask начнём с создания основного исполняемого файла:
Вставим следующий код:
Создадим отдельный файл с указанием использованных зависимостей:
И перечислим используемые программные пакеты:
Настроим простой пример модульного тестирования для демонстрации, в котором проверим доступность страницы. Создадим файл теста:
Скопируем и вставим текст:
Создадим файл, который будет являться входной точкой нашего приложения:
В котором укажем имя импортируемого объекта, который будет использовать Gunicorn:
Последним файлом в директории web будет Dockerfile, в котором будут перечислены команды для создания образа нашего сервиса:
Со следующим содержанием:
Для создания управляемых сервисов используем инструмент docker-compose, который позволяет указать, на основе какого образа происходит запуск контейнера и определяет поведение сервиса в целом. Для этого создадим файл docker-compose.yml:
И запишем такой текст, заменив доменное имя:
Рассмотрим подробнее структуру файла:
Для запуска на локальной машине нам понадобится создать дополнительный файл настройки docker-compose для упрощенного тестирования приложения без использования сервиса Nginx:
Вставим следующий текст:
По структуре файл напоминает основную версию, но не использует сервис Nginx и есть дополнительный раздел сборки контейнеров build.
Управление GitLab CI осуществляется через файл конфигурации:
Запишем следующий текст, поменяв example.ru на свое доменное имя:
Необходимо заменить значения полей DOCKER_HOST и URL на свои, а также внимательно изменить названия тегов образов Docker. Подробнее о доступных названиях образов можно посмотреть в Registry в GitLab.
В качестве тегов для образов мы использовали переменную окружения $CI_COMMIT_SHA для создания привязки между коммитом и образом. Для образа Redis мы указали тег latest в целях сохранения текущей базы данных.
Рассмотрим файл настроек подробнее:
Мы готовы запустить проект на локальной машине. Подобный метод запуска удобно использовать в целях разработки и тестирования в дальнейшем. Для начала установим Docker (мы приведем пример для Ubuntu 16.04, для Windows существует отдельный инсталлятор). Добавим репозиторий от разработчиков Docker для получения последней версии:
Установим последнюю версию Docker:
Запустим сборку проекта:
Если всё прошло без ошибок, запустим проект локально:
И перейдем в браузере по адресу:
В случае успешного запуска всех сервисов, вывод будет примерно следующим:
Если попробовать перезагрузить страницу несколько раз, счётчик посещений будет увеличиваться, а hostname останется прежним, потому что сейчас используется только один контейнер, в котором выполняется сервис web, генерирующей веб-страницу.
Пришло время самого интересного — запуска и обзора непрерывной интеграции. Для этого просто перейдем в директорию нашего проекта на локальной машине и произведем первый коммит и публикацию в удаленный репозиторий:
Если на предыдущих шагах не было совершенно ошибки, произойдет “пуш” в наш репозиторий GitLab, пройдут все тесты и сборка образов Docker, а затем развертывание в Docker Swarm.
Для отслеживания процессов перейдем в GitLab в раздел Pipelines и откроем последний:
Если ваш результат отличается от приведенного, перейдите в раздел Jobs и посмотрите логи по неудавшейся операции, часто это бывают опечатки или неверные адреса серверов.
Перейдем в раздел Environments:
Здесь происходит управление развернутыми средами для различных целей. Сейчас мы используем только среду master, но это не мешает вам настроить их под свои процессы.
Если было произведено уже несколько коммитов в одну среду, можно использовать функцию откатывания на предыдущую версию — для этого раскройте среду master, нажатием на название среды:
Для отката на предыдущую версию достаточно нажать кнопку Rollback, которая запустит стадию deploy для выбранного коммита.
Мы использовали развертывание среды на каждый коммит в качестве примера, но в реальности возможно настроить срабатывание такой работы на другие события, например, слияние веток.
Посмотрим на наше приложение. В браузере перейдите по адресу сервера Manager:
Если несколько раз перезагрузить страницу, то заметим, что значение hostname меняется в пределах 4 вариантов, что соответствует количеству реплик, которое мы указали для сервиса web.
Docker Swarm взял на себя контроль по размещению контейнеров между нодами в своей сети. При этом половина контейнеров сервиса web была автоматически размещена в подчиненном ноде. Для просмотра подробной информации можно выполнить следующую команду на сервере Manager, заменив название рабочей среды (если вы его меняли в команде docker stack deploy) на своё:
Мы рассмотрели один из способов применения GitLab CI для настройки непрерывной интеграции и доставки своих Docker-проектов. Следует отметить, что при использовании подобного решения для рабочих проектов следует уделить значительное внимание безопасности — использовать сертификаты доверенных центров, настроить сеть нодов в Docker Swarm для реагирования на перезагрузки серверов и контролировать количество хранимых и используемых образов Docker.
Сначала мы рассмотрим настройку рабочей среды, включая создание серверов для нодов Docker Swarm. Затем создадим простое приложение Flask с Redis и подготовим GitLab CI для непрерывной доставки.
Управление контейнерами и управление нагрузкой — нетривиальная тема и требует значительной подготовки, особенно если планируется самостоятельная настройка системы оркестрации (например, с помощью Kubernetes). Однако, существуют такие инструменты как Docker Swarm или Rancher, которые берут на себя управление контейнерами, внутренними сетями и распределение нагрузок и дают возможность развернуть масштабируемую систему на собственных серверах.
Кроме того, GitLab хорошо поддерживает Docker и позволяет подключать собственные системы хранения образов (GitLab Registry) в несколько простых шагов. А также отслеживать статус выполнения работ по проекту и управлять развернутыми версиями приложения, позволяя при необходимости откатиться на прошлую в один клик.
Предварительные требования
Перед началом необходимо удостовериться в выполнении следующих условий:
- установлен и доступен сервер с GitLab;
- GitLab защищен с помощью SSL-сертификата;
- в GitLab добавлен SSH-ключ.
Официальное руководство по настройке HTTPS в GitLab.
Установка серверов
Для настройки и запуска приложения в режиме Swarm нам понадобится 2 типа серверов — менеджер и подчиненный. Кроме того, дополнительно один сервер будет выделен под GitLab Runner для выполнения задачи сборки и запуска контейнеров.
Виртуальные сервера мы будем создавать на платформе Vscale, однако, если вы пользователь другого сервиса, например, DigitalOcean, то действия будут аналогичны изложенным далее.
Создадим три новых сервера из образа Docker:
- Runner — для выполнения работ GitLab Runner;
- Manager — управляющий нод Docker Swarm;
- Node1 — подчиненный нод Docker Swarm.
Полученные IP-адреса мы будем использовать далее.
Защита сервиса докера на управляющем сервере самоподписанными сертификатом
Примечание. Использование TLS и управление центром сертификации — тема, требующая значительной подготовки. Желательно ознакомиться с технологиями OpenSSL, x509 и TLS перед использованием их в реальных проектах.
На финальном этапе развертывания приложения в рабочей Swarm-среде необходимо защищенное соединение между GitLab Runner и сервисом Docker, запущенном на сервере Manager, что видно на схеме ниже:
Процесс развертывания приложения в рабочей среде.
Для этого необходимо использовать единый сертификационный центр для клиента (GitLab Runner) и сервиса Docker (Manager). После создания сертификата и ключа для клиента, их можно использовать для удаленного подключения к сервису Docker и выполнения различных операций. Следует быть максимально осторожными с хранением клиентских сертификатов и ключей, поскольку они дают полное управление надо сервисом Docker.
Обновление сервиса Docker на машине Manager
Подключимся по SSH к серверу Manager и обновим Docker, поскольку в дальнейшем нам потребуются дополнительные возможности, доступные в старшей версии Docker API. Добавим репозиторий от разработчиков Docker для получения последней версии:
$ apt-get update
$ apt-get install \
apt-transport-https \
ca-certificates \
curl \
software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
$ add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
$ apt-get update
Установим последнюю версию Docker:
$ apt-get install docker-ce
Для проверки установки выполним команду:
$ docker version
Вывод команды может отличаться, главное, чтобы обе версии API клиента и сервера были больше 1.24:
Client:
Version: 17.09.0-ce
API version: 1.32
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:42:18 2017
OS/Arch: linux/amd64
Server:
Version: 17.09.0-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:40:56 2017
OS/Arch: linux/amd64
Experimental: false
Создание сертификата и ключей
Оставаясь в сервере Manager, приступим к созданию сертификационного центра (CA). Перейдем в новую директорию:
$ mkdir certificates
$ cd certificates
Для начала нужно создать приватный и публичный RSA-ключ для CA (потребуется придумать кодовое слово длиной не меньше 4 символов):
$ openssl genrsa -aes256 -out ca-key.pem 4096
Generating RSA private key, 4096 bit long modulus
...............................................................................................................................................................................................................................++
..................................................++
e is 65537 (0x10001)
Enter pass phrase for ca-key.pem:
Verifying - Enter pass phrase for ca-key.pem:
Приступим к созданию локального сертификационного центра. Будут запрошены данные связанные с идентификацией центра. На этапе ввода полного квалифицированного доменного имени (FQDN) требуется ввести доменное имя хоста, по которому доступен сервер Manager, но в целях примера (не используйте подобный метод в рабочих машинах!) используем слово manager для обозначения сервера:
$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
Enter pass phrase for ca-key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:manager
Email Address []:your@email.com
Далее создадим приватный ключ для сервера:
$ openssl genrsa -out server-key.pem 4096
Теперь у нас есть сертификационный центр и мы можем создать запрос на подпись SSL сертификата (CSR). Поле CN (Common Name) должно совпадать с использованным на предыдущем шаге значением FQDN:
$ openssl req -subj "/CN=manager" -sha256 -new -key server-key.pem -out server.csr
Дополнительно требуется указать IP-адрес сервера Manager (машина, в которой мы сейчас работаем):
$ echo subjectAltName = DNS:manager,IP:{ваш IP-адрес} >> extfile.cnf
Создадим подписанный ключ для сервера:
$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out server-cert.pem -extfile extfile.cnf
Создадим клиентский ключ, который будем использовать для доступа к сервису Docker:
$ openssl genrsa -out key.pem 4096
Создадим запрос на подпись и дополнительно укажем тип использования ключа — для авторизации:
$ openssl req -subj '/CN=client' -new -key key.pem -out client.csr
$ echo extendedKeyUsage = clientAuth >> extfile.cnf
Получим подписанный клиентский ключ:
$ openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem \
-CAcreateserial -out cert.pem -extfile extfile.cnf
Теперь можно удалить файлы запросов:
$ rm -v client.csr server.csr
В итоге, мы получили следующие файлы:
$ ls
ca-key.pem ca.srl extfile.cnf server-cert.pem
ca.pem cert.pem key.pem server-key.pem
Оставим терминал с сессией на сервере Manager открытым, поскольку он понадобится нам далее.
Сейчас у нас есть всё необходимое для настройки защищенного доступа между GitLab Runner и рабочей Swarm-средой.
Настройка секретных переменных в GitLab CI
Мы не будем хранить данные клиентских ключей на машине Runner из соображений безопасности. Для таких задач в GitLab CI реализована функция секретных переменных среды.
Создадим новый проект в GitLab:
После создания проекта перейдем в настройки CI / CD:
Откроем область секретных переменных (Secret variables) и будем работать с ней:
Нам необходимо добавить и сохранить три переменные со следующими названиями и значениями файлов, которые мы создали на предыдущем шаге:
- переменная TLSCACERT значение файла ca.pem;
- переменная TLSCERT значение файла cert.pem;
- переменная TLSKEY значение файла key.pem.
Вернёмся к терминалу с сессией на сервере Manager и выполним команду:
$ cat ca.pem
(Сокращенный вывод)
-----BEGIN CERTIFICATE-----
MIIFgTCCA2mgAwIBAgIJAMzFvrYTSMoxMA0GCSqGSIb3DQEBCwUAMFcxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
...
bI9XGs39F+r8Si5y6oHqkZHMpRX631i2KRA6k4jBPrZrS0MH3OwsCobuat5T1ONH
Kx7TFZSuFO25XIut1WucVn5yPWLTKRniMV7dVws9i9x9Sp2Iamk+w2x1GPO6bHtr
BWqdORkUEWMs+DTgX2J989AFh7gnYwHZ2Bo7HKlC6IbOlol7b2E/5p7hWrpe7sf+
oQDn1bhgoauhq2AL4BysJfA3uHoA
-----END CERTIFICATE-----
Скопируем это значение и добавим новую секретную переменную в GitLab:
Теперь по этому примеру добавим оставшиеся значения cert.pem и key.pem.
Настройка сервиса Docker на управляющем сервере Manager
По-умолчанию доступ к сервису Docker имеет только пользователь-владелец процесса. Для выполнения операций по развертыванию приложения с удаленного хоста, нам необходимо разрешить подключение извне, при этом использовать TLS-протокол. Мы уже получили необходимые сертификаты и ключи, осталось настроить Docker для работы с ними.
Мы создадим отдельный конфигурационный файл явно прописывающий хосты, по которым будет доступен Docker, поэтому для начала нам нужно удалить стандартный параметр -H, прописывающий хост. Для этого создадим новую директорию docker.service.d, в которой переопределим параметры запуска сервиса:
$ mkdir -p /etc/systemd/system/docker.service.d
Создадим файл настройки:
$ nano /etc/systemd/system/docker.service.d/exec-start.conf
Добавим следующую секцию, для параметра ExecStart требуется сначала очистить предыдущие значения и затем указать новые:
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
Создадим новый конфигурационный файл:
$ nano /etc/docker/daemon.json
И запишем следующий текст, определяющим использование протокола TLS для доступа к сервису Docker, а также расположение серверного ключа и сертификата:
{
"hosts": ["tcp://0.0.0.0:2376","fd://"],
"tlsverify": true,
"tlscacert": "/root/certificates/ca.pem",
"tlscert": "/root/certificates/server-cert.pem",
"tlskey": "/root/certificates/server-key.pem"
}
Для вступления изменений в силу, перезапустим сервис Docker:
$ systemctl daemon-reload
$ service docker restart
Теперь мы можем подключиться по TLS к нашему сервису Docker по адресу
[IP адрес сервера]:2376
Активация режима Swarm
Для начала рекомендуем изучить материалы на тему режима Swarm, например, на официальном сайте Docker. Swarm — это кластер сервисов Docker, расположенных на различных физических или виртуальных машинах и ведущих себя как единое целое.
Распределение запросов между имеющимися сервисами Docker осуществляется по схеме ingress load balancing, суть которой в том, что любой запрос проходит через внутренний механизм балансировки, а затем перенаправляется на тот сервис, который в данный момент может обслужить запрос.
Масштабирование осуществляется за счет указания количества реплик внутренних сервисов, с которыми мы столкнемся позднее.
Мы активируем режим Docker Swarm на сервере Manager, на котором будет располагаться менеджер этого кластера. Затем мы добавим подчиненный сервис Docker с машины Node1.
В терминале с открытой сессией на сервере Manager выполним команду:
$ docker swarm init
Swarm initialized: current node (r1mbxr2dyuf48zpm5ss0kvwv7) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-5ihkl37kbs13po7htnj9dzzg3gex4i6iuvjho7910crd0hv895-36jw5epwcw3xwpzmqf1mqgod2 {ваш IP-адрес}:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
Как видно из сообщения, текущий сервис Docker стал менеджером и готов к добавлению подчиненных хостов через выполнение указанной команды. Скопируем эту команду и подключимся к серверу Node1 по SSH, для добавления его добавления в Swarm:
$ docker swarm join --token SWMTKN-1-1lhmuomvb060rnom4jqj8gxc565f4wgwadjs9ucvqx6huwvbfc-6vt1ljdhldxtetjv2hnct7sh4 {ваш IP-адрес}:2377
Результатом успешного выполнения команды должно стать сообщение:
This node joined a swarm as a worker.
Следующем шагом станет настройка рабочего сервера, который будет выполнять все работы от GitLab CI.
Настройка Gitlab Runner
Финальным этапом настройки среды непрерывной интеграции и развертывания с Docker является подключение рабочего сервиса GitLab CI, на котором будут выполняться все работы по сборке и тестированию приложения.
Можно использовать совместные сервисы выполнения работ, но в данном руководстве рассмотрим создание собственного сервиса на созданном ранее сервере Runner.
Подключимся по SSH к серверу Runner. Сперва необходимо установить GitLab Runner и соединить этот сервер с GitLab.
Добавим репозиторий разработчиков GitLab:
$ apt update
$ apt install curl
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash
$ apt-get install gitlab-runner
Вернемся к веб-интерфейсу GitLab для получения URL и registration-token. Снова зайдем в настройки проекта в раздел CI / CD, где мы остановились в прошлый раз. Откроем секцию Runner settings:
В разделе Runner settings есть информация по подключенным рабочим хостам: приватным и открытым:
В блоке Specific Runners есть необходимые значения URL и registration token.
Вернемся в терминал с сессией на сервере Runner и заменив значения на свои выполним команду:
$ gitlab-runner register -n \
--url http:// {ваш IP-адрес}/ \
--registration-token _Kof1SxCHzVNcwuZZEwx \
--executor docker \
--description "Docker Prod Runner" \
--docker-image "docker:latest" \
--docker-privileged \
--tag-list docker
Registering runner... succeeded runner=_Kof1SxC
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Теперь у нас зарегистрирован рабочий хост, который будет выполнять все работы, посылаемые GitLab CI.
Осталось настроить SSH доступ для Git-репозитория проекта на GitLab.
Создадим приватный и публичный ключи, заменив свой email-адрес и оставив все запрашиваемые значения по-умолчанию:
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Далее нужно добавить информацию о сервере GitLab, на котором расположен Git-репозиторий в список известных хостов для предотвращения ошибок во время подключения (IP адрес нужно заменить на IP адрес сервера GitLab, доступный в панели управления):
$ ssh-keyscan -t rsa {ваш IP-адрес} >> .ssh/known_hosts
Затем необходимо добавить публичный ключ в GitLab, чтобы разрешить подключение с сервера Runner. Скопируем значение ключа:
$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDMY+G6rmx+AZ6Ow1lVr+4ox0HaAaV4xwthCS3ucyI3KsXVV+ltLU0zkFOP8WZoTXCHo38Fpcu5KwYe3V6L/hZ26fNse6WhJ6EvRmVx7wVHyixhpzKj6Jp9zzAf24SbtrjGgNtN4ASKyouU///a3+gtM+eWQYdxavz6wlJ0xgm8MnDqpbCUv1M7IRWsKhejA9vLSXjfdkxQnxVSCOT/FXb/eDsGRTs7WMXYapqeQ0msTXDCFlNDVQaRWZagXpHLRDkeOhRE2rJ6daj8YNKKx0jaatRKIsICqwUljvPgsrnpF9FiUg8n8PTWyYbz3VpwUoIPnFiFXvbgIn8xLb2/4QkFDoZUgyLI+VgrmZmd0HZPWvW5QbMLZ8vwb/Izi0TG/+qoMm8jas0RaUUp18rQAc4GmCLRsFbzN3DsnME31xFa0y/pwA3LK9ptIRivYq82uP5twq0jXpMSji8w+No7kBI5O9VUHmbRYYYWpn+jeKTxmoVORsrCHpAT7Cub0+Ynyq1M7Em0RMqZgdzLsP9rlLwRkc6ZEgqpVQHDZgwJsnQ5qo/6lr18bD9QHSe5t+SSnUbnkmXkp0xb0ivC4XayxCjYVIOoZV2cqyGa+45s7LY+ngPk0Cg+vSMHV8/enEwu1ABdpoGVjaELJOtw1UBr4y9GCyQ0OhKnrzWmqL6+HnEMDQ== your_email@example.com
И добавим его в GitLab:
Перейдем к созданию и докеризации простого Flask приложения, использующего два дополнительных сервиса: Nginx для маршрутизации запросов и Redis для хранения счетчика посещений страницы.
Подключение Docker Registry в GitLab
Перед созданием приложения нам необходимо активировать функцию хранения образов Docker в нашем приложении GitLab для эффективного управления развернутыми версиями приложения и обеспечения возможности отката на предыдущие версии.
Подключимся по SSH к серверу GitLab и откроем конфигурационный файл:
$ nano /etc/gitlab/gitlab.rb
Далее добавим с новой строки адрес, по которому будет доступно хранилище Docker, заменив example.com на имя своего хоста:
registry_external_url 'https://gitlab.example.com:4567'
Добавим ещё две строки с указанием места хранения сертификата и ключа. Поскольку мы используем такое же доменное имя, что и для основного приложения GitLab (если вы ещё не настроили HTTPS для GitLab, можно это сделать сейчас):
registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.example.com/fullchain.pem"
registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.example.com/privkey.pem"
Перезагрузим сервис GitLab для активации хранилища:
$ gitlab-ctl reconfigure
Перейдем к созданному ранее проекту flask-docker-swarm в GitLab. В случае успешной активации хранилища, в меню проекта станет доступен раздел Registry:
Для дальнейшей работы с внутренним хранилищем образов нам понадобится использовать связку логин-пароль для подключения к нему. Используем возможность добавления секретных переменных в GitLab для добавления пароля. Для этого перейдем в раздел Settings и выберем блок CI / CD:
Раскроем раздел Runner settings и добавим новую переменную HUB_REGISTRY_PASSWORD, значением которой является пароль от учетной записи пользователя GitLab:
Создание приложения
Программа будет представлять собой простое веб-приложение, считающее количество посещений и отображающее информацию о контейнере, в котором оно запущено. Для этого нам необходимо создать несколько Dockerfile (файлов конфигурации образа Docker), для каждого используемого сервиса (Nginx, Redis, Flask) и указать, как они должны взаимодействовать между собой.
Откроем страницу проекта, созданного ранее:
Выполним следующую команду для клонирования репозитория и перехода в рабочую директорию, заменив доменное имя:
$ git clone git@gitlab.example.ru:root/flask-docker-swarm.git
$ cd flask-docker-swarm
Создадим внутри три директории для каждого сервиса:
$ mkdir nginx
$ mkdir web
$ mkdir redis
Создание сервиса Nginx
Для сервиса Nginx нам понадобится создать три файла — Dockerfile и два файла настроек. Создадим и запишем общие настройки для всего веб-сервера:
$ nano nginx/nginx.conf
И запишем следующий текст:
# Укажем какой пользователь запускает и выполняет Nginx процесс
user nginx;
# Укажем количество рабочих процессов, рекомендуемое число -
# число процессоров на сервере
worker_processes 1;
# Укажем расположение лога ошибок и уровень значимости записываемых сообщений
error_log /var/log/nginx/error.log warn;
# Укажем имя файла, в котором будет хранится PID главного Nginx-процесса
pid /var/run/nginx.pid;
events {
# Укажем максимальное число одновременных соединений
worker_connections 1024;
}
# http блок определяет как должен вести себя Nginx c http-трафиком
http {
# Включение файла с перечислением всех поддерживаемых типов файлов
include /etc/nginx/mime.types;
# Определение файла возвращаемого по-умолчанию
default_type text/html;
# Определяет формат сообщений-логов
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# Указывает путь сохранения логов запросов на доступ к Nginx
access_log /var/log/nginx/access.log main;
# Параметры для оптимизации доставки статических файлов
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# Определяет время жизни соединения с клиентом
keepalive_timeout 65;
# Параметр включает компрессирование gzip для экономии трафика
#gzip on;
# Включение дополнительных параметров для виртуальных хостов
include /etc/nginx/conf.d/*.conf;
}
Следующий файл определяет параметры для виртуального сервера, непосредственно здесь указывается связь на сервис web, в котором будет выполняться наше приложение:
$ nano nginx/flask.conf
И запишем текст:
# Блок server определяет параметры виртуального хоста/сервера
server {
# Определение имени сервера, IP адреса и/или порта, на котором слушает сервер
listen 80 default_server;
# server_name xxx.yyy.zzz.aaa
# Определение типа символов для поля “Content-Type” в заголовке ответа
charset utf-8;
# Настройка Nginx для доставки статических файлов через указанную директорию
#location /static {
# alias /usr/src/app/web/static;
#}
# Настройка Nginx в качестве прокси-сервера на внутренний сервер выгрузки данных (Gunicorn (WSGI server))
location / {
# Адрес и порт сервера выгрузки данных
proxy_pass http://web:5000;
# Переопределение заголовков посылаемых серверу выгрузки данных
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# Максимальный размер файлов для загрузки
client_max_body_size 5M;
client_body_buffer_size 5M;
}
}
Блок со статическим контентом закомментирован, поскольку в нашем приложении не будет дополнительных файлов, но в дальнейшем можно добавить директорию static в сервисе web и открыть этот блок для эффективной передачи статических файлов.
Создадим Dockerfile, в котором используем готовый образ Nginx в DockerHub и модифицируем его для использования своих файлов настройки:
$ nano nginx/Dockerfile
И запишем следующий текст:
FROM nginx:1.13.6
RUN rm /etc/nginx/nginx.conf
COPY nginx.conf /etc/nginx/
RUN rm /etc/nginx/conf.d/default.conf
COPY flask.conf /etc/nginx/conf.d
Создание сервиса Redis
Для сервиса Redis создадим Dockerfile:
$ nano redis/Dockerfile
С простым содержанием:
FROM redis:3.2.11
Мы не вносим дополнительных изменений, но в будущем они вполне возможны, поэтому создадим отдельный сервис.
Создание сервиса с приложением Flask
Сервис с приложением Flask начнём с создания основного исполняемого файла:
$ nano web/main.py
Вставим следующий код:
from flask import Flask
from redis import Redis, RedisError
import os
import socket
# Connect to Redis
redis = Redis(host="redis", db=0, socket_connect_timeout=2, socket_timeout=2)
app = Flask(__name__)
@app.route("/")
def hello():
try:
visits = redis.incr("counter")
except RedisError:
visits = "<i>cannot connect to Redis, counter disabled</i>"
html = "<h3>Hello {name}!</h3>" \
"<b>Hostname:</b> {hostname}<br/>" \
"<b>Visits:</b> {visits}"
return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname(), visits=visits)
if __name__ == "__main__":
app.run()
Создадим отдельный файл с указанием использованных зависимостей:
$ nano web/requirements.txt
И перечислим используемые программные пакеты:
Flask==0.12.2
Redis==2.10.6
Gunicorn==19.7.1
Nose2
Coverage
Настроим простой пример модульного тестирования для демонстрации, в котором проверим доступность страницы. Создадим файл теста:
$ nano web/test_smoke.py
Скопируем и вставим текст:
import os
import unittest
from main import app
class BasicTests(unittest.TestCase):
# executed prior to each test
def setUp(self):
app.config['TESTING'] = True
app.config['WTF_CSRF_ENABLED'] = False
app.config['DEBUG'] = False
self.app = app.test_client()
self.assertEqual(app.debug, False)
# executed after each test
def tearDown(self):
pass
def test_main_page(self):
response = self.app.get('/', follow_redirects=True)
self.assertEqual(response.status_code, 200)
if __name__ == "__main__":
unittest.main()
Создадим файл, который будет являться входной точкой нашего приложения:
$ nano web/wsgi.py
В котором укажем имя импортируемого объекта, который будет использовать Gunicorn:
from main import app
if __name__ == "__main__":
app.run(host='0.0.0.0')
Последним файлом в директории web будет Dockerfile, в котором будут перечислены команды для создания образа нашего сервиса:
$ nano web/Dockerfile
Со следующим содержанием:
FROM python:3.6.3
RUN groupadd flaskgroup && useradd -m -g flaskgroup -s /bin/bash flask
WORKDIR /app
ADD . /app
RUN pip install -r requirements.txt
Создание сервисов на основе контейнеров Docker
Для создания управляемых сервисов используем инструмент docker-compose, который позволяет указать, на основе какого образа происходит запуск контейнера и определяет поведение сервиса в целом. Для этого создадим файл docker-compose.yml:
$ nano docker-compose.yml
И запишем такой текст, заменив доменное имя:
version: "3.4"
services:
web:
image: gitlab.example.ru:4567/root/flask-docker-swarm/web:${CI_COMMIT_SHA}
deploy:
replicas: 4
restart_policy:
condition: on-failure
command: gunicorn -w 3 --bind 0.0.0.0:5000 wsgi:app
nginx:
image: gitlab.example.ru:4567/root/flask-docker-swarm/nginx:${CI_COMMIT_SHA}
deploy:
mode: global
restart_policy:
condition: on-failure
ports:
- "80:80"
redis:
image: gitlab.example.ru:4567/root/flask-docker-swarm/redis:latest
deploy:
replicas: 1
placement:
constraints: [node.role == manager]
restart_policy:
condition: on-failure
ports:
- "6379"
Рассмотрим подробнее структуру файла:
- блок services включает в себя описание всех создаваемых сервисов;
- в каждом сервисе есть раздел image, который определяет используемый образ для создания контейнеров на его основе. Подобный формат записи позволяет получать образы с хранилища, доступного по адресу gitlab.example.ru:4567. Последний аргумент ${CI_COMMIT_SHA} — переменная окружения, связанная с значением хеша текущего коммита, которую мы используем для различия сборок друг от друга в данном руководстве;
- блок deploy используется только при использовании команды docker stack deploy. Мы используем три ключевых слова внутри данного блока:
- replicas — количество копий контейнера;
- placement — расположение контейнеров относительно рабочих нодов;
- restart_policy — условия перезапуска контейнеров;
- открытие портов для общения между сервисами и внешней средой осуществляется в разделе ports;
- для выполнения дополнительных команд при старте сервиса используется блок command.
Для запуска на локальной машине нам понадобится создать дополнительный файл настройки docker-compose для упрощенного тестирования приложения без использования сервиса Nginx:
$ nano docker-compose.override.yml
Вставим следующий текст:
version: "3.4"
services:
web:
image: web
environment:
- FLASK_APP=wsgi.py
- FLASK_DEBUG=1
build:
context: ./web
dockerfile: Dockerfile
command: 'flask run --host=0.0.0.0'
links:
- redis
ports:
- "5000:5000"
volumes:
- ./web/:/usr/src/app/web
redis:
image: redis
build:
context: ./redis
dockerfile: Dockerfile
ports:
- "6379:6379"
По структуре файл напоминает основную версию, но не использует сервис Nginx и есть дополнительный раздел сборки контейнеров build.
Управление GitLab CI осуществляется через файл конфигурации:
$ nano .gitlab-ci.yml
Запишем следующий текст, поменяв example.ru на свое доменное имя:
image: docker:17.09.0-ce
services:
- docker:dind
before_script:
- apk add --update py-pip &&
pip install docker-compose
stages:
- test
- build
- deploy
- stage
unittests:
stage: test
script:
- cd web
- pip install -q -r requirements.txt
- nose2 -v --with-coverage
tags:
- docker
docker-build:
stage: build
script:
- docker login -u root -p $HUB_REGISTRY_PASSWORD https://gitlab.example.ru:4567/
- docker build -t gitlab.example.ru:4567/root/flask-docker-swarm/nginx:$CI_COMMIT_SHA ./nginx
- docker push gitlab.example.ru:4567/root/flask-docker-swarm/nginx:$CI_COMMIT_SHA
- docker build -t gitlab.example.ru:4567/root/flask-docker-swarm/web:$CI_COMMIT_SHA ./web
- docker push gitlab.example.ru:4567/root/flask-docker-swarm/web:$CI_COMMIT_SHA
- docker build -t gitlab.example.ru:4567/root/flask-docker-swarm/redis:latest ./redis
- docker push gitlab.example.ru:4567/root/flask-docker-swarm/redis:latest
tags:
- docker
deploy-to-swarm:
stage: deploy
variables:
DOCKER_HOST: tcp://{manager_ip_address}:2376
DOCKER_TLS_VERIFY: 1
DOCKER_CERT_PATH: "/certs"
script:
- mkdir -p $DOCKER_CERT_PATH
- echo "$TLSCACERT" > $DOCKER_CERT_PATH/ca.pem
- echo "$TLSCERT" > $DOCKER_CERT_PATH/cert.pem
- echo "$TLSKEY" > $DOCKER_CERT_PATH/key.pem
- docker login -u root -p $HUB_REGISTRY_PASSWORD $CI_REGISTRY
- docker stack deploy -c docker-compose.yml env_name --with-registry-auth
- rm -rf $DOCKER_CERT_PATH
environment:
name: master
url: http://{manager_ip_address}
only:
- master
tags:
- docker
Необходимо заменить значения полей DOCKER_HOST и URL на свои, а также внимательно изменить названия тегов образов Docker. Подробнее о доступных названиях образов можно посмотреть в Registry в GitLab.
В качестве тегов для образов мы использовали переменную окружения $CI_COMMIT_SHA для создания привязки между коммитом и образом. Для образа Redis мы указали тег latest в целях сохранения текущей базы данных.
Рассмотрим файл настроек подробнее:
- вначале файла указывается блок image, который определяет на основе какого образа будет осуществляться сборка проекта;
- в блоке services мы дополнительно подключаем образ с настроенным Docker, для запуска контейнеров Docker внутри Docker;
- раздел before_script содержит команды, выполняемые перед запуском каждой стадии сборки проекта;
- блок stages перечисляет в каком порядке будут исполняться различные стадии выполнения работ;
- выполнение каждого раздела происходит в именованном блоке, например, unittests, который в свою очередь состоит из нескольких разделов:
- поле stage указывает в какой стадии выполняется блок;
- поле variables может содержать дополнительные переменные окружения, необходимые для выполнения операций;
- поле script содержит список команд, которые будут выполнены в этом блоке;
- поле tags определяет на каких GitLab Runners может выполняться даный блок.
Запуск проекта на локальной машине
Мы готовы запустить проект на локальной машине. Подобный метод запуска удобно использовать в целях разработки и тестирования в дальнейшем. Для начала установим Docker (мы приведем пример для Ubuntu 16.04, для Windows существует отдельный инсталлятор). Добавим репозиторий от разработчиков Docker для получения последней версии:
$ sudo apt-get update
$ sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
software-properties-common
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
$ sudo apt-get update
Установим последнюю версию Docker:
$ sudo apt-get install docker-ce
Запустим сборку проекта:
$ sudo docker-compose -f docker-compose.override.yml build
Если всё прошло без ошибок, запустим проект локально:
$ sudo docker-compose -f docker-compose.override.yml up
И перейдем в браузере по адресу:
localhost:5000
В случае успешного запуска всех сервисов, вывод будет примерно следующим:
Если попробовать перезагрузить страницу несколько раз, счётчик посещений будет увеличиваться, а hostname останется прежним, потому что сейчас используется только один контейнер, в котором выполняется сервис web, генерирующей веб-страницу.
Непрерывная интеграция и доставка
Пришло время самого интересного — запуска и обзора непрерывной интеграции. Для этого просто перейдем в директорию нашего проекта на локальной машине и произведем первый коммит и публикацию в удаленный репозиторий:
$ git add --all
$ git commit -m “init”
$ git push origin master
Если на предыдущих шагах не было совершенно ошибки, произойдет “пуш” в наш репозиторий GitLab, пройдут все тесты и сборка образов Docker, а затем развертывание в Docker Swarm.
Для отслеживания процессов перейдем в GitLab в раздел Pipelines и откроем последний:
Если ваш результат отличается от приведенного, перейдите в раздел Jobs и посмотрите логи по неудавшейся операции, часто это бывают опечатки или неверные адреса серверов.
Перейдем в раздел Environments:
Здесь происходит управление развернутыми средами для различных целей. Сейчас мы используем только среду master, но это не мешает вам настроить их под свои процессы.
Если было произведено уже несколько коммитов в одну среду, можно использовать функцию откатывания на предыдущую версию — для этого раскройте среду master, нажатием на название среды:
Для отката на предыдущую версию достаточно нажать кнопку Rollback, которая запустит стадию deploy для выбранного коммита.
Мы использовали развертывание среды на каждый коммит в качестве примера, но в реальности возможно настроить срабатывание такой работы на другие события, например, слияние веток.
Посмотрим на наше приложение. В браузере перейдите по адресу сервера Manager:
Если несколько раз перезагрузить страницу, то заметим, что значение hostname меняется в пределах 4 вариантов, что соответствует количеству реплик, которое мы указали для сервиса web.
Docker Swarm взял на себя контроль по размещению контейнеров между нодами в своей сети. При этом половина контейнеров сервиса web была автоматически размещена в подчиненном ноде. Для просмотра подробной информации можно выполнить следующую команду на сервере Manager, заменив название рабочей среды (если вы его меняли в команде docker stack deploy) на своё:
$ docker stack ps env_name
Мы рассмотрели один из способов применения GitLab CI для настройки непрерывной интеграции и доставки своих Docker-проектов. Следует отметить, что при использовании подобного решения для рабочих проектов следует уделить значительное внимание безопасности — использовать сертификаты доверенных центров, настроить сеть нодов в Docker Swarm для реагирования на перезагрузки серверов и контролировать количество хранимых и используемых образов Docker.
