Migrer des bases de données vers Kubernetes à l’aide de Konveyor


  • FrançaisFranç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.yaml et les secrets de secret-db.yaml si 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          4m

    NAME                                      TEAM          VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE   STATUS
    postgresql.acid.zalan.do/trading-app-db   trading-app   13        4      1Gi                                     15m   Running

    NAME                            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   15m

    NAME                         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.

    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    La Rédaction

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *