Automatisation CI/CD Linux avec exemples pratiques : guide pas à pas

Introduction

L'automatisation CI/CD Linux avec exemples pratiques doit aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui travaillent avec Linux CI/CD. Il relie l'automatisation Linux, le déploiement Linux, le pipeline Linux et la restauration Linux à des commandes, des sorties attendues, des signaux d'échec et des décisions de récupération adaptés à la technologie choisie.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables à la place des secrets, vérifier le résultat et documenter la procédure de récupération si l'état attendu n'est pas atteint.

Inventaire de la version et de l'environnement

Avant de modifier un pipeline CI/CD, établissez l'état actuel de l'environnement Linux et des outils utilisés. Inventoriez le système d'exploitation, le shell, la plateforme CI/CD et les cibles de déploiement. Cette section couvre les commandes d'observation en lecture seule, les vérifications de version et ce qu'il faut capturer avant d'apporter des modifications.

Observer le système d'abord

Exécutez ces commandes sur l'hôte Linux cible pour enregistrer l'environnement actuel. Utilisez des commandes en lecture seule pour ne pas altérer l'état du système :

uname -a
cat /etc/os-release
bash --version | head -n 1
git --version

La sortie attendue ressemble à ceci :

Linux build-agent-01 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 22.04.3 LTS"
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
git version 2.34.1

Enregistrez la sortie dans un fichier journal ou une page wiki avec un horodatage. Par exemple :

date -u +"%Y-%m-%dT%H:%M:%SZ" > /tmp/env-inventory-timestamp.txt
uname -a >> /tmp/env-inventory.txt
cat /etc/os-release >> /tmp/env-inventory.txt

Identifier la plateforme CI/CD et sa version

Vérifiez quels outils CI/CD sont installés et leurs versions. Les plateformes courantes incluent Jenkins, GitLab CI, les runners auto-hébergés de GitHub Actions et Drone. Voici un exemple pour un runner auto-hébergé GitHub Actions :

./run.sh --version

Exemple de sortie attendue :

runner version 2.311.0

Pour Jenkins, vérifiez la version via la CLI ou l'interface utilisateur. Si Jenkins s'exécute sur le même hôte, vous pouvez lire le fichier de version :

cat /var/lib/jenkins/config.xml | grep -oP '(?<=<version>).*?(?=</version>)'

Cette commande retourne la version de Jenkins, par exemple 2.426.2. Si Jenkins s'exécute dans un conteneur, utilisez docker exec ou podman exec :

docker exec jenkins cat /var/lib/jenkins/config.xml | grep -oP '(?<=<version>).*?(?=</version>)'

Vérifier les cibles de déploiement

Si le pipeline déploie via SSH, vérifiez la connectivité SSH et la version du système d'exploitation de l'hôte distant sans apporter de modifications :

ssh [email protected] 'uname -a; cat /etc/os-release'

Si le pipeline déploie vers un orchestrateur de conteneurs, vérifiez la version du cluster. Pour Kubernetes :

kubectl version --short

Pour Docker :

docker version --format '{{.Server.Version}}'

Capturez la sortie pour une comparaison ultérieure. Cet inventaire garantit que vous appliquez des commandes adaptées à la version et comprenez le rayon d'impact de tout changement.

Chemin de configuration sûr

Une fois l'environnement inventorié, l'étape suivante consiste à configurer le pipeline CI/CD en toute sécurité. Cela signifie apporter des modifications petites et réversibles avec des variables explicites pour les secrets. Ne committez jamais de véritables identifiants, jetons ou clés privées. Utilisez des variables d'environnement ou des outils de gestion des secrets.

Exemple : Configurer un pipeline GitLab CI pour une application Python

Supposons que vous ayez une application Flask en Python et que vous souhaitiez ajouter un job CI qui exécute les tests et déploie vers un serveur de staging. Commencez par un fichier .gitlab-ci.yml minimal :

