Infrastructure as Software

Мир инфраструктуры движется (хочется написать, что в сраное говно, но нет) в сторону упрощения управления сущностями. А сложность самих сущностей сильно возрастает. И то, что казалось шагами к упрощению, эту сложность как раз увеличивает в итоге.

Экскурс в историю (ну а куда же без него?). Изначально все управлялось каким-то набором скриптов и был бородатый дядька-сисадмин, который владел тайным знанием как и когда эти скрипты запускать. Все писали монолиты по Waterfall-у, релизились раз в полгода, а релиз занимал пару недель в лучшем случае и это всех устраивало. Всех кроме бизнеса, который хотел быстрее-выше-сильнее

Так появились agile-методологии, devops-практики, тут пропустим большой пласт истории, каждый желающий может найти по этой теме сотни статей на том же хабре и придем к тому, что мы имеем сейчас: у нас есть кубернетес, эдакий новый стандарт в индустрии, умеющий вообще все, что связано с запуском любых приложений. Имеет в основе своей декларативный формат описания своих сущностей. И их у него там не одна или две, а прям дохера, густо сплетенных между собой. И помимо базовых встроенных примитивов кубернетеса есть возможность писать свои, так называемые Custom Resource Definitions, что уносит количество примитивов прямо-таки в облака. Для тех же операторов кубера уже есть цельный отдельный "хаб". В итоге мы имеем пачку yaml-ов, огромное количество неочевидных связей между ними и какую-то логику их применения. Круто, можем положить это в гит и иметь версионирование, git blame и все вот это, что мы так любим.

Дальше у нас есть некий нижележащий слой условного железа, который в современной cloud-native среде превращается все равно в теже выделяемые провайдером ресурсы, которые надо бы как-то сначала сконфигурировать. Ну и плюсом у вас, например, не только кубернетес, а еще и какие-то ресурсы рядышком. Нужен Configuration Manager, который автоматом развернет и сконфигурирует приложения, да и тот же кубер например. Берем Ansible и получаем еще один набор ямликов, который описывает первичную конфигурацию всего нашего хозяйства. Ну и логику их применения конечно. Ах да, плюсом ансибл не знает ничего про состояние и в этом моменте его декларативность сыплется и нам уже нужно добавлять какую-то императивную логику, дабы все не порушить к херам. Но да, опять все положим в гит, потому как это все текстом описано удобненько

Но Ansible не может "заказать" ресурсы у провайдера, а может только работать уже с готовыми. А если вы оперируете сотнями инстансов VM у разных провайдеров (а VM, ну точнее Compute Node, например, все еще является базовым примитивом у облачного провайдера и никуда от них не деться), то человеческий фактор довольно быстро смачно даст вам под дых и превратит семейный субботний вечер в debugging hell. Нам на помощь приходит Terraform, приносит с собой свой собственный декларативный формат описания состояния, умеет получать информацию об этом состоянии прямо-таки вот из первых рук и вообще, очень хороший и удобный инструмент. Основную движущую силу которого, tf-файлы, также можно хранить в гите. Ну и иметь некую логику их применения.

И вот мы подошли к самому интересному. У нас есть гит как источник истины (Single Source of Truth), есть наша платформа, которая видоизменяется в соответствии с изменениями в нашем SSoT и есть инструменты, которые синхронизируют эти две сущности (GitOps, Infrastructure as Code и все такое). И вроде все кайфово и хорошо, но! Кто-то должен класть деньги в тумбочку. То есть эти ямлики в гит. И вот тут мы получаем развесистую пощечину и специальность "yaml-инженер". И я не шучу. Дело в том, что вот вся эта декларативная куча 💩 должна как-то управляться, а в силу декларативной природы, реализации логики в ней нет. А есть она в голове у инженера.