Blog ENI : Toute la veille numérique !
🎁 Jusqu'au 31/12, recevez notre
offre d'abonnement à la Bibliothèque Numérique. Cliquez ici
🎁 Jusqu'au 31/12, recevez notre
offre d'abonnement à la Bibliothèque Numérique. Cliquez ici
  1. Livres et vidéos
  2. Kubernetes
  3. Mise en place d’une réplication entre pods
Extrait - Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (3e édition)
Extraits du livre
Kubernetes Gérez la plateforme de déploiement de vos applications conteneurisées (3e édition) Revenir à la page d'achat du livre

Mise en place d’une réplication entre pods

Objectifs du chapitre et prérequis

Ce chapitre est la suite directe du chapitre précédent et va aborder la mise en place de la réplication (ou synchronisation) entre plusieurs pods de base de données.

Vous aborderez les mécanismes nécessaires à la mise en place de ce type de synchronisation comme :

  • la création de script de démarrage ;

  • les commandes à exécuter en fin de démarrage d’un conteneur ;

  • les commandes à exécuter en début d’arrêt d’un conteneur.

Le contenu de ce chapitre ne doit pas servir sur de la production. Il s’agit avant tout d’un exemple d’intégration entre Kubernetes et MariaDB. Pour mettre en place une base de données avec haute disponibilité, consultez le chapitre Les opérateurs Kubernetes.

Synchronisation des pods MariaDB

1. Exposition de la problématique

Les différentes bases démarrées précédemment sont totalement indépendantes : aucune synchronisation n’est en place.

Pour synchroniser ces bases, Kubernetes n’a pas de solutions directes. La synchronisation du contenu est à la charge de l’administrateur qui met en place la plateforme.

Avant d’intégrer proprement ce mécanisme au sein de Kubernetes, vous allez d’abord étudier une mise en place manuelle.

2. Principe de fonctionnement de la synchronisation

a. Opérations à réaliser

La synchronisation qui va être mise en place sera structurée de la manière suivante :

  • Un maître recevra les requêtes en écriture.

  • Un esclave répliquera les requêtes en provenance du maître.

  • Les requêtes en lecture se feront indifféremment sur le maître ou l’esclave.

Dans MariaDB, le mécanisme de synchronisation maître vers esclave passe par le principe suivant :

  • configuration de l’ID des serveurs maître et esclave(s) ;

  • création d’utilisateurs disposant des droits de réplication ;

  • configuration de la synchronisation sur les esclaves.

b. Nombre de réplicas

Pour la suite de l’exercice, le nombre de réplicas des serveurs MariaDB devra être de deux.

 Afin de réaliser cette opération, lancez la commande suivante :

$ kubectl scale sts mariadb --replicas=2 

La commande doit alors renvoyer le résultat suivant :

statefulset.apps/mariadb scaled 

3. Identifiants des serveurs

a. Connexion aux pods

 En premier lieu, lancez la commande afin d’ouvrir un shell sur le conteneur MariaDB :

$ kubectl exec -it mariadb-0 -- bash 

b. Connexion à la base de données

Une fois le shell ouvert dans le contexte du pod, la connexion à la base va se faire à l’aide de la commande mariadb suivie des options suivantes :

  • l’option -u suivi de l’utilisateur root ;

  • l’option -p suivi du mot de passe.

Le mot de passe de l’administrateur MariaDB est contenu dans la variable d’environnement MARIADB_ROOT_PASSWORD.

 En prenant en compte ces indications, lancez la commande suivante afin d’ouvrir une connexion avec le serveur MariaDB :

$ mariadb...

Automatisation de la synchronisation

1. Scripts de démarrage et synchronisation

a. Script de démarrage

Avant d’aller plus loin, une première chose va être abordée : changer les options de démarrage en fonction du nom du pod.

Le script va récupérer l’identifiant du pod (0 pour mariadb-0, 1 pour mariadb-1, etc.) et l’incrémenter de 1. Le chiffre ainsi obtenu servira d’identifiant pour l’option server-id.

Autre action à réaliser : la configuration de la synchronisation en fonction du rôle :

  • création d’un compte de synchronisation sur le maître ;

  • configuration de la synchronisation sur l’esclave.

Afin de séparer un peu les choses, cette seconde action sera réalisée par un autre script.

Autre point important, la création de l’utilisateur ne doit pas être réalisée par le conteneur MariaDB du pod mariadb-1. Si l’utilisateur est déjà présent lors de l’activation de la synchronisation, le process de l’esclave s’arrêtera en indiquant que l’utilisateur existe déjà.

Une solution sera de supprimer la déclaration des variables MARIADB_USER et MARIADB_PASSWORD avec la commande unset.

En reprenant toutes ces indications, le script suivant sera utilisé pour le démarrage de MariaDB et sera stocké sous le nom start.sh :

#!/bin/sh 
INDEX=`hostname | awk -F- '{ print $2 }'` 
ID=`expr $INDEX + 1` 
OPTIONS="--server-id=$ID --log-bin --log-basename=master" 
OPTIONS="$OPTIONS --binlog-do-db=$MARIADB_DATABASE" 
OPTIONS="$OPTIONS --binlog-format=row 
--replicate-do-db=$MARIADB_DATABASE" 
/mariadb-init-db/configure-sync.sh 
case `hostname` in 
   mariadb-0) : ;; 
   *) unset MARIADB_USER MARIADB_PASSWORD ;; 
esac 
exec docker-entrypoint.sh $OPTIONS 

b. Configuration de la synchronisation

Le second script de configuration de la synchronisation sera stocké sous le nom configure-sync.sh et prendra la forme suivante :

#!/bin/sh 
# Si sur le maître => on crée le compte de réplication et on sort 
if [ `hostname` = "mariadb-0" ]; then 
   cp /mariadb-init-db/replication-user.sql...