Infrastructure as a Code: ожидания и реальность (2023)

Wandarnem 7 часов назад

Блог компании Яндекс Практикум Системное администрирование *Программирование *DevOps *

Кейс

Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.

Не спешите применять это правило ко всем знакомым SRE, потому что в основном они поддерживают инфраструктуру проекта: запускают серверы, мониторят Kubernetes и перекладывают JSON из одного сервиса в другой. Решение всех этих задач они стремятся оформить в виде кода: скриптов, утилит, пайплайнов и манифестов.

А ведь со временем кода станет очень много, и его придётся читать, тестировать, рефакторить. Можно переписать внутреннее устройство функции, но для пользователя функции её поведение не изменится. Зато читабельность и производительность кода возрастут!

Рефакторить — перерабатывать архитектуру кода так, чтобы это было незаметно внешним пользователям.

У ребят из команды SRE основной объём кода будет инфраструктурным, то есть манифесты описания инфраструктуры. И стандарт де-факто для такого описания сегодня — это Terraform. Жизненный цикл сопровождения такого Tеrraform-кода зависит от проекта, и тут нет «волшебной пилюли» и строгих правил.

Разберём один из примеров организации IaaC-репозитория (Infrastructure as a Code) для Terraform и начнём с вредных советов.

Ничто не предвещало беды

На старте проекта вы создаёте свою первую виртуальную машину в Terraform-манифесте с помощью соответствующего ресурса.

Ресурсом в Terraform называется блок, описывающий инфраструктурный объект в облаке: виртуальная машина, сеть или DNS-запись.

Здесь и далее в качестве примера будем использовать Terraform-провайдер для Yandex Cloud.

Сделайте так, чтобы в файле-манифесте compute.tf у вас появилось описание:

compute.tf

resource "yandex_compute_instance" "default" { name = "test" platform_id = "standard-v1" zone = "ru-central1-a" resources { cores = 2 memory = 4 } boot_disk { initialize_params { image_id = "image_id" } } network_interface { subnet_id = "${yandex_vpc_subnet.foo.id}" } metadata = { foo = "bar" ssh-keys = "ubuntu:${file("~/.ssh/id_rsa.pub")}" }}

Хотя нет. Сначала нужно создать VPC и подсеть: разместим эти ресурсы в файле network.tf.

network.tf

resource "yandex_vpc_network" "foo" {}resource "yandex_vpc_subnet" "foo" { zone = "ru-central1-a" network_id = "${yandex_vpc_network.foo.id}" v4_cidr_blocks = ["10.5.0.0/24"]}

Теперь нам нужно запустить Kubernetes-кластер в облаке, поэтому создадим файл k8s.tf:

k8s.tf

resource "yandex_kubernetes_cluster" "my_cluster" { name = "name" description = "description" network_id = "${yandex_vpc_network.network_resource_name.id}" master { version = "1.17" zonal { zone = "${yandex_vpc_subnet.foo.zone}" subnet_id = "${yandex_vpc_subnet.foo.id}" } public_ip = true security_group_ids = ["${yandex_vpc_security_group.security_group_name.id}"] maintenance_policy { auto_upgrade = true maintenance_window { start_time = "15:00" duration = "3h" } } master_logging { enabled = true log_group_id = "${yandex_logging_group.log_group_resoruce_name.id}" kube_apiserver_enabled = true cluster_autoscaler_enabled = true events_enabled = true } } service_account_id = "${yandex_iam_service_account.service_account_resource_name.id}" node_service_account_id = "${yandex_iam_service_account.node_service_account_resource_name.id}" labels = { my_key = "my_value" my_other_key = "my_other_value" } release_channel = "RAPID" network_policy_provider = "CALICO" kms_provider { key_id = "${yandex_kms_symmetric_key.kms_key_resource_name.id}" }}

И сюда же добавим описание нод-кластера. Или давайте добавим ноды в отдельный файл k8s-nodes.tf, ведь бывает много отдельных групп, которые нужно быстро найти:

k8s-nodes.tf

