Поиск по сайту:

Как настроить конвейеры непрерывной интеграции с GitLab CI в Ubuntu 16.04

Введение

GitLab Community Edition — это независимый поставщик Git-репозитория с дополнительными функциями, помогающими в управлении проектами и разработке программного обеспечения. Одной из самых ценных функций, которые предлагает GitLab, является встроенный инструмент непрерывной интеграции и доставки под названием GitLab CI.

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

Предпосылки

Прежде чем мы начнем, вам нужно настроить начальную среду. Нам нужен безопасный сервер GitLab, настроенный для хранения нашего кода и управления нашими процессами CI/CD. Кроме того, нам нужно место для запуска автоматических тестов. Это может быть либо тот же сервер, на котором установлен GitLab, либо отдельный хост. В следующих разделах требования более подробно описаны.

Сервер GitLab, защищенный с помощью SSL

Для хранения исходного кода и настройки наших задач CI/CD нам нужен экземпляр GitLab, установленный на сервере Ubuntu 16.04. В настоящее время GitLab рекомендует сервер как минимум с 2 ядрами ЦП и 4 ГБ ОЗУ. Чтобы защитить ваш код от раскрытия или подделки, экземпляр GitLab будет защищен с помощью SSL с использованием Let’s Encrypt. Ваш сервер должен иметь доменное имя или субдомен, связанный с ним, чтобы выполнить этот шаг.

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

  • Начальная настройка сервера с Ubuntu 16.04: создайте пользователя sudo и настройте базовый брандмауэр
  • Как установить и настроить GitLab в Ubuntu 16.04: установите GitLab на сервер и защитите его с помощью сертификата Let’s Encrypt TLS/SSL

Мы продемонстрируем, как совместно использовать исполнители CI/CD (компоненты, запускающие автоматические тесты) между проектами и как привязать их к отдельным проектам. Если вы хотите совместно использовать исполнителей CI между проектами, мы настоятельно рекомендуем вам ограничить или отключить публичную регистрацию. Если вы не изменили свои настройки во время установки, вернитесь назад и выполните необязательный шаг из статьи об установке GitLab об ограничении или отключении регистрации для предотвращения злоупотреблений со стороны сторонних лиц.

Один или несколько серверов для использования в качестве исполнителей GitLab CI

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

Этот шаг можно выполнить на сервере GitLab или на другом сервере Ubuntu 16.04, чтобы обеспечить дополнительную изоляцию и избежать конкуренции за ресурсы. Следующие руководства установят Docker на хост, который вы хотите использовать для запуска тестов:

  • Начальная настройка сервера с Ubuntu 16.04: создайте пользователя sudo и настройте базовый брандмауэр (вам не нужно выполнять это снова, если вы настраиваете средство выполнения CI на сервере GitLab)
  • Как установить и использовать Docker в Ubuntu 16.04: выполните шаги 1 и 2, чтобы установить Docker на сервер

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

Копирование примера репозитория с GitHub

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

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

На новой странице проекта нажмите на вкладку Импорт проекта:

Затем нажмите кнопку «Репозиторий по URL». Хотя есть вариант импорта GitHub, для него требуется токен личного доступа, и он используется для импорта репозитория и дополнительной информации. Нас интересует только код и история Git, поэтому импортировать по URL проще.

В поле URL-адрес репозитория Git введите следующий URL-адрес репозитория GitHub:

https://github.com/do-community/hello_hapi.git

Это должно выглядеть так:

Поскольку это демонстрация, вероятно, лучше оставить репозиторий с пометкой «Частный». Когда вы закончите, нажмите «Создать проект».

Новый проект будет создан на основе репозитория, импортированного из GitHub.

Понимание файла .gitlab-ci.yml

GitLab CI ищет файл с именем .gitlab-ci.yml в каждом репозитории, чтобы определить, как следует тестировать код. В импортированном репозитории есть файл gitlab-ci.yml, уже настроенный для проекта. Вы можете узнать больше о формате, прочитав справочную документацию .gitlab-ci.yml.

