Разворачивать приложения в облаке должно быть просто. Но на деле - всё наоборот. Вместо “вжух-вжух и в продакшн” получаем вечер с документацией, пляски с параметрами Terraform и постоянную проверку, правильно ли связались ресурсы.

В статье разберемся, как от использования UI консоли приходят к Terraform, и как OpenIDE позволяет вернуть легкость UI консоли при работе с Terraform.

Почему развертывание в облако до сих пор сложно?

Облака сейчас повсюду, но до сих пор многим развертывание приложений в них кажется "загадкой". Вроде начинается с простого - заходишь в UI консоль облака, создаешь виртуальную машину, разворачиваешь на неё приложение, например с docker-compose, и всё готово. И для самого простого тестового приложения действительно достаточно. Но как только дело доходит до рабочего развертывания, всё усложняется. 

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

Всё ещё больше усложняется, когда нужно одновременно иметь несколько окружений (dev, stage, prod). Постепенно появляются расхождения в окружении, и всё чаще из уст разработчиков звучит фраза: “У меня на окружении всё работает, разбирайтесь с продом сами”.

Более того, с ростом проекта, как правило, растет и команда разработки. И теперь знания о развертывании есть только “в головах” определенных людей. Команды начинают задумываться об автоматизации развертывания и настройке CI/CD.

Начинаем писать скрипты

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

Одни проблемы решили - и сразу получили новые.

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

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

  • Заранее понять, какие изменения произойдут в облаке после применения скриптов, зачастую невозможно. Цена ошибки в императивных скриптах высока: если выполнение прервётся на середине, инфраструктура может оказаться в частично изменённом состоянии. Быстро и безопасно вернуться к предыдущей конфигурации в таком случае зачастую затруднительно.

Переходим к IaC

Для решения этих проблем в индустрии давно используется подход инфраструктура как код (IaC). Среди подобных инструментов лидируют Terraform и его форк OpenTofu. 

В Terraform инфраструктура описывается декларативно на собственном языке HCL. Не нужно самому думать над порядком создания ресурсов - описывается желаемое состояние инфраструктуры, а всё остальное Terraform делает “под капотом”. Terraform хранит состояние инфраструктуры и на его основе сравнивает текущее состояние с ожидаемым. 

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

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

Как вернуть простоту работы с облаком?

Мы задумались, может ли IDE вернуть част�� простоты UI-консоли, не жертвуя преимуществами Terraform и подхода IaC. В составе OpenIDE идет Amplicode, который уже помогает разработчикам автоматизировать рутинные действия при написании приложений на Spring Boot, предоставляя визуальные инструменты и генераторы. И этот опыт отлично ложится на работу с Terraform!

Палитра облачных ресурсов

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

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

Допустим, мы хотим развернуть тестовое окружение для приложения в Yandex Cloud. Возьмем, например, Spring Petclinic. Это веб-приложение, использующее PostgreSQL в качестве базы данных. Чтобы развернуть его в самом простом виде, нам понадобятся кластер PostgreSQL и виртуальная машина для запуска приложения внутри Docker.

Создаем новую Terraform конфигурацию и добавляем провайдер для Yandex Cloud из палитры. IDE добавит блок провайдера yandex и автоматически объявит его в секции required_providers.

После добавления провайдера создаем из палитры ресурс Managed PostgreSQL Cluster. На первом шаге задаем настройки кластера - версию PostgreSQL, класс хостов, тип и размер дискового хранилища, набор хостов и их сетевое размещение. На следующем шаге задаются параметры базы данных и пользователя. Параметры можно задать явно или вынести в Terraform-переменные.

Теперь создадим виртуальную машину для приложения. Аналогично выбираем из палитры Instance with Docker Compose и заполняем параметры в открывшемся диалоговом окне. При создании виртуальной машины IDE сразу предлагает создать сервисный аккаунт для виртуальной машины и подсказывает выдать роль container-registry.images.puller для доступа к Yandex Container Registry.

Amplicode создал ресурсы для виртуальной машины, сервисного аккаунта, а также файл docker-compose.yaml, который будет запускаться вместе с виртуальной машиной. Осталось добавить сервис в файл Docker Compose и передать параметры подключения к PostgreSQL. В Docker Compose файлах Amplicode также предоставляет палитру, в которой выбираем Spring Boot Application.

Объявляем переменные окружения и передаем соответствующие значения в Terraform, используя templatefile.

Конфигурация полностью готова! Её создание заняло у нас не более 2 минут, при этом большая часть конфигурации была сгенерирована и настроена с помощью визуальных инструментов IDE. OpenIDE не отменяет привычные практики работы с инфраструктурой: вся сгенерированная конфигурация остаётся обычным Terraform-кодом и может свободно редактироваться вручную. Дальше конфигурацию можно развернуть в облаке через локальный вызов terraform plan и apply или настроить CI/CD-пайплайн с вызовом этих команд.

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

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

Обзор Terraform конфигураций

Для всех Terraform конфигураций в проекте панель Amplicode Explorer отображает список ресурсов в иерархическом виде.

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

Обзор связей между ресурсами

Другой частой задачей при работе с Terraform конфигурациями - это поиск и быстрый переход к связанным ресурсам. Можно построить граф ресурсов с помощью terraform graph, потом визуализировать его с помощью GraphViz, а потом искать нужный ресурс в графе... но почему опять так сложно?

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

Наши планы

Мы не собираемся останавливаться на достигнутом и планируем и дальше развивать поддержку Terraform в OpenIDE. Одно направление, как я отмечал выше, - это поддержка большего числа облаков, в первую очередь отечественных. 

Сейчас повсюду говорят о программировании с помощью ИИ агентов. Команда Amplicode активно работает над Spring MCP, который дает ИИ агентам набор инструментов для работы с проектами на Spring. Аналогичный подход мы планируем применить и к Terraform-конфигурациям, предоставив ИИ-агентам инструменты для анализа, навигации и мод��фикации инфраструктурного кода.

Как попробовать?

Попробовать на практике можно уже сейчас. Скачивайте OpenIDE и изучайте возможности на любом Spring Boot проекте (например, Petclinic). На текущий момент описанная в статье функциональность находится в preview и доступна только для Spring Boot проектов. В начале 2026 года мы сделаем ее доступной для любых проектов.

Следите за обновлениями в нашем Telegram канале, чтобы не пропустить свежие обновления OpenIDE и полезные материалы.