stages:
  - test
  - deploy

variables:
  APP_NAME: "flask-app"

test_job:
  stage: test
  image: python:3.11-slim
  script:
    - pip install -r requirements.txt
    - pytest tests/

deploy_staging:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
  script:
    - scp -o StrictHostKeyChecking=no app.tar.gz [email protected]:/tmp/
    - ssh -o StrictHostKeyChecking=no [email protected] 'tar -xzf /tmp/app.tar.gz -C /var/www/flask-app && systemctl restart flask-app'
  only:
    - main

Cette configuration utilise des variables pour le nom de l'application et l'adresse du serveur. Modifiez selon votre environnement.

Utiliser les secrets en toute sécurité

Ne placez pas la clé privée SSH dans le fichier YAML. Stockez-la plutôt comme variable CI/CD avec protection. Dans GitLab, allez dans Paramètres > CI/CD > Variables, ajoutez SSH_PRIVATE_KEY comme variable protégée et masquée. Référencez-la ensuite dans le job :

deploy_staging:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
  script:
    - scp -o StrictHostKeyChecking=no app.tar.gz [email protected]:/tmp/
    - ssh -o StrictHostKeyChecking=no [email protected] 'tar -xzf /tmp/app.tar.gz -C /var/www/flask-app && systemctl restart flask-app'
  only:
    - main

De même, pour Jenkins, utilisez le plugin Credentials ou des variables d'environnement. Pour GitHub Actions, utilisez des secrets chiffrés dans les paramètres du dépôt.

Limiter le rayon d'impact

Apportez des modifications dans une branche de fonctionnalité et testez le pipeline sur un environnement de staging avant de fusionner vers main. Par exemple, dans GitLab, utilisez des branches ou variables spécifiques à l'environnement :

deploy_staging:
  stage: deploy
  script:
    - echo "Déploiement vers staging"
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main

Pour déployer en production uniquement avec un déclencheur manuel, ajoutez when: manual :

deploy_production:
  stage: deploy
  script:
    - echo "Déploiement vers production"
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - main

Cela nécessite qu'un humain clique sur le bouton de déploiement, réduisant les mises en production accidentelles.

Gestion de version et restauration

La configuration elle-même doit être versionnée. Stockez le fichier .gitlab-ci.yml dans le dépôt et taguez les versions avec des tags Git. Pour la restauration, vous pouvez revenir à un tag précédent ou utiliser un job de déploiement qui prend en charge la restauration en redéployant un artefact précédent.

Vérification et diagnostics

Après avoir configuré le pipeline, vérifiez que chaque étape fonctionne et diagnostiquez les échecs à l'aide des journaux et des commandes d'état. Cette section fournit des étapes de vérification concrètes pour les tâches CI/CD courantes.

Exécuter un pipeline et vérifier l'état

Pour GitLab CI, poussez un commit et surveillez l'état du pipeline. Vous pouvez utiliser la CLI GitLab ou l'API.

Avec la CLI glab :

glab ci status

Sortie attendue :

Getting pipeline status for branch 'main'
Pipeline #123456: running

Pour afficher les journaux d'un job spécifique :

glab ci trace <job-id>

Pour Jenkins, utilisez la CLI :

java -jar jenkins-cli.jar -s http://jenkins.example.com -auth user:token list-jobs
java -jar jenkins-cli.jar -s http://jenkins.example.com -auth user:token console <job-name>

Vérifier le succès du déploiement

Après le job de déploiement, vérifiez que l'application s'exécute sur le serveur cible. Utilisez SSH ou une requête HTTP.

Pour SSH :

ssh [email protected] 'systemctl status flask-app --no-pager'

La sortie attendue inclut Active: active (running).

Pour HTTP :

curl -I https://staging.example.com

La sortie attendue inclut HTTP/2 200 ou HTTP/1.1 200 OK.

Diagnostiquer les échecs courants

