Terraform, Ansible, Helm — главные инструменты оптимизации инфраструктуры малого и среднего бизнеса

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

Еще одна серьезная проблема — конкуренция, в том числе и с высокотехнологичными корпорациями-гигантами. Каким же образом малый и средний бизнес в IT может выстоять?

Ответ прост и одновременно является решением всех проблем — это автоматизация, непосредственное участие в которой принимают инструменты Terraform, Ansible и Helm, о которых я подробно расскажу далее, а также приведу реальные примеры того, как грамотная методология их использования помогла локальным бизнесам масштабироваться и стабилизироваться. 

Terraform, Ansible и Helm и их роль в решении бизнес-проблем

Terraform 

Первым рассмотрим Terraform — программную платформу, которая позволяет описывать всю инфраструктуру как код, а также заранее показать, как она будет выглядеть. После чего администратору или DevOps-специалисту остается только принять решение: используем или нет.

Одно из главных преимуществ Terraform — повторяемость и предсказуемость структуры. Любят его также и за то, что инструмент легко интегрируется с облачными платформами. Например, с Amazon Web Services (AWS), Google Cloud Platform (GCP), облаком билайн (beeline cloud) и другими. Следовательно, доступна опция использования нескольких провайдеров одновременно, вместе с чем значительно увеличивается гибкость инфраструктуры.

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

Для наглядности — вот поэтапное создание БД PostgreSQL в AWS и сохранение доступа к ней в GitHub Secrets:

1. Определяем переменные, которыми будем пользоваться: для примера взяты db_name, availability_zone, github_repo.
2. Генерируем случайный пароль длиной 24 символа.
3. Создаем саму БД PostgreSQL.
4. Записываем данные о БД в секреты и переменные GitHub Actions.

// локальные переменные

locals {
 db_name           = "myproject"
 availability_zone = "eu-west-2c"
 github_repo       = "my_github_repo"
}

// генерируем случайный пароль для БД

resource "random_password" "root" {
 length      = 24
 special     = false
 min_lower   = 1
 min_numeric = 1
 min_upper   = 1
}

// создаем RDS PostgreSQL

resource "aws_db_instance" "my_db" {
 identifier             = "${local.db_name}-db"
 allocated_storage      = 10
 db_name                = local.db_name
 engine                 = "postgres"
 engine_version         = "15"
 instance_class         = "db.t3.micro"
 username               = "root"
 password               = random_password.root.result
 skip_final_snapshot    = true
 availability_zone      = local.availability_zone
 db_subnet_group_name   = "your_subnet_name"
 vpc_security_group_ids = ["your_security_group_id"]
}

// Сохраняем данные о БД в секреты github

resource "github_actions_variable" "postgres_host" {
 repository    = local.github_repo
 variable_name = "POSTGRES_HOST"
 value         = aws_db_instance.my_db.address
}

resource "github_actions_secret" "postgres_user" {
 repository      =  local.github_repo
 secret_name     = "POSTGRES_USER"
 plaintext_value = aws_db_instance.my_db.username
}

resource "github_actions_secret" "postgres_password" {
 repository      =  local.github_repo
 secret_name     = "POSTGRES_PASSWORD"
 plaintext_value = aws_db_instance.my_db.password
}

Ansible 

В случае с Ansible используется декларативный подход, схожий с Terraform. Система управления конфигурациями работает по принципу Agentless, то есть не требует установки каких-либо агентов или миньонов, а использует SSH-подключение.

Главное преимущество Ansible — простота конфигурации. Инфраструктура в нем легко описывается и так же легко читается. Даже самые сложные задачи в Ansible будут выглядеть просто. 

Кроме того, система может быть легко интегрирована в уже существующую инфраструктуру на любом этапе. При этом никаких проблем у Ansible не возникнет. 

Ниже пример установки и настройки веб-сервера Caddy:

1. Установка зависимостей.
2. Добавление репозитория в apt.
3. Установка самого Caddy.
4. Копирование конфигурации из шаблона.

