Как разместить репозиторий образов Docker и собирать образы Docker с помощью GitLab Self-Managed Instance на Ubuntu 20.04

Технология контейнеризации значительно продвинулась в сфере разработки программного обеспечения как наиболее признанный метод упаковки и развертывания приложений в облачных средах. Это было обусловлено необходимостью непрерывной интеграции (CI) и непрерывного развертывания (CD), которые являются определяющими аспектами DevOps. Разработчики и инженеры программного обеспечения используют контейнеры для реализации аспекта CI/CD в архитектуре ПО. Контейнер, по сути, представляет собой полностью упакованную портативную и независимую вычислительную платформу. Хотя в сети существует несколько платформ контейнеризации, Docker является наиболее распространенной.

Docker — это платформа контейнеризации с открытым исходным кодом, которая делает разработку эффективной и предсказуемой. Docker предлагает публичный репозиторий образов Docker, доступный по адресу Docker Hub. Он содержит множество образов Docker с открытым исходным кодом для наиболее распространенных реализаций, которые вы можете скачать и использовать. Поскольку это публичный репозиторий, вы также можете свободно добавлять свои собственные образы Docker, чтобы делиться ими с общественностью. Однако, если у вас приватный/проприетарный код, вам, возможно, придется заплатить за приватный репозиторий образов или создать собственную службу репозитория образов. Именно здесь на сцену выходит GitLab.

GitLab — это веб-репозиторий Git, который представляет собой нечто большее, чем просто инструмент контроля версий. Он предоставляет инструменты DevOps для непрерывной интеграции и развертывания, отслеживания проблем, реестров образов Docker и многого другого. Он предлагает три варианта: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) и GitLab SaaS. GitLab CE и GitLab EE — это self-managed решения, которые позволяют вам самостоятельно загружать, устанавливать и управлять экземпляром GitLab. GitLab SaaS размещается компанией GitLab Inc., и вам не нужно беспокоиться об установке чего-либо для его использования.

В предыдущем руководстве мы показали вам, как настроить экземпляр GitLab на сервере CloudSigma и разместить собственный репозиторий Git. Мы также показали вам, как реализовать конвейеры непрерывной интеграции с помощью GitLab runner, чтобы автоматически собирать и запускать тесты при каждом новом коммите. Если вы еще не ознакомились с упомянутыми руководствами, пожалуйста, сделайте это, так как они являются основой для этого руководства.

В этом руководстве мы продемонстрируем, как создать простой образ Docker и разместить его на собственном сервере GitLab (независимо от того, используете ли вы Community Edition или Enterprise Edition – последовательность шагов одинакова).

Предварительные требования

Чтобы следовать каждому шагу этого руководства, убедитесь, что у вас есть GitLab CI runner и собственный сервер GitLab, как описано ниже.

1. Безопасный сервер GitLab

Мы будем использовать его для хранения исходного кода, выполнения задач CI/CD и размещения реестра образов Docker. У вас должен быть сервер как минимум с 2 CPU ядрами и 4GB of RAM, как рекомендовано GitLab для установки self-managed экземпляра GitLab. Вам также понадобится зарегистрированное доменное имя, указывающее на сервер, так как мы будем использовать его для получения SSL-сертификата от Let’s Encrypt для защиты сервера. Ниже приведены ссылки, по которым вы можете перейти для настройки собственного экземпляра GitLab.

• Зарегистрируйте доменное имя у любого регистратора доменных имен по вашему выбору и направьте его на CloudSigma.
• Следуйте этому руководству для первоначальной настройки сервера Ubuntu, добавления пользователя без прав root, и включения брандмауэра UFW в Ubuntu.
• Наконец, следуйте этому руководству по установке и настройке собственного экземпляра GitLab.

2. GitLab CI runner

GitLab CI runner необходим для запуска автоматизированных задач для ваших тест-кейсов. Руководство по настройке конвейеров непрерывной интеграции GitLab на Ubuntu 20.04 дает вам представление о сервере GitLab CI и показывает, как запускать задачи. Выполните шаги из руководства, чтобы настроить службу GitLab CI runner, если вы этого еще не сделали. В руководстве используется демо-приложение Node.js с тест-кейсами – мы будем использовать его в этом руководстве.

Теперь давайте начнем!

Шаг 1. Настройка привилегированного GitLab CI Runner

В руководстве по настройке GitLab CI Runner мы настроили GitLab runner с помощью команды sudo gitlab-runner register команда, которая позволила нам в интерактивном режиме добавить необходимые параметры. Хотя это работало для нашего предыдущего сценария использования, который заключался в запуске сборок и тестов в изолированных контейнерах Docker, это может не подойти для сборки образов Docker. Сборка образов Docker требует, чтобы раннер имел полный доступ к службе Docker. Вы можете добиться такой конфигурации, используя официальный docker-in-docker образ для запуска задач. Такая конфигурация предполагает предоставление раннеру privileged режима выполнения.

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

Мы создадим еще один раннер с привилегированным режимом выполнения. Это будет раннер для конкретного проекта из-за упомянутых выше соображений безопасности. Он будет принимать задачи из проекта Node Pipeline, который мы создали в руководстве по тому, как настроить непрерывные конвейеры CI с помощью GitLab.

Первое, что вам нужно сделать, это убедиться, что Shared Runners отключены в проекте. На странице проекта Node Pipeline, нажмите на Settings в левом нижнем меню и выберите CI/CD в подменю:

Найдите кнопку Expand в разделе Runners и нажмите ее, чтобы просмотреть сведения о доступных раннерах:

Нажмите переключатель, чтобы Disable Shared Runners для этого проекта. Если вы добавили раннер для конкретного проекта в предыдущем разделе, также отключите его. Мы будем добавлять privileged раннер для конкретного проекта для запуска задач этого проекта. Это гарантирует, что мы не столкнемся с ошибками сборки в случае, если GitLab случайным образом назначит задачи раннерам, которые не были зарегистрированы с привилегированным режимом выполнения. На скриншоте выше на вкладке Specific runners вы должны увидеть регистрационный токен вашего проекта. Запишите его, так как он понадобится вам ниже.

Note: Раннер для конкретного проекта также может быть назначен другим проектам из раздела Admin panel > Runners. Когда вы выбираете раннер из списка, вы переходите на страницу конфигурации раннера. Прокрутите вниз, чтобы просмотреть раздел Restrict projects for this runner:

Пришло время открыть терминал. Если вы еще не выполнили шаги из руководства по настройке конвейеров непрерывной интеграции GitLab на Ubuntu 20.04, сделайте перерыв в этом руководстве и выполните эти шаги, чтобы у вас был сервер с запущенной службой раннера GitLab CI. В противном случае подключитесь по SSH к серверу раннера GitLab CI под вашим sudo user для выполнения следующих шагов.

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

Этот вывод показывает успешную регистрацию:

Чтобы убедиться, что ваш экземпляр GitLab обнаружил раннер, вернитесь в браузер и обновите страницу Settings > CI/CD. Разверните раздел Runners, и вы должны увидеть свой раннер в разделе Specific Runners:

При желании, если вы перейдете в Admin Panel (нажав кнопку Menu в верхней панели и выбрав Admin), а затем выбрав Runners в меню:

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

К этому моменту вы успешно настроили раннер, который может собирать образы Docker.

Step 2: Configuring GitLab’s Docker Registry

Некоторые критически важные рабочие процессы требуют независимости от внешних сервисов. Именно здесь на помощь приходит self-managed Docker Registry от GitLab. Он не только безопасен, но и обеспечивает гибкость настройки ваших задач и конвейеров в соответствии с вашими потребностями. Чтобы настроить Docker Registry, вы будете изменять конфигурационный файл GitLab. Сначала подключитесь к инстансу GitLab по SSH, а затем откройте файл с помощью следующей команды:

Прокрутите вниз, пока не увидите Container Registry Settings:

Раскомментируйте строку с registry_external_url и установите в качестве её значения доменное имя вашего инстанса GitLab, указав порт 8888 в конце:

Далее нам нужно указать, где реестр будет находить сертификаты Let’s Encrypt, добавив следующие строки. Не забудьте заменить доменное имя на реальное имя вашего инстанса GitLab:

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

Затем подождите несколько секунд, пока команда завершит выполнение. В случае успеха вы должны увидеть следующий вывод:

Далее нам нужно убедиться, что брандмауэр (ufw) разрешает трафик на назначенный нами порт реестра с помощью команды:

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

В выводе отобразится сообщение Login Succeeded следующего вида:

Это означает, что реестр успешно настроен и работает. При создании образов они будут сохраняться локально в файловой системе сервера GitLab. Это нормально для частного реестра компании. Однако, если вы планируете сделать свой реестр общедоступным, вам может потребоваться хранилище большего объема. К счастью, GitLab предлагает варианты подключения к бакетам облачного хранилища. Вы можете узнать больше в официальной документации GitLab container registry docs, чтобы узнать, как настроить бакет хранилища для вашего инстанса GitLab.

