Comment migrer hors des applications Kubernetes gérées par GitLab –
GitLab Managed Apps était une fonctionnalité de l’intégration Kubernetes de la plate-forme qui permettait l’installation en un clic des applications de cluster courantes. Cette itération de la fonctionnalité a été dépréciée pendant le cycle de publication de GitLab 13 et entièrement supprimée dans la version 14.0 de juin. Voici comment migrer vos applications gérées vers un modèle de déploiement pris en charge.
Sommaire
S’éloigner des applications gérées
Les applications gérées ont été développées pour simplifier la mise en place et l’exécution d’un nouveau cluster Kubernetes. GitLab a fourni des modèles pour des applications telles que NGINX Ingress, Cert Manager et Prometheus.
Deux méthodes d’installation différentes étaient proposées : un clic et CI/CD. La méthode en un clic fournissait une interface utilisateur dans GitLab qui répertoriait les applications disponibles et vous permettait de cliquer pour installer. Certaines applications ont également exposé les paramètres de configuration de base. La méthode CI/CD offrait un modèle GitLab CI pour ajouter des applications à un cluster dans le cadre d’un pipeline.
Les installations en un clic ont maintenant complètement disparu. La méthode CI reste fonctionnelle mais est obsolète et sera supprimée dans GitLab 15.0. Bien que les applications gérées simplifient considérablement l’installation, elles seul pris en charge cette étape du cycle de vie du cluster. Les applications ont été installées ou désinstallées, vous deviez donc rapidement passer aux outils de gestion Kubernetes classiques pour effectuer la maintenance et la personnalisation.
Malgré la suppression de la fonctionnalité, les installations d’applications gérées existantes continueront de fonctionner dans GitLab 14.0. Vous pouvez mettre à niveau GitLab en toute sécurité sans vous soucier des temps d’arrêt de votre cluster. La mise à niveau supprimera cependant l’interface utilisateur des applications gérées, vous ne pourrez donc pas afficher ou désinstaller les applications à partir de GitLab.
Prendre le contrôle de vos applications
La migration hors des applications gérées ne nécessite pas nécessairement une action immédiate de votre part. Comme vos applications resteront opérationnelles, vous pouvez les laisser telles quelles si vous êtes satisfait qu’elles restent dans le gitlab-managed-apps espace de noms.
Comme les applications sont simplement des déploiements Helm dans votre cluster, vous pouvez les gérer à l’aide du kubectl et les binaires de ligne de commande Helm. Ils apparaîtront en tant que ressources Kubernetes régulières.
Vous pouvez répertorier les ressources de cluster qui ont été installées par GitLab à l’aide de cette commande Kubectl :
kubectl get all -n gitlab-managed-apps
Cela vous permet de vérifier ce qui s’exécute dans votre cluster en l’absence de l’ancienne page « Applications » de GitLab.
Vous pourriez rencontrer des problèmes avec les applications installées par les anciennes versions de GitLab. Ceux-ci peuvent avoir été ajoutés à l’aide de Helm v2, qui n’est pas compatible avec les clients Helm v3 modernes. Si vous n’êtes pas sûr d’avoir installé des applications v2, utilisez la commande suivante pour vérifier :
kubectl get all -n gitlab-managed-apps | grep 'helm.sh/release'
Des applications qui sommes montré dans la sortie de cette commande ont été installés par Helm v3. Comparez la liste avec la précédente get all commande pour identifier les applications ajoutées par Helm v2.
S’il s’avère que vos applications utilisent Helm v2, vous devrez parcourir manuellement le guide de migration Helm pour les mettre à jour. Il est recommandé de passer à Helm v3 si vous souhaitez conserver les applications à long terme. Comme alternative, l’installation de Helm v2 sur votre machine vous permettra d’interagir avec les applications pour appliquer des correctifs et une maintenance immédiats.
Mise à niveau vers le nouveau modèle d’applications de cluster de GitLab
L’objectif primordial des applications gérées – simplifier la configuration des clusters – n’a pas été complètement écarté par GitLab. GitLab 14.0 se concentre sur les « projets de gestion » des clusters en tant que nouveau modèle de déploiement pour l’approvisionnement des clusters.
GitLab fournit un modèle de projet que vous pouvez utiliser pour installer des applications dans des clusters Kubernetes. Cela résout les problèmes d’origine avec les applications gérées en garantissant que vous avez un contrôle total sur les graphiques Helm qui sont déployés. Vous clonez le modèle, connectez le projet à votre cluster, puis modifiez et supprimez les graphiques d’application individuels si nécessaire. L’exécution d’un pipeline CI déploiera les applications sélectionnées sur votre cluster.
Vous pouvez migrer les applications gérées existantes vers le format de projet de gestion. Cela vous permet de continuer à les utiliser en utilisant une approche approuvée par GitLab. Nous supposerons que vous avez déjà un cluster Kubernetes connecté à votre instance GitLab, en raison de vos déploiements existants.
Commencez par créer un nouveau projet GitLab en utilisant le bouton plus en haut à droite. Cliquez sur « Créer à partir d’un modèle », puis faites défiler jusqu’au modèle « GitLab Cluster Management ». Cliquez sur le bouton « Utiliser le modèle ». Sur l’écran suivant, donnez un nom à votre projet et appuyez sur « Créer un projet ».
Le modèle fournit une série de graphiques Helm pour déployer des applications dans votre cluster. Les graphiques d’application individuels sont stockés dans le applications annuaire. Chaque application a son propre sous-répertoire.#
Commencez par éditer helmfile.yaml à la racine de votre projet, soit dans le GitLab Web IDE, soit en clonant le référentiel à l’aide de Git. Ce fichier fait référence aux modèles d’application individuels. Activez les applications que vous utilisez en décommentant les lignes pertinentes. Dans cet exemple, nous avons déjà installé Ingress et Cert Manager en tant qu’applications gérées GitLab, nous les activons donc dans le projet de gestion de cluster.
Ensuite, vous devez déterminer quelle version de graphique est déjà déployée sur votre cluster. Cette étape est importante afin de ne pas remplacer involontairement votre application par une version différente.
Vous pouvez obtenir la version d’une application en exécutant helm ls -n gitlab-managed-apps. Recherchez l’application dans le tableau de sortie et notez la version affichée dans le CHART colonne. Cela prendra le format app-name-X.Y.Z; vous n’avez besoin que du X.Y.Z partie.
Revenez à votre nouveau projet GitLab et ouvrez le helmfile.yaml associés à l’application, tels que applications/ingress/helmfile.yaml. Changer la version correspondant à la version que vous avez notée.
Enfin, remplacez la valeur par défaut values.yaml avec votre ensemble de valeurs Helm existant. Utilisez Helm pour charger la représentation YAML du fichier de valeurs de votre application :
helm get values ingress -n gitlab-managed-apps -a --output yaml
Remplacer ingress avec le nom du déploiement de votre application. Copiez l’intégralité de la sortie YAML et utilisez-la pour écraser le applications/ingress/values.yaml déposer. Assurez-vous d’ajuster le chemin du fichier pour qu’il corresponde à votre application. Vous êtes maintenant prêt à exécuter le déploiement du projet de gestion de cluster.
Un pipeline de déploiement démarre automatiquement lorsque vous fusionnez vos modifications dans la branche par défaut (qui est généralement main pour les nouveaux projets dans GitLab 14.0). Utilisez Git pour valider vos modifications et les fusionner dans :
git checkout -b my-branch git add . git commit -m "Migrate existing GitLab Managed Apps" git checkout main git merge my-branch git push -u origin main
Le pipeline s’exécutera. Si les modifications apportées au modèle étaient correctes, il ne devrait y avoir aucun impact sur vos applications en cours d’exécution. Certaines métadonnées inoffensives peuvent être modifiées à mesure que le mécanisme de déploiement change.
Vous êtes maintenant prêt à utiliser le projet de gestion de cluster pour la maintenance continue de vos applications. Par exemple, vous pouvez mettre à jour vers une nouvelle version d’une application en modifiant le version champ dans son helmfile.yaml. Fusionner le changement dans main inciterait Helm à appliquer les modifications à l’intérieur de votre cluster.
Conclusion
GitLab Managed Apps a aidé de nombreux utilisateurs à faire leurs premiers pas avec Kubernetes. La simplicité de la fonctionnalité s’est finalement avérée trop limitante, elle est donc maintenant supprimée dans un processus en plusieurs étapes.
Heureusement, il est assez simple de terminer votre migration hors des applications gérées. Ils n’ont rien de spécial – ce sont simplement des déploiements Helm réguliers qui se trouvent dans votre cluster gitlab-managed-apps espace de noms. Cela signifie que vos charges de travail resteront disponibles même si vous effectuez une mise à niveau vers GitLab 14.0, vous laissant libre de faire la transition à votre rythme.
À l’avenir, les projets de gestion de clusters sont l’approche privilégiée pour utiliser GitLab pour installer des applications populaires sur Kubernetes. Bien qu’un peu plus exigeant techniquement, ce modèle vous donne beaucoup plus de contrôle et vous aide à gérer votre infrastructure en tant que code.
