Мы занимаемся заказной разработкой. В основном это web-сервисы, требующие отказоустойчивости, горизонтального масштабирования и имеющие микросервисную архитектуру. Мы уже внедрили достаточно давно CI/CD/QA-автотесты - это все позволяет нам деплоить десятки сервисов, хоть каждый день гонять по 3-4 тысячи тестов перед релизом, но оставался единственный фактор ошибок - по-разному настроенные боевые и тестовые среды, выбор очевиден - внедрение IaC. Но после внедрения обнаружили много плюсов данного подхода. Об этом ниже.

Мы запускаем более 15 проектов в год и трудозатраты на инфраструктуру были огромными - много микросервисов, 4 среды, настроить это все, да еще и без ошибок, задача не из простых. Но инфраструктура любого проекта на 80% идентичная (да, мы жестко следим за зоопарком технологий). Да и каждый раз приходилось настраивать одни и те же системы по нескольку раз для каждого проекта. Мы внедрили и используем подход "DevOps-инфраструктура как код". Теперь вся инфраструктура - это код. Мы используем Ansible как средство, но можно и другие. Кодовая база разбита на модули - postgres, elk, haproxy, kubernetes, rabbitmq и т.п. - каждый модуль настраивает конкретную систему. Эти модули хранятся и развиваются в GIT. Модули используются в разных проектах и позволяют инфраструктуру нового проекта поднять за 4 часа - набрав из модулей новый проект и задав конфигурации (Ip-хостов и т.п. настройки, специфичные для каждого конкретного проекта). Этот подход дал нам такие плюсы - экономия времени - вся инфраструктура за 4 часа, отсутствие человеческого фактора - настройку делает машина, делает ровно то, что в коде - ни больше, ни меньше, живая документация - код, ревью кода инфраструктуры в GIT, историчность изменений, откаты.

Но вы помните, что мы таким способом настраиваем 80% инфраструктуры, а где же оставшиеся 20? - это Docker в сочетании с Kubernetes. Администраторы любят, хотят и хорошо настраивают что-то фундаментальное - их часть это Ansible и все модули, о которых мы говорили выше. Разработчики же хорошо знают и дотошно понимают прикладные системы - настройки nginx, node.js, какую версию .net Core поставить и т.п, а админам ну совсем этим заниматься не хочется. Поэтому весь приклад 20% разработчики самостоятельно настраивают внутри Docker-контейнеров и так же хранят все настройки в GIT. Таким образом удалось четко разделить обязанности и дать возможность каждому заниматься тем, что ему нравится, естественно, с перекрытием компетенций на стыке.

Это 100% практический опыт, которым я и хотел бы поделиться. Многие компании внедряют у себя CI/CD/QA, но забывают что CI/CD/QA никак не поможет если production-сервер настроен иначе чем staging, а идентичность настроек можно добиться только c IaC.

Второй момент. Многие считают, что IaС - это очень дорого и долго, отчасти они правы, но на масштабе - это гораздо дешевле, чем ручные операции и исправление ошибок и финансовые риски в случае падения системы.

ТЕЗИСЫ:
1. О себе и компании.
2. Проблематика - зачем это нужно, какие проблемы решает.
3. Суть подхода.
3. Конкретные проблемы, которые будем решать.
3.1 Много проектов, все похожи на 80%, модули.
3.2 Переиспользование модулей, хранение в Git, ревью, пересборка, удаление машин и т.п.
3.3 Ansible - смотрим на код, примеры.
4. 20% - что у разработчиков, идея отдать разработчикам приклад, зачем, почему администраторы не любят приклад и т.п
4.1 Смотрим на код, практическое решение Docker + Kubernetes.
5. Подводим итоги.
5.1 Экономика - финансовые выгоды.
5.2 Технические выгоды - горизонтальное масштабирование в 1 клик (допустим, добавили новую ноду в kubernetes, модуль хапрокси увидел, что в группе с нодами кубернетес добавилась новая и при запуске перенастроит свои конфиги уже на +1 ноду, контейнеры в кубернетес, естественно, переедут сами на новую ноду).

Возможно, что-то еще, план примерный, выгод от подхода много.