Jenkins et les pipelines CI
(Section : Technologie et infrastructure)
Résumé succinct
Jenkins reste le « moteur » universel de CI dans les infrastructures hybrides iGaming : il intègre l'assemblage d'applications, la conteneurisation, les tests, le contrôle de sécurité et la publication d'artefacts. Le succès est un pipeline en tant que code (Declarative/Multibranch), des Libraries partagées, des agents éphémères chez Kubernetes, une sécurité et des secrets rigides, une gestion GitOps du config, ainsi que des métriques de performance et de coût.
1) Jenkins Architecture sous iGaming
Contrôleurs (LTS) + agents : minimum de plugins sur le contrôleur ; le travail est transféré aux agents.
Agents éphémères : lancement en K8s/sous dynamique 'jnlp' (démarrage rapide, environnement propre).
Isolation des œuvres : dossiers/droits (Folders + Role-Based Strategy), credenshles sur les droits les plus faibles.
Observability : exportation de métriques (latitude, file d'attente), logs d'étapes centralisés, trace-ID en piplines.
2) Modèles de pipelines : Declarative et Multibranch
Quand Declarative : convoyeurs standard avec des étapes homogènes, des « post » clairs.
Quand Scripted : branches « non standard » rares.
Multibranch : auto-pipline pour chaque branche/PR ; les politiques « seulement les branches actives ».
Base Declarative-Pipline
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) Agents Kubernetes et environnements de conteneurs
Exemple 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
'''
}
}
}
}
}Pratique : cache de couches via un cache commun 'emptyDir '/remote cache ; limites CPU/RAM ; 'nodeSelector/taints' pour la séparation des assemblages lourds.
4) Bibliothèques partagées : DRY et normes uniformes
Proposez des étapes générales (linters, SAST, assemblage, publication) dans la bibliothèque partagée.
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'
}
}
}
}
}Conseils : Versionnez la bibliothèque ('tags'), couvrez les étapes avec des tests unitaires, conduisez CHANGELOG.
5) Secrets et informations d'identification
Credentials Binding: `usernamePassword`, `string`, `file`, `sshUserPrivateKey`.
Scopes secrets : un minimum de droits ; utilisation uniquement au bon stade.
Gestionnaires de secrets : fournisseurs de stockage externe (KMS/Secret Manager/HashiCorp Vault).
groovy withCredentials([string(credentialsId: 'cosign-key', variable: 'COSIGN_KEY')]) {
sh 'cosign sign --key $COSIGN_KEY $IMAGE'
}6) Parallélisme, matrices, cache
Assemblages matriciels
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' } }
}
}Cache : Docker layer cache, cache de dépendance ('~/.m2', '~/.cache/pip') sur volume ; artefacts entre les étapes - via 'stash/unstash' ou artefact-storage.
7) Contrôles de sécurité et conformité
SCA/SAST/Secret-scan en CI, DAST dans un environnement séparé.
SBOM (Syft/CycloneDX), signature d'artefacts (cosign), stratégie « pas de signature - pas de déchet ».
Policy-gates : stop pipline aux CVE critiques ; rapports au PR.
Contours PII : ne pas logier les secrets, masquer les variables, agents individuels pour les assemblages sensibles.
8) Publication d'artefacts et intégration avec CD
Registry : Docker/OCI avec politique de rétention, étiquettes d'immutabilité.
Package Repos: Maven/NPM/PyPI proxy+cache.
Déclencheurs de CD : envoyez des événements à Argo CD/Flagger ou créez des PR dans le référentiel de manifeste GitOps.
9) Jenkins Configuration as Code (JCasC) и GitOps
Gardez le flig du contrôleur comme code : jobs modèles, credenshls (liens), RBAC, agents.
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}"Pratique : config - à Git, PR-revue, promotion dev→stage→prod ; secrets - via des gestionnaires variables/externes.
10) Observabilité, fiabilité et coût
Métriques : file d'attente, durée des étapes, pourcentage de redémarrages, bande passante des agents.
Échecs : 'retry', 'timeout', 'stable' -- marquage des tests flaky, notifications dans ChatOps.
FinOps : Désactivation automatique des agents inactifs, limites des assemblages parallèles, quotas par dossier/commande.
11) Piplines pour différentes tâches
Backend/Service Web
Lint/units → SAST/SCA → Build → SBOM/Signe → Publish → (déclencheur CD).
Data/ETL
Validation des schémas (dbt test) → génération d'artefacts → analyse statique SQL → publication de modèles et de documentation.
ML/LLM
Validation des données/licences → formation dans les agents spot → exportation ONNX/TensorRT → tests de perf (latency/tokens/s) → signature et publication du modèle.
12) Runabooks (incidents types)
La file d'attente grandit : ajoutez des agents, vérifiez les piplines « suspendues », les limites de concurrence.
Les assemblages flottent : frapper les versions des outils dans le conteneur de l'agent ; désactiver shared workspace.
Le secret des « canards » dans les logs : supprimer les build-logs, remplacer le credenshl, effectuer un audit ; ajouter le masquage.
Chute du contrôleur : Restauration à partir de backup JCasC + stockage gob/plugins versioné.
13) Chèque de mise en œuvre
1. Jenkins LTS avec un ensemble minimal de plugins ; tout le reste est dans les agents.
2. Agents K8s éphémères, limites de ressources, caches layer.
3. Declarative/Multibranch, validation PR, 'post {always {cleanWs ()}}'.
4. Bibliothèques partagées avec versioning ; une seule étape qualité/sécurité.
5. Credentials Binding + secrets externes ; des écorces minimales.
6. SCA/SAST/Secret-scan/DAST, SBOM et signature d'image.
7. JCasC et GitOps-contrôle de configh ; Je récuse les changements.
8. Métriques/alertes/ChatOps ; Retrai/Timaouta ; artefacts et revues.
9. Politiques de stockage/retraite, auto-hygiène des espaces de travail.
10. Runabooks documentés et jour de jeu régulier.
14) Anti-modèles
Le contrôleur « comme le serveur de tout » : assemblages lourds et plugins sur lui.
Jobs scriptés sans versioning et code-revu.
Mélange de secrets et de loges ; Credenshles avec de larges droits.
Il y a peu d'agents/ils sont permanents → dérive des environnements, des tests flaky.
Pas de SBOM/signature d'artefacts et de gates par CVE.
Contrôle « manuel » du config, pas de JCasC/GitOps.
Résultats
Jenkins reste le noyau puissant et flexible de CI. En traduisant la configuration en code (JCasC), en normalisant les étapes dans les bibliothèques partagées, en lançant les assemblages sur des agents K8s éphémères et en intégrant la sécurité/signature/SBOM directement dans la chaîne de montage, vous obtiendrez des versions prévisibles, un coût contrôlé et une résistance aux pics de charge iGaming.