Лучшие практики CI/CD

Для чего компании внедрять CI/CD

Best practices CI/CD

• DinD требует привилегированных контейнеров, что делает его менее безопасным в сравнении с Kaniko.

• При использовании DinD могут возникать проблемы с производительностью из-за сложностей с запуском Docker внутри Docker.
  

## common_artifact
FROM registry.examle.ru/infra/ubuntu-base:common AS common_artifact

SHELL ["/bin/bash", "-o", "pipefail", "-c"]

RUN su app -c 'wget --quiet https://repo1.maven.org/maven2/com/google/javascript/closure-compiler/v.../closure-compiler-v....jar -O  /opt/closure-tools/compiler.jar --no-check-certificate'

COPY --chown=app:app . /app

ARG db_string
ARG db_user_name
ARG db_password
ARG db_host
ARG db_port
ARG db_name

RUN echo "${db_host}  pgsql.db" >> /etc/hosts && \
    /usr/bin/php some commads

COPY --chown=app:app ./.infra/files/js_min.sh /app/js_min.sh

RUN su app -c '/bin/bash /app/js_min.sh'

WORKDIR /app/somedir/protected

RUN su app -c '/bin/bash gulpc'

### frontend
FROM registry.examle.ru/infra/nginx-upstream-limit:nginx-gc AS frontend

COPY ./.infra/files/frontend/nginx.conf /etc/nginx/nginx.conf
COPY ./.infra/files/frontend/content /app/somedir/content
COPY . /app

RUN rm -rf /app/somedir/protected/modules \
    /app/somedir/protected/resource \
    /app/somedir/js \
    /app/_sql/sqlLocalizationUpdate*

COPY --from=common_artifact /app/somedir/protected/modules /app/somedir/protected/modules
COPY --from=common_artifact /app/somedir/protected/resource /app/somedir/protected/resource
COPY --from=common_artifact /app/somedir/js /app/somedir/js
COPY --from=common_artifact /app/_sql/sqlLocalizationUpdate* /app/_sql/

## backend
FROM registry.examle.ru/infra/ubuntu-base:backend AS backend

SHELL ["/bin/bash", "-o", "pipefail", "-c"]

ENV LC_ALL=ru_RU.UTF-8
ENV LANG=ru_RU.UTF-8

COPY --chown=app:app ./.infra/files/backend/fonts /usr/share/fonts/TTF
RUN chown -R app:app /usr/share/fonts/TTF && chmod -R 0755 /usr/share/fonts/TTF

COPY ./.infra/files/frontend/wp_content /app/somedir/wp-content
COPY --chown=app:app ./.infra/files/somedir/cron.d /etc/cron.d
COPY --chown=app:app ./.infra/files/somedir/somedir /etc/somedir
COPY --chown=app:app ./.infra/files/somedir/d /etc/service/d
COPY --chown=app:app ./.infra/files/somedir/supercronic_run /etc/service/supercronic/run
COPY --chown=app:app ./.infra/files/backend/php-fpm.conf /etc/php/7.4/fpm/php-fpm.conf
COPY --chown=app:app ./.infra/files/backend/php.ini /etc/php/7.4/cli/php.ini
COPY --chown=app:app ./.infra/files/backend/php-fpm.ini /etc/php/7.4/fpm/php.ini
COPY --chown=app:app . /app

WORKDIR /app

RUN rm -rf /app/somedir/protected/modules \
    /app/somedir/protected/resource \
    /app/somedir/js \
    /app/_sql/sqlLocalizationUpdate* && \
    mkdir -p /app/somedir/protected/runtime && \
    chown -R app:app /app/somedir/protected/runtime

COPY --from=common_artifact --chown=app:app /app/somedir/protected/modules /app/somedir/protected/modules
COPY --from=common_artifact --chown=app:app /app/somedir/protected/resource /app/somedir/protected/resource
COPY --from=common_artifact --chown=app:app /app/somedir/js /app/somedir/js
COPY --from=common_artifact --chown=app:app /app/_sql/sqlLocalizationUpdate* /app/_sql/

