Управление облачной инфраструктурой и Infrastructure as Code

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

Вам может показаться, что это заботы провайдера, ради этого компания и обращается в облако. Всё так. Но важно понимать один нюанс: любое IT-решение — это инструмент для достижения целей бизнеса, который стремится оптимизировать использование ресурсов, то есть сократить расходы и увеличить прибыль. В таком случае управлять облачной инфраструктурой и при этом учитывать бизнес-составляющую позволяет концепция Infrastructure as Code (IaC).

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

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

Концепция Infrastructure as Code

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

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

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

Подходы IaC

Декларативный (функциональный)

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

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

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

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

Императивный (процедурный)

✏️ Императивный подход подразумевает детальное описание шагов развёртывания или настройки инфраструктуры в конфигурационном файле.

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

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

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

IaC-инструменты

Ansible — популярный IaC-инструмент, который реализует как декларативный подход, так и элементы императивного, позволяя описывать состояние инфраструктуры в формате YAML. Имеет большое комьюнити, что обеспечивает доступ к многочисленным руководствам, плагинам и готовым решениям.
Crossplane — популярный инструмент для DevOps, интегрируемый с оркестратором Kubernetes. Он обеспечивает управление инфраструктурой с автоматическим отслеживанием изменений в конфигурациях. Crossplane особенно полезен для обеспечения единообразия конфигураций при динамическом масштабировании.
Pulumi — инструмент управления инфраструктурой с использованием широкого набора языков программирования, таких как Python, Java и Go. Это делает его идеальным для разработчиков, предпочитающих работать в знакомой среде.
Terraform позволяет описать виртуальную инфраструктуру любой сложности и управлять ею с помощью собственного декларативного языка HCL (HashiCorp Configuration Language).
Сервисы облачных провайдеров, например AWS CloudFormation, Azure Resource Manager и Google Cloud Deployment Manager, предлагают решения, специфичные для своих платформ, с уникальными возможностями и синтаксисом. Эти инструменты идеальны для использования в соответствующих облачных экосистемах.

Что почитать про IaC-инструменты

Ansible community documentation

Crossplane Introduction

Get started with Pulumi

Terraform

AWS CloudFormation

Общие сведения об Azure Resource Manager

Google Cloud Deployment Manager documentation

Каждый из упомянутых инструментов имеет свои плюсы и свои ограничения. Ansible удобен благодаря поддержке популярного формата YAML-конфигураций, но требует высокого уровня квалификации в больших командных проектах. Crossplane требует знания Kubernetes. А использование Pulumi может вызвать проблемы с переносимостью из-за зависимости от кода. Выбор инструмента и подхода зависит от ресурсов команды, от задачи, уровня автоматизации и требований.

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

Теперь предлагаем рассмотреть концепцию IaC на примере инструмента Terraform.

Terraform

Когда полезен Terraform

Локальная инфраструктура Terraform может использоваться для управления ресурсами, такими как виртуальные серверы, сети и хранилища данных в традиционных дата-центрах или виртуальных средах.
Облачные сервисы Terraform активно применяется для развёртывания и управления инфраструктурой на различных облачных платформах, таких как Yandex Cloud, AWS, Microsoft Azure и Google Cloud.
Контейнеризация С помощью Terraform возможно развёртывание и управление контейнеризированными решениями.
CI/CD Terraform интегрируется с системами контроля версий (например, git) и другими CI/CD-инструментами.

Как работает Terraform

Этап 1. Инициализация (Initialize)

Этот этап начинается после написания кода конфигурации либо с инициализации уже существующего проекта из репозитория. Команда terraform init подготовит рабочий каталог, структуру проекта, загрузит зависимости, а также доступ к API провайдеров.

Если проект уже существует в Git-репозитории, вы можете загрузить его в свою локальную директорию с помощью команды git clone.

💡 Хорошим тоном считается интеграция Terraform с GitLab на этапе внедрения IaC, поскольку в GitLab есть функционал CI/CD и он идёт прямо «из коробки» в отличие от, например, GitHub. Кроме того, в некоторых компаниях, особенно крупного бизнеса и государственных предприятий, есть требования к безопасности, которые регламентируют разворачивание инфраструктуры и сервисов On-premise. Gitlab можно развернуть на собственных серверах компании.

Этап 2. Планирование изменений (Plan)

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

Этап 3. Применение изменений (Apply)

Команда terraform apply разворачивает указанные ресурсы или вносит изменения в инфраструктуру. Cоздаются и изменяются реальные ресурсы, такие как виртуальные машины или сеть. Когда вы завершите развёртывание и проверите результаты, лучше сохранить изменения в системе контроля версий с помощью команд git commit и git push.