resource "yandex_kubernetes_node_group" "my_node_group" { cluster_id = "${yandex_kubernetes_cluster.my_cluster.id}" name = "name" description = "description" version = "1.22" labels = { "key" = "value" } instance_template { platform_id = "standard-v2" network_interface { nat = true subnet_ids = ["${yandex_vpc_subnet.foo.id}"] } resources { memory = 2 cores = 2 } boot_disk { type = "network-hdd" size = 64 } scheduling_policy { preemptible = false } container_runtime { type = "containerd" } } scale_policy { fixed_scale { size = 1 } } allocation_policy { location { zone = "ru-central1-a" } } maintenance_policy { auto_upgrade = true auto_repair = true maintenance_window { day = "monday" start_time = "15:00" duration = "3h" } maintenance_window { day = "friday" start_time = "10:00" duration = "4h30m" } }}

Но виртуальных машин у нас может быть много, да и кластеров K8s тоже. Поэтому разделим их не по типу ресурса, а по проектам. Так проще сопровождать конкретный проект. Создадим файл project1.tf.

Зависимости

Ресурсы в манифестах обязательно зависят друг от друга — идентификаторы одних ресурсов будут использоваться в описании других.

Например, чтобы быстро находить серверы при настройке сетевых доступов между ними, создадим файл для групп безопасности (security groups) — sg.tf.

Виртуальным машинам нужен доступ в Kubernetes, а сервисам в Kubernetes — к виртуальным машинам. А ещё некоторые виртуальные машины «ровнее других», и им нужен доступ к сервисам в другом проекте (но не наоборот).

В одном проекте такие зависимости легко реализуются. Можно сослаться на идентификатор ресурса в соответствующих правилах:

