Как развернуть свой GitLab с CI-CD, используя IaC

Всем привет! Меня зовут Александр, я обучаюсь в магистратуре СПбПУ. А заодно являюсь младшим разработчиком на C++ и стараюсь использовать и внедрять практики DevOps в мою ежедневную разработку. Недавно я получил зачет за то, что развернул собственный GitLab (именно GitLab, а не аналог) на серверах Selectel ^[1] с CI/CD и Container Registry. Собственно, об этом и расскажу и в статье.

Мы в Selectel готовим новый сервис. Если арендуете серверы в рабочих или личных проектах, нам очень поможет ваш опыт — записывайтесь ^[2] на короткое онлайн-интервью. За участие подарим плюшевого Тирекса и бонусы на услуги Selectel.

Используйте навигацию, если не хотите читать текст полностью:
→ Задача и инструменты ^[3]
→ Поднимаем GitLab ^[4]
→ Запуск GitLab Runner ^[5]
→ Тестируем Франкенштейна ^[6]
→ Выводы ^[7]

Задача и инструменты

В процессе работы необходимо:

1. развернуть GitLab,
2. развернуть и зарегистрировать GitLab Runner,
3. создать учетные записи для студентов из списка.

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

Для описания выделения ресурсов будем использовать Terraform. Он позволяет в формате кода разворачивать цифровые ресурсы. С точки зрения переиспользования конфигурации инфраструктуры это может быть очень полезным инструментом.

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

Действия по развертыванию можно повторить самому, используя проект, опубликованный на GitHub ^[8].

Поднимаем GitLab

Перед этим шагом необходимо выделить публичный IP и зарегистрировать на него домен нашего будущего GitLab.

После того как публичный IP зарегистрирован, заходим в панель управления Selectel ^[9] → Продукты → Облачные серверы.

Нажимаем Создать сервер.

Кликаем по полю Источник, переходим на вкладку Приложения и выбираем Cloud Gitlab 16.11.10 64-bit.

Использование готового образа поможет нам избежать ручной настройки БД и ручного конфигурирования GitLab. Кроме того, в образ входит конфигурация Container Registry. Она позволит хранить собранные для проекта Docker-образы.

Фактически, установка GitLab и GitLab Runner на серверах автоматизирована, необходимо лишь выделить нужное количество ресурсов под наши нужды. Это делается на той же странице чуть ниже.

Выбираем в конфигурации сервера 8 vCPU в соответствии с техническими требованиями GitLab ^[10].

Еще чуть ниже добавляем загрузочный диск (SSD Быстрый, 50 ГБ) и диск для данных (SSD Универсальный v2, 100 ГБ).

Листаем ниже до раздела Автоматизация. Здесь в поле для ввода текста вписываем скрипт cloud-init. Он позволит настроить root-пользователя и корректную временную зону.

#cloud-config
timezone: Europe/Moscow
# Start GitLab Instance
# Configure GitLab root user and DB
write_files:
- path: "/opt/gomplate/values/user-values.yaml"
  permissions: "0644"
  content: |
    gitlabDomain: "<domain_name>"
    gitlabRootEmail: "<email>"
    gitlabRootPassword: "
"
    gitlabPostgresDB: "gitlab"
    gitlabPostgresUser: "gitlab"
    gitlabPostgresPassword: "gitlab"
    useExternalDB: false

Теперь нажимаем Создать сервер и ждем, когда он запустится. GitLab на это нужно около пяти минут, иногда меньше. Если статус сменился на ACTIVE, сервер готов и GitLab запущен.

Все действия выше можно описать с использованием Terraform.