- name: install dependencies
  apt:
   name:
     - apt-transport-https
     - debian-archive-keyring
     - debian-keyring
   update_cache: yes
   cache_valid_time: 3600

- name: gpg keyring
  apt_key:
   url: "https://dl.cloudsmith.io/public/caddy/stable/gpg.key"

- name: Add Caddy repository to sources list
  apt_repository:
   repo:
     "deb https://dl.cloudsmith.io/public/caddy/stable/deb/debian any-version main"
   state: present
   filename: caddy-stable

- name: install caddy
  apt:
   name: caddy
   update_cache: yes

- name: caddy config
  template:
   src: caddy.j2
   dest: /etc/caddy/Caddyfile
  notify: restart caddy

Kubernetes и его помощник Helm

Рассматривать эти два инструмента отдельно друг от друга нет никакого смысла. Но начнем мы с Kubernetes — не просто так он считается настолько важным в IT-мире. Он обеспечивает эффективное управление контейнерами, что и ведет к автоматизации и масштабированию. Это также гарантирует быструю адаптацию к рынку. 

Helm — пакетный менеджер Kubernetes, который упрощает работу с ним и его микросервисами. Дополнительно он управляет различными версиями приложений, что сильно выручает. Например, в случае выката некорректной версии на продакшен через Helm можно без проблем вернуться к другой версии, что значительно упрощает жизненный цикл для приложения.

Чтобы было понятнее, давайте разберем YAML-манифест и покажем реальную схему деплоя. Приведенный ниже пример helm-чарта устанавливает matrix-сервис с подключением в Keycloak и был взят из реальной практики.

# once: helm repo add ananace-charts https://ananace.gitlab.io/charts

# helm upgrade --install matrix-synapse ananace-charts/matrix-synapse 
--create-namespace --namespace matrix --values values-matrix.yaml

serverName: matrix.my-project.ru
publicServerName: matrix.my-project.ru
wellknown.enabled: true

config:
 enableRegistration: false
 turnUris: ["turn:sip.my-project.ru?transport=udp", "turn:sip.my-project.ru?transport=tcp"]

extraConfig:
 turn_shared_secret: "oXFeWO4gzXG0BjqL"
 # enable_registration_without_verification: "true"
 sso:
   update_proifile_information: true
 oidc_providers:
   - idp_id: keycloak
     idp_name: "Центральный сервер авторизации CAS"
     issuer: "https://auth.my-project.ru/realms/my-project"
     client_id: "matrix"
     client_secret: "VerySecurePassword"
     scopes: ["openid", "profile"]
     user_mapping_provider:
       config:
         localpart_template: "{{ user.preferred_username }}"
         display_name_template: "{{ user.name }}"
         email_template: "{{ user.email }}"
     backchannel_logout_enabled: true # Optional

ingress:
 enabled: true
 hostname: matrix.my-project.ru
 ingressClassName: nginx
 tls:
   - secretName: chart-my-project-tls
     hosts:
       - matrix.my-project.ru

 annotations:
   cert-manager.io/cluster-issuer: "http01-clusterissuer"
   kubernetes.io/ingress.class: nginx
   nginx.ingress.kubernetes.io/proxy-body-size: 10m
   kubernetes.io/tls-acme: "true"

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

Сложности и ограничения инструментов оптимизации 

Мы поговорили только о достоинствах инструментов оптимизации. Но будет не совсем честно не предупредить и о сложностях, которые с ними связаны. Самые общие —организационные, так как необходимо, чтобы команда имела культуру и дисциплину использования инструментов и подходов IaC и не допускала соблазнительных изменений в инфраструктуре без кода.

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

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

Terraform

• Привязан к версии. 

У всех членов команды должна быть одна единая версия CLI, чтобы работать с общим кодом.

• Зависит от state-файла. 

