Jenkins і пайплайни CI
(Розділ: Технології та Інфраструктура)
Коротке резюме
Jenkins залишається універсальним «двигуном» CI в гібридних інфраструктурах iGaming: він об'єднує збірку додатків, контейнеризацію, тести, перевірку безпеки і публікацію артефактів. Успіх - це конвеєр як код (Declarative/Multibranch), Shared Libraries, ефемерні агенти в Kubernetes, жорстка безпека і секрети, GitOps-управління конфігом, а також метрики продуктивності і вартості.
1) Архітектура Jenkins під iGaming
Controller (LTS) + агенти: мінімум плагінів на контролері; робота переноситься в агенти.
Ефемерні агенти: запуск в K8s/під динамічний'jnlp'( швидкий старт, чисті оточення).
Ізоляція робіт: папки/права (Folders + Role-Based Strategy), креденшли з найменших прав.
Observability: експорт метрик (latency, черга), централізовані логи стадій, трейс-ID в пайплайнах.
2) Патерни пайплайнів: Declarative и Multibranch
Коли Declarative: стандартні конвеєри з однорідними стадіями, чіткі'post'-кроки.
Коли Scripted: рідкісні «нестандартні» розгалуження.
Multibranch: авто-пайплайн для кожної гілки/PR; політики «тільки активні гілки».
Базовий Declarative-пайплайн
groovy pipeline {
agent { label 'k8s' } // или agent { kubernetes {... } }
options {
timestamps()
ansiColor('xterm')
buildDiscarder(logRotator(numToKeepStr: '50'))
timeout(time: 30, unit: 'MINUTES')
disableConcurrentBuilds()
}
environment {
REGISTRY = 'registry. example. com'
IMAGE = "${env. REGISTRY}/payments:${env. GIT_COMMIT}"
}
stages {
stage('Checkout') {
steps { checkout(scm) }
}
stage('Lint & Unit') {
parallel {
stage('Lint') { steps { sh 'make lint' } }
stage('Unit') { steps { sh 'make test' } }
}
}
stage('SCA/SAST') {
steps {
sh'make deps_audit'//SCA (dependencies)
sh'make sast '//static analysis
}
}
stage('Build Image') {
steps { sh 'docker build -t $IMAGE. && docker push $IMAGE' }
}
stage('SBOM & Sign') {
steps {
sh 'syft $IMAGE -o spdx-json > sbom. json'
sh 'cosign sign --key $COSIGN_KEY $IMAGE'
archiveArtifacts artifacts: 'sbom. json', fingerprint: true
}
}
}
post {
success { echo '+ Build OK' }
failure { echo '- Build failed'; sh 'printenv sort sed -n "1,50p"' }
always { cleanWs() }
}
}3) Kubernetes-агенти і контейнерні оточення
Приклад podTemplate (Declarative)
groovy pipeline {
agent {
kubernetes {
yaml """apiVersion: v1 kind: Pod spec:
serviceAccountName: jenkins containers:
- name: build image: docker:27-dind securityContext: { privileged: true }
- name: tools image: alpine:3. 20 command: ['cat']
tty: true
"""
defaultContainer 'tools'
}
}
stages {
stage('Build in DinD') {
steps {
container('build') {
sh '''
dockerd-entrypoint. sh & sleep 5 docker build -t $IMAGE.
docker push $IMAGE
'''
}
}
}
}
}Практика: кеш шарів через загальний'emptyDir '/remote cache; ліміти CPU/RAM;'nodeSelector/taints'для відділення важких збірок.
4) Shared Libraries: DRY і єдині стандарти
Виносьте загальні кроки (лінтери, SAST, збірка, публікація) в Shared Library.
groovy
// vars/withQuality. groovy def call(Closure body) {
stage('Quality Gate') {
parallel(
"Lint": { sh 'make lint' },
"Unit": { sh 'make test' },
"SCA": { sh 'make deps_audit' }
)
}
body()
}groovy
@Library('ci-lib@v3') _
pipeline {
agent any stages {
stage('Pipeline') {
steps {
withQuality {
sh 'make build'
}
}
}
}
}Поради: версіонуйте бібліотеку ('tags'), покривайте unit-тестами кроків, ведіть CHANGELOG.
5) Секрети та облікові дані
Credentials Binding: `usernamePassword`, `string`, `file`, `sshUserPrivateKey`.
Secret scopes: мінімум прав; використання тільки на потрібних стадіях.
Менеджери секретів: провайдери для зовнішніх сховищ (KMS/Secrets Manager/HashiCorp Vault).
groovy withCredentials([string(credentialsId: 'cosign-key', variable: 'COSIGN_KEY')]) {
sh 'cosign sign --key $COSIGN_KEY $IMAGE'
}6) Паралелізм, матриці, кеш
Matrix-збірки
groovy stage('Test Matrix') {
matrix {
axes {
axis { name 'PY'; values '3. 10', '3. 12' }
axis { name 'DB'; values 'mysql', 'postgres' }
}
stages {
stage('Run') { steps { sh 'pytest -q' } }
}
post { always { junit 'reports/.xml' } }
}
}Кешування: Docker layer cache, кеш залежностей ('~/.m2','~/.cache/pip') на volume; артефакти між стадіями - через'stash/unstash'або артефакт-сховище.
7) Перевірки безпеки та відповідність
SCA/SAST/Secret-scan в CI, DAST в окремому оточенні.
SBOM (Syft/CycloneDX), підпис артефактів (cosign), політика «без підпису - ні деплоя».
Policy-гейти: зупинка пайплайну при критичних CVE; звіти в PR.
Контури PII: не логувати секрети, маскувати змінні, окремі агенти для чутливих збірок.
8) Публікація артефактів та інтеграція з CD
Registry: Docker/OCI з ретеншн-політикою, immutability тегів.
Package Repos: Maven/NPM/PyPI proxy+cache.
CD-тригери: відправка подій в Argo CD/Flagger, або створення PR в GitOps-репозиторій маніфестів.
9) Jenkins Configuration as Code (JCasC) и GitOps
Тримайте конфіг контролера як код: джоби-шаблони, креденшли (посилання), RBAC, агенти.
yaml jenkins:
systemMessage: "Jenkins (iGaming CI)"
numExecutors: 0 authorizationStrategy:
roleBased:
roles:
global:
- name: "readers"
pattern: "."
permissions: ["Overall/Read"]
nodes:
- permanent:
name: "edge-builder"
remoteFS: "/home/jenkins"
labels: "docker"
unclassified:
location:
url: "https://ci. example. com/"
credentials:
system:
domainCredentials:
- credentials:
- string:
id: "cosign-key"
description: "Cosign key ref"
secret: "${COSIGN_KEY_FROM_ENV}"Практика: конфіг - в Git, PR-рев'ю, промоушен dev→stage→prod; секрети - через змінні/зовнішні менеджери.
10) Спостережуваність, надійність і вартість
Метрики: черга, тривалість стадій, відсоток перезапусків, пропускна здатність агентів.
Відмови: 'retry','timeout','stable'-маркування flaky-тестів, повідомлення в ChatOps.
FinOps: авто-вимикання простоюючих агентів, ліміти паралельних збірок, квоти за папками/командами.
11) Пайплайни під різні завдання
Backend/Web сервіс
Лінт/юніти → SAST/SCA → Build → SBOM/Sign → Publish → (тригер CD).
Data/ETL
Перевірка схем (dbt test) → генерація артефактів → статичний аналіз SQL → публікація моделей і документації.
ML/LLM
Перевірка даних/ліцензій → тренування в spot-агентах → експорт ONNX/TensorRT → перф-тести (latency/tokens/s) → підпис і публікація моделі.
12) Рунабуки (типові інциденти)
Черга зростає: додати агенти, перевірити «підвислі» пайплайни, ліміти concurrency.
Плавають збірки: пинити версії інструментів в контейнері агента; вимкнути shared workspace.
Секрет «качок» в логи: видалити build-логи, замінити креденшл, провести аудит; додати маскування.
Падіння контролера: відновлення з backup JCasC + сховище джоб/плагінів версіоновано.
13) Чек-лист впровадження
1. Jenkins LTS з мінімальним набором плагінів; все інше - в агенти.
2. Ефемерні K8s-агенти, ліміти ресурсів, layer-кеші.
3. Declarative/Multibranch, PR-валідація,'post {always {cleanWs ()}}'.
4. Shared Libraries з версіонуванням; єдині кроки якості/безпеки.
5. Credentials Binding + зовнішні секрети; Мінімальні скоупи.
6. SCA/SAST/Secret-scan/DAST, SBOM і підпис образів.
7. JCasC і GitOps-управління конфігом; PR-рев'ю змін.
8. Метрики/алерти/ChatOps; ретраї/таймаути; артефакти і журнали.
9. Політики зберігання/ретенції, авто-гігієна робочих просторів.
10. Документовані рунабуки і регулярні game-day.
14) Антипатерни
Контролер «як сервер всього»: важкі збірки і плагіни на ньому ж.
Scripted-джоби без версіонування і код-рев'ю.
Змішування секретів і логів; креденшли з широкими правами.
Агентів мало/вони постійні → дрейф оточень, flaky-тести.
Відсутність SBOM/підпису артефактів і гейтів по CVE.
«Ручне» управління конфігом, немає JCasC/GitOps.
Підсумки
Jenkins залишається потужним і гнучким ядром CI. Перевівши конфігурацію в код (JCasC), стандартизувавши кроки в Shared Libraries, запускаючи збірки на ефемерних K8s-агентах і вбудувавши безпеку/підпис/SBOM прямо в конвеєр, ви отримаєте передбачувані релізи, контрольовану вартість і стійкість до пікових навантажень iGaming.