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

Важно: раздел описывает подготовку инфраструктуры для self-hosted GitHub Runner

Требования

  • GitHub Actions;

  • Хост для установки GitHub Runner, имеющий:

    • Bash;

    • Git версии 2.18.0 или выше;

    • GPG.

Установка и регистрация GitHub Runner

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

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

Для установки Buildah выполните следующие инструкции на хосте для GitLab Runner:

  • Установите пакет Buildah, следуя официальным инструкциям, но не производите его дальнейшую настройку. Если для вашего дистрибутива нет готовых пакетов Buildah, используйте следующие инструкции:
Ручная установка Buildah
  • Установите пакеты, предоставляющие программы newuidmap и newgidmap.

  • Убедитесь, что программы newuidmap и newgidmap имеют корректные права:

    sudo setcap cap_setuid+ep /usr/bin/newuidmap
    sudo setcap cap_setgid+ep /usr/bin/newgidmap
    sudo chmod u-s,g-s /usr/bin/newuidmap /usr/bin/newgidmap
    
  • Установите пакет, предоставляющий файлы /etc/subuid и /etc/subgid.

  • Убедитесь, что в файлах /etc/subuid и /etc/subgid имеется строка вида gitlab-runner:1000000:65536, где:

    • gitlab-runner — имя пользователя GitLab Runner;

    • 1000000 — первый subUID/subGID в выделяемом диапазоне;

    • 65536 — размер диапазона subUIDs/subGIDs (минимум 65536).

    Избегайте коллизий с другими диапазонами, если они имеются. Изменение файлов может потребовать перезагрузки. Подробнее в man subuid и man subgid.

  • (Для Linux 5.12 и ниже) Установите пакет, предоставляющий программу fuse-overlayfs.

  • Убедитесь, что путь /home/gitlab-runner/.local/share/containers создан, и пользователь gitlab-runner имеет доступ на чтение и запись.

  • Команда sysctl -ne kernel.unprivileged_userns_clone НЕ должна вернуть 0, а иначе выполните echo 'kernel.unprivileged_userns_clone = 1' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.

  • Команда sysctl -n user.max_user_namespaces должна вернуть 15000 или больше, а иначе выполните echo 'user.max_user_namespaces = 15000' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.

  • (Для Ubuntu 23.10 и выше) установите значения kernel.apparmor_restrict_unprivileged_unconfined и kernel.apparmor_restrict_unprivileged_userns в 0 командой:{ 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

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

Требования

  • GitHub Actions;

  • GitHub-hosted Runner или self-hosted GitHub runner.

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

  • Создайте и сохраните access token для очистки ненужных образов из container registry со следующей конфигурацией:

    • Token name: werf-images-cleanup;

    • Scopes: read:packages и delete:packages.

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

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

      • Name: REGISTRY_CLEANUP_TOKEN;

      • Secret: <сохранённый "werf-images-cleanup" access token>.

  • Сохраните kubeconfig-файл для доступа к Kubernetes-кластеру в зашифрованный секрет KUBECONFIG_BASE64, предварительно закодировав его в Base64.

Конфигурация CI/CD проекта

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

.github
.helm
app
werf.yaml
name: cleanup
on:
  schedule:
    - cron: "0 3 * * *"

jobs:
  cleanup:
    name: cleanup
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - run: git fetch --prune --unshallow

      - uses: werf/actions/install@v2

      - run: |
          source "$(werf ci-env github --as-file)"
          werf cleanup
        env:
          WERF_KUBECONFIG_BASE64: ${{ secrets.KUBECONFIG_BASE64 }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          WERF_REPO_GITHUB_TOKEN: ${{ secrets.REGISTRY_CLEANUP_TOKEN }}

name: prod
on:
  push:
    branches:
      - main

jobs:
  prod:
    name: prod
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - uses: werf/actions/install@v2

      - run: |
          source "$(werf ci-env github --as-file)"
          werf converge
        env:
          WERF_ENV: prod
          WERF_KUBECONFIG_BASE64: ${{ secrets.KUBECONFIG_BASE64 }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          WERF_BUILDAH_MODE: auto

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

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

  • Для использования GitHub-hosted Runner укажите ubuntu-latest в runs-on;

  • Если вы не используете ghcr в качестве container registry, то проставьте WERF_REPO, выполните werf cr login, а также учтите особенности вашего container registry при очистке.) вашего container registry при очистке.