Si le job de test échoue, vérifiez le journal du job. Pour un échec de test Python, cherchez la sortie pytest. Par exemple :

FAILED tests/test_app.py::test_index - assert 404 == 200

Cela indique que le code de statut attendu était 200 mais que vous avez obtenu 404, signalant un problème de routage.

Si le job de déploiement échoue en raison d'une authentification SSH, vérifiez que la variable de clé privée est correctement définie et a les bonnes permissions. Utilisez la journalisation SSH verbeuse pour le débogage :

ssh -vvv [email protected]

Cela montre si la clé est proposée et acceptée.

Utiliser des commandes de diagnostic en lecture seule

Pour les déploiements Kubernetes, utilisez kubectl get et kubectl describe pour vérifier l'état des pods sans rien modifier :

kubectl get pods -n staging
kubectl describe pod <pod-name> -n staging

Pour Docker, inspectez les journaux du conteneur :

docker logs <container-id> --tail 100

Ces commandes en lecture seule aident à diagnostiquer sans affecter le système en cours d'exécution.

Modes d'échec et récupération

Les pipelines CI/CD échouent pour de nombreuses raisons : configuration incorrecte, dépendances manquantes, problèmes réseau et erreur humaine. Cette section couvre les modes d'échec courants et les procédures de récupération étape par étape.

Mode d'échec 1 : Échec du test en raison d'une dépendance manquante

Symptôme : Le job de test échoue avec ModuleNotFoundError ou ImportError.

Diagnostic : Vérifiez le journal du job et assurez-vous que requirements.txt inclut le paquet et la version correcte.

Récupération : Ajoutez le paquet manquant à requirements.txt, épinglez la version et poussez un nouveau commit. Par exemple :

# requirements.txt
flask==2.3.3
pytest==7.4.2

Relancez ensuite le pipeline.

Mode d'échec 2 : Échec du déploiement en raison des permissions de la clé SSH

Symptôme : Le job de déploiement échoue avec Permission denied (publickey).

Diagnostic : Le fichier de clé privée peut avoir des permissions trop larges ou un mauvais propriétaire. Dans l'environnement CI, assurez-vous que la clé est écrite avec chmod 600.

Récupération : Ajoutez chmod 600 dans la section before_script ou script comme indiqué précédemment. Vérifiez également que la clé publique se trouve dans le fichier ~/.ssh/authorized_keys du serveur distant.

Mode d'échec 3 : Pipeline déclenché sur la mauvaise branche

Symptôme : Le pipeline s'exécute sur les branches de fonctionnalité alors qu'il ne devrait s'exécuter que sur main, provoquant des builds inutiles.

Diagnostic : Vérifiez la section only ou rules de la configuration CI. Pour GitLab, utilisez rules avec la protection de branche :

deploy_staging:
  stage: deploy
  script:
    - echo "Déployer vers staging"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Récupération : Mettez à jour la configuration pour limiter la branche, puis poussez et vérifiez que le pipeline ne se déclenche plus sur d'autres branches.

Mode d'échec 4 : Restaurer un mauvais déploiement

Symptôme : Après un déploiement, l'application renvoie des erreurs ou est indisponible.

Diagnostic : Consultez les journaux de l'application et l'historique récent du pipeline pour identifier le commit fautif.

Récupération : Restaurez en redéployant l'artefact précédent connu comme bon ou en annulant le commit. Pour Kubernetes, utilisez kubectl rollout undo :

kubectl rollout undo deployment/flask-app -n staging

Sortie attendue :

deployment.apps/flask-app rolled back

Vérifiez avec :

kubectl rollout status deployment/flask-app -n staging

Si vous utilisez un tag Git pour les versions, redéployez le tag précédent en vérifiant ce tag et en exécutant le job de déploiement manuellement.

Mode d'échec 5 : Variable d'environnement non définie

Symptôme : Le pipeline échoue avec KeyError ou unbound variable.

Diagnostic : La variable peut ne pas être définie dans les paramètres CI/CD ou peut être limitée à un environnement différent.

