Мы запустили официальный Terraform-провайдер для работы с Selectel. Этот продукт позволяет пользователям полностью реализовать управление ресурсами через методологию Infrastructure-as-code (инфраструктура как код).
В настоящее время провайдер поддерживает управление ресурсами услуги «Виртуальное приватное облако» (далее VPC). В будущем мы планируем добавить в него управление ресурсами других услуг, предоставляемых Selectel.
Как вы уже знаете, услуга VPC построена на базе OpenStack. Однако, в силу того, что OpenStack не предоставляет нативных средств для обслуживания публичного облака, мы реализовали недостающую функциональность в наборе дополнительных API, которые упрощают управление сложными составными объектами и делают работу более удобной. Часть функциональности, доступной в OpenStack, закрыта от использования напрямую, но доступна через наш API.
В Terraform-провайдере Selectel сейчас реализована возможность управления следующими ресурсами VPC:
проекты и их квоты;
пользователи, их роли и токены;
публичные подсети, в том числе кросс-региональные и VRRP;
лицензии ПО.
Провайдер использует нашу публичную Go-библиотеку для работы с API VPC. И библиотека и сам провайдер являются open-source, их разработка ведется на Github:
Для управления остальными ресурсами облака, такими как виртуальные машины, диски, кластеры Kubernetes, вы можете использовать Terraform-провайдер OpenStack. Официальная документация для обоих провайдеров доступна по следующим ссылкам:
Манифесты для работы с Selectel создаются посредством Terraform либо используя набор готовых примеров, которые доступны в нашем Github-репозитории: terraform-examples.
Репозиторий с примерами разбит на две директории:
modules, содержащая небольшие переиспользуемые модули, которые принимают на вход набор параметров и управляют небольшим набором ресурсов;
examples, содержащая примеры полного набора связанных между собой модулей.
После установки Terraform, создания ключа Selectel API и ознакомления с примерами, переходим к практическим примерам.
В файле vars.tf описаны все параметры, которые будут использованы при вызове модулей. Некоторые из них имеют значения по умолчанию, например, сервер будет создан в зоне ru-3a со следующей конфигурацией:
Аргумент ignore_changes позволяет игнорировать изменение атрибута id для образа, используемого для создания виртуальной машины. В сервисе VPC большинство публичных образов обновляется автоматически раз в неделю и при этом их id также меняется. Это обусловлено особенностями работы компонента OpenStack — Glance, в котором образы считаются неизменяемыми сущностями.
Если создается или изменяется существующий сервер или диск, у которого в качестве аргумента image_id используется id публичного образа, то после того как этот образ будет обновлен, повторный запуск манифеста Terraform приведет к пересозданию сервера или диска. Использование аргумента ignore_changes позволяет избежать такой ситуации.
Примечание: аргумент ignore_changes появился в Terraform достаточно давно: pull#2525.
Аргумент ignore_resize_confirmation нужен для успешного изменения размера локального диска, ядер или памяти сервера. Такие изменения производятся через компонент OpenStack Nova при помощи запроса resize. По умолчанию Nova после запроса resize переводит сервер в статус verify_resize и ждет от пользователя дополнительного подтверждения. Однако это поведение можно изменить так, чтобы Nova не дожидалась от пользователя дополнительных действий.
Указанный аргумент позволяет Terraform не дожидаться статуса verify_resize для сервера и быть готовым к тому, что сервер окажется в активном статусе после изменения его параметров. Аргумент доступен с версии 1.10.0 Terraform-провайдера OpenStack: pull#422.
Создание ресурсов
Перед запуском манифестов следует учесть, что в нашем примере запускаются два разных провайдера, причем провайдер OpenStack зависит от ресурсов провайдера Selectel, так как без создания пользователя в проекте управлять принадлежащими ему объектами невозможно. К сожалению, по этой же причине мы не можем просто запустить команду terraform apply внутри нашего примера. Нам потребуется вначале сделать apply для модуля project_with_user и уже после этого для всего остального.
Примечание: указанная проблема еще не решена в Terraform, за ее обсуждением можно следить на Github в issue#2430 и issue#4149.
После запуска команды Terraform покажет, какие ресурсы он хочет создать и потребует подтверждения:
Plan: 3 to add, 0 to change, 0 to destroy.
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
Как только проект, пользователь и роль будут созданы, можно запустить создание остальных ресурсов:
C созданной виртуальной машиной можно работать через SSH по указанному IP.
Редактирование ресурсов
Помимо создания ресурсов через Terraform, их также можно изменять.
Для примера увеличим количество ядер и памяти для нашего сервера, изменив значения для параметров server_vcpus и server_ram_mb в файле examples/vpc/server_local_root_disk/main.tf:
В обоих случаях потребуется подтвердить удаление всех объектов:
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
Этот пример создает проект, пользователя с ролью в проекте и поднимает один кластер Kubernetes. В файле vars.tf можно увидеть значения по умолчанию, такие как количество нод, их характеристики, версия Kubernetes и прочее.
Для создания ресурсов аналогично первому примеру первым делом запустим инициализацию модулей и создание ресурсов модуля project_with_user, а затем создание всего остального:
Передадим создание и управление кластерами Kubernetes через компонент OpenStack Magnum. Подробнее о том, как работать с кластером, вы можете узнать в одной из наших предыдущих статей, а также в базе знаний.
При подготовке кластера будут созданы диски, виртуальные машины и произойдет установка всех необходимых компонентов. Подготовка занимает около 4 минут, в это время Terraform будет выводить сообщения вида:
module.kubernetes_cluster.openstack_containerinfra_cluster_v1.cluster_1: Still creating... (3m0s elapsed)
После завершения установки Terraform сообщит, что кластер готов и отобразит его идентификатор:
Для управления созданным кластером Kubernetes через утилиту kubectl необходимо получить файл доступа к кластеру. Для этого перейдите в проект, созданный через Terraform, в списке проектов вашего аккаунта:
Далее перейдите по ссылке вида xxxxxx.selvpc.ru, которая отображается ниже имени проекта:
В качестве данных для входа используйте имя и пароль пользователя, которые были созданы через Terraform. Если вы не изменяли vars.tf или main.tf для нашего примера, то пользователь будет иметь имя tf_user. В качестве пароля нужно использовать значение переменной TF_VAR_user_password, которое было указано при запуске terraform apply ранее.
Внутри проекта вам нужно перейти на вкладку Kubernetes:
Здесь расположен кластер, созданный через Terraform. Скачать файл для kubectl можно на вкладке «Доступ»:
На этой же вкладке находится инструкция по установке kubectl и использованию скачанного config.yaml.
После запуска kubectl и установки переменной окружения KUBECONFIG можно использовать Kubernetes:
При изменении количества нод кластер будет оставаться доступным. После добавления ноды через Terraform, можно использовать ее без дополнительной конфигурации:
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
tf-cluster-rz6nggvs4va7-master-0 Ready,SchedulingDisabled master 8m v1.12.4
tf-cluster-rz6nggvs4va7-minion-0 Ready <none> 8m v1.12.4
tf-cluster-rz6nggvs4va7-minion-1 Ready <none> 8m v1.12.4
tf-cluster-rz6nggvs4va7-minion-2 Ready <none> 3m v1.12.4
Заключение
В этой статье мы ознакомились с основными способами работы с «Виртуальным приватным облаком» через Terraform. Будем рады, если вы воспользуетесь официальным Terraform-провайдером Selectel и предоставите обратную связь.
Обо всех найденных багах Terraform-провайдера Selectel можно сообщить посредством Github Issues.