Conteneurs, Kubernetes et cloud native

1. Pourquoi les conteneurs #

« Ça marche sur ma machine » ne suffit plus.

Les apports #

• Un artefact unique et reproductible qui contient l'application et ses dépendances.
• La parité entre développement, test et production (12 facteurs, facteur X).
• Un démarrage en secondes, adapté à la mise à l'échelle et aux déploiements progressifs.
• Une interface commune pour tous les langages : le pipeline et la plateforme traitent toutes les applications de la même façon.

Une bonne image #

# Dockerfile multi-stage : image finale minimale, sans outils de build
FROM python:3.12-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip wheel --no-cache-dir -r requirements.txt -w /wheels

FROM python:3.12-slim
RUN useradd -r -u 10001 app
WORKDIR /app
COPY --from=build /wheels /wheels
RUN pip install --no-cache-dir /wheels/* && rm -rf /wheels
COPY src/ .
USER app
EXPOSE 8080
HEALTHCHECK CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8080/health')"
CMD ["gunicorn", "-b", "0.0.0.0:8080", "main:app"]

Bonne Pratique : Image de base minimale et épinglée, utilisateur non root, une seule application par conteneur, logs sur la sortie standard, configuration par variables d'environnement.

2. Kubernetes #

La plateforme d'exécution standard.

Ce qu'il apporte au DevOps #

Helm et Kustomize #

# Kustomize : une base et des surcouches par environnement
overlays/production/kustomization.yaml
resources: [../../base]
images:
  - name: shop-api
    newName: ghcr.io/mon-org/shop-api
    newTag: 3f9c2e1
replicas:
  - name: shop-api
    count: 6

kustomize build overlays/production | kubectl apply -f -
helm upgrade --install shop ./chart -f values-production.yaml --set image.tag=3f9c2e1 --atomic

3. Choisir son modèle d'exécution #

Pas de Kubernetes par défaut.

Comparaison #

À savoir : Les formations Docker et Kubernetes de RousselTM Learning détaillent la construction d'images, Compose, Swarm, l'orchestration et la sécurité des clusters.