С ним есть два нюанса. Во-первых, он единственный и уникальный для всей инфраструктуры, описанной в нем. Это приводит к конфликту с IaC-подходом, где код хранится в Git, а значит, имеет множество версий. Актуальная же версия state-файла только одна и не может храниться в Git. Во-вторых, это же ограничение действует и на одновременную работу с инфраструктурой разными членами команды: только один человек может применять изменения в конкретный момент времени, что иногда блокирует других коллег.

Ansible

• Есть ограничения при большом количестве серверов. 

Например, при инфраструктуре в 1000 хостов можно бесконечно ждать, пока Ansible прокатит playbook, из-за подключения к SSH, к каждому серверу по отдельности. 

Helm

• Ограничение — лишь сфера применения.

Используется только с Kubernetes. Есть, конечно, нюансы управления большим числом чартов, хаосом в values.yaml, а также самого обучения работе с ним. Но ни один из этих фактов не отменяет того, что Helm — сейчас один из лидеров рынка.

Инструкция по тому, как внедрить инструменты

Этап 1. Анализ текущей инфраструктуры и потребностей бизнеса

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

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

Этап 2. Выбор подходящего инструмента или комбинации инструментов

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

Этап 3. Настройка и интеграция

Terraform, Ansible или Helm — вне зависимости от того, какой именно инструмент был выбран на предыдущем этапе, — внедряются пошагово или уже в действующую инфраструктуру, или при полном выстраивании новой с нуля. Причем первый вариант возможен преимущественно только для Ansible, так как тот же Terraform способен фактически «убить» текущую инфраструктуру и создавать ее заново. 

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

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

Этап 4. Обучение команды и запуск пилотного проекта

Не стоит забывать и про обучение команды основам методологии автоматизации и использованию таких инструментов, как Terraform, Ansible или Helm. Для этого можно воспользоваться специализированными курсами и учебными программами или пригласить DevOps-специалиста. 

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

Выбор инструмента под задачу

Нередко встает вопрос, какой конкретно инструмент для оптимизации инфраструктуры выбрать. Больше всего проблем возникает с Terraform и Ansible из-за их сильной схожести. Давайте разберемся. 

Terraform — это инструмент, работающий через API (где есть provider), и в первую очередь — с облаками. Но им же можно настроить всё, что поддерживает API, например HashiCorp Vault, Keycloak, Grafana, GitLab/GitHub и т. п.

Ansible же работает через SSH. Всё, что можно сделать на сервере через SSH/RDP, Ansible предлагает сделать идемпотентно, то есть когда повторное выполнение приводит к тому же результату, что и самое первое. 

Про реальный пример внедрения

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

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

• получение сертификатов SSL;
• мониторинг метрик;
• сбор и анализ логов;
• репликация и отказоустойчивость БД и очередей;
• пайплайны и автотесты;
• управление секретами;
• файрволы и сети;
• доступы разработчиков к данным;
• дашборды с Grafana/Kibana, AKHQ, Argo CD и пр.

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

Гарантировано: где-то что-то будет забыто, потеряно и т. д.

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

Итоги и советы для малого и среднего бизнеса

Начнем с советов:

1. Старайтесь использовать IaC-подход в своей инфраструктуре с самого начала, и проблем будет меньше.
2. Если с самого начала не получилось, то выберите время и выделите ресурсы, чтобы отобразить в IaC текущую инфраструктуру как можно раньше. Чем дольше тянете, тем дороже будет переход в дальнейшем.
3. Используйте инструменты оптимально: не нужно создавать серверы Ansible и конфигурировать их Terraform (хоть такое и возможно). Каждый инструмент имеет свою зону применения.
4. IaC — это работа с системой контроля версий (наиболее популярная — Git). То есть 100% инфраструктуры всё равно должны храниться в Git и обладать историей изменений, связки с тикетами в Jira или в аналогах. Каждое изменение обязано быть отображено в Git.
5. Следите за обновлениями на рынке и пробуйте новые инструменты.
6. Автоматизируйте как минимум ключевые процессы в компании.
7. Помните, что мониторинг — важнейшая проактивная деятельность. 

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

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