Управлять облачной инфраструктурой можно с помощью разных инструментов. И хотя все они позволяют делать похожие вещи, но у каждого из них есть свои особенности. Если сравнивать с автомобилем, то можно сказать, что управление виртуальной инфраструктурой может быть ручным или автоматическим. Выбор зависит от вкусов и предпочтений, задач, уровня навыков сотрудников и масштаба компании. Сегодня расскажем об инструментах, которые мы предоставляем для управления Т1 Облако: API, веб‑интерфейсе управления и Terraform. Разберём их особенности, приведём примеры из практики и дадим рекомендации, как с их помощью управлять инфраструктурой.

API как фундамент, на котором строится управление облаком

API — это программный интерфейс для взаимодействия с облачными сервисами. Он позволяет «программно» совершать те же действия, которые пользователь может выполнять через веб‑интерфейс управления, Terraform и различные SDK.

Рис. 1. В любом облаке всё взаимодействие с виртуальной инфраструктурой и сервисами осуществляется через API, даже когда вы что-то делаете в веб-интерфейсе
Рис. 1. В любом облаке всё взаимодействие с виртуальной инфраструктурой и сервисами осуществляется через API, даже когда вы что-то делаете в веб-интерфейсе

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

Эндпоинт — это URL, по которому API может быть доступен клиентскому приложению.

Все доступные пользователям эндпоинты, их возможности, необходимые для передачи параметры и варианты ответов описаны в документации. Например, для сервиса управления облачными сетями (VPC) представлен набор эндпоинтов с указанием действий, которые можно выполнять с ними:

Рис. 2. Набор эндпоинтов для сервиса VPC
Рис. 2. Набор эндпоинтов для сервиса VPC

В свою очередь, для каждого действия приведён набор параметров, необходимых для работы, и варианты ответов, например:

Приведём пример, как через API в Т1 Облако создаётся сеть:

curl -X 'POST' \  
  'https://api.t1.cloud/vpc/api/v1/projects/proj-0000001/networks' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <API_TOKEN>' \ 
  -d '{
  "name": "test-network"
  "description": "Network for testing"
}'

API для интеграции облачных сервисов с приложениями

Если сравнивать с управлением автомобилем, то эндпоинты — это «ручки» управления. «Тянем» за одну — создаётся IP‑адрес, «тянем» за другую — создаём сеть, и так далее. За эти ручки «дёргают» также веб‑интерфейс облачного провайдера, Terraform и другие внешние приложения. Иначе говоря, API — это своего рода коннектор, через который различные облачные сервисы можно интегрировать с клиентскими приложениями. То есть, используя API, работу с облачными сервисами (создание, изменение, удаление) можно интегрировать в клиентское приложение.

ПРИМЕР. У одного из наших клиентов есть внутренний мониторинг, который является частью мастер‑системы. Чтобы отслеживать статус работы заказанного облачного сервиса, клиент не заходит в веб‑интерфейс управления Т1 Облако, а пользуется собственным мониторингом, в который загружает из нашего облака данные, получаемые через API.

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

Когда нужен API

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

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

Веб-интерфейс управления облаком

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

Одна из главных особенностей веб‑интерфейса заключается в том, что он намного проще, чем API. Это визуально понятный графический интерфейс, где каждая кнопка подписана. Для сравнения: в случае с API нужно знать, как работать через командную строку или другие инструменты, использующие текстовый формат команд.

Как уже упоминали выше, веб‑интерфейс взаимодействует с сервисами через API. Он открывается через браузер и выглядит как приложение, в котором пошагово можно выполнить то или иное действие: заказать и настроить ВМ, базу данных, подключить объектное хранилище и др. Чтобы клиент не потерялся в интерфейсе, мы сделали по нему полноценное руководство. Там же можно заглянуть в документацию, получить подсказки по параметрам сервера, которые облегчат его заказ. Можно сказать, что с помощью веб‑интерфейса управлять облаком так же просто, как телевизором, а портал — это пульт.