Récupération : Ajoutez la variable dans les paramètres CI/CD avec la bonne portée et protection. Pour GitLab, assurez-vous que la variable n'est pas protégée si elle doit être disponible dans toutes les branches. Relancez ensuite le pipeline.

Créer un runbook de récupération

Documentez chaque mode d'échec avec les symptômes, les étapes de diagnostic et les commandes de récupération dans un runbook accessible à l'équipe. Gardez-le sous contrôle de version avec la configuration du pipeline. Par exemple, un fichier Markdown recovery.md à la racine du dépôt :

# Runbook de récupération

## Permission SSH refusée
- Vérifiez les permissions de `~/.ssh/id_rsa` dans le job CI
- Assurez-vous que `chmod 600` est défini
- Vérifiez la clé publique dans `~/.ssh/authorized_keys`

## Restauration du déploiement
- `kubectl rollout undo deployment/<name> -n <namespace>`
- Vérifiez avec `kubectl rollout status deployment/<name> -n <namespace>`

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après avoir apporté des modifications à un pipeline CI/CD Linux. Chaque élément inclut le responsable et la fréquence de révision.

Liste de contrôle avant modification

[ ] Inventorier l'environnement : Exécutez uname -a, cat /etc/os-release et vérifiez les versions des outils CI/CD. Enregistrez la sortie dans le journal des modifications.
Responsable : Priya Shah, ingénieure DevOps
Fréquence : À chaque demande de modification, mais au moins une fois par semaine.

[ ] Sauvegarder la configuration actuelle : Copiez les fichiers de pipeline existants et les scripts associés vers un emplacement de sauvegarde (par exemple, cp .gitlab-ci.yml /backup/.gitlab-ci.yml.$(date +%F)).
Responsable : Marcus Lee, gestionnaire Build & Release
Fréquence : Avant chaque modification.

[ ] Identifier le rayon d'impact : Listez les environnements et applications affectés par la modification. Utilisez un tableau comme :

Environnement	Application	Impact
Staging	Flask-app	Job de déploiement
Production	Flask-app	Déploiement manuel uniquement

Responsable : Priya Shah, ingénieure DevOps
Fréquence : Pour chaque modification.

[ ] Confirmer le plan de restauration : Assurez-vous de pouvoir annuler la modification. Pour la configuration du pipeline, c'est un revert Git. Pour le déploiement, assurez-vous d'avoir l'artefact précédent ou un tag Git.
Responsable : Marcus Lee, gestionnaire Build & Release
Fréquence : Pour chaque modification.

Vérification après modification

[ ] Exécuter le pipeline sur une branche de fonctionnalité ou un environnement de staging : Surveillez l'état et les journaux du pipeline.
Responsable : Priya Shah, ingénieure DevOps
Fréquence : Après chaque modification.

[ ] Vérifier le déploiement : Utilisez curl ou systemctl status pour confirmer que l'application s'exécute comme prévu.
Responsable : Priya Shah, ingénieure DevOps
Fréquence : Après chaque déploiement.

[ ] Vérifier les effets secondaires inattendus : Consultez les journaux de l'application et les métriques système pour détecter de nouvelles erreurs ou une dégradation des performances.
Responsable : Marcus Lee, gestionnaire Build & Release
Fréquence : Dans les 24 heures suivant la modification.

[ ] Mettre à jour le runbook : Si la modification introduit un nouveau mode d'échec ou une étape de récupération, mettez à jour recovery.md.
Responsable : Priya Shah, ingénieure DevOps
Fréquence : Au besoin, mais révisé mensuellement.

Liste de contrôle de révision mensuelle

[ ] Réviser l'efficacité du pipeline : Identifiez les étapes lentes et envisagez la mise en cache ou la parallélisation.
Responsable : Marcus Lee, gestionnaire Build & Release
Fréquence : Mensuelle.

