Orchestrez vos conteneurs avec Kubernetes

Configurez votre application

La configuration des applications est un aspect crucial, et les environnements de développement (Dev) et de production (Prod) ont souvent des configurations différentes pour de bonnes raisons.

La configuration permet de personnaliser le comportement d'une application sans modifier son code source. Cela permet d'adapter l'application à différents environnements, besoins des utilisateurs ou changements de l'infrastructure. Elle isole les paramètres variables du code principal, ce qui améliore la maintenabilité et la lisibilité du code.

La configuration permet de stocker des informations sensibles (mots de passe, clés API, etc.) de manière sécurisée, séparément du code source.

Différentes configurations peuvent être utilisées pour tester l'application dans différents scénarios et pour déployer l'application dans différents environnements sans avoir à recompiler le code.

Par exemple, le site web de LiveCorp se configure grâce à des variables d’environnement qui peuvent être différentes entre l’environnement de développement et l’environnement de production. Le nombre de réplicas peuvent aussi être différent. Il n’est pas nécessaire d’avoir 3 réplicas en environnement de développement, alors qu’en environnement de production, les 3 réplicas servent à gérer la haute disponibilité.

Dans la suite de ce chapitre, vous allez configurer le site web avec une base de données qui sera configurée via les variables d’environnements nécessaires.

Les environnements de développement et de production ont des objectifs et des contraintes différents, ce qui nécessite des configurations distinctes.

Essayons de résumer ces différences dans un tableau comparatif :

Kubernetes offre deux principales méthodes pour gérer la configuration des applications : les variables d'environnement et les ConfigMaps. Chacune a ses avantages et ses inconvénients, et le choix dépend de vos besoins spécifiques.

Prenez en main l’API ConfigMap

Lors du déploiement en production, le site web de LiveCorp doit être déployé avec une base de données afin de gérer la persistance des données. Le site web doit pouvoir récupérer la valeur par exemple de l’URL du service de base de données.

Cette valeur est récupérée lors du démarrage de l’application via des variables d’environnements.

Les variables d'environnement

Les variables d'environnement sont des paires clé-valeur qui sont injectées dans les conteneurs de vos pods. Vous pouvez les définir directement dans le fichier YAML de votre pod ou de votre déploiement.

Elles sont faciles à utiliser et à comprendre. Les variables d'environnement sont un mécanisme standard pris en charge par la plupart des langages de programmation et des frameworks.

Mais cela ne convient pas pour stocker des informations sensibles, car elles peuvent être exposées dans les journaux ou les outils de surveillance.

De plus, la taille des variables d'environnement est limitée par le système d'exploitation.

Enfin, gérer un grand nombre de variables d'environnement peut devenir difficile, c’est pourquoi il est plutôt recommandé d’utiliser des ConfigMaps.

Les ConfigMaps

Un ConfigMap est un objet Kubernetes qui stocke des données de configuration sous forme de paires clé-valeur. Ces données peuvent être de différents types :

• Chaînes de caractères : Par exemple, des URL de base de données, des noms d'hôtes, des paramètres d'application ;

• Fichiers : Des fichiers de configuration entiers peuvent être stockés dans un ConfigMap ;

• Données binaires : Des données binaires peuvent être stockées en base64.

Les ConfigMaps permettent de stocker la configuration de votre application séparément de son code source, ce qui améliore la maintenabilité et la flexibilité. Vous pouvez gérer toutes les configurations de votre application à un seul endroit, ce qui facilite les mises à jour et le déploiement. Kubernetes peut injecter les données du ConfigMap dans vos pods en tant que variables d'environnement ou en tant que fichiers montés.

Comment créer un ConfigMap ?

Afin de configurer le site web, vous devez déployer une base de données MySQL. Vous allez déployer cette base grâce à un manifeste de déploiement et l’exposer via un service.

Voici le manifeste de déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:8.4.0
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql

Et celui du service :

apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
selector:
app: mysql

Lors du démarrage du site web, celui-ci regarde plusieurs variables d’environnement comme  MYSQL_HOST  ,  MYSQL_USER  ,  MYSQL_PASSWORD  et  MYSQL_DB  . Ces valeurs vont devoir être injectées dans le manifeste de déploiement du site web. 

Dans un premier temps, vous allez créer le ConfigMap suivant :