Веб‑интерфейс можно сравнить с передней панелью в салоне автомобиля. Хотя кнопки и «крутилки» у разных марок отличаются, но интуитивно их значение понятно и поехать всё равно получится, потому что внешне они похожи. Так же похожи и интерфейсы у разных провайдеров.

Рис.3. Веб-интерфейс управления Т1 Облако
Рис.3. Веб-интерфейс управления Т1 Облако

Базовые возможности

С помощью веб‑интерфейса управления можно:

  1. Заказывать ресурсы (серверы, диски, сети, IP‑адреса, резервные копии и др.) и облачные сервисы (базы данных, Kubernetes…).

  2. Управлять идентификацией и доступами, то есть настраивать разные роли (админ, наблюдатель, редактор), а также создавать проекты и папки для удобной работы команд.

  3. Выбирать нужный тип биллинга: фиксированную оплату за ресурсы (Allocated) или оплату по факту потребления (Pay As You Go).

  4. Следить за расходами на подключённые сервисы, детализировать траты в облаке, настраивать бюджеты, смотреть статистику потребления ресурсов, проверять остаток на лицевом счёте, настраивать уведомления о достижении лимита трат.

  5. Проверять статус доступности сервисов и историю событий.

  6. Просматривать журнал изменений, где есть информация о пользователях и их действиях, например, действия отдельной учётной записи.

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

  8. Обращаться в техническую поддержку прямо из интерфейса.

Как управлять облаком

Все действия пользователь накликивает выполняет вручную: выбирает необходимую конфигурацию ВМ (подходящий процессор, количество VCPU и RAM), выделяет себе дисковое пространство, подключает IP‑адреса, настраивает доступ в сеть и делает его защищённым. И так каждый раз, когда нужно создать отдельный экземпляр того или иного ресурса.

ПРИМЕР. Небольшая компания через веб‑интерфейс может создать одну виртуалку, разместить на ней 1С: Бухгалтерию и спокойно работать дальше, а компания с масштабной инфраструктурой — разместить в публичном облаке различные ресурсы, включая ВМ, объектное хранилище, бэкапы и др.

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

Рис. 4. Заказ виртуальной машины
Рис. 4. Заказ виртуальной машины
  1. Чтобы заказать виртуальный сервер, в главном меню веб‑интерфейса переходим в раздел Ресурсы → Cloud Engine → Серверы и нажимаем кнопку «Создать», а затем заполняем поля.

  2. Дальше выбираем образ из списка доступных ОС.

  3. Настраиваем системный диск — выбираем объём в гигабайтах и его тип.

  4. Настраиваем вычислительные ресурсы:

    1. Выбираем семейство процессоров General‑purpose или Advanced, а также серию процессоров в зависимости от нужной тактовой частоты:

      1. b2 Intel Cascade Lake 2.2 GHz — для небольшой нагрузки;

      2. b5 Intel Ice lake 2.8 GHz;

      3. a5 Intel Ice lake 2.8 GHz;

      4. a1 Intel Cascade Lake 3.0 GHz;

      5. b3 Intel Cascade Lake 3.0 GHz — подходят для большинства задач.

    2. Выбираем количество процессоров vCPU и объём оперативной памяти в гигабайтах.

  5. Далее выбираем сетевые настройки.

Созданный сервер отобразится в веб-интерфейсе:

Если нажмем на строку с нужным сервером, то откроется страница с подробной информацией о нём:

Развитие платформы

Облачная платформа Т1 — наша собственная разработка, и мы продолжаем улучшать её, в том числе на основе обратной связи от клиентов.

  • Например, в Cloud Engine увеличили количество доступных для заказа шаблонов конфигураций (флейворов), которые можно выбирать с помощью бегунков. В частности, количество типовых шаблонов для серии b3 увеличилось в четыре раза.

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

  • В рамках концепции отчуждаемого облака, когда у клиента есть «железо» и он хочет развернуть облако на нём, мы также передаём наш веб‑интерфейс, и по желанию клиента можем его доработать.