Шаг 3. Изменение файла gitlab-ci.yml и сборка Docker-образа

Для продолжения этого шага у вас должен быть проект Node Pipeline в вашем инстансе GitLab. Вот как выглядит этот проект в GitLab:

Мы говорили о gitlab-ci.yml как о файле, который считывает GitLab CI runner при запуске, чтобы знать, как собирать ваше приложение и выполнять автоматические тесты. Нам нужно изменить этот файл, чтобы добавить инструкции по сборке Docker-образов. Вы можете отредактировать этот файл прямо в интерфейсе GitLab. Вы также можете клонировать его на свою локальную машину, отредактировать в любимом редакторе, а затем сделать коммит и выполнить git push обратно в GitLab. Для краткости мы будем использовать интерфейс GitLab.

Нажмите на файл, чтобы открыть его, а затем нажмите кнопку Редактировать:

Это откроет файл для редактирования. Удалите все из файла и добавьте следующий код:

Добавляя приведенный выше фрагмент кода, не забудьте обновить выделенную часть своими фактическими данными. Когда закончите, сохраните изменения, нажав кнопку Commit changes. Если вы работали вне GitLab, закоммитьте и отправьте свои изменения.

Давайте разберемся, что делает код, который мы добавили в файл .gitlab-ci.yml. Первая строка указывает GitLab использовать официальный Docker-in-Docker image и подключает его к службе docker-in-docker (docker:dind). Затем мы определяем этапы для build, test, и release. Этап build собирает образ, используя инструкции из Dockerfile, а затем загружает его в Docker Registry, который мы настроили на предыдущем шаге.

При успешном завершении этапа build, этап test скачивает образ, запускает его как контейнер и выполняет команду npm test для проведения автоматического тестирования внутри него. Если этап test завершается успешно, управление переходит к этапу release. На этапе выпуска образ скачивается и помечается тегом node_pipeline:latest. Затем он отправляется обратно в реестр.

Это лишь базовая конфигурация для демонстрационного проекта. В реальных проектах у вас могут быть другие этапы, например staging, production и т. д. При сохранении файла после редактирования запускается конвейер. Затем он начинает выполнять задачи. Вернитесь на страницу Node Pipeline. Вы должны увидеть, что задача в данный момент выполняется:

Нажмите на иконку индикатора CI, чтобы просмотреть различные этапы задачи:

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

В левом меню нажмите на Packages & Registries и выберите Container Registry:

Откроется страница со списком доступных Docker-образов для выбранного проекта. Собранный и выпущенный нами образ должен появиться в списке с тегом присвоенным:

Нажмите, чтобы раскрыть различные теги для образа:

Если на вашем локальном компьютере установлен Docker, вы можете скачать образ и проверить его работу. Нажмите на иконку Copy рядом с именем тега образа. В буфер обмена будет скопировано полное имя образа, которое можно использовать с командой docker pull:

Приведенные выше команды скачают образ и запустят его внутри контейнера:

Приложение теперь доступно на порту 8090. Если вы откроете браузер и перейдете по адресу your-IP-address:8090, вы должны увидеть отображаемую страницу:

Если вы видите такую страницу в своем браузере, значит, вы успешно создали образ Docker и разместили его в приватном Docker Registry. В будущем, если вы внесете какие-либо изменения в master ветку, этапы, определенные в файле .gitlab-ci.yml, будут запущены, и в случае их успешного выполнения новый образ Docker с тегом latest будет пересобран и отправлен в реестр.

Заключение

В этом проекте вы узнали, как добавить privileged раннер GitLab в свой собственный инстанс GitLab, чтобы иметь возможность собирать образы Docker. Вы также настроили приватный реестр образов Docker для их хранения. Используя проект Node pipeline, вы смогли протестировать каждый компонент настройки и убедиться, что они подключаются и взаимодействуют должным образом. Как только ваш образ стал доступен в реестре, вы смогли загрузить его и подтвердить, что он работает внутри контейнера.

Это вводное руководство, дающее вам основы для дальнейшей работы. Пожалуйста, следуйте официальной документации GitLab, чтобы узнать больше о GitLab. Эта ссылка может предоставить информацию о GitLab Container Registry.

Для получения дополнительных ресурсов по использованию Docker вы можете ознакомиться с другими руководствами в нашем блоге:

• Обмен данными между контейнерами Docker
• Настройка приватного Docker Registry на Ubuntu 18.04
• Как обмениваться данными между контейнером Docker и хостом
• Очистка ресурсов Docker — образов, контейнеров и томов

Приятной работы!