apiVersion: v1
kind: ConfigMap
metadata:
name: site-ecommerce-configmap
data:
MYSQL_HOST: mysql.default.svc.cluster.local
MYSQL_USER: root
MYSQL_PASSWORD: password
MYSQL_DB: todos

Examinons les différentes parties. Nous retrouvons dans un premier temps les blocs  api  ,  kind  et  metadata  que vous connaissez maintenant. 

apiVersion: v1
kind: ConfigMap
metadata:
name: site-ecommerce-configmap

Ensuite, le blocdata  défini toutes les variables d’environnement nécessaires :

data:
MYSQL_HOST: mysql.default.svc.cluster.local
MYSQL_USER: root
MYSQL_PASSWORD: password
MYSQL_DB: todos

Ici, les variables d’environnements nécessaires au démarrage de l’application sont définies dans le ConfigMap. Une fois le manifeste créé, il faut maintenant l’appliquer sur le cluster :

kubectl apply -f site-ecommerce-configmap.yml

Vous pouvez vérifier que le ConfigMap a bien été créé :

kubectl get configmap
NAME                                                      DATA   AGE
site-ecommerce-configmap-4-m9dm2f92bt   4  37s

Et vérifier que les données sont bien présentes :

kubectl describe configmaps/site-ecommerce-configmap-4-m9dm2f92bt
Name:     demo-config
Namespace: default
Labels:   <none>
Annotations:  <none>
Data
====
MYSQL_HOST:
----
mysql.default.svc.cluster.local
MYSQL_USER:
----
root
MYSQL_PASSWORD:
----
password
MYSQL_DB:
----
todos

Il est maintenant temps de modifier le manifeste de déploiement afin de tirer parti de ces variables.

Regardons le manifeste du déploiement du site web :

apiVersion: apps/v1
kind: Deployment
metadata:
name: site-ecommerce-deployment
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080

Vous allez modifier ce fichier en ajoutant les sections suivantes :

apiVersion: apps/v1
kind: Deployment
metadata:
name: site-ecommerce-deployment
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080
        env:
          - name: MYSQL_HOST
             valueFrom:
               configMapKeyRef:
                 name: site-ecommerce-configmap
                 key: MYSQL_HOST
          - name: MYSQL_USER
             valueFrom:
               configMapKeyRef:
                 name: site-ecommerce-configmap
                 key: MYSQL_USER
          - name: MYSQL_PASSWORD
             valueFrom:
               configMapKeyRef:
                 name: site-ecommerce-configmap
                 key: MYSQL_PASSWORD
          - name: MYSQL_DB
             valueFrom:
               configMapKeyRef:
                 name: site-ecommerce-configmap
                 key: MYSQL_DB

Ces sections vont indiquer au déploiement de créer des variables d’environnements nommées  MYSQL_HOST  ,  MYSQL_USER  ,  MYSQL_PASSWORD  et  MYSQL_DB  et que ces variables sont référencées dans le ConfigMap  site-ecommerce-configmap  .

Une fois le fichier modifié, vous allez l’appliquer de nouveau sur le cluster afin de changer le comportement de l’application :

kubectl apply -f site-ecommerce-deployment.yml

Ainsi, lors du redémarrage de l’application, le site va se connecter au serveur MySQL et persister ces données dans la base de données.

Si vous avez bien remarqué les variables d’environnements, vous avez dû remarquer qu’une variable est sensible. Cette variable est la variable MYSQL_PASSWORD.

Kubernetes contient une ressource pour stocker ce genre de variable sensible qui s’appelle un Secret.

Prenez en main l’API Secret

Les secrets

Les secrets sont stockés de manière chiffrée dans etcd, la base de données de Kubernetes. Cela les protège contre les accès non autorisés.

Ils sont gérés indépendamment des pods, ce qui facilite leur mise à jour et leur rotation. Vous pouvez contrôler quels pods ont accès à quels secrets en utilisant les rôles et les autorisations de Kubernetes (RBAC). Les secrets peuvent être injectés dans les pods en tant que variables d'environnement ou montés en tant que fichiers, ce qui facilite leur utilisation par les applications.

Pour stocker le mot de passe de la base de données du site web, vous allez créer une ressource de type Secret et modifier le déploiement afin de tirer partie de cette nouvelle ressource.

Les secrets dans Kubernetes sont stockés en base64. Toute personne ayant accès au secret dans le cluster pourra alors voir les données sensibles.

Pour créer un secret dans Kubernetes, le mieux est d’utiliser la commande kubectl afin que la ressource soit bien créée. Vous allez maintenant créer le Secret pour stocker le mot de passe de la base de données :

