Андрей Иванов

Привет! На связи Андрей Иванов, старший системный администратор по облачным продуктам. Очень часто к нам обращаются клиенты по вопросам автоматизации работы с инфраструктурой. Лучший подход для подобных задач — IaC (Infrastructure as Code), когда весь комплекс элементов и их взаимодействие описывается с помощью кода, вместо настройки вручную. Самый известный инструмент для этого — Terraform от компании HashiCorp, который стал отраслевым стандартом для воплощения IaC в жизнь. Сегодня рассмотрим принципы работы с ним, а в качестве примера создадим кластер Managed Kubernetes версии 1.33.5. Что такое Terraform и в чем его сила Terraform от компании HashiCorp — это инструмент управления состоянием инфраструктуры, который позволяет описывать и разворачивать ее компоненты с помощью декларативных конфигурационных файлов. С его помощью можно поднимать серверы, настраивать сети, балансировщики нагрузки, служебных пользователей и прочие элементы инфраструктуры. Чаще всего Terraform используют в связке с Ansible, который отвечает за автоматизацию программного обеспечения на оборудовании, подготовленном с помощью Terraform. Немаловажно то, что Terraform и Ansible — это инструменты с открытым исходным кодом. Ключевые преимущества подхода IaC Автоматизация и скорость. Вся инфраструктура создается и обновляется одной командой, что экономит десятки часов ручного труда. Воспроизводимость. Описанные в коде компоненты и их взаимосвязи будут воспроизведены одинаково в любом окружении — будь то тестовая среда или продакшен. Прозрачность и контроль версий. Конфигурационные файлы можно хранить в Git, отслеживать все изменения, проводить ревью кода и легко откатываться к предыдущим версиям. Предотвращение ошибок. Команда terraform plan позволяет увидеть все планируемые изменения до их применения, что помогает избежать случайного удаления или неверной настройки критически важных ресурсов. Что будем делать Наша цель — развернуть в облаке базовый, но готовый к реальной работе кластер Kubernetes. Мы создадим для него изолированную приватную сеть и настроим облачный роутер для доступа в интернет. Этот пример коснется фундаментальных и самых важных практик, таких как правильная структура проекта, которую легко поддерживать и расширять. При этом мы сознательно опускаем некоторые продвинутые темы, чтобы не перегружать материал. За рамками статьи останутся CI/CD-интеграция, создание сложных переиспользуемых модулей и тонкая настройка Kubernetes. Наша задача — получить прочную и правильную основу. Шаг 0. Предварительные требования При работе с Terraform мы взаимодействуем с несколькими компонентами. Terraform CLI — инструмент для выполнения команд. Его можно назвать «ядром» системы. Конфигурационные файлы (*.tf) описывают инфраструктуру — конечный результат, который должен получиться. State (состояние) — отражение реальной инфраструктуры. Terraform сравнивает желаемое состояние инфраструктуры с действительным и самостоятельно предпринимает действия, чтобы эта разница перестала обнаруживаться. Модули — это группы ресурсов, которые могут быть использованы повторно. Они позволяют создавать абстракции и упрощают управление. Провайдер — плагин, который позволяет Terraform взаимодействовать с внешними сервисами и API. В Terraform используется несколько команд для взаимодействия с инфраструктурой: terraform init — первоначальная настройка проекта, которая включает загрузку необходимых провайдеров и модулей; terraform plan — отображает план изменений перед решающим шагом; terraform apply — утверждения плана и воплощение его в реальных компонентах инфраструктуры; terraform destroy — удаление всех созданных ресурсов. Перед началом работы убедимся, что у нас есть все необходимое. Аккаунт Selectel Учетную запись можно завести на странице регистрации. Понадобится указать электронную почту и придумать пароль. Вся дальнейшая работа будет происходить в панели управления Selectel. Также желательно для нашей задачи создать отдельный проект. Название можно задать произвольное, в нашем случае — WorkLab. Служебный пользователь Переходим в проект, выбираем вкладку Пользователи и нажимаем на ссылку Сервисные пользователи. Создадим одного «начального» служебного пользователя. Ему потребуются роли iam_admin и member в области видимости Аккаунт. Его учетные данные будем использовать для первоначальной аутентификации Terraform. Файлы проекта удобно хранить в одном месте — заранее создадим для них каталог на компьютере. Выбрать для него имя, совпадающее с именем проекта, — вполне логично. Пусть это тоже будет WorkLab: Terraform CLI Сложного ничего нет — устанавливаем дистрибутив Terraform, подходящий для нашей операционной системы. Самый простой вариант — с сайта HashiCorp. Обратите внимание: для каждого пакетного менеджера команды свои — их можно взять на той же странице HashiCorp. Ниже — вариант для Debian/Ubuntu/SelectOS: Если с доступом к ресурсам HashiCorp наблюдаются проблемы, то Terraform можно взять с нашего зеркала. В таком случае пригодится инструкция. Установленный kubectl В официальной документации Kubernetes подробно описаны действия для установки утилиты командной строки. Поддерживаются различные пакетные менеджеры. В общем случае, выбрав нужную архитектуру (доступна также x86-64), скачиваем нужный образ, контрольную сумму, проверяем соответствие и, наконец, запускаем установку. Если все прошло без неожиданностей, остается удостовериться, что установлена актуальная версия: В рассматриваемом примере: Client Version: v1.34.0 Kustomize Version: v5.7.1 Шаг 1. Установка и настройка Правильная организация файлов — залог порядка в проекте. Разделение конфигурации на логические части делает код более читаемым и простым в обслуживании. Создадим файлы и разместим в созданной директории для нашего проекта — ~/WorkLab. versions.tf — здесь мы объявляем версии Terraform и необходимых провайдеров. Такая фиксация гарантирует, что конфигурация будет работать стабильно и предсказуемо даже спустя время. main.tf — размещаем основные ресурсы нашей инфраструктуры, такие как сам кластер Kubernetes, а также проект и сервисного пользователя для него. variables.tf — определяем входные переменные. Такой подход делает код гибким и позволяет, не затрагивая основную логику, легко менять параметры — например, количество серверов. outputs.tf — в этом файле описываем выходные данные. После создания инфраструктуры нам понадобится информация о ней — например, kubeconfig для доступа к кластеру. secret.tfvars — в этом файле опишем пароли, чтобы не указывать их в открытом виде. Флаги доступа к файлу можно настроить по своему усмотрению, но разумно забрать права на чтение и запись у всех, кроме владельца файла и, может быть, его группы. Начнем с файла versions.tf. В качестве провайдеров укажем Selectel и OpenStack, поскольку инфраструктура нашего облака построена на его основе. Мы должны вписать актуальные версии, которые можно посмотреть в реестре Terraform на страницах OpenStack и Selectel. Использование оператора пессимистичного ограничения ~> — хорошая практика. Она позволяет автоматически получать минорные обновления и исправления ошибок, но защищает от мажорных версий с ломающими изменениями. Шаг 2. Описание проекта и инфраструктуры Теперь, когда инициализация настроена, приступим к авторизации внутри провайдера и описанию инфраструктуры. Создадим нового сервисного пользователя и новый проект в файле main.tf. Такой подход предпочтителен при разворачивании инфраструктуры, поскольку следует принципу наименьших привилегий. Указывать значения напрямую в каждом параметре мы не будем, вместо этого сообщим переменные var, которые Terraform берет из variables.tf.Также рассмотрим, как работать с уже существующими проектом и сервисным пользователем. 1. В main.tf первым делом прописываем авторизационные доступы. Здесь у нас будут задействованы учетные данные сервисного пользователя из панели управления: 2. Далее объявим проект и сервисного пользователя: Список variables.tf на данном этапе будет выглядеть следующим образом: В случае работы с уже созданным сервисным пользователем в рамках существующего проекта нам потребуется предварительно импортировать нужные ресурсы. Для этого понадобятся их идентификаторы. Перейдем в раздел Аккаунт → Проекты и увидим UUID проекта. Посмотреть UUID сервисного пользователя можно в разделе Аккаунт → Сервисные пользователи. Копируем их и указываем при импорте ресурсов: terraform import selectel_vpc_project_v2.project_1 "7c2c2e1769e849c3b97ae1ff4bafd0cc" terraform import selectel_iam_serviceuser_v1.serviceuser_1 "1a3e8a0c78864f14ab9f02bdea87d925" Остается только объявить их в variables.tf: В variables.tf в качестве пароля мы указывали параметр sensitive, который позволяет использовать переменную вместо указания реального пароля в манифесте. Если мы выполним в консоли terraform apply, нас спросят пароль. Чтобы не вводить его постоянно, мы создали отдельный файл secret.tfvars для хранения секретов: Чтобы файл с секретами сработал, при выполнении apply используем параметр -var-file"secret.tfvars". То есть после указания провайдеров, а также сервисного пользователя, приступаем к инициализации конфигурации Terraform. При выполнении скачиваются плагины провайдеров, указанные в versions.tf, и настраивается удаленное хранилище состояния (бэкенд), описанное там же. Если возникнет проблема с инициализацией провайдеров, попробуйте использовать VPN. Если все прошло благополучно, в числе прочей информации вы увидите: Terraform has been successfully initialized! Кроме того, команда apply создаст сервисного пользователя и новый проект, если мы не импортировали существующие. Шаг 3. Развертывание кластера Managed Kubernetes Для развертывания кластера нужно создать сеть, при этом крайне важно учесть несколько особенностей: подсеть должна быть подключена к облачному роутеру; также она не должна пересекаться с диапазонами 10.10.0.0/16, 10.96.0.0/12, 10.250.0.0/16 и 10.251.0.0/24, которые участвуют во внутренней адресации Managed Kubernetes; в подсети должен быть выключен DHCP. В таком случае в main.tf нам потребуется добавить ресурсы: приватную сеть и подсеть, а также облачный роутер. В данном примере возьмем подсеть, которую будем использовать для будущего кластера. В сеть пропишем облачный роутер, подключенный к интернету — через него наши тестовые воркер‑ноды будут выходить в мир. Для примера возьмем CIDR 192.168.195.0/24, и DNS-сервера Selectel. Добавляем следующие аннотации: Все готово для создания самого кластера. Добавим в main.tf ресурсы для него и группы нод. Ресурс data "selectel_mks_kubeconfig_v1" "kubeconfig" позволит нам пробросить в директорию /WorkLab наш kubeconfig и работать с кластером сразу после его создания: Обратите внимание: согласно техническому требованию API, для базового, не отказоустойчивого кластера (zonal true), необходимо отключать автоматическое обновление патч-версий: Наконец, опишем все наши переменные в файле variables.tf. Список доступных флейворов для нод представлен в документации. Шаг 4. Применение конфигурации Проводим генеральную репетицию Команда выше анализирует наш код и сравнивает его с текущим состоянием инфраструктуры, а затем показывает детальный план будущих изменений. Следует внимательно изучить вывод этой команды. В конце находится сводка: Plan: X to add, Y to change, Z to destroy. Нужно убедиться, что количество ресурсов на создание, изменение и особенно на удаление (destroy) соответствует ожиданиям. Это главный инструмент для предотвращения непреднамеренных разрушений. Выполняем план, показанный на предыдущем шаге Команда apply создает, изменяет или удаляет ресурсы в облаке в соответствии с планом. Участие пользователя тоже потребуется — надо подтвердить действие, напечатав yes. Шаг 5. Доступ к кластеру Кластер создан, но как к нему подключиться? Для этого нам понадобится файл kubeconfig. Terraform может сгенерировать его автоматически. После выполнения terraform apply можно извлечь kubeconfig командой: Теперь настроим kubectl для работы с новым кластером. Необходимо указать полный путь до kubeconfig: Наконец, проверяем ноды: Если видно список нод со статусом Ready, поздравляем — кластер готов к работе! Шаг 6. Управление инфраструктурой как кодом Главная сила Terraform — в управлении изменениями. Допустим, нам нужно увеличить количество узлов в кластере с двух до трех. Для этого достаточно поправить одно значение в файле variables.tf: Можно запустить terraform plan, и удостовериться, что Terraform предлагает изменить только один параметр у одного ресурса: Plan: 0 to add, 1 to change, 0 to destroy. После ввода следующей команды, исправления отразятся в реальной инфраструктуре: Шаг 7. Удаление созданных ресурсов Если вы хотите удалить только определенные ресурсы, достаточно убрать связанные с ними аннотации из файла main.tf , после чего выполнить: Когда инфраструктура больше не нужна, ее можно полностью удалить одной командой. Такой подход убережет от списания средств за неиспользуемые ресурсы: Terraform покажет список всех удаляемых ресурсов и попросит подтверждения. Заключение Мы рассмотрели полный цикл управления кластером Managed Kubernetes в Selectel с помощью Terraform. Ресурсы можно не просто создавать без усилий, а делать это безопасно: использовать отдельный файл для секретов, получать доступ к кластеру правильным способом. Помните, верные практики — прочная основа для построения надежной и масштабируемой «инфраструктуры как код».

Андрей Иванов

Материалы автора

Основы работы с Terraform в Selectel на примере Managed Kubernetes