# Создание ключевой пары для доступа к ВМ
module "keypair" {
  source         = "../modules/keypair"
  keypair_name       = "ssh_key_ed"
  keypair_public_key = file("${var.ssh_key_file}.pub")
  region         = var.region
}
# Создание приватной сети для ВМ
module "nat" {
  source = "../modules/nat"
}
# Создание GitLab-сервера.
module "gitlab_server" {
  source = "../modules/server_gitlab"
  server_name         = "gitlab"
  server_zone         = var.server_zone
  server_vcpus        = var.gitlab_vcpus
  server_ram_mb       = var.gitlab_ram_mb
  server_root_disk_gb     = var.gitlab_root_disk_gb
  server_boot_volume_type = var.gitlab_boot_volume_type
  server_volume_type      = var.server_volume_type
  server_image_name       = var.gitlab_image_name
  server_ssh_key      = module.keypair.keypair_name
  region              = var.region
  network_id          = module.nat.network_id
  subnet_id           = module.nat.subnet_id
  attached_disk_gb    = var.gitlab_attached_disk_gb
  public_ip           = var.gitlab_public_ip
  user_data           = file(var.gitlab_user_data_path)
  server_preemptible_tag = var.server_no_preemptible_tag
}
# Создание inventory файла для ansible
resource "local_file" "ansible_inventory" {
  content = templatefile("../resources/inventory.tmpl",
    {
        gitlab_public_ip  = module.gitlab_server.floating_ip
        ssh_key_file      = var.ssh_key_file
    }
  )
  filename = "../../ansible/resources/inventory.ini"
}

Как можно заметить, мы также добавили создание inventory-файла, который содержит публичный IP создаваемого сервера, путь до SSH-ключа и SSH-порт для доступа к серверу:

[gitlab]
${gitlab_public_ip} ansible_ssh_private_key_file=${ssh_key_file} ansible_port=22022

Inventory-файл пригодится нам на следующем этапе для настройки GitLab с помощью Ansible. Пока что будем держать в голове, что он есть.

Все файлы с конфигурацией Terraform и Ansible можно посмотреть в репозитории ^[8].

Запускаем создание инфраструктуры и переходим по указанному домену. Нас встретит страница входа.

Заходим с данными root-пользователя, которые мы указали ранее, и радуемся жизни. Первый этап завершен.

У нас теперь есть свой GitLab!

Конфигурируем GitLab

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

Передача требуемых данных, скриптов, а также их запуск производятся посредствам Ansible.

Конфигурация группы и пользователей

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

def is_invalid_username(username);
    is_invalid = false;
    if User.find_by_username(username);
        is_invalid = true;
    end;
    is_invalid;
End;
# Читаем список пользователей
users_list = File.read('/tmp/users.txt').split(/n/);
unique_users = users_list.group_by { |item| item.downcase };
users_creds = {'users' => Array.new};
# Создаем группу
group_name = 'Devops' + Date.today.cwyear.to_s;
unless Group.find_by_path_or_name(group_name);
    puts 'Creating group';
    group = Group.create;
    group.name = group_name;
    group.path = group.name.downcase;
    group.lfs_enabled = false;
    group.add_owner(User.first);
    group.save!;
end;
group = Group.find_by_path_or_name(group_name);
# Создаем пользователей
puts 'Creating users';
unique_users.each do |key, names|;
    names.each_index do |index|;
        name = names[index];
        t_username = name.gsub(/[[:space:]]/, '').downcase;
        username = t_username;
        password = SecureRandom.hex(12);
        if is_invalid_username(username)
            i = 1;
            while not is_invalid_username(username);
                username = t_username + i.to_s;
                i += 1;
            end;
        end;
    user = User.new(username: "#{username}", email: "#{username}@devops-spbstu.ru", name: "#{name}", password: "#{password}", password_confirmation: "#{password}", admin: false)
    user.assign_personal_namespace(Organizations::Organization.default_organization)
    user.skip_confirmation! # Пропускаем авторизацию пользователя
    user.save!; # Сохраняем пользователя
    users_creds['users'].append({"#{user.name}" => {'login'=>"#{user.username}", "email"=>"#{user.email}", "password"=>"#{user.password}"}}) # Сохраняем данные о пользователе
    group.add_developer(user) # Добавляем пользователя в группу как разработчика
    end;
end;
File.write("/tmp/users-creds.yaml", users_creds.to_yaml); # Сохраняем данные о пользователях в файл

В данном случае имена пользователей читаются из файла /tmp/users.txt. В результате выполнения скрипта данные будут выглядеть следующим образом:

---
users:
- Ivan Ivanov:
    login: ivanivanov
    email: ivanivanov@devops-spbstu.ru
    password: <секретный пароль 1>
- John Cane:
    login: johncane
    email: johncane@devops-spbstu.ru
    password: <секретный пароль 2>

Конфигурация раннера

Для работы с CI/CD в GitLab необходимо веб-приложение (агент) — GitLab Runner. Оно интерпретирует конфигурационный файл CI/CD и автоматически выполняет описанные задачи.

