Наша команда почала перехід на Terraform навесні. Сформували вимоги до коду, правила найменувань для ресурсів, погодили з іншими дотичними відділами. Цей процес тісно пов’язаний з глобальним переходом компанії в AWS Cloud. Ще з самого початку ми вирішили закласти надійний фундамент нашої інфраструктури, базуючись на підходах IaC (Infrastructure as a Code).

Так могла починатись стаття про більш-менш стандартне використання Terraform. Але зараз ми спробуємо поговорити саме про конфігурацію і налаштування наших інструментів розробки.

Більшість людей використовують Terraform для роботи з інфраструктурою у хмарах —  Amazon, Google, Azure. Але функціонал інструмента ширший, він дозволяє менеджерити сторонні сервіси за допомогою досить великого вибору провайдерів (як офіційних, так і від ком’юніті). Ми використовуємо Terraform комплексно — для менеджменту інфраструктури, на якій працюємо. Це — GitLab, SonarQube (і, можливо, у майбутньому Artifactory). Ці інструменти застосовуємо для організації робочого простору команд.

Як організована робота з онбордингу нового проєкту

В компанії зʼявляється новий проєкт, якому потрібно створити підгрупу, репозиторії тощо в Gitlab. Для аналізу коду ми використовуємо ще й SonarQube.Тому необхідно зробити такі ж речі для нового проєкту ще і на ньому, щоб забезпечити командам можливість безшовної інтеграції для перевірки якості коду. За допомогою Terraform з урахуванням узгодження імен для ресурсів створюється група для групи репозиторіїв проєкту та окремий проєкт, який відповідає GitLab.

Також створюються секʼюріті групи для звʼязку з Active Directory. Це зручно для наших розробників, оскільки допомагає отримувати доступ до проєктів на GitLab.

Далі ми забезпечуємо безшовну інтеграцію цих двох інструментів. У звичайному кейсі (ручна робота) треба, щоб користувач додав лінк, токен інтеграцій, спеціальну задачу в сам пайплайн. Ми тут трохи ліниві, тому це теж автоматизували. Інтеграція виходить зворотна: спочатку ми створюємо сутності на GitLab та SonarQube, а потім додаємо токен інтеграцію в потрібний проєкт на GitLab. 

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

В цей пайплайн можна додати Artifactory — сервіс, що дозволяє мати приватні репозиторії на будь-яку технологію. Це контейнери, Terraform-модулі тощо. Зазвичай кінцевим результатом діяльності є артефакт. Хороша практика — мати під них окремі репозиторії. Коли зʼявляється новий проєкт, на Artifactory так само треба створити місце, куди команди вивантажуватимуть результати своєї роботи.

Як виглядає наш флоу для інженера

Приклад коду Terraform для налаштування частини з SonarQube

“`

#################################################################################

# SonarQube project configuration

#################################################################################

resource “sonarqube_project” “this” {

  name       = var.name

  project    = var.name

  visibility = var.project_visability_level

  tags       = [lower(var.project_tag)]

}

resource “sonarqube_permissions” “this” {

  group_name  = “temabit/${lower(var.project_tag)}”

  project_key = sonarqube_project.this.project

  permissions = [“codeviewer”, “user”]

}

#################################################################################

# SonarQube Project Analysis token

#################################################################################

resource “terraform_data” “retention_trigger” {

  input            = var.project_token_retention

  triggers_replace = true

}

resource “sonarqube_user_token” “this” {

  name            = “${lower(var.project_tag)}-${var.name}-project-token”

  type            = var.token_access_level

  project_key     = sonarqube_project.this.project

  expiration_date = local.user_token_expires_at

  login_name      = var.sonarqube_integration_user

  lifecycle {

    ignore_changes = [

      expiration_date

    ]

    replace_triggered_by = [

      terraform_data.retention_trigger

    ]

  }

}

#################################################################################

# Gitlab Project SonarQube token

#################################################################################

data “gitlab_project” “this” {

  path_with_namespace = var.project_subgroup == null ? “temabit/${var.project_tag}/${var.name}” : “temabit/${var.project_tag}/${var.project_subgroup}/${var.name}”

}

resource “gitlab_project_variable” “sonar_token” {

  project = data.gitlab_project.this.id

  key     = “SONAR_TOKEN”

  value   = sonarqube_user_token.this.token

  masked  = true

}

resource “gitlab_project_variable” “sonar_url” {

  project = data.gitlab_project.this.id

  key     = “SONAR_HOST_URL”

  value   = var.sonarqube_url

  masked  = false

}

“`

У чому переваги Terraform

Перевага процесу в тому, що це один пайплайн. Все працює максимально швидко. Формуємо тікет, даємо назву. Далі наш інженер створює конфігурацію для Terraform, контролює, що все працює, дає апрув пайплайну, і за декілька хвилин отримуємо всі необхідні налаштування для роботи з новим проєктом. Час на опрацювання тікету — до 30 хвилин. Але ми плануємо в майбутньому повністю автоматизувати і цей процес.

Навіщо ми це робимо? Це дозволяє суттєво скоротити витрати часу інженера на обробку запитів, а також —  скоротити рутинні задачі. Допомагає сфокусуватись і не розпорошує увагу інженера. Все контролюється, ми бачимо всі зміни.

Як команда адаптувалася до Terraform

Ми стартували фактично з нуля з новим інструментом — GitLab. Разом з командою почали все автоматизовувати. Раніше ми всі уже працювали з Terraform. Команда зібралася досить досвідчена, тож було не дуже складно, але це був новий етап — ми по-іншому підійшли до використання Terraform. Якщо повернутись до питання загального використання Terraform, то слід зазначити що ми продовжуємо розширювати горизонти й зміцнюємо технічну експертизу. До прикладу, використання AWS CDK можливе з усіма перевагами Terraform. Але це тема іншої статті.

З гарних результатів — процес онбордингу скоротився з трьох годин до 30 хвилин. Звісно, тут присутній людський фактор — скажімо, інженера може не бути на робочому місці, і потрібен буде додатковий час. Але працюємо і над цим. Наразі тестуємо різні рішення. Намагаємось знайти оптимальний набір інструментів, який підходить саме нам. Головне, щоб час технічної та рутинної роботи значно зменшився.

Олександр Сапожніков, Lead of SRE Team, TemaBit Fozzy Group