Formation CI/CD DevOps

FAQ - Questions fréquentes

Questions générales sur la formation

Quel est le niveau requis pour suivre cette formation ?

Niveau recommandé :

  • Connaissances de base en développement logiciel
  • Familiarité avec Git et les concepts de versioning
  • Notions de base sur les systèmes Linux/Unix
  • Expérience avec les lignes de commande

Prérequis techniques :

  • Docker installé et fonctionnel
  • Git configuré
  • Éditeur de code (VS Code recommandé)
  • 16GB RAM et 50GB d'espace disque libre

Puis-je suivre la formation sur Windows/macOS ?

Oui, absolument ! Cette formation a été conçue pour être cross-platform.

Windows :

  • Utiliser WSL2 (Windows Subsystem for Linux) recommandé
  • Docker Desktop for Windows
  • Git Bash ou PowerShell

macOS :

  • Homebrew pour l'installation des outils
  • Docker Desktop for Mac
  • Terminal natif

Linux :

  • Environnement natif idéal
  • Package managers (apt, yum, pacman)
  • Docker Engine

Combien de temps faut-il prévoir pour maîtriser ces concepts ?

Formation initiale : 3 jours intensifs

Maîtrise pratique :

  • Niveau opérationnel : 2-3 mois de pratique
  • Niveau expert : 6-12 mois d'expérience continue
  • Expertise avancée : 1-2 ans selon le domaine de spécialisation

Conseil : La pratique régulière est plus importante que la durée. 2h par semaine pendant 3 mois valent mieux que 20h d'affilée.

Questions techniques - Jour 1

Pourquoi utiliser Gitea plutôt que GitHub/GitLab ?

Avantages de Gitea :

  • Self-hosted : Contrôle total de vos données
  • Léger : Faible consommation de ressources
  • Simple : Interface épurée et intuitive
  • Open source : Code libre et transparence
  • Économique : Pas de coûts de licence pour les équipes privées

Cas d'usage idéaux :

  • Équipes qui veulent maîtriser leur infrastructure
  • Environnements avec contraintes de sécurité/compliance
  • Projets nécessitant des customisations spécifiques
  • Budget limité pour les outils DevOps

Les actions Gitea sont-elles aussi puissantes que GitHub Actions ?

Fonctionnalités similaires :

  • Syntaxe YAML compatible
  • Déclencheurs sur événements Git
  • Matrice de builds
  • Secrets et variables d'environnement
  • Actions marketplace (limitée)

Différences principales :

  • Écosystème d'actions plus restreint
  • Runners self-hosted uniquement
  • Moins de templates prêts à l'emploi
  • Performance dépendante de votre infrastructure

Verdict : Suffisant pour la plupart des besoins CI/CD, surtout en environnement contrôlé.

Comment gérer les secrets sensibles en sécurité ?

Niveaux de sécurité :

  1. Repository secrets (Gitea/GitHub)

    • Chiffrés au repos
    • Accessibles aux workflows du repo
    • Ne pas logger ou exposer

  2. External secret managers

    • HashiCorp Vault
    • AWS Secrets Manager
    • Azure Key Vault
    • Google Secret Manager

  3. Kubernetes secrets

    • Base64 encodés (pas chiffrés !)
    • Utiliser des operators comme External Secrets

Bonnes pratiques :

YAMLCode
 
# ✅ Bon usage
env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}

# ❌ À éviter
env:
  DATABASE_URL: "postgresql://user:password@localhost/db"

Questions techniques - Jour 2

Kubernetes est-il vraiment nécessaire pour toutes les applications ?

Kubernetes est justifié quand :

  • Applications multi-services (microservices)
  • Besoins de haute disponibilité
  • Scaling automatique requis
  • Équipes multiples travaillant sur des services différents
  • Environnements multi-cloud ou hybrid

Alternatives plus simples :

  • Docker Compose : Parfait pour le développement et petites applications
  • Docker Swarm : Orchestration simple
  • Serverless : AWS Lambda, Google Functions
  • Platform as a Service : Heroku, Railway, Fly.io