Прежде чем создавать инфраструктуру под веб-приложение через Terraform, необходимо зарегистрировать новую запись об агенте в GitLab и получить ключ доступа.

GitLab Runner регистрируется для всех пользователей и может быть использован для запуска через него CI/CD конвейеров. В данном случае создаем раннер типа Docker с тегом docker:

# Создаем раннер
runner = Ci::Runner.new(description: 'My Shared Runner', active: true, name: 'my-runner' + SecureRandom.hex(4), token: SecureRandom.hex(20), runner_type: Ci::Runner::runner_types["instance_type"]);
runner.docker_executor_type!;
runner.tag_list = ['docker'];
runner.save!; # Сохраняем раннера
runner_cred = {"#{runner.name}" => {"token" => "#{runner.token}"}};
reg_data = {"url"=>"Gitlab.config.gitlab.url", "token"=>"#{runner.token}"}
# Создаем cloud-init файл с токеном раннера
data = '#cloud-config
timezone: Europe/Moscow
write_files:
- path: "/opt/gomplate/values/user-values.yaml"
  permissions: "0644"
  content: |
'
data += "    gitlabURL: "#{Gitlab.config.gitlab.url}"n"
data += "    token: "#{runner.token}"n"
File.write("/tmp/runner-metadata.cfg", data);
File.write("/tmp/runner-creds.yaml", runner_cred.to_yaml);

И вуаля, раннер зарегистрирован. На выходе получаем файл конфигурации для cloud-init.

#cloud-config
timezone: Europe/Moscow
write_files:
- path: "/opt/gomplate/values/user-values.yaml"
 permissions: "0644"
 content: |
   gitlabURL: "https://gitlab.devops-spbstu.ru"
   token: <супер секретный ключ 1>

А также yaml-файл с данными о ранере: название и ключ доступа.

my-runnere8d7802a:
 token: <супер секретный ключ 1>

Кастуем всю магию за раз

Чтобы выполнить это не ручками, а автоматически, повторим все через Ansible.

- name: Configure Gitlab
  hosts: gitlab
  tasks:
    # Меняем временную зону (исправляем 500 код)
    - name: Changing systems timezone
      community.docker.docker_container_exec:
    container: gitlab
    command: ln -s -f /usr/share/zoneinfo/Europe/Moscow /etc/localtime
    - name: Changing gitlab timezone
      community.docker.docker_container_exec:
    container: gitlab
    command: echo "gitlab_rails['time_zone'] = 'Europe/Moscow'" >> /etc/gitlab/gitlab.rb && gitlab-ctl reconfigure && gitlab-ctl restart
    # Создаем пользователей
    - name: Copy users-list to server
      ansible.builtin.copy:
    src: ./resources/users.txt
    dest: /tmp/users.txt
    - name: Copy users-list to gitlab
      community.docker.docker_container_copy_into:
    container: gitlab
    path: /tmp/users.txt
    container_path: /tmp/users.txt
    #
    - name: Copy users-create script to server
      ansible.builtin.copy:
    src: ./scripts/create_users.rb
    dest: /tmp/users.rb
    - name: Copy users-create script to gitlab
      community.docker.docker_container_copy_into:
    container: gitlab
    path: /tmp/users.rb
    container_path: /tmp/users.rb
    - name: Create users
      community.docker.docker_container_exec:
    container: gitlab
    command: gitlab-rails runner /tmp/users.rb
    # Выгружаем данные о пользователях с сервера
    - name: Load users creds to server
      ansible.builtin.shell: docker cp gitlab:/tmp/users-creds.yaml /tmp/users-creds.yaml
    - name: Load users creds locally
      ansible.builtin.fetch:
    src: /tmp/users-creds.yaml
    dest: ./resources/user-creds.yaml
    flat: true
    # Создаем раннер для группы
    - name: Copy runner-create script to server
      ansible.builtin.copy:
    src: ./scripts/create_runner.rb
    dest: /tmp/runner.rb
    - name: Copy runner-create script to gitlab
      community.docker.docker_container_copy_into:
    container: gitlab
    path: /tmp/runner.rb
    container_path: /tmp/runner.rb
    - name: Create group-runner
      community.docker.docker_container_exec:
    container: gitlab
    command: gitlab-rails runner /tmp/runner.rb
    # Выгружаем данные о раннере с сервера
    - name: Load runner creds from gitlab to server
      ansible.builtin.shell: docker cp gitlab:/tmp/runner-creds.yaml /tmp/runner-creds.yaml
    - name: Load runner creds locally
      ansible.builtin.fetch:
    src: /tmp/runner-creds.yaml
    dest: ./resources/runner-creds.yaml
    flat: true
    # Выгружаем cloud-init конфиг раннера с сервера
    - name: Load runner config from gitlab to server
      ansible.builtin.shell: docker cp gitlab:/tmp/runner-metadata.cfg /tmp/runner-metadata.cfg
    - name: Load runner config locally to terraform
      ansible.builtin.fetch:
    src: /tmp/runner-metadata.cfg
    dest: ../terraform/resources/runner_metadata.cfg
    flat: true
    # Перезагружаем Gitlab
    - name: Restarting gitlab
      community.docker.docker_container_exec:
    container: gitlab
    command: gitlab-ctl restart

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