resource "yandex_vpc_security_group" "group1" { name = "My security group 1" description = "description for my security group" network_id = yandex_vpc_network.foo.id # Разрешаем исходящий трафик к хостам group2 egress { protocol = "UDP" description = "rule3 description" security_group_id = yandex_vpc_security_group.group2.id port = 8080 }}resource "yandex_vpc_security_group" "group2" { name = "My security group 2" description = "description for my security group" network_id = yandex_vpc_network.foo.id # Разрешаем входящий трафик от хостам group1 ingress { protocol = "TCP" description = "rule1 description" security_group_id = yandex_vpc_security_group.group1.id port = 8080 }}

Но подождите, у нас тут циклическая зависимость двух ресурсов. Давайте для каждого сервиса будем создавать по две группы безопасности. Одну сделаем пустой и будем указывать её в правилах других групп безопасности, а вторая поработает в правилах:

# Пустая группа для хостов group1resource "yandex_vpc_security_group" "group1-initial" { name = "My initial security group 1" description = "description for my security group" network_id = yandex_vpc_network.foo.id}resource "yandex_vpc_security_group" "group1" { name = "My security group 1" description = "description for my security group" network_id = yandex_vpc_network.foo.id# Чтобы избежать циклических зависимостей, указываем пустую group2-initial egress { protocol = "UDP" description = "rule3 description" security_group_id = yandex_vpc_security_group.group2-initial.id port = 8080 }}resource "yandex_vpc_security_group" "group2-initial" { name = "My security group 2" description = "description for my security group" network_id = yandex_vpc_network.foo.id}resource "yandex_vpc_security_group" "group2" { name = "My security group 2" description = "description for my security group" network_id = yandex_vpc_network.foo.id ingress { protocol = "TCP" description = "rule1 description" security_group_id = yandex_vpc_security_group.group1-initial.id port = 8080 }}

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

Некоторое время спустя

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

.├── project1.tf├── project1-xyz.tf├── project1-db-master.tf├── project1-s3-project2-copy1.tf├── project1-s3-project3-copy1.tf├── project1-s3-project3.tf├── project1-s3-project4.tf├── project1-subnets.tf├── project1-secrets.tf├── project-6.tf├── project2-test.tf├── project2-test2.tf├── project2-integrations.tf├── project2-from-company.tf├── project2-dev.tf├── project2-ci.tf├── project2-to-company-sg.tf├── project2-to-company.tf├── jump-host.tf├── monitoring.tf├── cdn-internal.tf├── cdn-external.tf├── cicd.tf├── siem-dev-compute.tf├── cloud-init│ ├── de-keys│ ├── de-devops-keys│ ├── de-admin-keys│ ├── de-whoami-keys│ ├── devops-keys│ ├── ipv4-router.yaml│ ├── ipv6-router.yaml│ ├── scripts.yaml│ ├── k8s-keys│ ├── super-super-users.yaml│ └── super-users.yaml├── cloud.tf├── cloud_company_test.tf├── compute-non-production.tf├── compute.tf├── control.tf├── servers.tf├── dev-project1-integrations-kafka-topics.tf├── dev-project1-integrations-kafka.tf├── dev-project1-integrations.tf├── dev-project1-db.tf├── my-vm.tf├── dns-microservices.tf├── dns-macroservices.tf├── inokentiy.tf├── accounting-1c.tf├── accounting-1c-enterprise.tf├── accounting-backups.tf├── accounting-db.tf├── accounting-analytics.tf├── accounting-project8-s3.tf├── accounting-containers.tf├── accounting-s3.tf├── accounting-subnets.tf├── accounting.tf├── express-all.tf├── security-rules-s3.tf├── security-rules.tf├── ci-project1-sec.tf├── ci-ansible.tf├── ci-autotests.tf├── ci-common.tf├── ci-deploy.tf├── ci-accounting.tf├── ci-infra.tf├── ci-here.tf├── ci-project8.tf├── ci-build.tf├── ci-tf.tf├── cicd2.tf├── mons.tf├── iam.tf├── proxy-nonsecure.tf├── proxy-secure.tf├── ipsec.tf├── k8s-sib.tf├── k8s-common.tf├── k8s-dev-common-nodes.tf├── k8s-dev-ingress.tf├── k8s-dev-nodes.tf├── k8s-dev-sa.tf├── k8s-dev-vm-nodes.tf├── k8s-dev.tf├── k8s-secure-dev-common-nodes.tf├── k8s-secure-dev-ingress.tf├── k8s-secure-dev-nodes.tf├── k8s-secure-dev-vm-nodes.tf├── k8s-secure-dev.tf├── k8s-test-common-nodes.tf├── k8s-test-ingress.tf├── k8s-test-nodes.tf├── k8s-test-secure-common-nodes.tf├── k8s-test-secure-ingress.tf├── k8s-test-secure-nodes.tf├── k8s-test-secure-sql-nodes.tf├── k8s-test-secure-vm-nodes.tf├── k8s-test-secure.tf├── k8s-test-sa.tf├── k8s-test-vm-nodes.tf├── k8s-test.tf├── keys.tf├── lb.tf├── test-dev-compute.tf├── adapter.tf├── connector.tf├── db-backend-baza.tf├── db-backend.tf├── db.tf├── midnight-computer.tf├── nat.tf├── network.tf├── cache.tf├── outputs.tf├── secure-dmz.tf├── backups.tf├── project8-stand-folder.tf├── project8-stand-sg.tf├── project8-stands.tf├── project8-proxy.tf├── project8-new-left.tf├── project8-new.tf├── project8-new-vars.tf├── project8-folder.tf├── project8-some-tests.tf├── project8-lb.tf├── project8-proxy-compute.tf├── project8-proxy-sg.tf├── project8-proxy-variables.tf├── project8-smoke-compute.tf├── project8-smoke-dns.tf├── project8-smoke-db.tf├── project8-smoke-network.tf├── project8-smoke-s3.tf├── project8-smoke-sg.tf├── project8-smoke-variables.tf├── project8-test-compute.tf├── project8-test-dns.tf├── project8-test-folder.tf├── project8-test-lb.tf├── project8-test-lockbox.tf├── project8-test-db.tf├── project8-test-network.tf├── project8-test-copies.tf├── project8-test-sg.tf├── project8-test-variables.tf├── project8-testlab-compute.tf├── project8-to-internet.tf├── project8-test-folder.tf├── project8-test.tf├── proxy-to-partners.tf├── qa.tf├── containers.tf├── s3.tf├── s3_project8_project1.tf├── s3_project8_project2.tf├── external-to-project8.tf├── scripts│ ├── manage.sh│ └── unmanage.sh├── project7-test.tf├── project7.tf├── sg-for-servers.tf├── sg.tf├── sg-nikolay.tf├── work-in-progress.tf├── ver1-work-in-progress.tf├── sib-compute.tf├── sib-lb.tf├── sib-db.tf├── sib-other.tf├── sib-sg.tf├── wtf.tf├── analyze-compute.tf├── analyze-lb.tf├── analyze-db-proxy.tf├── analyze-other.tf├── analyze-sg.tf├── templates│ ├── script.yaml│ ├── open.yaml│ ├── forwarder.yaml│ ├── logs.yaml│ └── logs-forwarder.yaml├── test-project1-integrations-kafka-topics.tf├── test-project1-integrations-kafka.tf├── test-project1-integrations.tf├── test-project1-db-int.tf├── test-project1-db.tf├── test-project1-s3-exchange.tf├── test-project1-s3-project8.tf├── test-project1-s3-wtf.tf├── test-project1-subnets.tf├── test-dns-microservices.tf├── test-dns-macroservices.tf├── test-backend-kafka.tf├── test-backend-redis.tf├── test-backend-db.tf├── secrets-test-dev-compute.tf├── secrets.tf├── playground.tf├── manager.tf├── s3-share.tf└── sa.tf

Если вы хотели посмотреть на реальный проект — вот он выше.

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

Если запустить terraform plan в таком проекте, то можем ждать от 10 до 40 минут, и наш state заблокируется на всё время выполнения.

plan показывает намерения изменений, которые Terraform собирается выполнить.

terraform state — это хранилище состояния текущей инфраструктуры. Такое состояние сравнивается с кодом описания в манифестах и с реальным положением вещей в облаке. После такого сравнения Terraform принимает решение о выполнении изменений. Стейт хранится в файле, поэтому можете использовать различные бэкенды для централизованного размещения этого файла.

Как раз успеете распить цикорий всей командой.

Хотя, конечно, добавление очередной виртуальной машины или правила в группу безопасности займёт гораздо больше времени: понадобится раскрутить клубок зависимостей, вставить описание ресурсов в нужное место и проделать несколько итераций запуска terraform plan для отладки изменений.

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

Самое главное — работой вы точно будете обеспечены! Со временем и вовсе станете матёрыми экспертами: в голове кристаллизуется граф зависимостей между ресурсами, в котором вы будете хорошо ориентироваться, а у молодого и неопытного джуна появится наставник.

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

А что тут плохого?

Давайте выпишем список совершенных грехов:

1. В репозитории отсутствует хоть сколько-нибудь логичная структура — в этом наборе файлов сам чёрт ногу сломит.

2. Блокирование стейта снижает эффективность команды: кто-то катит очередные изменения, а вы ждёте, пока они применятся.

3. Неопределённые интерфейсы в зависимостях. Тут можно провести аналогию с языками динамической типизации: несоответствия типов могут всплывать слишком поздно, когда они уже нанесли вред продовой инфраструктуре.

4. Много «копипасты» и повторения кода.

5. К такому коду мало доверия: новичку сложно ответить на вопрос «Что будет, если я запущу terraform apply?».

6. Как это всё запускать в CI?

А как надо?

Модули

Описание вашего проекта нужно начать с Terraform-модулей. Terraform-модуль — это набор манифестов, собранных вместе для решения определенной задачи. Модуль можно выложить в общий доступ с помощью git-репозитория, хранить локально или использовать специальный сервис Terraform Registry. Типовой модуль может иметь следующую файловую структуру:

├── main.tf├── outputs.tf├── variables.tf├── README.md

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

И какой вариант вам больше нравится?

Во-вторых, модули описывают строгие контракты для входных и выходных переменных. При использовании модулей вы соединяете выходные переменные (outputs) одного модуля c входными переменными (variables) другого модуля, а строгие контракты позволяют избежать ошибок в процессе сопровождения инфраструктуры и серьёзных инцидентов.

Например, описание сложной переменной для сетевых интерфейсов определяется её типом:

variable "network_interfaces" { description = "Instance network interfaces" # optional и значения по умолчанию появились в Terraform ≥ 1.3 type = map(object({ subnet_id = string ip_address = optional(string) security_group_ids = optional(set(string)) ipv6 = optional(bool) nat = optional(bool) nat_ip = optional(string) dns_record = optional(object({ dns_zone_id = string ttl = optional(number, 300) ptr = optional(bool, true) })) nat_dns_record = optional(object({ dns_zone_id = string ttl = optional(number, 300) ptr = optional(bool, true) })) })) default = {}}

Если на вход подать некорректный объект, например, не указав обязательное поле subnet_id, то Terraform сообщит нам об ошибке на ранней стадии валидации кода.

В-третьих, для каждого отдельного модуля можно написать тесты.

Тесты

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

Тесты особенно полезны в сложных модулях, в которых используются динамические блоки, циклы и вычисляемые локальные переменные (locals): поведение таких модулей почти невозможно прогнозировать, только читая код.

Наиболее популярный фреймворк для тестирования модулей — это Terratest — библиотека для Go, с помощью которой можно проверить как простые test-кейсы (ожидаемый output), так и сложную интеграционную логику с другими модулями.

package testimport ("testing""github.com/gruntwork-io/terratest/modules/terraform""github.com/stretchr/testify/assert")func TestTerraformModule(t *testing.T) {terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{TerraformDir: "./tests",})// Удаляем ресурсы после тестовdefer terraform.Destroy(t, terraformOptions)// Запускаем apply для тестовых ресурсовterraform.InitAndApply(t, terraformOptions)output := terraform.Output(t, terraformOptions, "hello_world")// Проверяем - тестируем, что output соответствует ожиданиямassert.Equal(t, "Hello, World!", output)}

При тестировании Terraform-модулей будет создаваться реальная инфраструктура в облаке. Такие тесты не похожи на Unit-тестирование — возможности создать mock-объекты для облачных провайдеров пока нет. Хотя что-то можно проверить, анализируя только вывод terraform plan.

Разбивка кода проекта на логичную структуру

Теперь подумаем, как нам разбить весь проект на логичную структуру. В любом проекте обязательно выделяется инфраструктурный фундамент в виде VPC, подсетей и DNS-зоны. Назовём этот фундамент infra:

.└── terraform └── infra ├── dns │ └── main.tf ├── sa └── vpc

Для каждого окружения заведём отдельную директорию:

.└── terraform ├── envs │ ├── dev │ ├── prod │ └── test └── infra ├── dns ├── sa └── vpc

Но для работы с такой структурой нам нужно зайти в каждую директорию и выполнить terraform apply, а для обмена данными можно использовать terraform_remote_state источника данных (data source).

Terragrunt

Конечно, в любой CI-системе это можно организовать с помощью скриптов. Для оркестрации инфраструктурного Terraform-кода в сложном проекте хорошо зарекомендовал себя инструмент-враппер Terragrunt. Как и в случае с чистым Terraform, вы разбиваете код на модули, но для вызова этих модулей и передачи им входных переменных используете конфигурационные файлы terragrunt.hcl:

.└── terraform ├── envs │ ├── dev │ │ └── compute│ │ └── terragrunt.hcl │ │ k8s │ │ └── terragrunt.hcl │ ├── prod │ └── test └── infra ├── dns ├── sa └── vpc

При выполнении команды terragrunt run-all apply в корневой директории проекта оркестратор пройдётся по всем вложенным директориям и применит конфигурацию модуля, описанную в terragrunt.hcl.

Для каждого расположения конфигурации Terragrunt создаст свой собственный state-файл, например, envs/dev/compute/terraform.tfstate в настроенном бэкенде, а для обмена данными между этими стейтами будут использоваться переменные и выходные переменные модулей.

Чтобы описать зависимости между двумя модулями, используют ключевое слово dependency:

dependency "vpc" { config_path = "../../../infra/vpc"}inputs = { vpc_id = dependency.vpc.outputs.vpc_id}

В этом примере мы описали зависимость модуля compute от модуля vpc и передали входную переменную vpc_id в модуль compute.

Вспомним всё и подведём итоги

Давайте теперь вспомним список проблем, который мы составляли в самом начале, и что получили:

1. В репозитории присутствует логичная структура: модули и их использование в Terragrunt позволили разбить код на логичные структурные блоки.

2. Каждая небольшая часть инфраструктуры работает со своим состоянием, не блокируя работу с другими: для каждого окружения создаётся свой state-файл.

3. Между модулями определены интерфейсы в виде входных переменных и выходных значений.

4. Организация кода в виде модулей добавляет возможность переиспользования.

5. К коду модуля больше доверия за счёт тестов: мы можем убедиться, что модуль работает корректно.

6. CI теперь можно организовать довольно гибко: для каждой части инфраструктуры и для каждого окружения.

Заключение

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

Теперь можно смело переходить к следующему этапу — автоматизации с помощью CI-систем. Конечная цель организации инфраструктурного кода — создание надёжной и масштабируемой инфраструктуры, которая может поддерживаться и расширяться без лишних трудностей для SRE-инженера и команды, а таких трудностей можно избежать благодаря CI-системам.

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