[ ] Mettre à jour les versions des outils CI/CD : Vérifiez les correctifs de sécurité et planifiez les mises à niveau dans une fenêtre de maintenance.
Responsable : Priya Shah, ingénieure DevOps
Fréquence : Mensuelle, ou selon les exigences des avis de sécurité.

[ ] Auditer les secrets et les permissions : Faites tourner les identifiants de plus de 90 jours et vérifiez l'accès au moindre privilège.
Responsable : Marcus Lee, gestionnaire Build & Release
Fréquence : Mensuelle.

Pièges courants et comment les éviter

Même les équipes expérimentées tombent dans des pièges avec le CI/CD Linux. Voici les pièges fréquents, pourquoi ils surviennent et comment les prévenir ou s'en remettre.

Piège 1 : Committer des secrets dans Git

Pourquoi cela arrive : Les développeurs codent en dur les identifiants pour plus de commodité ou incluent accidentellement des fichiers .env.

Comment éviter : Utilisez des outils de gestion des secrets (Vault, AWS Secrets Manager, variables CI/CD GitLab). Ajoutez les fichiers .env et de clés privées à .gitignore. Activez l'analyse des secrets dans le dépôt.

Récupération : Si un secret est commité, faites-le tourner immédiatement et purgez-le de l'historique Git en utilisant git filter-repo ou BFG Repo-Cleaner. Mettez ensuite à jour la variable CI/CD.

Piège 2 : Exécuter les étapes du pipeline avec des privilèges excessifs

Pourquoi cela arrive : Les jobs sont exécutés avec root ou des rôles IAM larges parce que c'est plus facile que le moindre privilège.

Comment éviter : Exécutez les jobs avec les permissions minimales requises. Pour Docker, utilisez des utilisateurs non-root. Pour les déploiements cloud, utilisez des rôles limités par environnement.

Récupération : Si une violation se produit en raison de privilèges excessifs, révoquez les permissions larges, auditez les journaux et réappliquez les politiques de moindre privilège.

Piège 3 : Ne pas épingler les versions des dépendances

Pourquoi cela arrive : Utiliser des tags latest ou des requirements non épinglés conduit à des builds imprévisibles.

Comment éviter : Épinglez des versions exactes dans requirements.txt, package.json et les images de base Docker. Utilisez des fichiers de verrouillage.

Récupération : Si un build casse à cause d'une mise à jour de dépendance, épinglez la dernière version connue comme fonctionnelle et enquêtez sur le changement cassant.

Piège 4 : Ignorer le retour du pipeline

Pourquoi cela arrive : Les équipes désactivent les tests instables ou ignorent les pipelines échoués, conduisant à des branches main cassées.

Comment éviter : Traitez les échecs de pipeline comme une priorité élevée. Utilisez des règles de protection de branche pour empêcher la fusion lorsque les pipelines échouent. Réparez les tests instables au lieu de les commenter.

Récupération : Si main est cassée, annulez le commit fautif, relancez le pipeline et analysez la cause racine.

Piège 5 : Absence de plan de restauration

Pourquoi cela arrive : Les équipes se concentrent sur le déploiement en avant et supposent que la restauration est triviale, mais peinent sous pression.

Comment éviter : Documentez et testez régulièrement les procédures de restauration. Utilisez des déploiements blue-green ou des releases canary pour réduire les risques.

Récupération : Si une restauration échoue, utilisez le dernier artefact connu comme bon et redéployez. Conservez les artefacts précédents pendant au moins 30 jours.

Conclusion

L'automatisation CI/CD Linux avec exemples pratiques n'est utile que si chaque recommandation est limitée à la version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque pour le CI/CD Linux, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que systemd, Bash et Docker.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.

Commencez par les commandes d'inventaire de cet article, adoptez une pratique de configuration sûre et construisez progressivement un runbook de récupération. Votre pipeline deviendra plus résilient et votre équipe passera moins de temps à éteindre les incendies.