kubectl create secret generic site-ecommerce-secret --from-literal=MYSQL_PASSWORD=password

Vous pouvez vérifier ensuite que le secret a bien été créé :

kubectl get secrets
NAME                                         TYPE                                  DATA   AGE
site-ecommerce-secret            Opaque                              1          1h

Et vérifier le contenu de ce secret :

kubectl describe secret site-ecommerce-secret
Name:         site-ecommerce-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>
Type:  Opaque
Data
====
MYSQL_PASSWORD:  16 bytes

Vous allez maintenant modifier légèrement le manifeste de déploiement afin que l’application récupère le mot de passe non plus dans le ConfigMap, mais dans le Secret :

apiVersion: apps/v1
kind: Deployment
metadata:
name: site-ecommerce-deployment
spec:
replicas: 5
selector:
matchLabels:
app: site-ecommerce
template:
metadata:
labels:
app: site-ecommerce
spec:
containers:
- name: site-ecommerce
image: site-ecommerce:1.2.0
ports:
- containerPort: 8080
env:
- name: MYSQL_HOST
valueFrom:
configMapKeyRef:
name: site-ecommerce-configmap
key: MYSQL_HOST
- name: MYSQL_USER
valueFrom:
configMapKeyRef:
name: site-ecommerce-configmap
key: MYSQL_USER
          - name: MYSQL_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: site-ecommerce-secret
                 key: MYSQL_PASSWORD
- name: MYSQL_DB
valueFrom:
configMapKeyRef:
name: site-ecommerce-configmap
key: MYSQL_DB

Une fois le fichier modifié, il faut maintenant l’appliquer de nouveau sur le cluster afin que la configuration soit prise en compte :

kubectl apply -f site-ecommerce-deployment.yml

L’application va alors récupérer les différentes informations dans les différentes ressources déclarées.

Configurer votre application

Afin de configurer le site web, vous devez déployer une base de données MySQL. Vous allez déployer cette base grâce à un manifeste de déploiement et l’exposer via un service.

Voici le manifeste de déploiement de la base de données :

apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:8.4.0
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql

Et celui du service associé :

apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
selector:
app: mysql

Lors du démarrage du site web, celui-ci regarde plusieurs variables d’environnement comme  MYSQL_HOST  ,  MYSQL_USER  ,  MYSQL_PASSWORD  et  MYSQL_DB  . Ces valeurs vont devoir être injectées dans le manifeste de déploiement du site web.

Dans un premier temps, vous allez créer le ConfigMap suivant :

apiVersion: v1
kind: ConfigMap
metadata:
name: site-ecommerce-configmap
data:
MYSQL_HOST: mysql.default.svc.cluster.local
MYSQL_USER: root
MYSQL_PASSWORD: password
MYSQL_DB: todos

Ce ConfigMap contient les variables nécessaires à l’application.

Dans ce screencast, vous avez :

• créé un ConfigMap pour paramétrer l’application ;

• créé un secret avec le mot de passe de la base de données ;

• modifié le déploiement pour prendre en compte le ConfigMap et le Secret.

A vous de jouer

Contexte

Alice : J’ai vu que tu avais résolu le problème de la persistance des données. Bien joué ! Par contre, les variables d’environnements sont codées en dur dans l’application. Je crois qu’un de nos développeurs avait modifié l’application pour pouvoir la configurer à chaud via des variables d'environnements. Ce serait bien de créer des variables différentes entre environnement de développement et environnement de production.

Peux-tu créer des manifestes afin de pouvoir configurer indépendamment les deux environnements ?

Mais fais attention, si tu utilises des données sensibles, il faut que ces données soient chiffrées !

Consignes

1. Déployez une base de données ;

2. Configurez l’application pour récupérer les valeurs de la base de données ;

3. Stockez le mot de passe de la base dans un endroit sécurisé ;

4. Modifiez le déploiement pour configurer l’application ;

5. Vérifiez que l’application est bien reconfiguré.

En résumé

• Les variables d’environnements sont utilisées pour configurer à chaud une application.

• Un ConfigMap sert à stocker des variables qui peuvent changer entre environnements.

• Un Secret sert à stocker des données sensibles sous base64.

• Un Secret n’est pas un moyen de chiffrer les données.

Dans le prochain chapitre, vous allez apprendre à exposer votre application à l’extérieur du cluster !