Migration Kubernetes simplifiée avec Konveyor Move2Kube

Konveyor Move2Kube aide les développeurs à migrer des projets depuis des plateformes telles que Cloud Foundry et Docker Swarm vers Kubernetes et OpenShift. Move2Kube analyse le code source de votre application et génère des artefacts Infrastructure-as-Code (IaC) tels que les fichiers YAML Kubernetes, les graphiques Helm, les pipelines Tekton, etc.

Powering Move2Kube est un cadre de transformateur qui permet de chaîner plusieurs petits transformateurs pour transformer complètement les artefacts.

De nombreux transformateurs différents sont impliqués lors de la transformation d’un projet Java ou Node.js pour créer tous les artefacts de destination. Cela permet la réutilisation des transformateurs dans divers flux de bout en bout. Chaque transformateur est capable d’effectuer plusieurs activités.

Move2Kube

Vous pouvez utiliser Move2Kube comme commande de terminal ou comme application Web. Sa fonctionnalité principale comprend la planification et la transformation. Dans la phase de planification, Move2Kube analyse les artefacts pour identifier les services impliqués. Dans la phase de transformation, il transforme ces services en artefacts de destination.

La commande terminal est un binaire unique, que vous pouvez Télécharger et installer. Move2Kube fournit également un script d’assistance pour télécharger et placer le binaire dans votre système de fichiers local :

curl \ https://raw.githubusercontent.com/konveyor/move2kube/main/scripts/install.sh \

-o move2kube_install.sh

Examinez le script pour vous assurer que sa méthode d’installation correspond à vos préférences, puis exécutez-le :

$ sh ./move2kube_install.sh

Pour utiliser la commande, il suffit de l’exécuter sur un répertoire contenant le code source de l’application :

$ move2kube transform -s ./src

Transformez une application à l’échelle de l’entreprise

Move2Kube peut être utilisé pour reformater une application d’entreprise réelle. Une application d’entreprise de démonstration est incluse dans le Référentiel git Move2Kube pour démontrer le flux de travail. Cette application de démonstration est similaire à une application typique du monde réel avec des opérations CRUD et une architecture à plusieurs niveaux.

Pour l’essayer, téléchargez le code source de l’application d’entreprise :

$ curl https://move2kube.konveyor.io/scripts/download.sh \
| bash -s -- -d samples/enterprise-app/src -r move2kube-demos

Le code source de l’application d’entreprise se trouve dans le src annuaire.

Tout d’abord, utilisez le move2kube transform commande:

$ move2kube transform -s ./src

Après avoir exécuté la commande, regardez dans le myproject dossier. Il existe de nouveaux répertoires, y compris deploy, scriptset source. Le deploy Le répertoire contient tous les artefacts IaC, tels que les fichiers Kubernetes YAML, les pipelines Tekton, les graphiques Helm, les fichiers Knative, les fichiers de composition et les fichiers OpenShift. Le scripts Le répertoire contient des scripts shell pour créer et pousser des images de conteneur vers le registre de votre choix. Finalement, le source répertoire contient le code source et Dockerfiles.

Fonctionnalités fournies par Move2Kube

Move2Kube dispose d’un puissant moteur QA. Les transformateurs peuvent obtenir l’entrée d’un utilisateur à l’aide de ce moteur. Les transformateurs reçoivent l’entrée sous forme d’interaction utilisateur via un terminal, une interface Web, une API REST ou un fichier de configuration.

Par exemple, dans l’application d’entreprise de démonstration, le moteur d’assurance qualité Move2Kube peut demander sur quel port l’application frontale doit écouter, quel registre de conteneurs doit être utilisé pour stocker les images ou quel hôte d’entrée doit être utilisé.

Pour exécuter une application en mode non interactif, utilisez le --qa-skip drapeau. Cette option oblige Move2Kube à utiliser les réponses par défaut :

$ move2kube transform -s ./src --qa-skip

Si vous voulez répondre aux questions à partir d’un fichier de configuration, utilisez le -f option:

$ move2kube transform -s ./src -f ./m2kconfig.yaml

Une liste de toutes les réponses utilisées pour l’exécution est capturée en tant que configuration dans le m2kconfig.yaml déposer.

Capacité de personnalisation

Move2Kube comprend plusieurs transformateurs prêts à l’emploi et permet aux utilisateurs d’écrire de nouveaux transformateurs. Move2Kube expose toutes les capacités des transformateurs internes à exploiter pour écrire des transformateurs personnalisés. Ces fonctionnalités incluent un moteur d’assurance qualité, des modèles étendus activés par les modèles Golang et l’isolation. Les transformateurs personnalisés se comportent exactement de la même manière que les transformateurs intégrés. Les deux types peuvent être chaînés pour réaliser une transformation de bout en bout.