Coût vs bénéfice : Kubernetes apporte de la complexité. Ne l'utilisez que si vous avez vraiment besoin de ses capacités.

Comment choisir entre différentes stratégies de déploiement ?

Rolling Update (défaut)

YAMLCode
 
Cas d'usage: Applications stateless, mises à jour fréquentes
Avantages: Simple, pas de downtime
Inconvénients: Période avec 2 versions simultanées

Blue/Green

YAMLCode
 
Cas d'usage: Applications critiques, rollback rapide nécessaire
Avantages: Switch instantané, rollback simple
Inconvénients: Double infrastructure nécessaire

Canary

YAMLCode
 
Cas d'usage: Applications avec trafic important, réduction des risques
Avantages: Test progressif, impact limité si problème
Inconvénients: Plus complexe, monitoring avancé requis

Recreate

YAMLCode
 
Cas d'usage: Applications stateful, base de données
Avantages: Simple, pas de problème de version
Inconvénients: Downtime pendant le déploiement

Faut-il vraiment un Docker Registry privé ?

Registry privé recommandé si :

  • Contraintes de sécurité/compliance
  • Code propriétaire sensible
  • Contrôle des coûts de bande passante
  • Performance critique (latence)
  • Personnalisations nécessaires

Registry public suffisant si :

  • Projets open source
  • Applications simples
  • Budget limité
  • Équipe réduite

Hybrid approach :

  • Registry public pour les images de base
  • Registry privé pour vos applications métier

Questions techniques - Jour 3

GitOps vs CI/CD traditionnel : quelle différence ?

CI/CD traditionnel (Push-based) :

Code
 
graph LR
A[Code] --> B[CI] --> C[Build] --> D[Deploy to K8s]
  • Pipeline pousse les changements vers la production
  • Accès direct aux clusters de production depuis CI/CD
  • État désiré défini dans les outils CI/CD

GitOps (Pull-based) :

Code
 
graph LR
A[Code] --> B[CI] --> C[Build] --> D[Update Config Repo]
E[Argo CD] --> F[K8s Cluster]
D --> G[Config Repo] --> E
  • Agent dans le cluster tire les changements
  • Aucun accès externe direct au cluster
  • État désiré versionné dans Git

