Сборка образов и поддержка репозитория образов Docker на GitLab

VPS | Amber | Комментировать запись

Контейнеризация быстро стала наиболее приемлемым методом упаковки и развертывания приложений в облачных средах. Стандартизация, которую обеспечивает эта технология, наряду с ее эффективностью использования ресурсов (по сравнению с полноценными виртуальными машинами) и гибкостью, делает ее отличным инструментом DevOps. Многие полезные облачные средства развертывания, оркестровки и мониторинга становятся доступными благодаря полной контейнеризации приложений и микросервисов.

Сегодня контейнеры Docker являются наиболее распространенным видом контейнеров. Публичные репозитории образов Docker, такие как Docker Hub, предлагают множество образов с открытым исходным кодом, которые вы можете скачать, но чтобы получить образ с закрытым кодом, вам нужно либо заплатить за сборку и хранение образа, либо собрать его самостоятельно.

GitLab Community Edition – это самостоятельный программный пакет, который включает в себя, среди прочих функций, хостинг репозитория Git, отслеживание проектов, службы CI/CD и реестр образов Docker. В этом мануале вы научитесь использовать сервис непрерывной интеграции GitLab для создания образов Docker на примере приложения Node.js. Затем вы протестируете эти образы и загрузите их в собственный реестр Docker.

Требования

Прежде чем начать, вам нужно настроить безопасный сервер GitLab и CI runner GitLab для выполнения задач непрерывной интеграции. Ниже приведены ссылки и более подробная информация.

Защита сервера GitLab с помощью SSL

Для хранения исходного кода, запуска задач CI/CD и обслуживания реестра Docker вам понадобится экземпляр GitLab, установленный на сервер Ubuntu 16.04. В настоящее время GitLab рекомендует использовать сервер с не менее чем 2 ядрами и 4 ГБ оперативной памяти. Кроме того, вам нужно защитить сервер SSL-сертификатами от Let’s Encrypt. Для этого вам потребуется доменное имя сервера.

Вы можете обратиться за помощью к следующим мануалам:

• Как настроить имя хоста (здесь вы узнаете, как управлять доменом).
• Начальная настройка сервера Ubuntu 16.04 (поможет подготовить к работе новый сервер – создать нужных пользователей, включить брандмауэр и т.п.).
• Установка и настройка GitLab на Ubuntu 16.04.

Настойка GitLab CI Runner

В мануале Настройка непрерывной интеграции в GitLab в Ubuntu 16.04 вы найдете обзор сервиса GitLab CI и сможете настроить CI runner для обработки заданий. Полученная инфраструктура будет использоваться в этом руководстве.

1: Установка GitLab CI Runner с привилегиями

В мануале Настройка непрерывной интеграции в GitLab в Ubuntu 16.04 GitLab runner был настроен с помощью команды sudo gitlab-runner register и интерактивного процесса. Этот runner может запускать сборку и тестирование программ внутри изолированных контейнеров Docker.

Однако для создания образов Docker runner нуждается в полном доступе к самому сервису Docker. Рекомендуемый способ настроить это – использовать официальный образ Docker docker-in-docker для запуска заданий. Для этого нужно предоставить runner-у специальный режим privileged, поэтому лучше создать второй runner с поддержкой этого режима.

Примечание: Поддержка режима privileged отключает все преимущества безопасности использования контейнеров. К сожалению, другие методы создания runner-ов с поддержкой Docker также несут аналогичные последствия для безопасности. Пожалуйста, прочитайте официальную документацию GitLab на Docker Build, чтобы узнать больше о различных параметрах runner-а и подобрать наиболее подходящие для вашей ситуации.

Поскольку использование runner-а с повышенными привилегиями имеет последствия для безопасности, сейчас нужно создать runner для конкретного проекта, который будет принимать только задания Docker в проекте hello_hapi (администраторы GitLab всегда смогут позже вручную добавить этого runner-а в другие проекты). На странице проекта hello_hapi нажмите Settings в нижней части левого меню, затем нажмите CI/CD.

Затем кликните Expand рядом с Runners settings.

Здесь будет информация о настройке Specific Runner, включая регистрационный токен. Обратите внимание на этот токен. Когда мы используем его для регистрации нового runner-а, runner будет ограничен только одним конкретным проектом.

Пока вы на этой странице, нажмите кнопку Disable shared Runners. Задачи Docker должны всегда запускаться на runner-е с повышенными привилегиями. Если при этом будет доступнен расшаренный runner с такими привилегиями, GitLab может использовать его, что приведет к ошибкам сборки.