Нажмите на файл .gitlab-ci.yml в интерфейсе GitLab для только что созданного проекта. Конфигурация CI должна выглядеть так:

image: node:latest

stages:
  - build
  - test

cache:
  paths:
    - node_modules/

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

test_with_lab:
  stage: test
  script: npm test

В файле используется синтаксис конфигурации GitLab CI YAML для определения действий, которые следует выполнять, порядка их выполнения, условий их выполнения и ресурсов, необходимых для выполнения каждой задачи. При написании собственных файлов GitLab CI вы можете посетить синтаксический линтер, перейдя в /ci/lint в своем экземпляре GitLab, чтобы убедиться, что ваш файл отформатирован правильно.

Файл конфигурации начинается с объявления image Docker, который следует использовать для запуска набора тестов. Поскольку Hapi — это фреймворк Node.js, мы используем последний образ Node.js:

image: node:latest

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

stages:
  - build
  - test

Имена, которые вы выбираете здесь, произвольны, но порядок определяет порядок выполнения последующих шагов. Этапы — это теги, которые можно применять к отдельным заданиям. GitLab будет запускать задания одного и того же этапа параллельно и будет ждать выполнения следующего этапа, пока не будут выполнены все задания на текущем этапе. Если этапы не определены, GitLab будет использовать три этапа, называемые build, test и deploy, и назначит все задания test этап по умолчанию.

После определения этапов конфигурация включает определение cache:

cache:
  paths:
    - node_modules/

Это указывает файлы или каталоги, которые можно кэшировать (сохранять для последующего использования) между запусками или этапами. Это может помочь сократить время, необходимое для выполнения заданий, зависящих от ресурсов, которые могут не меняться между запусками. Здесь мы кэшируем каталог node_modules, куда npm будет устанавливать загружаемые зависимости.

Наша первая задача называется install_dependencies:

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

Задания могут называться как угодно, но, поскольку имена будут использоваться в пользовательском интерфейсе GitLab, описательные имена полезны. Обычно npm install можно комбинировать со следующими этапами тестирования, но чтобы лучше продемонстрировать взаимодействие между этапами, мы извлекаем этот этап для выполнения на отдельном этапе.

Мы явно помечаем этап как \build с помощью директивы stage. Затем мы указываем фактические команды для запуска с помощью директивы script. Вы можете включить несколько команд, добавив дополнительные строки в разделе script.

Подраздел artifacts используется для указания путей к файлам или каталогам для сохранения и передачи между этапами. Поскольку команда npm install устанавливает зависимости для проекта, нашему следующему шагу потребуется доступ к загруженным файлам. Объявление пути node_modules гарантирует, что на следующем этапе будет доступ к файлам. Они также будут доступны для просмотра или загрузки в пользовательском интерфейсе GitLab после тестирования, поэтому это также полезно для создания артефактов, таких как двоичные файлы. Если вы хотите сохранить все, что было создано на этапе, замените весь раздел paths на untracked: true.

Наконец, второе задание с именем test_with_lab объявляет команду, которая фактически запустит набор тестов:

test_with_lab:
  stage: test
  script: npm test

Мы помещаем это на этап test. Поскольку это более поздний этап, он имеет доступ к артефактам, созданным на этапе build, которые в нашем случае являются зависимостями проекта. Здесь раздел script демонстрирует однострочный синтаксис YAML, который можно использовать, когда есть только один элемент. Мы могли бы использовать этот же синтаксис и в предыдущем задании, поскольку была указана только одна команда.

Теперь, когда у вас есть общее представление о том, как файл .gitlab-ci.yml определяет задачи CI/CD, мы можем определить один или несколько исполнителей, способных выполнять план тестирования.

Запуск непрерывной интеграции

