Hoe te migreren van door GitLab beheerde Kubernetes-apps

0
162

GitLab Managed Apps was een functie van de Kubernetes-integratie van het platform die de installatie met één klik van veelvoorkomende cluster-apps mogelijk maakte. Deze iteratie van de functie werd gedeprecieerd tijdens de GitLab 13-releasecyclus en volledig verwijderd in de 14.0-release van juni. Hier leest u hoe u uw beheerde apps migreert naar een ondersteund implementatiemodel.

Afstappen van beheerde apps

Beheerd Apps zijn ontwikkeld om het opstarten met een nieuw Kubernetes-cluster te vereenvoudigen. GitLab leverde sjablonen voor applicaties zoals NGINX Ingress, Cert Manager en Prometheus.

Er werden twee verschillende installatiemethoden aangeboden: één klik en CI/CD. De methode met één klik zorgde voor een gebruikersinterface binnen GitLab met een lijst van beschikbare apps en waarmee je kon klikken om te installeren. Sommige apps hebben ook basisconfiguratie-instellingen blootgelegd. De CI/CD-methode bood een GitLab CI-sjabloon om apps aan een cluster toe te voegen als onderdeel van een pijplijn.

Installaties met één klik zijn nu helemaal verdwenen. De CI-methode blijft functioneel, maar is verouderd en wordt verwijderd in GitLab 15.0. Hoewel Managed Apps de installatie drastisch vereenvoudigden, waren ze alleen geschikt voor deze fase van de levenscyclus van het cluster. Apps zijn geïnstalleerd of verwijderd, dus u moet snel overstappen op reguliere Kubernetes-beheertools om onderhoud en aanpassingen uit te voeren.

Ondanks de verwijdering van de functie, blijven bestaande beheerde app-installaties werken in GitLab 14.0. U kunt GitLab veilig upgraden zonder dat u zich zorgen hoeft te maken over downtime in uw cluster. Als u een upgrade uitvoert, wordt de gebruikersinterface voor beheerde apps verwijderd, dus u kunt geen apps bekijken of verwijderen vanuit GitLab.

Controle krijgen over uw Apps

Als u uit beheerde apps migreert, hoeft u niet per se onmiddellijk actie te ondernemen. Omdat je apps operationeel blijven, kun je ze laten zoals ze zijn als je tevreden bent dat ze in de door gitlab beheerde-apps naamruimte blijven.

Advertentie

Omdat de apps gewoon Helm zijn implementaties in uw cluster, kunt u deze beheren met behulp van de binaire bestanden van de kubectl- en Helm-opdrachtregel. Ze verschijnen als normale Kubernetes-bronnen.

Je kunt clusterbronnen weergeven die door GitLab zijn geïnstalleerd met behulp van dit Kubectl-commando:

kubectl get all -n gitlab-managed-apps

Hiermee kunt u controleren wat er in uw cluster draait bij afwezigheid van GitLab's oude 'Applicaties' page.

U kunt problemen ondervinden met apps die door oude GitLab-versies. Deze zijn mogelijk toegevoegd met Helm v2, die niet compatibel is met moderne Helm v3-clients. Als je niet zeker weet of je v2-apps hebt geïnstalleerd, gebruik dan de volgende opdracht om te controleren:

kubectl get all -n door gitlab beheerde apps | grep 'helm.sh/release'

Apps die worden getoond in de uitvoer van deze opdracht, zijn geïnstalleerd door Helm v3. Vergelijk de lijst met de eerdere 'get all'-opdracht om apps te identificeren die zijn toegevoegd door Helm v2.

Advertentie

Als blijkt dat uw apps Helm v2 gebruiken, moet u de Helm-migratiehandleiding handmatig doorlopen om ze up-to-date te brengen. Het wordt aanbevolen om naar Helm v3 te gaan als je de apps voor de lange termijn wilt behouden. Als alternatief kunt u door Helm v2 op uw computer te installeren, communiceren met de apps om onmiddellijke oplossingen en onderhoud toe te passen.

Upgraden naar GitLab's nieuwe model voor clusterapps

Het overheersende doel van beheerde apps – vereenvoudiging van clusterconfiguratie – is niet volledig terzijde geschoven door GitLab. GitLab 14.0 richt zich op cluster "managementprojecten" als een nieuw implementatiemodel voor clusterinrichting.

GitLab biedt een projectsjabloon die u kunt gebruiken om apps in Kubernetes-clusters te installeren. Dit lost de oorspronkelijke problemen met beheerde apps op door ervoor te zorgen dat u volledige controle hebt over de Helm-diagrammen die worden geïmplementeerd. U kloont de sjabloon, verbindt het project met uw cluster en bewerkt en verwijdert vervolgens de afzonderlijke app-diagrammen indien nodig. Als u een CI-pipeline uitvoert, worden de geselecteerde apps in uw cluster geïmplementeerd.