ci-templates/

├── build/

│   └── kaniko-build-template.yml

├── test/

│   └── test-template.yml

├── deploy/

│   └── argo-deploy-template.yml

└── .gitlab-ci.yml

stages:
  - build

include:
  - local: stage-ci.yml

.build:
  stage: build
  image:
    name: registry-url/infra/kaniko-executor:v1.16.0-debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - cat ${CR_CONFIG} > /kaniko/.docker/config.json
    - touch new-test
    - echo "test" >> new-test
    - >
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${DOCKERFILE}"
      --destination "registry-url/${REGISTRY}/${IMAGE}"
      --cache=true
      --cache-repo "registry-url/${REGISTRY}/${CI_PROJECT_NAME}-cache"


build_dev:
  extends: 
    - .build
  variables:
    REGISTRY: $CR_AGENCY_DEV_ID
    CR_CONFIG: $CR_AGENCY_DEV_CONFIG
    IMAGE: ${CI_PROJECT_NAME}:${CI_COMMIT_SHORT_SHA}
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^feature\/.*/
    - if: $CI_COMMIT_BRANCH == "develop"
  cache:
    policy: push

build_prod:
  extends: 
    - .build
  variables:
    REGISTRY: $CR_AGENCY_PROD_ID
    CR_CONFIG: $CR_AGENCY_PROD_CONFIG
    IMAGE: ${CI_PROJECT_NAME}:${CI_COMMIT_TAG}
  rules:
    - if: $CI_COMMIT_TAG != null

build_stage:
  extends: 
    - .build
  variables:
    REGISTRY: $CR_AGENCY_PROD_ID
    CR_CONFIG: $CR_AGENCY_PROD_CONFIG
    IMAGE: ${CI_PROJECT_NAME}:${CI_COMMIT_TAG}
  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'

include:
  - project: 'ci-templates'
    file: 'build/kaniko-build-template.yml'

# Определение триггеров для сборки

workflow:
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
    - if: '$CI_COMMIT_REF_NAME == "staging"'
    - if: '$CI_COMMIT_REF_NAME == "develop"

1. 1. Унификация процессов. Использование шаблонов позволяет обеспечить единообразие процессов CI/CD для всех проектов. Это особенно важно для крупных организаций с большим количеством проектов.
2. 
   
3. 2. Повторное использование. Шаблоны могут быть использованы в разных проектах, что сокращает время на настройку CI/CD и минимизирует вероятность ошибок.
4. 
   
5. 3. Гибкость. При необходимости шаблоны можно модифицировать для определённых проектов, сохраняя при этом общую структуру.
   
   
   4. Облегчение управления изменениями. Все изменения в пайплайнах можно вносить централизованно, в репозитории с шаблонами. Это упрощает поддержку и обновление CI/CD процессов для всех проектов одновременно.
   
   

# Общие настройки для ArgoCD

global:
  image:
    repository: argoproj/argocd
    tag: v2.9.0 # Укажите актуальную версию ArgoCD
  installCRDs: true

# Настройки для сервера ArgoCD

server:
  service:
    type: ClusterIP
    port: 80

  # Настройка Ingress для доступа к UI ArgoCD

  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: nginx
      cert-manager.io/cluster-issuer: "letsencrypt-prod" # Опционально, если вы используете cert-manager для TLS
    hosts:
      - host: argo.example.com
        paths:
          - /
    tls:
      - secretName: argocd-tls
        hosts:
          - argo.example.com

# Настройки безопасности

# Определение ресурсов для ArgoCD серверов

controller:
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi

repoServer:
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi

# Настройка синхронизации проектов

applicationSet:
  enabled: true

# Опции RBAC для пользователей

rbacConfig:
  policy.default: role:readonly
  scopes: "[groups]"
# Автоматическое создание пользователя admin с паролем

initialAdminPassword: "supersecretpassword"

• enabled — включает Ingress.

