Ну поговорим теперь о технике. Этой вашей Инфраструктуре-как-Код (далее IaC).
В те давние времена, когда каждый админ автоматизировал свою работу в баш скриптах (а особо крутые в питон скриптах), людям нужно было вести журнал изменений (помните, что про Agile никто не знал, и все поголовно были ITILовцами).
В основном в качестве трекера изменений использовали ticket-систему, а в конфигурацию систем и серверов вносили номер ticket’а, по которому инициировалось изменение. Менеджер по изменениям мог видеть номер ticket’а в конфигурации почтового сервера, зайти в систему и посмотреть, кто это придумал, кто это реализовал, ну и, собственно, зачем.
Помимо этого велся отдельный журнал незапланированных изменений, этакий excel файлик на общем диске, куда люди вписывали, что они делали, на чем и когда.
Повторюсь, все это нужно было, чтобы отслеживать каждое изменение в инфраструктуре (ведь изменения имеют свойство ломать все вокруг), и даже самые ответственные админы не всегда добавляли нужные пометки.
Эта и много других проблем легли в основу практики IaC.
Вкратце IaC это подход, в котором инженеры относятся к своей инфраструктуре как к исходному коду приложения. А раз наша инфраструктура теперь приложение, то и применяются к ней все best practices разработки, а именно:
- держим “код” инфраструктуры в центральном репозитории, изменения к которому делаются через commit/push или pull/merge requests
- держим несколько “окружений” инфраструктуры: локальное (development), test/stage и production.
- держим код в чистоте - PEP8, Linting, etc
- гоняем тесты, в том числе интеграционные.
- проводим Code Review.
- все это проходит через CI/CD систему, после чего выкатывается на нужное окружение.
Инфраструктуру здесь стоит разбить на две категории (на самом деле можно и больше, но нам в конкретном случае достаточно и этого): сетевая инфраструктура (сеть, серверы, фаерволы и тд) и приложения (все, что ставится на сами серверы - базы данных, приложения и прочее).
Зачем это делается? Да затем, что в больших и маленький конторах за разные части инфраструктуры отвечают разные “роли” инженеров.
Сетевики правят конфиги фаерволлов и маршрутизаторов, ДБАшники тюнят базы данных, “обычные” админы накатывают обновление на серверы, релиз инженеры релизят, безопасники безопасят… в общем, много всего делается.
Можно уйти в дебри применения IaC в классических ЦОДах, где кругом хардкорный bare metal и вот это вот все.
Но поскольку у нас тут 21-ый век, облачные вычисления, managed services и хипстеры с макбуками, мы не будем лезть так глубоко.
Видите ли, если вы подсели на героин Амазона, Микрософта или Гугла, все эти роутеры, свичи, прошивки металлических серверов, гипервизоры виртуализации вас не касаются. Ими по-прежнему управляют, но не вы. Вы к настройкам сетки не прикоснетесь никак.
В вашем случае каждый кусок инфраструктуры вам доступен в качестве ресурса. Таблица маршрутизации - ресурс. Сети и подсети - ресурс. Базы данных - ресурс. Виртуальные машины - ресурс. Правила фаервола, вы не поверите, тоже ресурс! Ну и так далее.
Поэтому в увлекательном мире AWS/GCP/Azure вам нужно организовать только две группы: ресурсы и приложения.
Для того, чтобы управлять ресурсами есть много разных прикольных штук - от нативных (Cloudformation для AWS, Resource Manager для Azure и Google Cloud - причем это РАЗНЫЕ Resource Manager’ы!) до кастомных 3rd party штучек, таких как Packer, Ansible (да, он вам и сетки с подсетками сделает, ну не прелесть ли?), Terraform, Salt-Cloud и т.д.
А вот для управления приложениями служат наши старые добрые друзья, которые вам всем знакомы - Chef, Puppet, Ansible, Salt, CFEngine, ну и что я там еще мог забыть.
Нет смысла писать какие SCM системы применять. Git/SVN/CVS тут знают все (ну почти все). Для Linting тоже есть огромная масса финтифлюшек - взять например ansible-lint и hiera lint.
Для тестов вашей инфраструктуры существует ряд фреймворков - serverspec. testinfra… - всех не счесть. Если написанные утилитки вас не устраивают, то тесты можно написать и самому в том же скрипте.