U kunt bestaande beheerde apps migreren naar de beheerprojectindeling. Hierdoor kunt u ze blijven gebruiken met behulp van een door GitLab goedgekeurde aanpak. We gaan ervan uit dat u al een Kubernetes-cluster hebt aangesloten op uw GitLab-instantie, op grond van uw bestaande implementaties.

Begin met het maken van een nieuw GitLab-project met behulp van de plusknop in de rechterbovenhoek. Klik op “Maken van sjabloon” en scrol vervolgens omlaag naar de “GitLab Cluster Management” sjabloon. Klik op de “Sjabloon gebruiken” knop. Geef op het volgende scherm uw project een naam en druk op “Project maken.”

De sjabloon biedt een reeks Helm-diagrammen om apps in uw cluster te implementeren. De afzonderlijke app-diagrammen worden opgeslagen in de applicatiemap. Elke app krijgt zijn eigen submap.#

Advertentie

Begin met het bewerken van helmfile.yaml in de hoofdmap van uw project, in de GitLab Web IDE of door de repository te klonen met Git. Dit bestand verwijst naar de individuele aanvraagsjablonen. Schakel de applicaties die u gebruikt in door de relevante regels te verwijderen. In dit voorbeeld hebben we eerder Ingress en Cert Manager geïnstalleerd als door GitLab beheerde apps, dus we schakelen ze in in het clusterbeheerproject.

Vervolgens moet u uitzoeken welke kaartversie al in uw cluster is geïmplementeerd. Deze stap is belangrijk, zodat u uw app niet per ongeluk door een andere versie vervangt.

U kunt de versie van een app verkrijgen door helm ls -n gitlab-managed-apps uit te voeren. Zoek de app in de outputtabel en noteer de versie die wordt weergegeven in de CHART-kolom. Dit heeft de indeling app-naam-X.Y.Z; je hebt alleen het X.Y.Z-gedeelte nodig.

Keer terug naar uw nieuwe GitLab-project en open de helmfile.yaml die aan de toepassing is gekoppeld, zoals applications/ingress/helmfile.yaml. Wijzig het versieveld zodat het overeenkomt met de versie die u hebt genoteerd.

Vervang ten slotte de standaardwaarden.yaml door uw bestaande set Helm-waarden. Gebruik Helm om de YAML-weergave van het waardenbestand van uw app te laden:

helm get values ​​ingress -n gitlab-managed-apps -a –output yaml

Vervang ingress door de naam van de implementatie van uw app. Kopieer de volledige YAML-uitvoer en gebruik deze om het bestand applications/ingress/values.yaml te overschrijven. Zorg ervoor dat u het bestandspad aanpast aan uw app. Nu bent u klaar om de implementatie van het clusterbeheerproject uit te voeren.

 

Advertentie

Een implementatiepijplijn wordt automatisch gestart wanneer u uw wijzigingen samenvoegt met de standaardbranch (wat meestal het belangrijkste is voor nieuwe projecten in GitLab 14.0). Gebruik Git om uw wijzigingen vast te leggen en samen te voegen in:

git checkout -b mijn-tak git add . git commit -m “Bestaande door GitLab beheerde apps migreren” git checkout main git merge my-branch git push -u origin main

De pijplijn wordt uitgevoerd. Als de sjabloonwijzigingen correct waren, zou dit geen invloed moeten hebben op uw actieve toepassingen. Sommige onschadelijke metadata kunnen worden gewijzigd als het implementatiemechanisme verandert.

U bent nu klaar om het clusterbeheerproject te gebruiken voor het doorlopende onderhoud van uw apps. U kunt bijvoorbeeld updaten naar een nieuwe versie van een app door het versieveld in zijn helmfile.yaml te bewerken. Het samenvoegen van de wijziging in de main zou Helm ertoe aanzetten de wijzigingen binnen uw cluster toe te passen.

Conclusie

GitLab Managed Apps hielp veel gebruikers om hun eerste stappen met Kubernetes te zetten. De eenvoud van de functie bleek uiteindelijk echter te beperkend, dus wordt deze nu verwijderd in een proces dat uit meerdere stappen bestaat.

Gelukkig is het vrij eenvoudig om uw migratie te voltooien van beheerde apps. Er is niets bijzonders aan hen – het zijn gewoon reguliere Helm-implementaties die toevallig in de door gitlab beheerde-apps-naamruimte van uw cluster leven. Dit betekent dat uw workloads beschikbaar blijven, zelfs als u een upgrade naar GitLab 14.0 uitvoert, zodat u de vrijheid heeft om in uw eigen tempo over te stappen.

In de toekomst zijn clusterbeheerprojecten de voorkeursbenadering voor het gebruik van GitLab om populaire apps te installeren op Kubernetes. Hoewel dit model technisch wat veeleisender is, geeft het je veel meer controle en helpt het je om je infrastructuur als code te beheren.