Проверяем, появился ли зарегистрированный раннер в панели администратора. Для этого возвращаемся к Terraform.

Запуск GitLab Runner

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

Рекомендации по установке GitLab Runner советуют ставить GitLab и Runner на отдельных серверах. Поэтому поднимем инфраструктуру для него через Terraform.

Возьмем за основу образ Cloud GitLab Runner 17.5.4 64-bit. Развернем его на базе сервера с 2 CPU, 4 Gb RAM и загрузочным диском (SSD).

Описание через Terraform имеет следующий вид:

# Создание ключевой пары для доступа к ВМ
module "keypair" {
  source         = "../modules/keypair"
  keypair_name       = "ssh_runner_key_ed"
  keypair_public_key = file("${var.ssh_key_file}.pub")
  region         = var.region
}
# Создание приватной сети для ВМ
module "nat" {
  source = "../modules/nat"
}
# Создание GitLab-runner сервера.
module "gitlab_runner_server" {
  source = "../modules/server_gitlab_runner"
  server_name         = "runner"
  server_zone         = var.server_zone
  server_vcpus        = var.runner_vcpus
  server_ram_mb       = var.runner_ram_mb
  server_root_disk_gb     = var.runner_root_disk_gb
  server_boot_volume_type = var.server_volume_type
  server_image_name       = var.runner_image_name
  server_ssh_key      = module.keypair.keypair_name
  region              = var.region
  network_id          = module.nat.network_id
  subnet_id           = module.nat.subnet_id
  user_data           = file(var.runner_user_data_path)
  server_preemptible_tag = var.server_no_preemptible_tag
}

Запустим развертывание через Terraform. Результатом наших действий будет появившийся в панели облачной платформы сервер с GitLab Runner.

Кроме того, состояние нашего раннера должно измениться на активное в панели CI/CD в GItLab.

Раннер запустился и опознался готовым к работе в GitLab. Можно радоваться, жизнь удалась, GitLab и GitLab Runner работают!

Тестируем Франкенштейна

Запустим простой пайплайн со сборкой Python-приложения в Docker-образ через kaniko и выгрузкой в Container Registry. Также заодно запустим тесты.

Описание тестового конвейера:

stages:
 - build
 - test
variables:
 IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
build app:
 stage: build
 image:
   name: gcr.io/kaniko-project/executor:v1.23.2-debug
   entrypoint: [""]
 script:
   - /kaniko/executor
     --context "${CI_PROJECT_DIR}"
     --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
     --destination "$IMAGE_TAG"
 tags:
   - docker
unit tests:
 image: python:3.12-alpine
 stage: test
 before_script:
   - python --version
   - pip install pytest
   - ls
   - ls tests
 script:
   - python -m pytest tests/unit
 needs: [ build app ]
 tags:
   - docker

Структура проекта содержит библиотеку (lib) и тесты на pytest (tests/unit).

Запускаем пайплайн и видим, что он успешно завершился.

Проверяем работу Container Registry и видим, что образ приложения появился в проекте.

Какие были трудности

А теперь небольшой «нытинг». Для меня задача по развертыванию GitLab оказалась новой и была неким вызовом, чтобы попробовать свои силы в области, отличной от моей основной деятельности.

Корявые временные настройки

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

Отсутствие документации GitLab Rails

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

Выводы

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

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

Всем спасибо!