Где хранил конфиги CI?

Подход к хранению конфигураций CI/CD в DevOps-практике

В моей практике хранение конфигураций CI/CD (Continuous Integration/Continuous Deployment) — это критически важный аспект, который напрямую влияет на надёжность, безопасность и воспроизводимость процессов автоматизации. Я придерживаюсь принципа "Конфигурация как код" (Configuration as Code), что означает хранение всех конфигов исключительно в системах контроля версий, преимущественно в Git.

Основные места и стратегии хранения

1. Основной репозиторий приложения (Monorepo или Polyrepo)
В большинстве случаев конфигурации CI/CD хранятся в том же репозитории, что и исходный код приложения, которому они служат. Это обеспечивает:

• Версионирование и история изменений — каждый коммит с кодом сопровождается соответствующими изменениями в пайплайнах
• Согласованность — определённая версия кода всегда использует соответствующую версию конфигурации сборки
• Простота совместной разработки — разработчики видят и могут модифицировать пайплайны

Пример структуры в Git-репозитории:

project-root/
├── src/                    # Исходный код приложения
├── tests/                  # Тесты
├── .gitlab-ci.yml          # Конфиг GitLab CI
├── .github/workflows/      # Конфиги GitHub Actions
│   ├── build.yml
│   └── deploy.yml
├── Jenkinsfile             # Конфиг Jenkins
└── .circleci/config.yml    # Конфиг CircleCI

2. Отдельные репозитории для шаблонов и общих конфигураций
Для организаций с множеством сервисов использую отдельные репозитории с шаблонами:

• Шаблоны пайплайнов — DRY-принцип для избежания дублирования
• Общие библиотеки (например, Jenkins Shared Libraries)
• Декларативные конфигурации для многократного использования

Пример библиотеки Jenkins:

// vars/deployToK8s.groovy
def call(Map params) {
    pipeline {
        agent any
        stages {
            stage('Deploy to Kubernetes') {
                steps {
                    sh """
                        kubectl apply -f ${params.manifest}
                        kubectl rollout status deployment/${params.deployment}
                    """
                }
            }
        }
    }
}

3. Иерархическое хранение с наследованием
В сложных системах применяю иерархический подход:

• Базовые конфигурации в корпоративных шаблонах
• Оверрайды на уровне команд/проектов
• Индивидуальные настройки для специфичных окружений

Ключевые принципы и best practices

Безопасность хранения:

• Никогда не хранить секреты напрямую в репозиториях
• Использовать специализированные хранилища секретов (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Применять external secrets providers в пайплайнах

# Пример безопасного использования секретов в GitHub Actions
name: Secure Deployment
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to Production
        env:
          DEPLOY_TOKEN: ${{ secrets.PRODUCTION_DEPLOY_TOKEN }}
        run: |
          ./deploy.sh --token $DEPLOY_TOKEN

Управление конфигурациями:

• Явное версионирование всех зависимостей и инструментов
• Иммutable конфигурации — любые изменения только через коммиты
• Review process для изменений конфигураций через Pull Request
• Тестирование конфигураций CI/CD так же, как и прикладного кода

Организация и структура:

• Единый источник истины для каждой конфигурации
• Чёткое разделение окружений (dev, staging, production)
• Документация в README о назначении и использовании конфигураций
• Регулярный аудит и очистка устаревших конфигураций

Инструменты и технологии

В зависимости от стека технологий использовал различные подходы:

Для инфраструктуры как кода:

• Terraform — конфиги в отдельных репозиториях с remote state
• Ansible — разделение на inventory, playbooks и roles
• CloudFormation/Terraform — хранение шаблонов в S3/репозиториях

Для оркестрации контейнеров:

• Kubernetes manifests — в репозиториях приложений или отдельно
• Helm charts — как в репозиториях приложений, так и в chart repositories

Для мониторинга и alerting:

• Prometheus rules и Grafana dashboards — как код в Git
• Alertmanager configurations — версионированные и ревьювируемые

Эволюция подходов

За 10+ лет наблюдал эволюцию от:

1. Ручных настроек в веб-интерфейсах CI-систем
2. Скриптов в репозиториях без стандартизации
3. Декларативных конфигураций в YAML/JSON
4. Программируемых пайплайнов с полной гибкостью
5. GitOps-подхода, где Git становится единым источником истины

Современный подход — это GitOps, где не только конфигурации CI, но и CD, инфраструктура, политики безопасности хранятся в Git с автоматической синхронизацией в runtime-окружениях.

Такой комплексный подход обеспечивает воспроизводимость, аудитопригодность, коллаборацию и надёжность процессов CI/CD, что является фундаментом успешной DevOps-культуры в организации.