• annotations — опционально добавляем аннотации для интеграции с cert-manager, если требуется автоматическая настройка TLS сертификатов.

• hosts — задаёт доменное имя (в данном случае argo.example.com), по которому будет доступен ArgoCD.

• tls — настройка для автоматического получения TLS-сертификатов, указав secretName для хранения сертификатов.
  

4. controller.resources и repoServer.resources — задают ресурсы для компонентов ArgoCD (ограничения по CPU и памяти).

5. rbacConfig — позволяет настроить права доступа по умолчанию для пользователей, задавая роль readonly для базовых пользователей.

6. initialAdminPassword — задаёт начальный пароль для пользователя admin, который будет создан при установке ArgoCD.

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm install argo-cd argo/argo-cd --namespace argocd --create-namespace -f values.yaml

Пример файла values.yml для вашего приложения:

app:
  name: "my-app"
  version: "1.0.0"

image:
  repository: "my-registry/my-app"
  tag: "latest"
  pullPolicy: "IfNotPresent"

replicaCount: 2
service:
  type: "ClusterIP"
  port: 80

ingress:
  enabled: true
  annotations: {}
  hosts:
    - host: "my-app.example.com"
      paths:
        - "/"
  tls: []

resources:
  limits:
    cpu: 100m
    memory: 128Mi

  requests:
    cpu: 50m
    memory: 64Mi

1. 1. Шаблон деплоя с ArgoCD — создадим файл argo-deploy-template.yml:

stages:
  - deploy

.deploy_template: &deploy_template
  image: bitnami/kubectl:latest
  script:
    - kubectl config set-cluster $K8S_CLUSTER --server=$K8S_SERVER --insecure-skip-tls-verify=true
    - kubectl config set-credentials $K8S_USER --token=$K8S_TOKEN
    - kubectl config set-context $K8S_CONTEXT --cluster=$K8S_CLUSTER --user=$K8S_USER
    - kubectl config use-context $K8S_CONTEXT
    - argocd app sync my-app --prune --timeout 300

# Деплой на production

deploy_prod:
  <<: *deploy_template
  stage: deploy
  environment:
    name: production
  script:
    - argocd app sync my-app-prod --prune --timeout 300
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'

# Деплой на staging

deploy_stage:
  <<: *deploy_template
  stage: deploy
  environment:
    name: staging
  script:
    - argocd app sync my-app-stage --prune --timeout 300
  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'

# Деплой на development

deploy_dev:
  <<: *deploy_template
  stage: deploy
  environment:
    name: development
  script:
    - argocd app sync my-app-dev --prune --timeout 300
  rules:
    - if: '$CI_COMMIT_REF_NAME == "develop"'

Этот шаблон:

• Настраивает kubectl для работы с Kubernetes-кластером через предоставленные переменные (сервер, токен, контекст).

• Использует команду argocd app sync для синхронизации приложений в разных окружениях (prod, stage, dev).
  

include:
  - local: 'argo-deploy-template.yml'

workflow:
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
    - if: '$CI_COMMIT_REF_NAME == "staging"'
    - if: '$CI_COMMIT_REF_NAME == "develop"'

ArgoCD предлагает мощные инструменты для GitOps-ориентированного деплоя приложений, с поддержкой автоматической синхронизации и удобного управления через UI. Мы рассмотрели его установку через Helm, создание Helm-чарта на базе nxs-universal-chart, а также интеграцию с GitLab CI для деплоя в разные окружения.

Преимущества использования Vault

HashiCorp Vault — это инструмент для безопасного управления секретами и доступом к ним в приложениях и инфраструктуре. Он поддерживает шифрование данных, динамическое управление доступом и аудит использования секретов, что делает его важным элементом в CI/CD пайплайнах.

1. Параметр: Управление секретами

HashiCorp Vault: Централизованное управление секретами с поддержкой динамических секретов.

FluxCD Secret Management: Ограничено Kubernetes Secret и интеграцией с SOPS.

2. Параметр: Шифрование

HashiCorp Vault: Полноценное шифрование секретов в хранилище и при передаче.