Перед тем как зафиксировать изменения в git-репозитории, можно использовать команду terraform fmt для изменения кода.

Описание среды в Terraform

Конфигурационные файлы (.tf)
Это файлы с расширением .tf, в которых описываются ресурсы инфраструктуры, переменные и параметры, необходимые для работы Terraform. Они служат основой для определения того, как будет развёрнута ваша инфраструктура.
Файл состояния (.tfstate)
Когда Terraform разворачивает ресурсы, он сохраняет информацию о созданной инфраструктуре в файл состояния. Этот файл обычно называется terraform.tfstate и хранится локально или в удалённом хранилище S3.
Terraform сравнивает текущее состояние ресурсов с тем, что описано в конфигурационных файлах (.tf файлах). Это позволяет ему понять, что уже существует, что изменилось и что нужно создать или удалить.
Файл состояния включает в себя:
- Список всех созданных ресурсов, их идентификаторы и текущие конфигурации;
- Метаданные, такие как атрибуты, зависимости, IP-адреса, размеры дисков и другие параметры.
Провайдеры (Providers)
Провайдеры играют роль шлюза в Terraform, так как именно через них происходит взаимодействие с облачными сервисами или локальными ресурсами. Они выступают связующим звеном между кодом конфигурации и реальными объектами, которые необходимо создать, изменить или удалить.
Ресурсы (Resources)
Это элементы описания инфраструктуры, такие как виртуальные машины, сетевые компоненты, базы данных или балансировщики. Ресурсы описываются в конфигурационных файлах.
Провиженеры (Provisioners)
Провиженеры используются для настройки и управления ресурсами после их создания. Они позволяют автоматически разворачивать софт, копировать файлы или запускать скрипты на созданных ресурсах, чтобы подготовить их к работе.

Сергей

К практике!

Практика. Создание виртуального сервера

Для написания конфигурационных файлов в Terraform используется свой язык Hashicorp Configuration Language (HCL). В этом кейсе мы подробно рассмотрим синтаксис HCL, используя пример конфигурации для создания виртуального сервера в Yandex Cloud. Мы пройдёмся по каждому элементу конструкции, чтобы вы могли лучше понять, как работает Terraform и как с его помощью можно автоматизировать управление инфраструктурой в облаке.

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

Рассмотрим основные элементы конструкции HCL на этой конфигурации:

HCL

data "yandex_compute_image" "ubuntu" {
  family = "ubuntu-2204-lts"
}

resource "yandex_compute_disk" "testvm" {
  name = "test-vm-disk"
  type = "network-ssd"
  zone = "ru-central1-a"
  image_id = data.yandex_compute_image.ubuntu.image_id
  size = 15
}

resource "yandex_compute_instance" "testvm" {
  name = "test-vm"
  zone = "ru-central1-a"

  resources {
    cores  = 2
    memory = 2
  }

  boot_disk {
    disk_id = yandex_compute_disk.testvm.id
  }

  network_interface {
    subnet_id = "<< SUBNETID >>"
    nat       = true
  }

  metadata = {
    ssh-keys = "ubuntu:${file("~/.ssh/id_rsa.pub")}"
  }
}

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

HCL

data "yandex_compute_image" "ubuntu" { 
  family = "ubuntu-2204-lts"
}

Блок состоит из двух частей: определения блока и тела блока.

Определение блока
- data — это тип блока. Он используется для получения данных о существующем ресурсе провайдера. В нашем примере информацию о существующих образах операционных систем получаем у провайдера — Yandex Cloud. Тип блока может быть ресурсом (resource), данными (data), провайдером (provider) или переменной (variable) — в зависимости от того, что создаётся или запрашивается.
- "yandex_compute_image" — это значение указывает тип ресурса, к которому относится блок. Здесь запрашиваются данные образа виртуальной машины.
- "ubuntu" — этим значением мы задаём локальное имя блоку ресурса. Оно будет выступать в качестве ссылки во всём пространстве имён конфигурации.
Тело блока
После определения содержимое заключается в фигурные скобки { } — это тело блока. Внутри фигурных скобок находятся атрибуты ресурса или других элементов конфигурации.
В этом примере внутри блока data присутствует один атрибут family = "ubuntu-2204-lts". Значение указывает семейство/каталог образов операционной системы для поиска на ресурсе провайдера. У атрибута всегда есть имя и значение, присвоенное через =.
В результате исполнения этого блока будет возвращена информация от провайдера. В данном случае ожидается получение идентификатора образа ОС.

В следующем блоке типа resource мы создаём ресурс (виртуальный диск) типа "yandex_compute_disk" с именем "testvm". Далее перечисляем все атрибуты создаваемого ресурса (виртуального диска):

