infra / kubernetes

ConfigMaps

Leçon 61 exercice

Explication

Ce que vous allez apprendre

Expliquer pourquoi séparer configuration et code permet de réutiliser la même image dans plusieurs environnements
Injecter un ConfigMap dans un Pod via des variables d'environnement ou via un fichier monté
Choisir entre les deux méthodes d'injection selon le format de configuration attendu par l'application
Expliquer la différence de comportement lors d'une mise à jour : fichier monté (rafraîchi automatiquement) contre variable d'environnement (figée au démarrage)
Appliquer la technique du hash en annotation pour forcer un redéploiement propre après un changement de ConfigMap

Dans quel contexte ?

Une équipe déploie la même image Docker de son API dans trois environnements (dev, staging, prod), chacun pointant vers une base de données différente. Plutôt que de construire trois images distinctes, elle utilise un ConfigMap différent par environnement pour injecter l'URL de connexion adaptée. Quand quelqu'un modifie un ConfigMap monté en volume, l'équipe découvre que le fichier de configuration se met à jour tout seul dans les Pods déjà en cours d'exécution, avec un léger délai — mais que la même modification appliquée à une variable d'environnement reste totalement invisible tant que les Pods ne sont pas redémarrés.

Le principe à respecter : séparer code et configuration

D'abord, une règle de base : une même image d'application doit pouvoir tourner dans plusieurs environnements (dev, staging, prod) sans être reconstruite à chaque fois.

Ce qui change réellement entre environnements

Ce qui change entre ces environnements, ce n'est pas le code, c'est la configuration : une URL de base de données, un niveau de log, un drapeau de fonctionnalité.

L'objet conçu pour ça

Le ConfigMap est l'objet Kubernetes qui stocke cette configuration en dehors de l'image, pour pouvoir la modifier sans reconstruire ni republier le conteneur.

Première façon de la consommer : en variable

Il existe deux manières principales d'injecter cette configuration dans un Pod. La première l'expose comme des variables d'environnement, ce qui convient bien à des petites valeurs individuelles, comme un niveau de log ou une URL.

Deuxième façon : en fichier monté

La seconde la monte comme un fichier dans le système de fichiers du conteneur, adaptée aux fichiers de configuration complets, comme un .properties ou un .conf. Le choix dépend de la façon dont l'application elle-même lit sa configuration.

Méthode d'injection	Se met à jour après un changement du ConfigMap ?	Cas d'usage typique
Variable d'environnement	Non, jamais sans redémarrage du Pod	Petites valeurs individuelles (niveau de log, URL)
Fichier monté en volume	Oui, automatiquement avec un léger délai	Fichiers de configuration complets (.conf, .properties)

Une différence de comportement à connaître

Une fois le ConfigMap créé, un détail surprend souvent les débutants : quand il change après coup, un fichier monté en volume se met à jour automatiquement, avec un léger délai, alors qu'une variable d'environnement, elle, ne change JAMAIS après le démarrage du conteneur.

Piège fréquent

Modifier un ConfigMap consommé en variable d'environnement ne change RIEN pour les Pods déjà en cours d'exécution : la valeur a été figée au démarrage du conteneur. Il faut redémarrer ou recréer les Pods pour qu'ils voient la nouvelle valeur — une source fréquente de confusion en dépannage ("j'ai changé le ConfigMap mais rien ne se passe").

La conséquence pratique de cette différence

Il faut redémarrer le Pod pour qu'une variable d'environnement reflète la nouvelle valeur. C'est pourquoi une pratique courante consiste à versionner le nom du ConfigMap, ou à ajouter un hash en annotation, pour forcer un redéploiement propre à chaque changement.

Astuce

Ajouter un hash du contenu du ConfigMap en annotation du template de Pod force Kubernetes à considérer le Pod comme "changé" à chaque modification de configuration, déclenchant un rolling update propre — une pratique courante pour ne jamais oublier un redéploiement après un changement de configuration.

Ce que le ConfigMap ne doit jamais contenir

Enfin, un ConfigMap n'est absolument pas fait pour des données sensibles : mots de passe, jetons d'API, clés privées. Ces informations doivent aller dans un Secret, l'objet de la prochaine leçon, quasi identique dans sa syntaxe mais pensé différemment.

Commandes & code

ConfigMaps

Externalise la configuration non sensible hors de l'image (URLs, feature flags, fichiers de config).

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:
  LOG_LEVEL: "info"
  FEATURE_NEW_UI: "true"
  app.properties: |
    server.port=3000
    server.timeout=30s
    cache.enabled=true

# Injection en variables d'environnement individuelles
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myorg/api:1.4.2
          env:
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: api-config
                  key: LOG_LEVEL
          envFrom:
            - configMapRef:
                name: api-config     # injecte TOUTES les clés comme variables d'env
          volumeMounts:
            - name: config-volume
              mountPath: /etc/app
      volumes:
        - name: config-volume
          configMap:
            name: api-config          # monte "app.properties" comme fichier /etc/app/app.properties

kubectl apply -f configmap.yaml
kubectl get configmap api-config -o yaml
kubectl create configmap api-config --from-file=app.properties --from-literal=LOG_LEVEL=debug

# Un changement de ConfigMap monté en volume se propage (avec délai), PAS en env var
kubectl edit configmap api-config

Résumé

data: = clé/valeur ou fichiers texte complets multi-lignes (|).
envFrom.configMapRef injecte toutes les clés d'un coup en variables d'environnement.
Monté en volume, un fichier de config se met à jour à chaud (pas les variables d'env).
Pour forcer un redéploiement sur changement de config : versionner le nom du ConfigMap ou utiliser un hash en annotation.

Exercices pratiques

1 disponible

Mission : le changement de configuration invisible

Objectif : Diagnostiquer pourquoi une mise à jour de ConfigMap ne se reflète pas dans les Pods en cours d'exécution, selon la méthode d'injection utilisée.

Contexte

Un développeur modifie le ConfigMap api-config pour passer LOG_LEVEL de info à debug, dans l'espoir de déboguer un bug intermittent en production. Il attend cinq minutes, relance ses tests, et les logs restent désespérément au niveau info. Pendant ce temps, un fichier app.properties monté en volume dans le même Pod, lui, s'est bien mis à jour tout seul.

Résoudre l’exercice →