Kubernetes expliqué : gestion de la configuration des applications | Salvatore D’Angelo

Il s’agit du troisième article de la série Kubernetes Explained. Ici, je vais vous expliquer comment gérer la configuration de votre application à l’aide de Kubernetes. Cartes de configuration.

“Anatomie” de l’application

La plupart des applications peuvent être décomposées en trois niveaux :

La présentation et la logique se trouvent généralement dans le code binaire de l’application, qui ne doit jamais changer d’un environnement à l’autre. Ce qui change habituellement, c’est ceci données – et avec les données, nous incluons également configuration.

Selon l’application 12-Factor, la configuration doit toujours être séparée du code et des données.

La configuration elle-même peut être divisée en deux parties principales :

• commun valeurs de configuration
• secrets

Dans Kubernetes, la configuration est gérée à l’aide Cartes de configuration.

Qu’est-ce que ConfigMap dans Kubernetes ?

UN Carte de configuration il s’agit essentiellement d’un dictionnaire clé-valeur que vous pouvez créer et stocker dans votre cluster Kubernetes. Plus tard, vos Pods pourront référencer et utiliser ces valeurs.

Pourquoi utiliser ConfigMap ?

Une bonne conception d’application sépare la configuration des données et du code binaire. Kubernetes utilise ConfigMaps pour réaliser ce principe.

ConfigMap peut stocker :

• lignes de connexion
• autorité publique
• noms d’hôtes
• URL
• et bien plus encore

Cette séparation offre deux avantages clés :

1. Vous pouvez associer différents ConfigMaps au même Pod en fonction de l’environnement (développement, staging, production, etc.).
2. Vous pouvez mettre à jour ConfigMap au moment de l’exécution sans redéployer ni modifier le code de l’application.

Comment fonctionnent les ConfigMaps ?

Voici le flux de travail de base :

1. Créez une ou plusieurs cartes de configuration, généralement une par environnement.
2. Ajoutez ConfigMap à votre cluster Kubernetes.
3. Référencez-le à partir de vos pods afin que les conteneurs puissent prendre des valeurs.

Création de ConfigMaps

Vous pouvez créer des ConfigMaps de plusieurs manières.

Utiliser un fichier YAML

Voici un exemple qui définit les options de connexion à la base de données :

apiVersion: v1
kind: ConfigMap
metadata:
name: db-config
namespace: default
data:
connection.properties: |
db.name=mydb
db.port=5432
db.user=myuser
db.password=mypassword

Appliquer le fichier depuis :

kubectl apply -f YAML

Si vous ne spécifiez pas d’espace de noms, le ConfigMap sera créé dans celui par défaut.

Utiliser la ligne de commande

Si vous avez un dossier DIR avec des fichiers de configuration ou un seul fichier FILEcourir:

kubectl create configmap NAME --from-file=DIR --namespace=default
kubectl create configmap NAME --from-file=FILE --namespace=default

Vous pouvez également définir directement des paires clé-valeur :

kubectl create configmap db-config \
--from-literal=key1=value1 \
--from-literal=key2=value2

Comment les pods référencent ConfigMaps

Les pods peuvent utiliser ConfigMaps de deux manières :

1. Comment variables d’environnement
2. Comment volumes montés

Utiliser des variables d’environnement

Vous pouvez charger une seule valeur :

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image:x.y.z
env:
- name: DB_USER_ENV
valueFrom:
configMapKeyRef:
name: db-config
key: db.user

Ou chargez toutes les paires clé-valeur en même temps :

apiVersion: v1 
kind: Pod 
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image:x.y.z 
envFrom:
- configMapRef:
name: db-config

Ceci est un exemple de la deuxième méthode, où toutes les propriétés ConfigMap de db-config sont lues et utilisées comme variables d’environnement :

Utiliser des volumes montés

Une autre méthode courante consiste à monter le ConfigMap en tant que volume :

apiVersion: v1 
kind: Pod 
metadata:
name: my-pod 
spec:
volumes:
- name: my-volume
configMap:
name: db-config
containers:
- name: my-container
image: my-image:x.y.z
volumeMounts:
- name: my-volume
mountPath: /etc/config

Dans cet exemple, db-config ConfigMap est défini sur /etc/configcréer un connection.properties déposer.

Après avoir lancé le Pod, vous pouvez vérifier le contenu en utilisant :

kubectl exec -it my-pod -- sh
ls /etc/config/
cat /etc/config/connection.properties

Mon approche de l’utilisation de ConfigMaps

D’après ce que j’ai vu, environ 90 % des développeurs écrivant des applications Kubernetes transmettent les paramètres de configuration à leurs pods via variables d’environnement. Cette approche fonctionne bien si vous n’avez besoin que de quelques paramètres (un à trois), car c’est l’option la plus simple.

Cependant, dès que le nombre de paramètres augmente, je préfère une stratégie différente. Dans mon workflow de développement, je le garde local config.yml déposer. Cela me permet de :

• construire et tester des fonctions localement,
• exécuter des tests unitaires,
• et itérez rapidement, sans surcharge de Kubernetes ni scripts personnalisés pour définir des variables d’environnement.

Si l’application est déployée dans un environnement de test ou de production, je crée un ConfigMap pour chaque environnement. Chaque ConfigMap affiche les paramètres de mon développement config.ymlpuis monté à l’intérieur du conteneur en tant que volume, remplaçant la configuration de développement local.

Enfin, je tiens les variables d’environnement sont réservées aux secrets uniquement. Cela permet de séparer clairement les valeurs sensibles, tandis que la configuration reste organisée et cohérente dans tous les environnements.

et ensuite ?

Dans cet article, nous avons appris à gérer la configuration des applications à l’aide de Kubernetes ConfigMap. Cependant, il existe un mot de passe dans le fichier connection.properties qui constitue une donnée sensible (db.password). Ils sont gérés par Kubernetes Secretsun nouveau concept que nous analyserons dans le prochain article.