Comments 6
ожидание: код на тьюринг-полном языке программирования
реальность: куча конфигов и yml в гите
Это цена, скорость и уменьшение рисков.
"IaC это способ положить всю инфраструктуру разом." шуточная цитата от инженера из MAANG
Самая большая проблема IaC в том, что вы и описали в статье, есть средства разворачивания инфраструктуры такие как terraform, отдельно к ним идут средства управления конфигурациями (ansible), отдельно к ним идут средства доставки ваших приложений (helm), которые крутятся на сторонних средствах автоматизации и исполнения пайплайнов (jenkins), и все ничего друг о друге не знают. Список созданных terraform серверов не публикуется в ansible, а пайплайн автоматически не распознает эти хосты как пригодные для деплоя. Конфиг helm лезет в облако и создает нам load balancer, который не попадает в tfstate и так далее и тому подобное. Проблема как обычно в том что при попытке сделать решение все-в-одном, у нас появляется просто еще один способ решить частную проблему и таблица элементов продолжает расти без какой либо перспективы получить единый инструмент IaC.
Cdk, cdktf?
а как вы видите себе решение, которое абстрагирует в себя несколько слоев других абстракций?
Такой большой проект под силу только клауд провайдерам. Что-то подобное начали создавать Майкрософт со своим Azure DevOps, но это по прежнему система достаточно далекая от интеграции с самим облаком Azure, там все ходит по API через сервисные соединения, а в идеале я бы хотел видеть систему которая живет в том же облаке, где вся инфраструктура, имеет живой доступ к ресурсам и знает их статус, с возможностью менять компоненты индивидуально, не при помощи костыля в виде tfstate. В идеале получился бы единый инструмент по развертыванию инфраструктуры, настройке хостов и деплою приложений в облако, в одном «окне». Но где-то была информация что они бросают проект Azure DevOps, так что мечтам не суждено сбыться. Не знаю об остальных провайдерах, крайне мало с ними работал, но судя по тому что все компании с которыми я собеседовался так же используют терраформ и какой-нибудь паппет сверху, никакими «едиными решениями» пока не пахнет.
имхо, проблема в попытке соединить, то что должны быть раздельным.
вы правильно отметили, что есть несколько уровней абстракции, которые мало что про друг друга знают. и для управления эта малоинформированность слоев о друге друге мешает.
но с другой стороны, почему появились эти слои абстракции? как раз для того, чтобы каждый слой был максимально обособлен, и связь между ними была точно очерчена. тогда это дает возможность вносить изменения в каждый слой в отдельности, минимально влияя на соседние слои. т.е. наши абстракции умышленно создавались обособленными. в этом их главный плюс.
и да, этот плюс, с точки зрения управления является и минусом. ничего не достается бесплатно.
каков вывод: каждый новый слои абстракции может давать свои плюсы, расплачиваться за это приходится усложнением управления. хочется упростить управление? надо уменьшать количество абстракций.
Infrastructure as a Code – как инструмент DevOps