Move2Kube génère des artefacts que vous pouvez personnaliser pour vous conformer aux meilleures pratiques et politiques de l’organisation. Vous pouvez diriger l’outil Move2Kube vers des personnalisations à l’aide du -c ou --customization option.

Vous pouvez créer des personnalisations à l’aide de trois méthodes différentes :

1. Configurer les transformateurs intégrés : configurez un transformateur intégré pour qu’il se comporte différemment. Par exemple, vous pouvez modifier le transformateur de paramétrage pour paramétrer différentes valeurs en fonction des besoins de l’organisation.
2. Transformateurs basés sur Starlark : écrivez un transformateur complet dans un langage de type Python, Starlark. Par exemple, vous pouvez utiliser un transformateur basé sur Starlark pour ajouter des annotations personnalisées aux fichiers Kubernetes YAML.
3. Transformateurs exécutables : écrivez un transformateur complet dans le langage de votre choix et autorisez Move2Kube à l’exécuter avec les autres transformateurs. Par exemple, générez des chartes Helm personnalisées pour ajouter des fichiers et des répertoires personnalisés à des emplacements spécifiques.

Capacité de paramétrage et de personnalisation

Move2Kube permet aux utilisateurs de paramétrer des champs personnalisés dans les artefacts de la plate-forme cible, tels que les graphiques Helm. Par exemple, paramétrer le nombre de réplicas dans un chart Helm :

apiVersion: apps/v1
kind: Deployment
metadata:
    annotations:
        move2kube.konveyor.io/service.expose: "true"
    creationTimestamp: null
    labels:
        move2kube.konveyor.io/service: orders
    name: orders 
spec:
    progressDeadlineSeconds: 600
    replicas: {{ index .Values "common" "replicas" }}

Move2Kube vous permet également de personnaliser les artefacts de sortie. Par exemple, ajoutez une annotation personnalisée au fichier YAML Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
   annotations:
      kubernetes.io/ingress.class: haproxy
    creationTimestamp: null
    labels:
      move2kube.konveyor.io/service: myproject
    name: myproject

Études de cas Move2Kube

Mov2Kube a été largement adopté dans l’industrie et les communautés open source. Voici quelques études de cas où la replateforme à l’aide de Move2Kube a montré une amélioration considérable par rapport à l’effort manuel.

• InsApp
  • Pile de langage : Java (springboot), interface utilisateur angulaire JS
  • Plate-forme source : Docker Swarm
  • Nombre de prestations : 100
  • Effort manuel : 56 jours
  • Effort Move2Kube : 6 jours
  • Transformateurs intégrés invoqués : 6
  • Nombre de transformateurs externes : 0
• Étude de cas AA
  • Pile de langage : Java (springboot), interface utilisateur angulaire JS
  • Plate-forme source : Cloud-foundary
  • Nombre de prestations : 3
  • Effort manuel : 2 jours
  • Effort Move2Kube : 15 minutes
  • Transformateurs intégrés invoqués : 14
  • Nombre de transformateurs externes : 0
• Étude de cas PC
  • Pile de langage : Python
  • Plate-forme source : ECS Fargate
  • Nombre de prestations : 7
  • Effort manuel : 12 jours
  • Effort Move2Kube : 1 jour
  • Transformateurs intégrés invoqués : 13
  • Nombre de transformateurs externes : 0
• Étude de cas AMF
  • Pile de langage : interface utilisateur .NET Silverlight
  • Plate-forme source : Bare-metal/VM
  • Nombre de prestations : 4
  • Effort manuel : 9 jours
  • Effort Move2Kube : 5 heures
  • Transformateurs intégrés invoqués : 14
  • Nombre de transformateurs externes : 1 (dépendances personnalisées)
• Étude de cas TMP
  • Pile de langage : Java (springboot)
  • Plate-forme source : Cloud-Foundry
  • Nombre de prestations : 24
  • Effort manuel : 25 jours
  • Effort Move2Kube : 2,25 jours
  • Transformateurs intégrés invoqués : 15
  • Nombre de transformateurs externes : 1 (répertoires personnalisés)

Source des données : Seshadri, Padmanabha V., Harikrishnan Balagopal, Akash Nayak, Ashok Pon Kumar et Pablo Loyola. “Konveyor Move2Kube : un cadre pour la reformulation automatisée des applications.” En 2022 IEEE 15th International Conference on Cloud Computing (CLOUD), pp. 115-124. IEEE, 2022.

En savoir plus sur le convoyeur Move2Kube

Visiter le Site Move2Kube pour en savoir plus sur la replateforme à l’aide de Konveyor Move2Kube.