Поскольку наш репозиторий включает файл .gitlab-ci.yml, любые новые коммиты вызовут новый запуск CI. Если нет доступных исполнителей, для выполнения CI будет установлено значение «ожидание». Прежде чем мы определим исполнителя, давайте запустим выполнение CI, чтобы увидеть, как выглядит задание в состоянии ожидания. забрать ожидающий пробег.

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

На следующей странице введите dummy_file в поле Имя файла и введите текст в главном окне редактирования:

Нажмите Подтвердить изменения внизу, когда закончите.

Теперь вернитесь на главную страницу проекта. Небольшой значок паузы будет прикреплен к самой последней фиксации. Если вы наведете курсор мыши на значок, он отобразит «Commit:pending»:

Это означает, что тесты, проверяющие изменения кода, еще не выполнялись.

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

Примечание. С правой стороны находится кнопка для инструмента CI Lint. Здесь вы можете проверить синтаксис любых файлов gitlab-ci.yml, которые вы пишете.

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

Наконец, щелкните задание install_dependencies. Это даст вам конкретные сведения о том, что задерживает запуск:

Здесь сообщение указывает на то, что задание зависло из-за отсутствия исполнителей. Это ожидается, поскольку мы еще ничего не настроили. Когда бегун становится доступным, этот же интерфейс можно использовать для просмотра вывода. Это также место, где вы можете загрузить артефакты, созданные во время сборки.

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

Установка службы GitLab CI Runner

Теперь мы готовы настроить GitLab CI runner. Для этого нам нужно установить в систему пакет GitLab CI runner и запустить службу GitLab runner. Служба может запускать несколько экземпляров исполнителя для разных проектов.

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

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

Начните с загрузки последней версии скрипта конфигурации репозитория GitLab CI runner в каталог /tmp (это репозиторий, отличный от того, который используется сервером GitLab):

  1. curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh

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

  1. less /tmp/gl-runner.deb.sh

Как только вы будете удовлетворены безопасностью скрипта, запустите установщик:

  1. sudo bash /tmp/gl-runner.deb.sh

Скрипт настроит ваш сервер для использования поддерживаемых GitLab репозиториев. Это позволяет вам управлять пакетами GitLab runner с помощью тех же инструментов управления пакетами, которые вы используете для других системных пакетов. После этого вы можете продолжить установку с помощью apt-get:

  1. sudo apt-get install gitlab-runner

Это установит пакет запуска GitLab CI в системе и запустит службу запуска GitLab.

Настройка GitLab Runner

Далее нам нужно настроить GitLab CI runner, чтобы он мог начать принимать работу.

Для этого нам нужен токен исполнителя GitLab, чтобы бегун мог аутентифицироваться на сервере GitLab. Тип токена, который нам нужен, зависит от того, как мы хотим использовать этот бегун.

Бегун для конкретного проекта полезен, если у вас есть особые требования к бегуну. Например, если в вашем файле gitlab-ci.yml определены задачи развертывания, для которых требуются учетные данные, для правильной аутентификации в среде развертывания может потребоваться определенный исполнитель. Если в вашем проекте есть ресурсоемкие шаги в процессе CI, это также может быть хорошей идеей. Бегун конкретного проекта не будет принимать задания из других проектов.

С другой стороны, общий бегун — это бегун общего назначения, который можно использовать в нескольких проектах. Исполнители будут брать задания из проектов в соответствии с алгоритмом, учитывающим количество заданий, выполняемых в настоящее время для каждого проекта. Этот тип бегуна более гибкий. Вам нужно будет войти в GitLab с учетной записью администратора, чтобы настроить общие бегуны.

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

Сбор информации для регистрации исполняющей программы для конкретного проекта

Если вы хотите, чтобы бегун был привязан к конкретному проекту, начните с перехода на страницу проекта в интерфейсе GitLab.

Отсюда щелкните пункт «Настройки» в меню слева. После этого щелкните пункт CI/CD в подменю:

На этой странице вы увидите раздел настроек Runners. Нажмите кнопку Развернуть, чтобы увидеть больше деталей. В подробном представлении в левой части поясняется, как зарегистрировать бегун для конкретного проекта. Скопируйте регистрационный токен, отображаемый на шаге 4 инструкции:

Если вы хотите отключить какие-либо активные общие бегуны для этого проекта, вы можете сделать это, нажав кнопку «Отключить общие бегуны» справа. Это необязательно.

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

Сбор информации для регистрации общего бегуна

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

Начните с нажатия значка гаечного ключа на верхней панели навигации, чтобы получить доступ к области администрирования. В разделе «Обзор» левого меню нажмите Runners, чтобы получить доступ к странице конфигурации общего бегуна:

Скопируйте токен регистрации, отображаемый в верхней части страницы:

Мы будем использовать этот токен для регистрации исполнителя GitLab CI для проекта.

Регистрация GitLab CI Runner на сервере GitLab

Теперь, когда у вас есть токен, вернитесь на сервер, на котором установлена служба GitLab CI runner.

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

  1. sudo gitlab-runner register

Вам будет задан ряд вопросов для настройки бегуна:

Пожалуйста, введите URL-адрес координатора gitlab-ci (например, https://gitlab.com/)

Введите доменное имя вашего сервера GitLab, используя https:// для указания SSL. При желании вы можете добавить /ci в конец вашего домена, но последние версии будут перенаправляться автоматически.

Пожалуйста, введите токен gitlab-ci для этого бегуна

Токен, который вы скопировали в последнем разделе.

Пожалуйста, введите описание gitlab-ci для этого бегуна

Имя для этого конкретного бегуна. Это будет отображаться в списке бегунов службы запуска в командной строке и в интерфейсе GitLab.

Пожалуйста, введите теги gitlab-ci для этого бегуна (через запятую)

Это теги, которые вы можете назначить бегуну. Задания GitLab могут выражать требования в терминах этих тегов, чтобы убедиться, что они выполняются на хосте с правильными зависимостями.

В этом случае вы можете оставить это поле пустым.

Привязывать ли Runner к текущему проекту [true/false]

Назначает бегуна конкретному проекту. Его нельзя использовать в других проектах.

Выберите «ложь» здесь.

Пожалуйста, введите исполнителя

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

Выберите «докер» здесь.

Пожалуйста, введите образ Docker по умолчанию (например, ruby: 2.1)

Изображение по умолчанию, используемое для запуска заданий, когда файл .gitlab-ci.yml не содержит спецификации изображения. Лучше всего указать здесь общее изображение и определить более конкретные изображения в файле .gitlab-ci.yml, как это сделали мы.

Мы введем здесь \alpine:latest в качестве небольшого безопасного значения по умолчанию.

После ответов на запросы будет создан новый исполнитель, способный выполнять задачи CI/CD вашего проекта.

Вы можете увидеть бегунов, которые в настоящее время доступны в сервисе бегунов GitLab CI, набрав:

  1. sudo gitlab-runner list



Output
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
example-runner                                      Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com

Теперь, когда у нас есть доступный раннер, мы можем вернуться к проекту в GitLab.

Просмотр выполнения CI/CD в GitLab

Вернувшись в веб-браузер, вернитесь к своему проекту в GitLab. В зависимости от того, сколько времени прошло с момента регистрации вашего бегуна, бегун может работать в настоящее время:

Или, возможно, он уже завершен:

Независимо от состояния, щелкните значок выполнения или прохождения (или сбоя, если вы столкнулись с проблемой), чтобы просмотреть текущее состояние выполнения CI. Вы можете получить аналогичный вид, щелкнув верхнее меню Pipelines.

Вы попадете на страницу обзора пайплайна, где сможете увидеть статус запуска GitLab CI:

Под заголовком «Этапы» будет кружок, показывающий статус каждого из этапов выполнения. Если вы нажмете на этап, вы увидите отдельные задания, связанные с этапом:

Нажмите на задание install_dependencies на этапе сборки. Вы перейдете на страницу обзора вакансий:

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

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

Заключение

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