ПРИМЕЧАНИЕ: werf поддерживает сборку образов с использованием Docker-сервера или с использованием Buildah. Поддерживается сборка как Dockerfile-образов, так и stapel-образов через Buildah.

1. Подготовьте кластер Kubernetes

Убедитесь, что удовлетворены системные требования и выберите один из доступных режимов работы и перейдите к нему.

Ядро Linux с поддержкой OverlayFS в режиме rootless

Дополнительные действия не требуются.

Ядро Linux без поддержки OverlayFS в режиме rootless и использование привилегированного контейнера

Дополнительные действия не требуются.

Ядро Linux без поддержки OverlayFS в режиме rootless и использование непривилегированного контейнера

Для подключения устройства /dev/fuse в контейнерах под управлением werf необходим плагин fuse device:

# werf-fuse-device-plugin-ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: werf-fuse-device-plugin
spec:
  selector:
    matchLabels:
      name: werf-fuse-device-plugin
  template:
    metadata:
      labels:
        name: werf-fuse-device-plugin
    spec:
      hostNetwork: true
      containers:
      - image: soolaugust/fuse-device-plugin:v1.0
        name: fuse-device-plugin-ctr
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
        volumeMounts:
          - name: device-plugin
            mountPath: /var/lib/kubelet/device-plugins
      volumes:
        - name: device-plugin
          hostPath:
            path: /var/lib/kubelet/device-plugins

Примените приведенный выше манифест плагина в пространстве имен kube-system:

kubectl -n kube-system apply -f werf-fuse-device-plugin-ds.yaml

Также давайте создадим политику LimitRange с тем, чтобы Pod’ы, создаваемые в некотором пространстве имен, имели доступ к /dev/fuse:

# enable-fuse-limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: enable-fuse-limit-range
  namespace: gitlab-ci
spec:
  limits:
  - type: "Container"
    default:
      github.com/fuse: 1

Создайте пространство имен gitlab-ci и примените манифест LimitRange в этом пространстве имен (позже мы настроим раннер GitLab на использование этого пространства имен при создании Pod’ов для выполнения CI-заданий):

kubectl create namespace gitlab-ci
kubectl apply -f enable-fuse-pod-limit-range.yaml

2. Настройте GitLab-раннер в Kubernetes

Выберите один из доступных режимов работы и перейдите к нему.

Ядро Linux с поддержкой OverlayFS в режиме rootless

Базовая конфигурация раннера (/etc/gitlab-runner/config.toml):

[[runners]]
  name = "kubernetes-runner-for-werf"
  executor = "kubernetes"
  ...
  [runners.kubernetes]
    ...
    namespace = "gitlab-ci"
    [runners.kubernetes.pod_annotations]
      "container.apparmor.security.beta.kubernetes.io/build" = "unconfined"
    [runners.kubernetes.pod_security_context]
      fs_group = 1000
      run_as_group = 1000
      run_as_non_root = true
      run_as_user = 1000

О дополнительных опциях можно узнать из документации к Kubernetes executor.

Ядро Linux без поддержки OverlayFS в режиме rootless и использование привилегированного контейнера

Базовая конфигурация раннера (/etc/gitlab-runner/config.toml):

[[runners]]
  name = "kubernetes-runner-for-werf"
  executor = "kubernetes"
  ...
  [runners.kubernetes]
    ...
    namespace = "gitlab-ci"
    privileged = true

О дополнительных опциях можно узнать из документации к Kubernetes executor.

Ядро Linux без поддержки OverlayFS в режиме rootless и использование непривилегированного контейнера

Базовая конфигурация раннера (/etc/gitlab-runner/config.toml):

[[runners]]
  name = "kubernetes-runner-for-werf"
  executor = "kubernetes"
  ...
  [runners.kubernetes]
    ...
    namespace = "gitlab-ci"
    [runners.kubernetes.pod_annotations]
      "container.apparmor.security.beta.kubernetes.io/build" = "unconfined"
    [runners.kubernetes.pod_security_context]
      fs_group = 1000
      run_as_group = 1000
      run_as_non_root = true
      run_as_user = 1000

О дополнительных опциях можно узнать из документации к Kubernetes executor.

3. Настройте доступ проекта к целевому кластеру Kubernetes

Существует 2 способа доступа к целевому кластеру Kubernetes, в который разворачивается приложение:

  1. Используя Service Account для Kubenetes executor. Этот метод подходит только в том случае, если Kubernetes executor работает в целевом кластере Kubernetes.
  2. Используя kubeconfig с соответствующим настройками.

Service account

Вот пример конфигурации Service Account’а с именем gitlab-kubernetes-runner-deploy:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-kubernetes-runner-deploy
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-kubernetes-runner-deploy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: gitlab-kubernetes-runner-deploy
    namespace: gitlab-ci

Скорректируйте конфигурацию GitLab-раннера (/etc/gitlab-runner/config.toml), чтобы использовать этот Service Account:

[[runners]]
  name = "kubernetes-runner-for-werf"
  ...
  [runners.kubernetes]
    service_account = "gitlab-kubernetes-runner-deploy"
    ...

Kubeconfig

Присвойте переменной окружения WERF_KUBECONFIG_BASE64 в GitLab-проекте содержимое файла ~/.kube/config, закодированное в base64. werf будет автоматически использовать эту конфигурацию для подключения к целевому кластеру Kubernetes.

Этот метод подходит для случаев, когда Kubernetes executor и целевой кластер Kubernetes — два разных кластера.

4. Настройте файл gitlab-ci.yml проекта

Ниже приведено описание базового задания по сборке и развертыванию проекта:

stages:
  - build-and-deploy

Build and deploy application:
  stage: build-and-deploy
  image: registry.werf.io/werf/werf
  script:
    - source $(werf ci-env gitlab --as-file)
    - werf converge
  tags: ["kubernetes-runner-for-werf"]
назад
далее