ჯენკინსი და payplines CI

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Jenkins რჩება CI უნივერსალური „ძრავა“ iGaming ჰიბრიდულ ინფრასტრუქტურაში: ის აერთიანებს პროგრამების შეკრებას, კონტეინერებს, ტესტებს, უსაფრთხოების შემოწმებას და არტეფაქტების გამოქვეყნებას. წარმატება არის კონვეიერი, როგორც კოდი (Declarative/Multibranch), Shared Libraries, Kubernetes ეფემერული აგენტები, მკაცრი უსაფრთხოება და საიდუმლოებები, GitOps კონფისკაცია, ასევე შესრულების და ღირებულების მეტრიკა.

1) Jenkins- ის არქიტექტურა iGaming- ის ქვეშ

კონტროლერი (LTS) + აგენტები: კონტროლერზე მინიმალური დანამატები; მუშაობა გადადის აგენტებად.
ეფემერული აგენტები: გაშვება K8s/დინამიური 'jnlp- ის ქვეშ (სწრაფი დაწყება, სუფთა გარემო).
ნამუშევრების იზოლაცია: საქაღალდეები/უფლებები (Folders + Role-Based Strategy), ყველაზე მცირე უფლებების კრედიტები.
Observability: მეტრიკის ექსპორტი (latency, ჯერი), სტადიების ცენტრალიზებული ლოგოები, ტრეისი-ID რულონები.

2) paypline ნიმუშები: Declarative და Multibranch

როდესაც Declarative: სტანდარტული კონვეიერები ერთგვაროვანი სტადიებით, მკაფიო 'post' -shagi.
როდესაც 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- ის მაგალითი

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 და ერთიანი სტანდარტები

გამოიტანეთ ზოგადი ნაბიჯები (linters, 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 gates: payline შეჩერება კრიტიკულ CVE- ში; მოხსენებები PR- ში.
PII კონტურები: არ მოაწყოთ საიდუმლოებები, შენიღბეთ ცვლადები, ინდივიდუალური აგენტები მგრძნობიარე შეკრებისთვის.

8) არტეფაქტების გამოქვეყნება და ინტეგრაცია CD- სთან

Registry: Docker/OCI ჭარბი პოლიტიკით, immutability tegs.
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 და black; საიდუმლოებები - ცვლადი/გარე მენეჯერების მეშვეობით.

10) დაკვირვება, საიმედოობა და ღირებულება

მეტრიკა: ხაზი, სტადიების ხანგრძლივობა, გადატვირთვის პროცენტი, აგენტების გამტარუნარიანობა.
უარი: 'retry', 'timeout', 'stable' - flaky ტესტების მარკირება, შეტყობინებები ChatOps- ში.
FinOps: უსაქმური აგენტების გამორთვა, პარალელური შეკრების ლიმიტები, მამების/გუნდების კვოტები.

11) Piplines სხვადასხვა დავალებისთვის

Backend/Web სერვისი

Lint/ერთეული - SAST/SCA - Build - SBOM/Sign - Publish (CD ტრიგერი).

Data/ETL

სქემების (dbt test) შემოწმება - არტეფაქტების წარმოება - SQL სტატიკური ანალიზი და მოდელების და დოკუმენტაციის გამოქვეყნება.

ML/LLM

მონაცემთა/ლიცენზიების შემოწმება - ტრენინგი spot აგენტებში - ONX/TensorRT ექსპორტი - პერფექტები (latency/tokens/s) - მოდელის ხელმოწერა და გამოქვეყნება.

12) რუნაბუკი (ტიპიური ინციდენტები)

რიგები იზრდება: დაამატეთ აგენტები, შეამოწმეთ „ჩამოკიდებული“ შეღებვები, შეზღუდვები.
შეკრებები ბანაობენ: აგენტის კონტეინერში ინსტრუმენტების ვერსიების დალევა; გამორთეთ shared workspace.
„იხვის“ საიდუმლო ლოგიკაში: ამოიღეთ build-logs, შეცვალეთ კრედიტი, ჩაატარეთ აუდიტი; დაამატეთ ნიღაბი.
კონტროლერის დაცემა: JCasC + backup საცავის აღდგენა ვერსირებულია.

13) განხორციელების შემოწმების სია

1. Jenkins LTS მინიმალური კომპლექტით; ყველაფერი დანარჩენი აგენტებშია.
2. Effemer 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; retrai/taimauty; ნივთები და ჟურნალები.
9. შენახვის/რეტენციების პოლიტიკა, სამუშაო სივრცეების ავტო-ჰიგიენა.
10. დოკუმენტირებული რუნები და რეგულარული თამაშის დღე.

14) ანტიპატერები

მაკონტროლებელი „როგორც ყველაფრის სერვერი“: მასზე მძიმე შეკრებები და მოდულები.
Scripted Jobe ვერსიის და კოდირების გარეშე.
საიდუმლოებებისა და ლოგოების შერევა; credenschles ფართო უფლებებით.
რამდენიმე აგენტი/ისინი მუდმივი არიან გარემოცვის დრიფტი, ფრენის ტესტები.
SBOM- ის არარსებობა/CVE- ს არტეფაქტებისა და კარიბჭეების ხელმოწერები.
„სახელმძღვანელო“ კონფისკაციის კონტროლი, არა JCasC/GitOps.

შედეგები

ჯენკინსი რჩება ძლიერი და მოქნილი CI ბირთვი. კონფიგურაციის კოდზე (JCasC) თარგმნით, ნაბიჯების სტანდარტიზაციით Shared Libraries- ში, ეფემერული K8s აგენტებზე შეკრების დაწყებით და უსაფრთხოების/ხელმოწერის/SBOM პირდაპირ კონვეიერში ჩასატარებლად, თქვენ მიიღებთ პროგნოზირებულ გამოშვებებს, რომლებიც აკონტროლებენ iGaming- ის პიკის დატვირთვას.