Отчуждаемое облако — модель предоставления услуг, по которой провайдер разворачивает внутри организации полноценное облако, но использует для этого локальную сеть, серверы, СХД и сетевое оборудование клиента. Компания получает все преимущества облачного размещения данных, но без доступа «снаружи».

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

Когда нужен веб-интерфейс

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

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

Terraform — инструмент для автоматизации

Это open-source инструмент для управления облачной инфраструктурой путём её описания в виде кода (так называемый подход Infrastructure as Code), или, правильнее сказать, декларативных конфигураций.

Terraform — не единственный инструмент, который применяют в рамках концепции «Инфраструктура как код» Infrastructure as Code (IaC). В частности, Terraform использует декларативный подход и описывает, что должно быть сделано: то есть пользователь задает желаемое состояние системы, а инструмент сам определяет последовательность действий, чтобы достичь желаемого. А инструменты вроде Ansible или Chef используют императивный подход: пользователь описывает, как достичь желаемого состояния, то есть подробную цепочку шагов для настройки системы.

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

ПРИМЕР. Используя API или Terraform, вы можете создать, допустим, сразу 1000 серверов. Время выполнения этой операции, конечно, будет продолжительным, так как будет выполняться некая последовательность действий. При этом вам не понадобится в ручном режиме 1000 раз заказывать одну и ту же конфигурацию через веб-интерфейс.

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

ПРИМЕР. Как мы рассказывали в книге «Инфраструктура как код», в одном крупном облачном проекте клиенту требовалось создать группу безопасности со 100 правилами. На каждый порт ему нужно было по одному правилу безопасности, и создавал он их через Terraform. Это оказалось быстрее и проще, чем если бы он всё делал вручную. По оценкам наших разработчиков, для выполнения этой задачи через веб-интерфейс ему пришлось бы совершить 400 кликов. В этом случае Terraform помог минимизировать ошибки, которые могли бы появиться при долгом однотипном вводе информации вручную.

ПРИМЕР. Один из наших продактов вспомнил историю, как в одной компании рядовым админам запрещали заходить в веб-интерфейс и они работали только через Terraform. Этот пример дополнительно характеризует Terraform как безопасный и быстрый инструмент работы с облаком.

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

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

Чтобы клиентам было удобно управлять виртуальной инфраструктурой, мы разработали свой Terraform-провайдер, который находится в нашем публичном GitLab-репозитории. Там же находятся подробные инструкции по использованию Terraform, а также примеры конфигурационных файлов. Приведём в качестве примера создание ВМ с помощью языка конфигурации HashiCorp Configuration Language (HCL).

В разделе «Ресурсы и источники данных» нужно выбрать ресурс «t1_compute_instance», описать желаемую инфраструктуру в виде кода, а затем запустить создание желаемой инфраструктуры.

Прежде чем мы посмотрим на код, важно понять две фундаментальные сущности в Terraform:

resource (Ресурс) — это то, что Terraform будет активно создавать, изменять или удалять. Это может быть ВМ, сеть, SSH-ключ, база данных — любой объект в облаке.

data (Источник данных) — это информация, которую Terraform должен найти или прочитать в облаке, чтобы использовать её для настройки ресурсов. Например, ID нужного образа ОС или ID стандартной сети. Мы не управляем этими данными, мы их только запрашиваем.

# --- Блок 1: Запрашиваем существующие данные из облака ---

# Находим информацию о подходящей конфигурации (flavor) ВМ.
# Мы ищем "general-purpose" машину с 2 CPU и 4 ГБ RAM.
data "t1_compute_flavor" "small" {
  vcpus          = 2
  ram            = 4
  family         = "general-purpose"
  cpu_series     = "Intel Ice lake 2.8 GHz"
  hardware_group = "public"
}

