Подготовка инфраструктуры
Важно: раздел описывает подготовку инфраструктуры для self-hosted GitHub Runner
Требования
-
GitHub Actions;
-
Хост для установки GitHub Runner, имеющий:
-
Bash;
-
Git версии 2.18.0 или выше;
-
GPG.
-
Установка и регистрация GitHub Runner
Установите и зарегистрируйте GitHub Runner на выделенный для него хост, следуя официальным инструкциям.
Настройка окружения для сборки с Buildah
Для установки Buildah выполните следующие инструкции на хосте для GitLab Runner:
- Установите пакет 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 для сборки и развертывания:
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 при очистке.