FluxCD Secret Management: Шифрование секретов через внешние инструменты.

3. Параметр: Политики и доступ

HashiCorp Vault: Гибкое управление доступом через политики и роли.

FluxCD Secret Management: Доступ на основе ролей Kubernetes и RBAC.

4. Параметр: Поддержка облаков и баз данных

HashiCorp Vault: Поддерживает динамическое создание временных учётных данных для облаков и баз данных.

FluxCD Secret Management: Отсутствует встроенная поддержка динамических секретов.

Vault обеспечивает более мощное и гибкое управление секретами, в то время как FluxCD ограничен базовой работой с Kubernetes Secret и интеграцией с инструментами шифрования, такими как SOPS.

Установка Vault через Helm

Чтобы развернуть HashiCorp Vault в Kubernetes-кластере, можно использовать Helm для установки. Установка включает редактирование файла values.yaml для кастомизации конфигурации под ваши нужды.

Добавим репозиторий Helm для Vault:

helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update

Создадим файл values.yaml, чтобы кастомизировать установку Vault, включая настройку Ingress.

Пример файла values.yaml для Vault с поддержкой Ingress:

server:
  # Включение режима HA (High Availability) для Vault
  ha:
    enabled: true
    replicas: 3
  
# Настройка сервиса для Vault
  service:
    type: ClusterIP

  # Включение и настройка Ingress для доступа к Vault UI

  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: nginx
      cert-manager.io/cluster-issuer: "letsencrypt-prod"  # Опционально, если вы используете cert-manager
    hosts:
      - host: vault.example.com
        paths:
          - /
    tls:
      - hosts:
          - vault.example.com
        secretName: vault-tls

  # Политики и начальные настройки

  extraConfig: |
    listener "tcp" {
      address = "0.0.0.0:8200"
      tls_disable = 1
    }
    storage "file" {
      path = "/vault/data"
    }
    ui = true

  # Задание ресурсов для Vault
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi

• ha.enabled — включает режим High Availability (HA) для повышения отказоустойчивости, с тремя репликами Vault.

• ingress — настраивает Ingress для доступа к Vault через домен vault.example.com. TLS поддерживается через cert-manager.

• extraConfig — конфигурация для работы Vault. Включаем интерфейс UI и определяем хранилище данных.

• resources — определение лимитов и запросов по ресурсам для оптимального использования кластера.
  

Установка Vault с нашим values.yaml:

helm install vault hashicorp/vault --namespace vault --create-namespace -f values.yaml

После установки Vault будет доступен через Ingress по адресу https://vault.example.com.

stages:
  - build
# Шаблон для использования Vault

.vault_template: &vault_template
  image: hashicorp/vault:latest
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/db-creds)
    - echo "Database password retrieved from Vault: $DB_PASSWORD"

# Билд для production

build_prod:
  <<: *vault_template
  stage: build
  environment:
    name: production
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/prod/db-creds)
    - ./build.sh
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'

# Билд для staging

build_stage:
  <<: *vault_template
  stage: build
  environment:
    name: staging
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/staging/db-creds)
    - ./build.sh

  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'

# Билд для development

build_dev:
  <<: *vault_template
  stage: build
  environment:
    name: development
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/dev/db-creds)
    - ./build.sh

  rules:
    - if: '$CI_COMMIT_REF_NAME == "develop"'

include:
  - local: 'vault-secrets-template.yml'
workflow:
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
    - if: '$CI_COMMIT_REF_NAME == "staging"'
    - if: '$CI_COMMIT_REF_NAME == "develop"'

Итоговый .gitlab-ci.yml файл

# Включение шаблонов для сборки, деплоя и работы с секретами Vault

include:
  - local: 'kaniko-build-template.yml'
  - local: 'argo-deploy-template.yml'
  - local: 'vault-secrets-template.yml'

# Определение этапов пайплайна

stages:
  - build
  - deploy

# Определение триггеров для пайплайнов на основе веток

workflow:
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
    - if: '$CI_COMMIT_REF_NAME == "staging"'
    - if: '$CI_COMMIT_REF_NAME == "develop"'

# Билд для production с Kaniko и Vault

build_prod:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  environment:
    name: production
  script:
    # Вход в Vault и получение секретов для продакшена
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/prod/db-creds)
    # Билд Docker-образа через Kaniko
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:prod --cache=true
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'

# Билд для staging с Kaniko и Vault

build_stage:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  environment:
    name: staging
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/staging/db-creds)
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:stage --cache=true
  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'

# Билд для development с Kaniko и Vault

build_dev:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  environment:
    name: development
  script:
    - vault login $VAULT_TOKEN
    - export DB_PASSWORD=$(vault kv get -field=password secret/dev/db-creds)
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:dev --cache=true
  rules:
    - if: '$CI_COMMIT_REF_NAME == "develop"'

# Деплой на production через ArgoCD
deploy_prod:
  stage: deploy
  image: bitnami/kubectl:latest
  environment:
    name: production
  script:
    - kubectl config set-cluster $K8S_CLUSTER --server=$K8S_SERVER --insecure-skip-tls-verify=true
    - kubectl config set-credentials $K8S_USER --token=$K8S_TOKEN
    - kubectl config set-context $K8S_CONTEXT --cluster=$K8S_CLUSTER --user=$K8S_USER
    - kubectl config use-context $K8S_CONTEXT
    - argocd app sync my-app-prod --prune --timeout 300

  rules:

    - if: '$CI_COMMIT_REF_NAME == "main"'

# Деплой на staging через ArgoCD

deploy_stage:
  stage: deploy
  image: bitnami/kubectl:latest
  environment:
    name: staging
  script:
    - kubectl config set-cluster $K8S_CLUSTER --server=$K8S_SERVER --insecure-skip-tls-verify=true
    - kubectl config set-credentials $K8S_USER --token=$K8S_TOKEN
    - kubectl config set-context $K8S_CONTEXT --cluster=$K8S_CLUSTER --user=$K8S_USER
    - kubectl config use-context $K8S_CONTEXT

    # Синхронизация приложения через ArgoCD
    - argocd app sync my-app-stage --prune --timeout 300
  rules:
    - if: '$CI_COMMIT_REF_NAME == "staging"'

# Деплой на development через ArgoCD
deploy_dev:
  stage: deploy
  image: bitnami/kubectl:latest
  environment:
    name: development
  script:
    - kubectl config set-cluster $K8S_CLUSTER --server=$K8S_SERVER --insecure-skip-tls-verify=true
    - kubectl config set-credentials $K8S_USER --token=$K8S_TOKEN
    - kubectl config set-context $K8S_CONTEXT --cluster=$K8S_CLUSTER --user=$K8S_USER
    - kubectl config use-context $K8S_CONTEXT
    - argocd app sync my-app-dev --prune --timeout 300
  rules:
    - if: '$CI_COMMIT_REF_NAME == "develop"'

Обзор итогового пайплайна:

1. Сборка:

• Используется Kaniko для сборки Docker-образов для каждого окружения (prod, staging, dev).

• В процессе сборки, перед запуском Kaniko, из Vault извлекаются секреты для каждого окружения (например, пароли для баз данных).
  

2. Деплой:

• После успешной сборки происходит деплой через ArgoCD.

• Для каждого окружения используется отдельное приложение в ArgoCD (my-app-prod, my-app-stage, my-app-dev).
  

3. Workflow:

Пайплайн запускается только при работе с ветками main (production), staging, и develop.

Заключение

Эффективный CI/CD-процесс сегодня — это не просто автоматизация сборки и деплоя, а комплексная система, которая включает управление секретами, безопасное окружение для сборки, гибкость конфигураций и контроль на каждом этапе. Интеграция инструментов, таких как GitLab CI, Kaniko, ArgoCD и HashiCorp Vault, позволяет создавать мощные и безопасные пайплайны, которые обеспечивают стабильность и предсказуемость процесса разработки.