Войдите на сервер, на котором находится текущий CI runner. Если у вас еще нет установленной машины с CI runner-ом, вернитесь к этому мануалу и завершите установку.

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

sudo gitlab-runner register -n \
--url https://gitlab.example.com/ \
--registration-token your-token \
--executor docker \
--description "docker-builder" \
--docker-image "docker:latest" \
--docker-privileged
Registering runner... succeeded                     runner=61SR6BwV
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Не забудьте указать свою собственную информацию. Укажите все параметры runner в командной строке вместо интерактивных подсказок (подсказки не позволяют задать режим –docker-privileged).

Теперь ваш runner настроен, зарегистрирован и запущен. Чтобы проверить это, вернитесь в свой браузер. Нажмите значок гаечного ключа в главной строке меню GitLab, а затем кликните Runners в левом меню. Вы увидите список runner-ов.

Теперь у вас есть runner, который может собирать образы Docker.

2: Настройка реестра Docker на GitLab

Собственный реестр образов Docker позволяет создавать и удалять образы с вашего сервера, повышая безопасность и уменьшая зависимость рабочего процесса от внешних сервисов.

GitLab настраивает частный реестр Docker с несколькими обновлениями конфигурации. Сначала нужно настроить URL-адрес, по которому будет находиться реестр. Затем нужно настроить реестр для использования S3-совместимого сервиса хранения объектов для хранения ваших данных (это опционально).

Подключитесь к серверу GitLab по SSH, а затем откройте конфигурационный файл GitLab:

sudo nano /etc/gitlab/gitlab.rb

Прокрутите страницу до раздела настроек реестра контейнера, Container Registry settings. Здесь нужно раскомментировать строку registry_external_url и установить в ней имя хоста GitLab с номером порта 5555:

registry_external_url 'https://gitlab.example.com:5555'

Затем добавьте следующие две строки, чтобы сообщить реестру, где найти сертификаты Let’s Encrypt:

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"

Сохраните и закройте файл. Затем выполните команду:

sudo gitlab-ctl reconfigure
. . .
gitlab Reconfigured!

Обновите настройки брандмауэра, чтобы он поддерживал трафик на порт реестра:

sudo ufw allow 5555

Теперь переключитесь на другую машину с установленным Docker и откройте частный реестр. Если у вас нет Docker на вашем локальном компьютере разработки, вы можете использовать любой сервер, настроенный для запуска ваших заданий CI GitLab, поскольку там уже установлен Docker:

docker login gitlab.example.com:5555

Вам будет предложено ввести имя пользователя и пароль. Используйте свои учетные данные GitLab для входа в систему.

Login Succeeded

Теперь реестр настроен и работает. В настоящее время он будет хранить файлы в локальной файловой системе сервера GitLab. Если вы хотите использовать сервис хранения объектов, продолжайте выполнять этот раздел. Если нет, перейдите к разделу 3.

Чтобы создать бэкэнд хранилище объектов для реестра, вам необходимо знать следующую информацию о сервисе хранения объектов:

• Access Key
• Secret Key
• Регион (например, us-east-1 при работе с Amazon S3) или конечная точка региона (при работе с S3-совместимым сервисом, например https://nyc.your-object-storage.com).
• Имя корзины.

Собрав всю информацию о хранилище объектов, откройте конфигурационный файл GitLab:

sudo nano /etc/gitlab/gitlab.rb

Еще раз прокрутите вниз до раздела реестра контейнера. Найдите блок registry[‘storage’], раскомментируйте его и обновите его следующим образом (указав свою информацию, где это необходимо):

registry['storage'] = {
's3' => {
'accesskey' => 'your-key',
'secretkey' => 'your-secret',
'bucket' => 'your-bucket-name',
'region' => 'nyc3',
'regionendpoint' => 'https://nyc3.your-object-storage.com'
}
}

Если вы используете Amazon S3, вам нужно указать только регион, а не конечную точку. Если вы используете S3-совместимый сервис, вам понадобится указать конечную точку региона, regionendpoint. В этом случае просто region ничего не настроит, и вводимое вами значение неважно, но оно все равно должно присутствовать.

Сохраните и закройте файл.

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

Запустите команду:

sudo gitlab-ctl reconfigure

Перейдите на другую машину Docker, снова откройте реестр и убедитесь, что все работает.

docker login gitlab.example.com:5555

Вы должны получить сообщение Login Succeeded.

Теперь, когда реестр Docker готов, обновите конфигурацию CI для создания и тестирования нашего приложения и переместите образы Docker в частный реестр.

3: Обновление gitlab-ci.yaml и сборка образа Docker

Примечание: Если вы не выполнили рекомендуемый мануал по GitLab CI, вам нужно скопировать образец репозитория на сервер GitLab. Для этого следуйте специальному разделу этого руководства.

Чтобы получить приложение в Docker, нужно обновить файл .gitlab-ci.yml. Вы можете отредактировать этот файл прямо в GitLab, кликнув по нему на главной странице проекта, а затем нажав кнопку Edit. Также можно клонировать репозиторий на свой локальный компьютер, отредактировать файл, а затем загрузить его обратно в GitLab с помощью git. Это делается так:

git clone git@gitlab.example.com:8host/hello_hapi.git
cd hello_hapi
# edit the file w/ your favorite editor
git commit -am "updating ci configuration"
git push

Сначала удалите все из файла, а затем вставьте в него следующие строки:

image: docker:latest
services:
- docker:dind
stages:
- build
- test
- release
variables:
TEST_IMAGE: gitlab.example.com:5555/8host/hello_hapi:$CI_COMMIT_REF_NAME
RELEASE_IMAGE: gitlab.example.com:5555/8host/hello_hapi:latest
before_script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab.example.com:5555
build:
stage: build
script:
- docker build --pull -t $TEST_IMAGE .
- docker push $TEST_IMAGE
test:
stage: test
script:
- docker pull $TEST_IMAGE
- docker run $TEST_IMAGE npm test
release:
stage: release
script:
- docker pull $TEST_IMAGE
- docker tag $TEST_IMAGE $RELEASE_IMAGE
- docker push $RELEASE_IMAGE
only:
- master

Обязательно обновите выделенные URL-адреса и имена пользователей, затем сохраните изменения с помощью кнопки Commit changes в GitLab. Если вы обновляете файл за пределами GitLab, скопируйте изменения и выполните команду git push.

Этот новый конфигурационный файл помогает GitLab использовать последний образ docker (image: docker:latest) и связать его с сервисом docker-in-docker (docker:dind). Затем он определяет стадии сборки, тестирования и релиза – build, test, release. Стадия build создает образ Docker с помощью Dockerfile, предоставленного в репозитории, а затем загружает его в реестр Docker. Если все пройдет успешно, стадия test загрузит новый образ и запустит в нем команду npm test. Если тестовый этап пройдет успешно, этап release загрузит образ, пометит его как hello_hapi:latest и вернет его обратно в реестр.

В зависимости от рабочего процесса вы также можете добавить дополнительные этапы test или даже этапы deploy, которые передают приложение промежуточной или производственной среде.

Обновление конфигурационного файла запустит новую сборку. Вернитесь в проект hello_hapi в GitLab и кликните по индикатору состояния CI.

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

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

Если вы нажмете маленький значок «document» рядом с именем образа, он скопирует соответствующую команду «docker pull…» в буфер обмена. Затем вы можете скачать и запустить образ:

docker pull gitlab.example.com:5555/8host/hello_hapi:latest
docker run -it --rm -p 3000:3000 gitlab.example.com:5555/8host/hello_hapi:latest
> hello@1.0.0 start /usr/src/app
> node app.js
Server running at: http://56fd5df5ddd3:3000

Образ был извлечен из реестра и запущен в контейнере. Перейдите в свой браузер и подключитесь к приложению по порту 3000 для тестирования. В этом случае контейнер запускается на локальной машине, поэтому вы можете получить к нему доступ через localhost по следующему URL-адресу:

http://localhost:3000/hello/test
Hello, test!

Если вы видите такое сообщение, значит, контейнер работает. Вы можете остановить контейнер с помощью CTRL-C. С этого момента каждый раз, когда вы будете вводить новый код в ветку master репозитория, вы будете автоматически собирать и тестировать образ hello_hapi:latest.

Заключение

В этом мануале вы создали новый runner GitLab для создания образов Docker, настроили частный реестр Docker для их хранения и обновили приложение Node.js, которое теперь можно собирать и тестировать внутри контейнера Docker.

Чтобы узнать больше о различных компонентах, используемых в этой настройке, вы можете прочитать официальную документацию GitLab CE, GitLab Container Registry и Docker.