Подготовка инфраструктуры

Требования

  • GitLab;

  • Хост для запуска GitLab Runner’а с предустановленным:

  • Argo CD.

Установка GitLab Runner

Установите GitLab Runner на выделенный для него хост, следуя официальным инструкциям.

Настройка окружения для сборки с Buildah

(Для Ubuntu 23.10 и выше) на хосте GitHub Runner запустите:

{ echo "kernel.apparmor_restrict_unprivileged_userns = 0" && echo "kernel.apparmor_restrict_unprivileged_unconfined = 0";} | sudo tee -a /etc/sysctl.d/20-apparmor-donotrestrict.conf && sudo sysctl -p /etc/sysctl.d/20-apparmor-donotrestrict.conf

Регистрация GitLab Runner

Следуйте официальным инструкциям по регистрации GitLab Runner’а в GitLab’е; укажите docker в качестве исполнителя и любой образ в качестве default image (например, alpine).

Настройка GitLab Runner

На хосте с GitLab Runner’ом откройте его конфигурационный файл config.toml и добавьте следующие параметры к GitLab Runner’у, который вы зарегистрировали выше:

[[runners]]
  name = "<имя зарегистрированного Runner'а>"
  [runners.docker]
    security_opt = ["seccomp:unconfined", "apparmor:unconfined"]
    volumes = ["/home/build/.werf"]

Если версия ядра Linux на хосте с GitLab Runner’ом ≤ 5.12, установите fuse на хост и добавьте дополнительный параметр в файл config.toml:

[[runners]]
  name = "<имя зарегистрированного Runner'а>"
  [runners.docker]
    devices = ["/dev/fuse"]

При необходимости проведите дополнительную настройку GitLab Runner’а.

Настройка container registry

Включите сборку мусора в своем container registry.

Подготовка системы для кроссплатформенной сборки (опционально)

Этот шаг необходим только если проводится сборка образов для платформ, отличных от хост-платформы, на которой запущен werf.

С помощью qemu-user-static зарегистрируйте эмуляторы в системе:

docker run --restart=always --name=qemu-user-static -d --privileged --entrypoint=/bin/sh multiarch/qemu-user-static -c "/register --reset -p yes && tail -f /dev/null"

Установка Argo CD Image Updater

Установите Argo CD Image Updater с патчем “continuous deployment of OCI Helm chart type application”:

kubectl apply -n argocd -f https://raw.githubusercontent.com/werf/3p-argocd-image-updater/master/manifests/install.yaml

Настройка проекта

Настройка приложения Argo CD

  1. В целевом кластере примените следующий Application CRD, чтобы развернуть бандл из container registry:
kubectl create -f - <<EOF
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/chart-version: ~ 1.0
    argocd-image-updater.argoproj.io/pull-secret: pullsecret:myproject-production/myproject-regcred
  name: myproject
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: myproject-production
    server: https://kubernetes.default.svc
  project: default
  source:
    chart: myproject
    repoURL: registry.mycompany.org/myproject
    targetRevision: 1.0.0
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
EOF

Значение argocd-image-updater.argoproj.io/chart-version="~ 1.0" означает, что оператор должен автоматически развернуть чарт с последней версией патча в диапазоне SEMVER 1.0.*.

  1. Создайте Secret для доступа к container registry проекта:
kubectl create -f - <<EOF
---
apiVersion: v1
kind: Secret
metadata:
  name: myproject-regcred
  namespace: myproject-production
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: BASE64_DOCKER_CONFIG_JSON
EOF

Настройка GitLab-проекта

  • Создайте и сохраните токен для очистки ненужных образов из container registry. Используйте следующие параметры:

    • Token name: werf-images-cleanup;

    • Role: developer;

    • Scopes: api.

  • Добавьте следующие переменные в переменные проекта:

    • Токен для очистки ненужных образов:

      • Key: WERF_IMAGES_CLEANUP_PASSWORD;

      • Value: <"werf-images-cleanup" токен для доступа, который вы сохранили выше>;

      • Protect variable: yes;

      • Mask variable: yes.

  • Добавьте ночную задачу по расписанию для очистки ненужных образов в container registry, установив ветку main/master в качестве целевой (Target branch).

Настройка CI/CD проекта

Вот как может выглядеть репозиторий, использующий werf для сборки и развертывания:

.helm
app
.gitlab-ci.yml
werf.yaml
stages:
  - release
  - cleanup

default:
  image:
    name: registry.werf.io/werf/werf:2-stable
    pull_policy: always
  before_script:
    - source $(werf ci-env gitlab --as-file)
  tags: ["<GitLab Runner tag>"]

Build and publish release:
  stage: release
  script:
    - werf bundle publish --tag "1.0.${CI_PIPELINE_ID}"
  only:
    - main
  except:
    - schedules

Cleanup registry:
  stage: cleanup
  script:
    - werf cr login $WERF_REPO
    - werf cleanup
  only:
    - schedules


apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: {{ .Values.werf.image.app }}


apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    app: app
  ports:
  - name: app
    port: 80


FROM node

WORKDIR /app
COPY . .
RUN npm ci

CMD ["node", "server.js"]


{
  "name": "app",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "app",
      "version": "1.0.0"
    }
  }
}


{
  "name": "app",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  }
}


const http = require('http');

const hostname = '127.0.0.1';
const port = 80;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});


configVersion: 1
project: myproject
---
image: app
dockerfile: Dockerfile
context: ./app

Дополнительно:

  • Добавьте параметры авторизации для werf cleanup в container registry, следуя инструкции.