HCL

resource "yandex_compute_disk" "testvm" {
  name = "test-vm-disk"
  type = "network-ssd"
  zone = "ru-central1-a"
  image_id = data.yandex_compute_image.ubuntu.image_id
  size = 15
}

name = "test-vm-disk" — имя для виртуального диска;
type = "network-ssd" — тип диска (SSD в сети);
zone = "ru-central1-a" — зона региона, в которой создаётся виртуальный диск;
image_id = data.yandex_compute_image.ubuntu.image_id — в этом атрибуте мы присваиваем значение id образа, полученного из блока data выше. Значение описывается через пространство имён;
size = 15 — размер диска (Гб).

Далее следует ещё один блок типа — resource, где мы создаём ресурс (виртуальный сервер), присваиваем ему имя и указываем зону региона через атрибуты name и zone соответственно.

Блок провайдера. Для начала укажем параметры подключения к провайдеру. В нашем случае — Yandex Cloud.

HCL

provider "yandex" {
  token     = "example-oauth-token"       # OAuth-токен
  cloud_id  = "b1g63e2fltlcti5hjucf"      # Cloud ID
  folder_id = "b1g6v5q9rdsufm6s48g0"      # ID
  zone      = "ru-central1-a"             # Указание региона провайдера
}

Создадим ресурс на виртуальный сервер с указанием имени виртуальной машины и региона, в котором будет создана виртуальная машина, а также параметры её окружения во вложенные блоки: resources, boot_disk, network_interface, metadata.

HCL

resource "yandex_compute_instance" "testvm" {
  name = "test-vm"        
  zone = "ru-central1-a"                  # Регион, в котором будет создана VM

  // Вложенный блок resources определяет ресурсы виртуальной машины
  resources {
    cores  = 2                            # Количество ядер процессора
    memory = 2                            # Объём оперативной памяти (Gb)
  }

  // Вложенный блок boot_disk связывает диск с виртуальной машиной, где
  // используем ID диска, созданного в корневом блоке
  boot_disk {
    disk_id = yandex_compute_disk.testvm.id 
  }

  // Блок описания сетевого интерфейса network_interface
  network_interface {
    subnet_id = "<<e9b1h0icgtq23md5ovl1>>" # Идентификатор подсети
    nat       = true                       # Включение NAT для выхода в интернет
  }

  // В блоке metadata опишем метаданные
  metadata = {
    ssh-keys = "testUser:${file("~/.ssh/id_rsa.pub")}" # SSH-ключ
  }
}

Задание 1

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

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

terraform init

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

terrafom apply

Команда terraform apply используется для применения изменений, указанных в конфигурационных файлах, к инфраструктуре. Она создаёт или изменяет ресурсы на основе текущего состояния и конфигурации.

terraform provision

terraform provision не является командой в Terraform. Термин «провиженинг» относится к настройке ресурсов после их создания, но для этого используются провиженеры, а не команда terraform provision.

terraform plan

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

Задание 2

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

Какие из следующих действий являются необходимыми шагами для создания и настройки виртуального сервера в Terraform? Выберите все правильные ответы.

Определение ресурса виртуального сервера с указанием его имени и зоны

Да, это важный шаг при создании инфраструктуры в Terraform.

Настройка конфигурации NAT (Network Address Translation) в сетевом интерфейсе

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

Применение команды terraform destroy перед развёртыванием нового ресурса

Использование команды terraform destroy приведёт к удалению всех существующих ресурсов, что не является необходимым шагом при создании нового ресурса.

Использование команды terraform plan для предварительного просмотра изменений

Команда terraform plan позволяет увидеть, какие изменения будут внесены в инфраструктуру перед их применением, что помогает избежать нежелательных последствий.

Определение провайдера с нужными параметрами подключения

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

Создание файла состояния (state file) для отслеживания текущей инфраструктуры

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

Задание 3

Как обозначаются начало и конец блока в HCL?

[ ]

Скобки [ ] используются для доступа к элементам массива или для определения параметров списка, но они не применяются для обозначения начала и конца блока в HCL.

{ }

В HCL фигурные скобки { } применяются для обозначения начала и конца блока, в котором описываются атрибуты и параметры ресурсов.

( )

Скобки ( ) чаще всего используются в выражениях или при вызове функций, но не для обозначения блока в HCL.

< >

Скобки < > не используются в HCL для обозначения начала и конца блоков. Они могут применяться в других языках для различных целей, но не в HCL.

Задание 4

Ваша компания решила внедрить подход IaC для управления своей облачной инфраструктурой. В процессе обсуждения внедрения этого подхода вам нужно объяснить коллегам основные принципы IaC и какие преимущества он может дать вашей команде. Какие из следующих утверждений правильно описывают подход Infrastructure as Code? Выберите все верные утверждения.