# Находим самый свежий образ Ubuntu 22.04.
data "t1_compute_image" "ubuntu" {
  os_distro  = "ubuntu"
  os_version = "22.04"
} 

# Получаем информацию о сети по умолчанию, чтобы к ней подключиться.
data "t1_vpc_network" "default" {
  name = "default"
}

# --- Блок 2: Описываем ресурсы, которые нужно создать ---

# Создаем новый SSH-ключ для доступа к машине. 
# Замените <SSH_KEY_RSA> на ваш публичный ключ!


resource "t1_compute_ssh_key" "test" {
  name        = "test-ssh"
  login       = "root"
  public_keys = [
	"ssh-rsa <SSH_KEY_RSA>"
  ]
}

# И наконец, создаем саму виртуальную машину, собирая вместе все части, как конструктор.
resource "t1_compute_instance" "vm" {
name = "habr-test-vm" // Дадим машине осмысленное имя

  system_volume = {
    size = 10  // Размер системного диска в ГБ
  }

# Ссылаемся на данные, которые нашли ранее

  flavor = data.t1_compute_flavor.small
  image  = data.t1_compute_image.ubuntu

  network_interface = {
# Берем ID первой подсети из найденной сети по умолчанию
    subnet_id = data.t1_vpc_network.default.subnets[0].id
  }
# Привязываем созданный нами SSH-ключ
   ssh_keys = [
    t1_compute_ssh_key.ssh.id,
  ]
}

Мы подготовили всё для создания ВМ, и теперь начинается новый этап — выполнение команды terraform apply. При её вводе Terraform:

  1. Прочитает ваш код и существующие источники данных.

  2. Спланирует изменения. Он покажет, что именно собирается создать, и попросит вашего подтверждения. Можно проверить, что всё пойдёт по плану.

  3. Применит изменения после вашего согласия.

Выполнение примера можно посмотреть здесь.
Вначале Terraform-провайдер читает ваш код и источники данных:
> terraform apply
data.t1_vpc_security_group.sg-default: Reading...
data.t1_vpc_network.default: Reading...
data.t1_compute_flavor.small: Reading...
data.t1_compute_image.ubuntu: Reading...
data.t1_vpc_security_group.sg-default: Read complete after 0s [id=1f8de31c-6ad5-
4895-be52-a8f77138d2fe]
data.t1_vpc_network.default: Read complete after 1s [id=94a7a60a-2540-404b-b528-
b94a7d62d99b]
data.t1_vpc_subnet.default: Reading...
data.t1_compute_flavor.small: Read complete after 1s [id=a629345a-7a9d-4ec5-936e-
7c3f81e8e9bd]
data.t1_vpc_subnet.default: Read complete after 0s [id=a18914fd-c915-496c-b201-
ca33cde5e76b]
data.t1_compute_image.ubuntu: Read complete after 1s [id=36939a58-d1b8-498fa1bb-
428211488572]
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
+ create

Terraform-провайдер показывает, какие действия он выполнит:
Terraform will perform the following actions:
# t1_compute_instance.test will be created
+ resource "t1_compute_instance" "test" {
+ allow_delete_volumes = true
+ description = "Acceptance test instance"
+ flavor = {
+ cpu_series = "Intel Cascade Lake 3.0 GHz"
+ family = "general-purpose"
+ hardware_group = "public"
+ id = "a629345a-7a9d-4ec5-936e-7c3f81e8e9bd"
+ name = "b5.large.2"
+ ram = 4
+ vcpus = 2
}
+ id = (known after apply)
+ image = {
Примеры кода 451
+ id = "36939a58-d1b8-498f-a1bb-428211488572"
+ name = "ubuntu_22_04"
+ os_distro = "ubuntu"
+ os_version = "22.04"
+ size = 2361393152
}
+ name = (known after apply)
+ network_interface = {
+ fixed_ip = (known after apply)
+ id = (known after apply)
+ security_group_ids = [
+ "1f8de31c-6ad5-4895-be52-a8f77138d2fe",
]
+ subnet_id = "a18914fd-c915-496c-b201-ca33cde5e76b"
}
+ region = "u-central1"
+ ssh_keys = [
+ (known after apply),
]
+ state = "off"
+ system_volume = {
+ disk_type = "Average cluster 3"
+ id = (known after apply)
+ size = 4
}
+ zone = "ru-central1-a"
}
# t1_compute_ssh_key.test will be created
+ resource "t1_compute_ssh_key" "test" {
+ id = (known after apply)
+ login = "root"
+ name = "test-f123"
+ public_keys = [
+ "ssh-rsa <SSH_KEY_RSA>",
]
}
Plan: 2 to add, 0 to change, 0 to destroy.

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

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

