Какие инструменты применял для деплоя

Мой стек для деплоя строится по принципу GitOps и идемпотентности.

1. Управление инфраструктурой (Provisioning):

• Terraform — основной инструмент. Я описываю всю инфраструктуру (VPC, подсети, security groups, кластеры Kubernetes, базы данных) в коде. Использую модули для переиспользования и remote state (храня в S3 с блокировкой через DynamoDB).

  # Пример модуля для создания EKS кластера в AWS
  module "eks" {
    source  = "terraform-aws-modules/eks/aws"
    version = "~> 19.0"
    cluster_name    = "prod-cluster"
    cluster_version = "1.27"
    vpc_id          = module.vpc.vpc_id
    subnet_ids      = module.vpc.private_subnets
  }

2. Оркестрация контейнеров (Runtime):

• Kubernetes — основная платформа. Для управления использую kubectl, а для упаковки приложений — Helm. Создаю Helm-чарты с шаблонами для deployment, service, ingress, configmap.

3. Непрерывная интеграция и доставка (CI/CD):

• GitLab CI/CD — мой основной инструмент. В .gitlab-ci.yml описываю стадии: сборка (build), сканирование уязвимостей (test), сборка образа и публикация в GitLab Container Registry, деплой.

  deploy_to_kubernetes:
    stage: deploy
    script:
      - helm upgrade --install my-app ./chart/ --values ./chart/values-$CI_ENVIRONMENT_NAME.yaml
    only:
      - main

• ArgoCD — для реализации GitOps. ArgoCD непрерывно следит за Git-репозиторием, где хранятся Helm-чарты и манифесты Kustomize, и автоматически синхронизирует состояние кластера с желаемым состоянием в репозитории.

4. Конфигурация и инициализация (Configuration Management):

• Для legacy-инфраструктуры или инициализации узлов использовал Ansible. Писал плейбуки для базовой настройки ОС, установки агентов мониторинга, настройки firewall.

Таким образом, процесс выглядит так: изменение кода -> GitLab CI/CD (сборка, тесты) -> обновление манифестов в Git -> ArgoCD автоматически применяет изменения в Kubernetes.