Avantages GitOps :

  • Sécurité renforcée (pas d'accès externe)
  • Auditabilité complète (tout dans Git)
  • Rollback simple (git revert)
  • Réconciliation continue

CDK8s vs Helm vs YAML brut : que choisir ?

YAML brut

YAMLCode
 
Avantages: Simple, explicite, pas de dépendances
Inconvénients: Duplication, pas de logique, maintenance difficile
Cas d'usage: Prototypes, applications très simples

Helm

YAMLCode
 
Avantages: Écosystème riche, templates, versioning
Inconvénients: Syntaxe Go templates, debugging difficile
Cas d'usage: Applications standard, réutilisation d'charts existantes

CDK8s

YAMLCode
 
Avantages: Programmable, testable, IDE support, réutilisabilité
Inconvénients: Courbe d'apprentissage, plus de complexité
Cas d'usage: Infrastructures complexes, logique métier, tests requis

Kustomize

YAMLCode
 
Avantages: Natif K8s, overlays, patching simple
Inconvénients: Logique limitée, pas de templating avancé
Cas d'usage: Customisation simple, multi-environnements

Comment gérer les secrets dans GitOps ?

Problème : Les secrets ne peuvent pas être stockés en clair dans Git.

Solutions :

  1. External Secrets Operator
YAMLCode
 
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: vault-secret
spec:
  refreshInterval: 15s
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: example-secret
  data:
  - secretKey: password
    remoteRef:
      key: secret/data/database
      property: password
  1. Sealed Secrets
TerminalCode
 
# Chiffrer un secret
echo -n mypassword | kubectl create secret generic mysecret --dry-run=client --from-file=password=/dev/stdin -o yaml | kubeseal -o yaml

# Le secret chiffré peut être commité dans Git
  1. SOPS (Secrets OPerationS)
YAMLCode
 
# .sops.yaml
creation_rules:
  - path_regex: .*\.yaml$
    encrypted_regex: ^(data|stringData)$
    age: age1xxxxxx
  1. Argo CD + Vault Plugin
YAMLCode
 
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  password: <path:secret/data/db#password | base64encode>

Questions de mise en production

Comment migrer une application existante vers ce stack ?

Approche progressive recommandée :

Phase 1 : Containerisation

  1. Dockeriser l'application existante
  2. Tester en local avec docker-compose
  3. Mettre en place le CI pour builder l'image

Phase 2 : Orchestration

  1. Déployer sur Kubernetes (1 environnement)
  2. Configurer les health checks
  3. Tester la résilience

Phase 3 : Pipeline

  1. Automatiser le déploiement CI/CD
  2. Ajouter les tests automatisés
  3. Multi-environnements

Phase 4 : GitOps

  1. Séparer code app et configuration
  2. Implémenter Argo CD
  3. Formation des équipes

Durée typique : 3-6 mois selon la complexité

Quels sont les coûts cachés de cette architecture ?

Coûts d'infrastructure :

  • Cluster Kubernetes (maître + workers)
  • Registry privé (stockage + bande passante)
  • Monitoring (Prometheus + Grafana)
  • Backup et disaster recovery

Coûts humains :

  • Formation des équipes (2-3 mois)
  • Maintenance quotidienne (0.5-1 FTE)
  • Support et troubleshooting
  • Veille technologique

Estimation typique :

  • Petite équipe (5-10 devs) : 20-30k€/an
  • Équipe moyenne (20-50 devs) : 50-80k€/an
  • Grande équipe (100+ devs) : ROI positif après 6-12 mois

Comment assurer la sécurité en production ?

Sécurité de l'infrastructure :

YAMLCode
 
Réseau:
  - Network Policies Kubernetes
  - Private clusters (pas d'IP publiques)
  - VPN ou bastion hosts
  - Chiffrement TLS everywhere

Images:
  - Scanner toutes les images (Trivy, Clair)
  - Signatures d'images (Cosign)
  - Images distroless ou minimal
  - Registry privé avec authentification

Runtime:
  - Pod Security Standards
  - RBAC granulaire
  - Service Accounts dédiés
  - Pas de pods privilégiés

Sécurité des pipelines :

YAMLCode
 
CI/CD:
  - Secrets externes (Vault, etc.)
  - Scan SAST/DAST automatique
  - Review obligatoire pour la prod
  - Isolation des runners

GitOps:
  - Signature des commits (GPG)
  - Branch protection rules
  - Audit trail complet
  - Rollback automatique

Monitoring sécurité :

YAMLCode
 
Runtime Security:
  - Falco pour la détection d'anomalies
  - Admission controllers (OPA/Gatekeeper)
  - Audit logs Kubernetes
  - SIEM integration

Compliance:
  - CIS benchmarks
  - SOC2/ISO27001 controls
  - Vulnerability management
  - Incident response

Questions de performance

Comment optimiser les performances des pipelines ?

Build optimization :

Code
 
# Multi-stage builds
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:18-alpine AS runtime
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
CMD ["npm", "start"]

Cache strategies :

YAMLCode
 
# GitHub Actions cache
- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

# Docker layer caching
- uses: docker/build-push-action@v4
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Parallel execution :

YAMLCode
 
jobs:
  test:
    strategy:
      matrix:
        node-version: [16, 18, 20]
    steps:
      - name: Test with Node ${{ matrix.node-version }}
        run: npm test

Comment scaler horizontalement cette architecture ?

Kubernetes scaling :

YAMLCode
 
# HorizontalPodAutoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Multi-cluster :

  • Argo CD Application Sets
  • Cluster API pour l'auto-provisioning
  • Service mesh multi-cluster (Istio)
  • GitOps avec cluster-specific configurations

Registry scaling :

  • Registry cluster avec load balancer
  • CDN pour la distribution d'images
  • Registry par région géographique
  • Garbage collection automatique

Questions sur l'équipe et l'organisation

Comment convaincre mon management d'adopter ces pratiques ?

Arguments business :

  • Time to market : Déploiements plus rapides et fréquents
  • Qualité : Réduction des bugs en production (-50%)
  • Coûts : Réduction des incidents et du support
  • Sécurité : Traçabilité et audit complets
  • Talent : Attraction et rétention des développeurs

Approche progressive :

  1. Proof of Concept : Petit projet pilote
  2. Métriques : Mesurer les gains (lead time, MTTR)
  3. Formation : Équipe technique d'abord
  4. Scale : Expansion progressive

ROI typique :

  • Investissement initial : 3-6 mois
  • Break-even : 6-12 mois
  • Gains long terme : 20-40% de productivité

Comment former une équipe à ces technologies ?

Plan de formation type :

Semaine 1-2 : Fondamentaux

  • Docker et containerisation
  • Git et workflows
  • Concepts CI/CD

Semaine 3-4 : Orchestration

  • Kubernetes basics
  • kubectl et premiers déploiements
  • Services et networking

Semaine 5-6 : Automation

  • CI/CD pipelines
  • GitOps concepts
  • Infrastructure as Code

Semaine 7-8 : Production

  • Monitoring et logging
  • Sécurité
  • Troubleshooting

Méthodes pédagogiques :

  • Hands-on labs (70% du temps)
  • Pair programming
  • Brown bag sessions
  • Mentoring senior/junior

Quels sont les rôles et responsabilités dans une équipe DevOps ?

DevOps Engineer

  • Pipelines CI/CD
  • Infrastructure automation
  • Monitoring et alerting
  • Support niveau 2

Platform Engineer

  • Outils et plateformes internes
  • Self-service pour les développeurs
  • Standards et bonnes pratiques
  • Architecture technique

SRE (Site Reliability Engineer)

  • Reliability et performance
  • SLI/SLO/Error budgets
  • Incident response
  • Capacity planning

Security Engineer

  • DevSecOps integration
  • Vulnerability management
  • Compliance et audit
  • Security policies

Évolution typique : Junior DevOps → DevOps → Senior DevOps → Staff Engineer / Manager

Troubleshooting et support

Où trouver de l'aide quand je suis bloqué ?

Documentation officielle :

  • Kubernetes docs (excellente)
  • Docker docs (complète)
  • Argo CD docs (claire)
  • CDK8s docs (exemples pratiques)

Communautés actives :

Support commercial :

  • Red Hat OpenShift
  • VMware Tanzu
  • SUSE Rancher
  • Google Cloud Run

Formation continue :

Comment rester à jour avec l'écosystème en évolution rapide ?

Veille technologique :

  • Newsletters : DevOps Weekly, KubeWeekly, CNCF Newsletter
  • Podcasts : Kubernetes Podcast, DevOps Chat, The New Stack
  • Blogs : CNCF Blog, Kubernetes Blog, Docker Blog
  • YouTube : CNCF, Docker, Google Cloud, AWS

Événements :

  • KubeCon (2x/an) - Must attend
  • DevOpsDays - Événements locaux
  • Meetups - Networking et apprentissage
  • Webinaires - Vendors et OSS projects

Expérimentation :

  • Labs mensuels : Tester 1 nouveau tool/mois
  • Side projects : Applications perso avec nouvelles techs
  • Contribute OSS : Bug reports, documentation
  • Blog/Share : Écrire consolide l'apprentissage

Cette FAQ sera mise à jour régulièrement avec de nouvelles questions. N'hésitez pas à poser vos questions spécifiques !

Last modified on
Prochaines étapes