Terraform применит изменения после вашего согласия. 

t1_compute_ssh_key.test: Creating...
t1_compute_ssh_key.test: Creation complete after 1s [id=5ef1b8ec-1511-
4f77-8a38-c9834e89c68a]
t1_compute_instance.test: Creating...
t1_compute_instance.test: Still creating... [2m40s elapsed]
t1_compute_instance.test: Creation complete after 2m41s [id=d9c75f1e-
5dd1-4019-ba15-d849e6028330]

В результате мы создали два ресурса: SSH-ключ и ВМ.
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Когда нужен Terraform

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

ПРИМЕР. Большая корпорация может развернуть тестовый стенд на 1000 виртуалок. DevOps'ы могут поставить автоматическую задачу, которая будет отключать виртуалки на выходные и включать в понедельник, чтобы не тратить лишние деньги.

ПРИМЕР. Крупный российский интернет‑сервис с помощью Terraform‑провайдера Т1 Облако раз в день разворачивал около 2000 ВМ, чтобы мониторить цены конкурентов, а затем автоматически эти машины сворачивал. Руками это было сделать невозможно.

Почему выбирают Terraform?

По данным различных исследований о состоянии DevOps в России, Terraform используют около 37 % специалистов. Мы в Т1 Облако наблюдаем динамику повышения спроса на этот инструмент среди клиентов на 40 %. По нашим прогнозам, в ближайшие три года использование Terraform в России будет демонстрировать устойчивый рост. Это обусловлено несколькими причинами: увеличением интереса к подходу IaC, автоматизацией процессов DevOps, необходимостью оптимизировать управления облачной инфраструктурой и снижать затраты на её обслуживание.

Этот инструмент:

  • экономит время на развёртывание инфраструктуры;

  • уменьшает вероятность ошибок в однотипных операциях;

  • делает эти операции масштабируемыми: за секунду можно сделать то, что через веб‑интерфейс придётся делать минутами, если не часами;

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

Неочевидные преимущества Terraform

  • Согласованность виртуальной инфраструктуры, или соответствие желаемого действительному. То есть можно запустить Terraform с определёнными параметрами, и он выдаст результат: соответствует ли реальная инфраструктура описанной в коде.

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

  • Авторасчёт бюджетирования. Если вашему отделу выделили определённый бюджет в месяц на инфраструктуру, то можно добавить скрипт, который при любом изменении инфраструктуры в один клик через Terraform будет анализировать TF‑файлы и проверять, не выходите ли вы за лимиты.

  • Возможность сократить издержки на инфраструктуру. Например, можно поставить автоматическую задачу, которая будет включать тестовые стенды, ВМ для dev‑сред и демостенды в будни с 10 до 19, а на ночь и на выходные выключать, чтобы они не простаивали. Это существенно сократит издержки. При этом важно внимательно спланировать эти ВМ, чтобы на них не хранилось ничего важного.

  • Возможность визуализировать инфраструктуру. По команде terraform graph можно получать так называемые графики для создания визуального представления конфигурации. Это помогает сделать шаги по созданию инфраструктуры более наглядными и видеть отношения между ресурсами. Графики выводятся в формате DOT, который можно преобразовать в изображение. Например:


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

Комментарии (0)