Aller au contenu principal

Chapitre 5.1 - ConfigMaps

Objectifs d'Apprentissage​

À la fin de ce chapitre, vous serez capable de:

  • Comprendre ce qu'est un ConfigMap et pourquoi l'utiliser
  • Créer des ConfigMaps de différentes manières
  • Utiliser des ConfigMaps dans vos Pods
  • Séparer la configuration du code applicatif
  • Appliquer les bonnes pratiques pour les ConfigMaps

Introduction​

Dans le développement d'applications, la configuration change souvent selon l'environnement (développement, staging, production). Hardcoder la configuration dans le code ou dans les images Docker n'est pas une bonne pratique.

Les ConfigMaps permettent de séparer la configuration du code applicatif.


Qu'est-ce qu'un ConfigMap?​

Un ConfigMap est un objet Kubernetes qui stocke des données de configuration non sensibles sous forme de paires clé-valeur. Ces données peuvent être utilisées par les Pods comme variables d'environnement, arguments de commande, ou fichiers de configuration.


Pourquoi Utiliser des ConfigMaps?​

Problèmes Sans ConfigMaps​

Problèmes:

  • Configuration hardcodée dans le code
  • Besoin de rebuild l'image pour changer la config
  • Difficile de gérer différents environnements
  • Pas de séparation des préoccupations

Avantages Avec ConfigMaps​

Avantages:

  • Configuration séparée du code
  • Pas besoin de rebuild l'image
  • Facile de gérer plusieurs environnements
  • Réutilisable entre plusieurs Pods

Création de ConfigMaps​

Méthode 1: Depuis des Littéraux​

kubectl create configmap app-config \
--from-literal=database_url=postgresql://localhost:5432/mydb \
--from-literal=log_level=info \
--from-literal=max_connections=100

Méthode 2: Depuis un Fichier​

Créer un fichier config.properties:

database_url=postgresql://localhost:5432/mydb
log_level=info
max_connections=100
kubectl create configmap app-config --from-file=config.properties

Méthode 3: Depuis un Fichier YAML​

apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: default
data:
database_url: "postgresql://localhost:5432/mydb"
log_level: "info"
max_connections: "100"
# Fichier complet
application.properties: |
server.port=8080
server.host=0.0.0.0
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb

Utilisation dans les Pods​

Méthode 1: Variables d'Environnement (Une Clé)​

apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: my-app:1.0
env:
- name: DATABASE_URL
valueFrom:
configMapKeyRef:
name: app-config
key: database_url
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: log_level

Méthode 2: Toutes les Clés (envFrom)​

apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: my-app:1.0
envFrom:
- configMapRef:
name: app-config

Résultat: Toutes les clés du ConfigMap deviennent des variables d'environnement.

Méthode 3: Comme Volume (Fichiers)​

apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: my-app:1.0
volumeMounts:
- name: config
mountPath: /etc/config
readOnly: true
volumes:
- name: config
configMap:
name: app-config

Résultat: Chaque clé devient un fichier dans /etc/config/ avec la valeur comme contenu.


Exemple Complet​

Étape 1: Créer le ConfigMap​

apiVersion: v1
kind: ConfigMap
metadata:
name: webapp-config
data:
# Variables simples
APP_NAME: "My Web Application"
APP_VERSION: "1.0.0"
ENVIRONMENT: "production"

# Fichier de configuration
nginx.conf: |
server {
listen 80;
server_name example.com;
root /usr/share/nginx/html;
index index.html;
}

Étape 2: Utiliser dans un Deployment​

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: nginx:1.20
env:
- name: APP_NAME
valueFrom:
configMapKeyRef:
name: webapp-config
key: APP_NAME
- name: ENVIRONMENT
valueFrom:
configMapKeyRef:
name: webapp-config
key: ENVIRONMENT
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx/conf.d
readOnly: true
volumes:
- name: nginx-config
configMap:
name: webapp-config
items:
- key: nginx.conf
path: default.conf

Cas d'Usage​

1. Configuration d'Application​

apiVersion: v1
kind: ConfigMap
metadata:
name: app-settings
data:
database_host: "db.example.com"
database_port: "5432"
cache_ttl: "3600"
feature_flags: "feature1,feature2"

2. Fichiers de Configuration​

apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
}

3. Scripts​

apiVersion: v1
kind: ConfigMap
metadata:
name: init-scripts
data:
init.sh: |
#!/bin/bash
echo "Initializing application..."
/app/setup.sh
exec /app/start.sh

Bonnes Pratiques​

1. Organisation par Environnement​

Créer des ConfigMaps séparés pour chaque environnement:

# Développement
kubectl create configmap app-config-dev --from-file=config-dev.properties

# Production
kubectl create configmap app-config-prod --from-file=config-prod.properties

2. Versioning​

Utiliser des labels pour versionner:

apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
labels:
version: v1
environment: production
data:
# ...

3. Ne Pas Stocker de Données Sensibles​

Ne jamais mettre dans un ConfigMap:

  • Mots de passe
  • Tokens d'API
  • Clés privées
  • Certificats

Utiliser des Secrets à la place.


Commandes Utiles​

Voir un ConfigMap​

kubectl get configmap app-config
kubectl describe configmap app-config
kubectl get configmap app-config -o yaml

Modifier un ConfigMap​

kubectl edit configmap app-config

Note: Les Pods existants ne verront pas les changements immédiatement. Il faut les redémarrer.

Supprimer un ConfigMap​

kubectl delete configmap app-config

Limitations​

Taille Maximale​

  • 1 MiB par entrée dans un ConfigMap
  • Total limité par etcd (généralement ~1.5 MiB par objet)

Mise à Jour​

  • Variables d'environnement: Ne changent pas sans redémarrer le Pod
  • Volumes: Mis à jour périodiquement (délai de quelques secondes)

Résumé​

Dans ce chapitre, vous avez appris:

ConfigMap: Objet Kubernetes pour stocker la configuration non sensible
Création: kubectl create, YAML, depuis fichiers
Utilisation: Variables d'environnement (env/envFrom) ou volumes
Avantages: Séparation config/code, flexibilité, réutilisabilité
Bonnes pratiques: Organisation par environnement, versioning, pas de secrets
Limitations: Taille maximale, mise à jour nécessite redémarrage pour env vars


Prochaines Étapes​

Chapitre 5.2: Secrets - Gestion des données sensibles
Lab 5.1: Création et Utilisation de ConfigMaps


Chapitre créé le: Décembre 2024