Как вносились изменения в борды

Историческая эволюция управления изменениями

Этот вопрос затрагивает одну из центральных парадигм DevOps: неизменяемую инфраструктуру (Immutable Infrastructure) и управление конфигурацией. Раньше "внесение изменений в борды" (скорее всего, речь о серверах, board — устаревший сленг) подразумевало прямое редактирование конфигураций на работающих системах (Snowflake Servers), что вело к дрейфу конфигурации и проблемам с воспроизводимостью. Современный подход кардинально иной.

Современный подход: инфраструктура как код (IaC)

Сегодня изменения не вносятся напрямую в сервера. Вместо этого мы меняем декларативный код, описывающий желаемое состояние всей инфраструктуры и конфигураций. Этот код хранится в системе контроля версий (например, Git). Основные принципы:

• Декларативное описание: Мы описываем что нужно (например, 3 инстанса с таким-то образом, балансировщиком, правилами безопасности), а не как это делать скриптами.
• Идемпотентность: Применение конфигурации многократно дает один и тот же результат.
• Версионирование: Каждое изменение — это коммит в Git с понятным сообщением, Pull/Merge Request (PR/MR) и код-ревью.
• Сквозная автоматизация: Изменение в коде через CI/CD-пайплайн автоматически разворачивается в среду.

Ключевые инструменты и технологии

• Провиженинг и оркестрация: Terraform, AWS CloudFormation, Pulumi, Ansible (более идемпотентный, но может быть и процедурным).
• Управление конфигурацией: Ansible, Chef, Puppet, SaltStack (для паттерна mutable infrastructure, но тоже через код).
• Контейнеризация: Самый яркий пример неизменяемости. Мы не патчим контейнер, а собираем новый образ (Dockerfile — это код) и заменяем старый.
• Система контроля версий: Git — единый источник истины.

Типичный рабочий процесс (GitOps-подход)

Давайте рассмотрим пример изменения масштаба кластера Kubernetes через GitOps с использованием Terraform и Helm.

1. Внесение изменения в код

Разработчик/инженер создает ветку от main, редактирует файл конфигурации Terraform, описывающий кластер (например, увеличивает количество узлов).

# main.tf (фрагмент) - Было
resource "aws_eks_node_group" "main" {
  ...
  scaling_config {
    desired_size = 3
    max_size     = 5
    min_size     = 3
  }
}

# main.tf (фрагмент) - Стало после редактирования
resource "aws_eks_node_group" "main" {
  ...
  scaling_config {
    desired_size = 5 # <- Изменение
    max_size     = 7
    min_size     = 5 # <- Изменение
  }
}

2. Ревью и согласование

Создается Pull Request. Команда проводит ревью кода: проверяет безопасность, стоимость, соответствие стандартам. Запускаются автоматические проверки в CI:

• terraform fmt и terraform validate для синтаксиса.
• terraform plan для предпросмотра изменений (что будет создано/изменено/удалено).

3. Слияние и автоматическое развертывание

После аппрува PR сливается в main. Это событие триггерит CI/CD-пайплайн (например, в GitLab CI, GitHub Actions или Jenkins).

# Пример этапа в .gitlab-ci.yml
deploy_production:
  stage: deploy
  environment: production
  script:
    - terraform init -backend-config="backend.hcl"
    - terraform apply -auto-approve # Автоматическое применение утвержденного плана
  only:
    - main
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

4. Верификация и мониторинг

После применения:

• CI/CD-пайплайн или отдельный инструмент мониторинга (Prometheus, Grafana) проверяет здоровье нового состояния.
• Запускаются интеграционные/смок-тесты.
• Все изменения зафиксированы, состояние инфраструктуры полностью соответствует коду в репозитории.

Важные аспекты для собеседования

1. Безопасность: Креденшалы никогда не хранятся в коде, используются секреты в vault (HashiCorp Vault, AWS Secrets Manager).
2. Стратегии развертывания: Для минимизации даунтайма применяются сине-зеленые развертывания или канареечные (canary), особенно при обновлении образов приложений.
3. Откат (Rollback): В случае проблемы, откат — это применение предыдущей, стабильной версии кода из Git (например, git revert и запуск пайплайна заново).
4. Документация: Код самодокументирован. По истории Git можно точно понять, кто, когда и зачем внес изменение.

Итог: Современный DevOps-инженер не "заходит на сервер", чтобы поменять конфиг. Он работает как разработчик: пишет код инфраструктуры, делает коммиты, отправляет на ревью и полагается на автоматизированные пайплайны для безопасного и предсказуемого развертывания изменений во всех средах. Сдвиг произошел от ручного управления состоянием к управлению через декларативный код и автоматизацию.