GitLab Managed Apps était une fonctionnalité de l'intégration Kubernetes de la plate-forme qui permettait l'installation en un clic de 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.
S'éloigner des applications gérées
Géré Les applications 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 a fourni une interface utilisateur dans GitLab qui répertorie les applications disponibles et vous permet 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 aient considérablement simplifié l'installation, elles n'ont pris en charge que 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 se poursuivront. pour 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, de sorte que vous ne pourrez pas afficher ou désinstaller les applications à partir de GitLab.
Gagner le contrôle de votre 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 l'espace de noms des applications gérées par gitlab.
Publicité
Comme les applications sont simplement Helm déploiements dans votre cluster, vous pouvez les gérer à l'aide des binaires de ligne de commande kubectl et Helm. Elles s'afficheront en tant que ressources Kubernetes normales.
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 des anciennes “Applications” page.
Vous pouvez 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 récupère toutes les -n applications gérées par gitlab | grep 'helm.sh/release'
Les applications qui sont affichées dans la sortie de cette commande ont été installées par Helm v3. Comparez la liste avec la commande get all précédente pour identifier les applications ajoutées par Helm v2.
Publicité
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 Nouveau modèle d'applications de cluster de GitLab
L'objectif primordial des applications gérées – simplifier la configuration du cluster – n'a pas été complètement écarté par GitLab. GitLab 14.0 se concentre sur les “projets de gestion” en tant que nouveau modèle de déploiement pour le provisionnement 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'à “GitLab Cluster Management” modèle. Cliquez sur le bouton “Utiliser le modèle” bouton. 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 répertoire des applications. Chaque application a son propre sous-répertoire.#
Publicité
Commencez par éditer helmfile.yaml à la racine de votre projet, soit dans 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 correspondantes. Dans cet exemple, nous avons précédemment 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 la colonne GRAPHIQUE. Cela prendra le format nom-application-X.Y.Z ; vous n'avez besoin que de la partie X.Y.Z.
Revenez à votre nouveau projet GitLab et ouvrez le fichier helmfile.yaml associé à l'application, tel que applications/ingress/helmfile.yaml. Modifiez le champ de version pour qu'il corresponde à la version que vous avez notée.
Enfin, remplacez les valeurs par défaut .yaml avec votre ensemble existant de valeurs Helm. 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
Remplacez l'entrée par le nom du déploiement de votre application. Copiez l'intégralité de la sortie YAML et utilisez-la pour écraser le fichier applications/ingress/values.yaml. 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.
Publicité
Un pipeline de déploiement démarrera automatiquement lorsque vous fusionnerez vos modifications dans la branche par défaut (ce qui est généralement principal pour les nouveaux projets dans GitLab 14.0). Utilisez Git pour valider vos modifications et les fusionner dans :
git checkout -b ma-branche git add . git commit -m “Migrer les applications gérées GitLab existantes” 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 champ de version dans son fichier helmfile.yaml. La fusion de la modification 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 limitative, elle est donc désormais supprimée dans le cadre d'un processus en plusieurs étapes.
Heureusement, il est assez simple de terminer votre migration. à partir des applications gérées. Ils n'ont rien de spécial – ce sont simplement des déploiements Helm normaux qui se trouvent dans l'espace de noms gitlab-managed-apps de votre cluster. 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 passer à votre rythme.
À l'avenir, les projets de gestion de cluster 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.