Migrer des bases de données vers Kubernetes à l’aide de Konveyor
Français
L’opérateur de base de données Kubernetes est utile pour créer des serveurs de base de données évolutifs en tant que cluster de base de données (DB). Mais comme vous devez créer de nouveaux artefacts exprimés sous forme de fichiers YAML, la migration des bases de données existantes vers Kubernetes nécessite beaucoup d’efforts manuels. Cet article présente un nouvel outil open source nommé Konveyor Tacle-DiVA-DOA (Adaptation d’un analyseur de validité à forte intensité de données à un opérateur de base de données). Il génère automatiquement des artefacts prêts à être déployés pour la migration de l’opérateur de base de données. Et il le fait grâce à une analyse de code centrée sur les données.
Qu’est-ce que Tackle-DiVA-DOA ?
Tackle-DiVA-DOA (DOA, en abrégé) est un outil d’analyse de configuration de base de données centré sur les données open source dans Konveyor Tackle. Il importe les fichiers de configuration de la base de données cible (tels que SQL et XML) et génère un ensemble d’artefacts Kubernetes pour la migration de la base de données vers des opérateurs tels que Opérateur Zalando Postgres.
(Yasuharu Katsuno et Shin Saito, CC BY-SA 4.0)
DOA trouve et analyse les paramètres d’un système existant qui utilise un système de gestion de base de données (SGBD). Ensuite, il génère des manifestes (fichiers YAML) de Kubernetes et de l’opérateur Postgres pour déployer un cluster DB équivalent.
(Yasuharu Katsuno et Shin Saito, CC BY-SA 4.0)
Les paramètres de base de données d’une application se composent de configurations de SGBD, de fichiers SQL, de scripts d’initialisation de base de données et de codes de programme pour accéder à la base de données.
- Configurations du SGBD inclure les paramètres du SGBD, la configuration du cluster et les informations d’identification. DOA stocke la configuration dans
postgres.yamlet les secrets desecret-db.yamlsi vous avez besoin d’informations d’identification personnalisées. - Fichiers SQL sont utilisés pour définir et initialiser des tables, des vues et d’autres entités dans la base de données. Ceux-ci sont stockés dans la définition Kubernetes ConfigMap
cm-sqls.yaml. - Scripts d’initialisation de la base de données créent généralement des bases de données et un schéma et accordent aux utilisateurs l’accès aux entités de base de données afin que les fichiers SQL fonctionnent correctement. DOA essaie de trouver les exigences d’initialisation à partir de scripts et de documents ou devine si ce n’est pas le cas. Le résultat sera également stocké dans un ConfigMap nommé
cm-init-db.yaml. - Code d’accès à la base de données, comme le nom de l’hôte et de la base de données, est dans certains cas intégré dans le code du programme. Ceux-ci sont réécrits pour fonctionner avec le cluster de bases de données migré.
Didacticiel
DOA est censé s’exécuter dans un conteneur et est livré avec un script pour créer son image. Assurez-vous que Docker et Bash sont installés sur votre environnement, puis exécutez le script de génération comme suit :
$ cd /tmp
$ git clone https://github.com/konveyor/tackle-diva.git
$ cd tackle-diva/doa
$ bash util/build.sh
…
docker image ls diva-doa
REPOSITORY TAG IMAGE ID CREATED SIZE
diva-doa 2.2.0 5f9dd8f9f0eb 14 hours ago 1.27GB
diva-doa latest 5f9dd8f9f0eb 14 hours ago 1.27GB
Cela crée DOA et les packs en tant qu’images de conteneurs. DOA est maintenant prêt à être utilisé.
L’étape suivante exécute un bundle run-doa.sh script wrapper, qui exécute le conteneur DOA. Spécifiez le référentiel Git de l’application de base de données cible. Cet exemple utilise une base de données Postgres dans le TradeApp application. Vous pouvez utiliser le -o option pour l’emplacement des fichiers de sortie et une -i option pour le nom du script d’initialisation de la base :
$ cd /tmp/tackle-diva/doa
$ bash run-doa.sh -o /tmp/out -i start_up.sh \
https://github.com/saud-aslam/trading-app
[OK] successfully completed.
Le /tmp/out/ répertoire et /tmp/out/trading-app, un répertoire avec le nom de l’application cible, sont créés. Dans cet exemple, le nom de l’application est trading-app, qui est le nom du référentiel GitHub. Les artefacts générés (les fichiers YAML) sont également générés sous le répertoire application-name :
$ ls -FR /tmp/out/trading-app/
/tmp/out/trading-app/:
cm-init-db.yaml cm-sqls.yaml create.sh* delete.sh* job-init.yaml postgres.yaml test//tmp/out/trading-app/test:
pod-test.yaml
Le préfixe de chaque fichier YAML indique le type de ressource défini par le fichier. Par exemple, chaque cm-*.yaml le fichier définit un ConfigMap, et job-init.yaml définit une ressource Job. À ce point, secret-db.yaml n’est pas créé et DOA utilise les informations d’identification que l’opérateur Postgres génère automatiquement.
Vous disposez maintenant des définitions de ressources requises pour déployer un cluster PostgreSQL sur une instance Kubernetes. Vous pouvez les déployer à l’aide du script utilitaire create.sh. Alternativement, vous pouvez utiliser le kubectl create commande:
$ cd /tmp/out/trading-app
$ bash create.sh # or simply “kubectl apply -f .”configmap/trading-app-cm-init-db created
configmap/trading-app-cm-sqls created
job.batch/trading-app-init created
postgresql.acid.zalan.do/diva-trading-app-db created
Les ressources Kubernetes sont créées, y compris postgresql (une ressource du cluster de base de données créée par l’opérateur Postgres), service, rs, pod, job, cm, secret, pvet pvc. Par exemple, vous pouvez voir quatre modules de base de données nommés trading-app-*car le nombre d’instances de base de données est défini sur quatre dans postgres.yaml.
$ kubectl get all,postgresql,cm,secret,pv,pvc
NAME READY STATUS RESTARTS AGE
…
pod/trading-app-db-0 1/1 Running 0 7m11s
pod/trading-app-db-1 1/1 Running 0 5m
pod/trading-app-db-2 1/1 Running 0 4m14s
pod/trading-app-db-3 1/1 Running 0 4mNAME TEAM VERSION PODS VOLUME CPU-REQUEST MEMORY-REQUEST AGE STATUS
postgresql.acid.zalan.do/trading-app-db trading-app 13 4 1Gi 15m RunningNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/trading-app-db ClusterIP 10.97.59.252 <none> 5432/TCP 15m
service/trading-app-db-repl ClusterIP 10.108.49.133 <none> 5432/TCP 15mNAME COMPLETIONS DURATION AGE
job.batch/trading-app-init 1/1 2m39s 15m
Notez que l’opérateur Postgres est livré avec une interface utilisateur (UI). Vous pouvez trouver le cluster créé sur l’interface utilisateur. Vous devez exporter l’URL du point de terminaison pour ouvrir l’interface utilisateur sur un navigateur. Si vous utilisez minikube, procédez comme suit :
$ minikube service postgres-operator-ui
Ensuite, une fenêtre de navigateur s’ouvre automatiquement et affiche l’interface utilisateur.
(Yasuharu Katsuno et Shin Saito, CC BY-SA 4.0)
Vous pouvez maintenant accéder aux instances de base de données à l’aide d’un module de test. DOA a également généré une définition de pod pour les tests.
$ kubectl apply -f /tmp/out/trading-app/test/pod-test.yaml # creates a test Pod
pod/trading-app-test created
$ kubectl exec trading-app-test -it -- bash # login to the pod
Le nom d’hôte de la base de données et les informations d’identification pour accéder à la base de données sont injectés dans le pod, vous pouvez donc accéder à la base de données en les utilisant. Exécutez le psql métacommande pour afficher toutes les tables et vues (dans une base de données) :
# printenv DB_HOST; printenv PGPASSWORD
(values of the variable are shown)# psql -h ${DB_HOST} -U postgres -d jrvstrading -c '\dt'
List of relations
Schema | Name | Type | Owner
--------+----------------+-------+----------
public | account | table | postgres
public | quote | table | postgres
public | security_order | table | postgres
public | trader | table | postgres
(4 rows)# psql -h ${DB_HOST} -U postgres -d jrvstrading -c '\dv'
List of relations
Schema | Name | Type | Owner
--------+-----------------------+------+----------
public | pg_stat_kcache | view | postgres
public | pg_stat_kcache_detail | view | postgres
public | pg_stat_statements | view | postgres
public | position | view | postgres
(4 rows)
Une fois le test terminé, déconnectez-vous du pod et retirez le pod de test :
# exit
$ kubectl delete -f /tmp/out/trading-app/test/pod-test.yaml
Enfin, supprimez le cluster créé à l’aide d’un script :
$ bash delete.sh
Bienvenue dans le monde de Konveyor Tackle !
Pour en savoir plus sur la refactorisation d’applications, vous pouvez consulter le Conveyor Tackle siterejoignez la communauté et accédez au code source sur GitHub.