IaC позволяет автоматизировать управление инфраструктурой с помощью написания кода, который описывает желаемое состояние инфраструктуры

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

С помощью IaC можно управлять инфраструктурой как программным кодом, используя системы контроля версий для отслеживания изменений

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

IaC требует ручной настройки и управления серверами через пользовательские интерфейсы облачных провайдеров

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

IaC поддерживает как декларативный, так и императивный подходы к описанию конфигурации инфраструктуры

IaC поддерживает оба подхода: декларативный (где описывается желаемое конечное состояние) и императивный (где указываются шаги для достижения этого состояния).

Основное преимущество IaC заключается в возможности развёртывания инфраструктуры без необходимости документировать изменения

Документация изменений важна, и с IaC это делается автоматически через системы контроля версий, что улучшает контроль и управление изменениями.

IaC помогает снизить количество ошибок и повысить повторяемость развёртывания инфраструктуры за счёт автоматизации

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

Задание 5

Вам поручено создать конфигурацию для развертывания виртуальной машины в облачной среде с использованием Terraform и языка HCL. Конфигурация должна включать параметры, такие как количество ядер, объём памяти, настройки сети и диск. Вы должны быть уверены, что используете правильный синтаксис и структуры, характерные для HCL.

Какие из следующих фрагментов кода HCL корректны для создания конфигурации виртуальной машины в Terraform?

HCL

resource "yandex_compute_instance" "example_vm" {
  name  = "example-vm"
  cores = 2
  memory = 4
}

Это корректный пример ресурса в HCL для создания виртуальной машины в Yandex Cloud с указанием количества ядер и объема памяти.

HCL

resource "aws_instance" "my_vm" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Это корректная конфигурация ресурса AWS для создания виртуальной машины с использованием AMI и указанием типа экземпляра.

HCL

resource "google_compute_instance" "example_vm" {
  name = "example-vm"
  zone = "us-central1-a"
  machine_type = "n1-standard-1"
  network_interface {
    network = "default"
    access_config {
    }
  }
}

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

HCL

resource "virtual_machine" "example" {
  name = "vm-example"
  cpu  = "4 cores"
  ram  = "8 GB"
}

В HCL параметры ресурсов, такие как CPU и RAM, должны быть заданы через стандартные атрибуты, такие как cores и memory, а не через строки вроде "4 cores" или "8 GB". Также "virtual_machine" не является корректным именем ресурса.

HCL

resource "yandex_compute_disk" "test_disk" {
  name = "example-disk"
  type = "network-ssd"
  zone = "ru-central1-a"
  size = 20
}

Это правильный фрагмент кода для создания виртуального диска в Yandex Cloud с использованием ресурса yandex_compute_disk.

Что почитать про Terraform

Начало работы с Terrafom — документация с примером на Yandex Cloud
IaC: Terraform — бесплатный курс с практикой от Yandex Cloud

Сергей

Подведём итоги

Итоги

Концепция Infrastructure as Code используется для автоматизации и управления IT-инфраструктурой путём описания её в виде программного кода. Это позволяет ускорить развёртывание и изменение инфраструктуры, повысить её надежность, улучшить масштабируемость и упростить процесс управления конфигурацией. IaC-инструменты решают и бизнес-задачи, связанные с ускорением вывода продукта на рынок и снижением затрат на IT-инфраструктуру.
Реализация IaC возможна в рамках двух основных подходов — декларативного и императивного. Декларативный подход описывает желаемое конечное состояние инфраструктуры, при этом шаги для его достижения определяет сама система. Это делает управление более простым и предсказуемым. Императивный подход, наоборот, фокусируется на последовательности команд, которые необходимо выполнить для развёртывания инфраструктуры, что даёт более точный контроль над процессом, но требует глубокого понимания всех этапов.
Общий алгоритм работы всех IaC-инструментов можно описать тремя этапами. На этапе инициализации инструмент подготавливает рабочую среду для взаимодействия с целевой инфраструктурой. На этапе планирования изменений анализируются текущая и желаемая конфигурации, формируется план действий. Затем, на третьем этапе реализации этот план выполняется — создаются или изменяются ресурсы.
Для описания среды в IaC-инструментах используются несколько элементов: в конфигурационных файлах описываются ресурсы инфраструктуры, переменные и параметры, необходимые для работы. Файл состояния хранит текущее состояние среды для отслеживания изменений. Провайдеры играют роль шлюза: через них происходит взаимодействие с облачными сервисами или локальными ресурсами. А для настройки и управления ресурсами после их создания используются провижинеры.