Спонсировал этот пост.
Текущие модели крупных языков (LLMS) могут генерировать синтаксически правильный код Terraform HCL, но могут ли они генерировать развертываемые функциональные стеки терраформ? Любой, кто попробовал, быстро заметит образец.
Давайте возьмем простой пример: небольшое приложение с ведром Amazon S3 и функцией лямбды.
Итерация 1: ИИ генерирует основы
Для приглашения «генерировать Terraform для создания ведра AWS S3 и функции лямбды, которая обрабатывает загруженные объекты», — ответ нашего ИИ был:
На первый взгляд, Terraform выглядит правильно и имеет достоверный синтаксис, но при ближайшем рассмотрении у него отсутствуют критические части.
Отсутствуют разрешения: Функция Lambda не имеет разрешения на чтение или запись в ведро S3.
Нет триггера событий: Ведро не уведомляет функцию лямбда при загрузке объекта.
Без ведения журнала, без тегов: Лучшие практики, такие как ведение журнала, мониторинг и метаданные ресурсы, отсутствуют. Итерация 2: добавление разрешений IAM
Я усовершенствовал подсказку, чтобы включить разрешения на управление идентификацией и доступом (IAM): «Убедитесь, что функция Lambda имеет наименьшую привилегию, необходимую для чтения и записи в ведро S3».
Ответ ИИ:
Теперь функция Lambda имеет минимальные необходимые разрешения, но она все еще отсутствует. Используя этот подход, мы можем итерации на неопределенный срок, пока не получим то, с чем мы довольны. Мы даже можем найти модели, которые, кажется, дают лучшие ответы с более четким подсказом.
Ключевой момент, однако, заключается в том, что, хотя LLM производит HCL, в конечном итоге именно навык и знания разработчика определяют качество и точность окончательного вывода. Чтобы направить LLM к удовлетворительному результату, разработчик нуждается в четкой картине их конечного дизайна, включая понимание услуг AWS, IAM и более тонкие точки настройки и интеграции этих компонентов.
Тренируется на фрагменты, а не системы
Я подозреваю, что большинство моделей искусственного интеллекта не обучены терраформу производственного класса, поскольку они в основном используют общедоступный контент для обучения. Учитывая, что большинство производственных проектов Terraform являются частными, представляется, что доступные данные обучения будут состоять из фрагментов и примеров кода, доступных в документах, учебных пособиях или проектах с открытым исходным кодом.
Подумайте о том, где живет наиболее доступной терраформ:
Документы и учебные пособия: Минимальные или фрагментированные конфигурации, предназначенные для демонстрации концепций и изолированных лучших практик, без широкого контекста или полных примеров.
Ответы на переполнение стека: Быстрые исправления, которые решают разовые проблемы, возможно, отсутствуют зависимости, настройки безопасности или более широкий контекст.
Проекты с открытым исходным кодом: Полезно, но непоследовательные-популярные коммерческие проекты с открытым исходным кодом не часто публикуют инфраструктуру как код (IAC) для их размещенных или платных решений, ограничивая доступность высококачественных, полных проектов IAC.
Модели не обучаются миллионам полных, безопасных и масштабируемых репозиториев инфраструктуры. Вместо этого они собирают фрагментированные фрагменты из доступных примеров. Вот почему я считаю, что сгенерированный AI Terraform часто не хватает:
Последовательная структура: Нет стандартизации между модулями.
Осознание зависимости: Ресурсы не связаны должным образом.
Лучшие практики безопасности: ИИ не обеспечивает наименьшую привилегию IAM Роли или сетевые правила.
Масштабируемость и операции фокусируются: Регистрация, мониторинг и автомассалирование часто игнорируются. Мы не можем ожидать, что ИИ решит неопределенные проблемы
Если вы попросите ИИ генерировать терраформ, не объясняя, что должна делать ваша инфраструктура, это даст вам очень общие версии того, о чем вы просили. Это потому, что он не будет знать о ваших требованиях безопасности, стратегии масштабирования или о том, как услуги должны взаимодействовать.
Дело не в том, что предоставленные ответы неверны, а в том, что слишком много неизвестных, поэтому предполагается, что он предполагает заполнить пробелы. И угадание не работает для реальных приложений.
Вместо этого модели должны использоваться квалифицированными операторами, которые относятся к ИИ как помощника, который работает в рамках структурированной структуры.
Лучший подход:
Используйте ИИ, чтобы помочь в написании кода приложения. Определите потребности вашего приложения в инфраструктуре вместо того, чтобы ожидать, что ИИ будет «разобраться». Используйте ИИ, чтобы помочь с Terraform, но обеспечить контекст для обеспечения безопасности, зависимостей и лучших практик. Убедитесь, что все готово к статическим инструментам анализа.
Этот подход заставляет ИИ работать в структуре, а не генерировать инфраструктуру слепо. Тем не менее, все еще есть одна серьезная проблема: определение ваших требований к инфраструктуре требует времени и полного понимания того, как ваше приложение должно работать в облаке, и эти знания часто хранятся вашими архитекторами и инженерами по надежности сайта (SRES).
Введение контекста и опыта
Большинство разработчиков не эксперты по терраформ, и большинство моделей ИИ не понимают полных архитектур. Вот где входит азот. Он не просто генерирует инфраструктуру; Он вводит контекст приложения и является самоуверенными в отношении того, как должно быть предоставлено ваше приложение.
Пример: функция с ведром
Давайте вернемся к нашему предыдущему примеру функции, которая записывает ведро S3.
Без азота
ИИ может генерировать что -то, что похоже на работу Terraform:
Есть проблемы:
Функции Lambda не хватает разрешений на запись в ведро. Нет триггера событий, чтобы вызвать функцию. Регистрация и мониторинг отсутствуют. Политика IAM не следует философии наименьшей привилегии, которая увеличивает векторы атаки. С азотом
NICE позволяет вам определить логику вашей приложения, и он генерирует инфраструктуру, которая соответствует требованиям вашего приложения. Это происходит путем создания спецификации ресурса или графика требований вашего приложения и отображения их с предопределенными модулями Terraform, которые готовы к производству, но могут быть переопределены или расширены вашими собственными модулями, которые вы можете использовать AI, чтобы помочь написать, если вы решите.
Код приложения (Python)
Сгенерированные выводы Terraform для Lambda и S3 Bucket
IAM разрешения правильно установлены. Правильный триггер событий подключен к ведению ведения журнала, а мониторинг автоматически настроена политики безопасности, и введены политики тега. Наименьшая привилегия гарантирована, потому что терраформ всегда синхронизируется с требованиями APP. Добавьте контекст в AI-написанный IAC
ИИ может быть мощным инструментом для создания кода инфраструктуры, но ему нужен правильный контекст, чтобы создать что -то действительно полезное. Ваша модель безопасности, потребности в масштабировании и эксплуатационные ограничения не понимают ИИ. По сути, это требует руководства.
Азотный прилив этот пробел, автоматически генерируя спецификацию инфраструктуры на основе кода приложения. Это гарантирует, что сгенерированный AI Terraform не просто функциональный, но следует правильным зависимостям, политике безопасности и передовым опытом.
Построенный в качестве проекта с открытым исходным кодом для сообщества, NICE делает облачное развитие более предсказуемым и безопасным. Присоединяйтесь к нам в формировании будущего — внесите вклад в NITIT сегодня!
NICE-это облачная структура, которая повышает производительность разработчиков и уверенность в OPS, объединение бэкэнд и кода инфраструктуры для быстрого создания и поставки облачных приложений. Devs создают ваше приложение, платформа определяет правильную инфраструктуру, а NILIC автоматизирует обеспечение, которое работает для обоих. Узнайте больше последних из Nitic Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Рак Шива, вице -президент по технике инженерии в команде NITIC, глубоко привержен повышению опыта для разработчиков программного обеспечения. С богатым 15-летним пребыванием в индустрии программного обеспечения он начал свое инженерное путешествие, погруженное в волнующие вызовы … Подробнее от Rak Siva
