Ручная настройка серверов через SSH приводит к тому, что окружения расходятся, а восстановление после сбоя занимает дни и держится на памяти одного человека. Инфраструктура как код убирает эту зависимость: вся конфигурация — сети, кластеры, базы, балансировщики, права доступа — описана в репозитории, версионируется в Git и разворачивается одной командой. Прод, стейдж и локальная среда собираются из одного описания и отличаются только параметрами.
Провижининг ресурсов ведётся через Terraform: VPC, подсети, узлы, managed-базы, объектное хранилище, DNS и правила фаервола описываются декларативно, состояние хранится в удалённом бэкенде с блокировками, изменения проходят через plan и review до применения. Настройка самих машин и базовых сервисов — через Ansible: идемпотентные роли вместо разрозненных скриптов.
Оркестрация приложений — Kubernetes: деплойменты, сервисы, ingress, автоскейлинг подов и узлов, ресурсные лимиты, health-checks и rolling-обновления. Пакетирование через Helm с разделением values по окружениям. Секреты выносятся во внешние хранилища (Vault, sealed-secrets), а не в манифесты. При GitOps-подходе состояние кластера синхронизируется с репозиторием через ArgoCD или Flux.
Работаю с AWS, GCP, Azure, Yandex Cloud и bare-metal. Выбор провайдера и managed-сервисов обосную стоимостью и требованиями к данным, а не привычкой. На выходе — репозиторий с инфраструктурой, документированные окружения и процедура восстановления, которую может выполнить любой инженер команды, а не только автор.
IaCTerraformTerragruntAnsiblePulumi
ОркестрацияKubernetesHelmArgoCDFlux
ОблакаAWSGCPAzureYandex Cloud
СетьVPCnginx-ingressCiliumCloudflare
СекретыVaultSOPSsealed-secretsExternal Secrets
РеестрDockerHarborGitLab RegistryTrivy
Провижининг через Terraform
Сети, кластеры, managed-базы, хранилища и права описаны кодом, состояние в удалённом бэкенде, изменения через plan и review.
Kubernetes-кластеры
Разворачивание и настройка кластеров, ingress, автоскейлинг подов и узлов, ресурсные лимиты, rolling-обновления.
Окружения dev/stage/prod
Идентичные среды из одного описания, отличаются только параметрами. Новое окружение поднимается за часы, а не недели.
Конфигурация через Ansible
Идемпотентные роли для настройки машин и базовых сервисов вместо разрозненных bash-скриптов и ручных правок.
Helm-пакетирование
Приложения как чарты с разделением values по окружениям, шаблонизация манифестов, версионирование релизов.
GitOps
Состояние кластера синхронизируется с репозиторием через ArgoCD или Flux, любое изменение проходит через Git.
Управление секретами
Секреты во внешних хранилищах (Vault, sealed-secrets, SOPS), а не в манифестах и не в переменных окружения открытым текстом.
Автоскейлинг и лимиты
Горизонтальное масштабирование подов и узлов под нагрузку, requests/limits, чтобы не платить за простаивающие ресурсы.
Мультиоблако и bare-metal
AWS, GCP, Azure, Yandex Cloud или свои серверы. Выбор провайдера обоснован стоимостью и требованиями к данным.
Документация и восстановление
Описание окружений и процедура disaster recovery, которую может выполнить любой инженер, а не только автор.
Зачем нужен Terraform, если всё уже работает?
Ручная настройка держится на памяти и разрозненных скриптах: восстановление после сбоя долгое, окружения расходятся, знания у одного человека. IaC делает инфраструктуру воспроизводимой, версионируемой и передаваемой. Особенно окупается при росте команды и числа сервисов.
Обязательно ли Kubernetes или можно проще?
Не обязательно. Kubernetes оправдан при множестве сервисов, нестабильной нагрузке и потребности в автоскейлинге. Для простого проекта достаточно нескольких машин под управлением Ansible и docker-compose. Решение обосную по нагрузке и составу, а не по моде.
Какое облако выбрать?
Под задачу: AWS и GCP — широкий набор managed-сервисов; Yandex Cloud — данные в РФ и 152-ФЗ; bare-metal — предсказуемая стоимость при стабильной нагрузке. Часто оптимален гибрид. Выбор обосную цифрами по стоимости и требованиями к данным.
Можно перенести существующую инфраструктуру в код?
Да. Сначала инвентаризация того, что уже развёрнуто, затем поэтапное описание в Terraform с импортом существующих ресурсов, без пересоздания и простоя. Прод переводится в код по частям, а не одним рискованным шагом.
Как будут храниться секреты и доступы?
Секреты выносятся во внешние хранилища — Vault, sealed-secrets или SOPS — и не попадают в манифесты и репозиторий открытым текстом. Доступы к облаку — по принципу минимальных прав, с аудитом. Терраформ-состояние — в защищённом бэкенде с блокировками.
Что если облачные счета выходят из-под контроля?
Разберу структуру затрат: неиспользуемые ресурсы, завышенные лимиты, дорогие managed-сервисы там, где хватит своего. Настрою requests/limits, автоскейлинг и алерты по бюджету. Часто экономия достигается без потери надёжности.
Сможет ли команда поддерживать это без вас?
Да, это цель подхода. Инфраструктура в репозитории, изменения через привычный Git-процесс, окружения и восстановление документированы в runbook-ах. Провожу обучение команды и передаю проект так, чтобы он не был «чёрным ящиком».