GitLab Managed Apps var en funktion i plattformens Kubernetes-integration som tillhandahöll installation med ett klick av vanliga klusterappar. Denna iteration av funktionen upphörde att gälla under GitLab 13-släppcykeln och togs bort helt i juni 14.0-släpp. Så här migrerar du dina hanterade appar till en distributionsmodell som stöds.
Flytta bort från hanterade appar
Managed Appar utvecklades som ett sätt att förenkla att komma igång med ett nytt Kubernetes-kluster. GitLab tillhandahöll mallar för applikationer som NGINX Ingress, Cert Manager och Prometheus.
Två olika installationsmetoder erbjöds: ett klick och CI/CD. Metoden med ett klick gav ett användargränssnitt inom GitLab som listade tillgängliga appar och låter dig klicka för att installera. Vissa appar exponerade också grundläggande konfigurationsinställningar. CI/CD-metoden erbjöd en GitLab CI-mall för att lägga till appar i ett kluster som en del av en pipeline.
Installationer med ett klick är nu helt borta. CI-metoden förblir funktionell men utfas och kommer att tas bort i GitLab 15.0. Även om Managed Apps drastiskt förenklade installationen, tog de bara hand om det här steget i klustrets livscykel. Appar installerades eller avinstallerades, så du måste snabbt flytta till vanliga Kubernetes-hanteringsverktyg för att utföra underhåll och anpassning.
Trots funktionens borttagning fortsätter befintliga installerade hanterade appinstallationer att fungera i GitLab 14.0. Du kan säkert uppgradera GitLab utan att oroa dig för stillestånd i ditt kluster. Uppgraderingen tar dock bort användargränssnittet för hanterade appar så att du inte kan se eller avinstallera appar från GitLab.
Få kontroll över din Appar
Att migrera bort från hanterade appar kräver inte nödvändigtvis någon omedelbar åtgärd från din sida. Eftersom dina appar kommer att förbli i drift kan du lämna dem som de är om du är nöjd med att de stannar i namnområdet för gitlab-hanterade appar.
Annons
Eftersom apparna helt enkelt är Helm distributioner i ditt kluster kan du hantera dem med kommandoradsbinarierna kubectl och Helm. De kommer att visas som vanliga Kubernetes-resurser.
Du kan lista klusterresurser som installerades av GitLab med det här Kubectl-kommandot:
kubectl få alla -n gitlab-managed-apps
Detta låter dig kontrollera vad som körs i ditt kluster i frånvaro av GitLabs gamla & # 8220; applikationer & # 8221; sida.
Du kan stöta på problem med appar installerade av gamla GitLab-versioner. Dessa kan ha lagts till med hjälp av Helm v2, som inte är kompatibel med moderna Helm v3-klienter. Om du inte är säker på om du har v2-appar installerade, använd följande kommando för att kontrollera:
kubectl hämta alla -n gitlab-managed-apps | grep 'helm.sh/release'
Appar som visas visas i kommandot utdata installerades av Helm v3. Jämför listan med tidigare get all-kommandot för att identifiera appar som lagts till av Helm v2.
Annons
Om det visar sig att dina appar använder Helm v2 måste du gå igenom Helm-migrationsguiden manuellt för att uppdatera dem. Det rekommenderas att du flyttar till Helm v3 om du behåller apparna på lång sikt. Som ett alternativ kan du installera Helm v2 på din dator så att du kan interagera med apparna för att tillämpa omedelbara korrigeringar och underhåll.
Uppgradering till GitLabs nya klusterappsmodell
Det övergripande målet för hanterade appar & # 8211; förenkla klusterinstallationen & # 8211; har inte kastats åt sidan av GitLab. GitLab 14.0 fokuserar på kluster & # 8220; hanteringsprojekt & # 8221; som en ny distributionsmodell för klusterprovisionering.
GitLab tillhandahåller en projektmall som du kan använda för att installera appar i Kubernetes-kluster. Detta åtgärdar de ursprungliga problemen med Managed Apps genom att se till att du har full kontroll över Helm-diagrammen som distribueras. Du klonar mallen, ansluter projektet till ditt kluster och redigerar och tar bort de enskilda appdiagrammen efter behov. Att köra en CI-pipeline distribuerar de valda apparna till ditt kluster.
Du kan migrera befintliga hanterade appar till hanteringsprojektformatet. Detta låter dig fortsätta använda dem med ett GitLab-godkänt tillvägagångssätt. Vi antar att du redan har ett Kubernetes-kluster anslutet till din GitLab-instans på grund av dina befintliga distributioner.
Börja med att skapa ett nytt GitLab-projekt med hjälp av plusknappen längst upp till höger. Klicka på & # 8220; Skapa från mall & # 8221 ;, bläddra sedan ner till & # 8220; GitLab Cluster Management & # 8221; mall. Klicka på & # 8220; Använd mallen & # 8221; knapp. På nästa skärm, ge ditt projekt ett namn och tryck på & # 8220; Skapa projekt. & # 8221;
Mallen tillhandahåller en serie hjälmdiagram för att distribuera appar i ditt kluster. De enskilda appdiagrammen lagras i applikationskatalogen. Varje app får sin egen underkatalog. #
Annons
Börja med att redigera helmfile.yaml i roten till ditt projekt, antingen i GitLab Web IDE eller genom att klona förvaret med Git. Den här filen refererar till de enskilda applikationsmallarna. Aktivera de applikationer som du använder genom att avmarkera relevanta rader. I det här exemplet har vi tidigare installerat Ingress och Cert Manager som GitLab Managed Apps, så vi aktiverar dem i klusterhanteringsprojektet.
Därefter måste du räkna ut vilken diagramversion som redan har distribuerats till ditt kluster. Det här steget är viktigt så att du inte oavsiktligt byter ut din app med en annan version.
Du kan få en appversion genom att köra rodret ls -n gitlab-managed-apps. Leta efter appen i utdatatabellen och anteckna den version som visas i kolumnen CHART. Detta tar formatet app-name-X.Y.Z; du behöver bara X.Y.Z-delen.
Gå tillbaka till ditt nya GitLab-projekt och öppna helmfile.yaml som är associerad med applikationen, till exempel applikationer/ingress/helmfile.yaml. Ändra versionsfältet så att det matchar den version du noterade.
Slutligen ersätt standardvärdena.yaml med din befintliga uppsättning hjälmvärden. Använd Helm för att ladda YAML-representationen av appens värden:
helm få värden ingång -n gitlab-managed-apps -a –output yaml
Ersätt inträde med namnet på din apps distribution. Kopiera hela YAML-utgången och använd den för att skriva över filen applikationer/ingress/values.yaml. Se till att justera filvägen så att den matchar din app. Nu är du redo att köra klusterhanteringsprojektdistributionen.
& nbsp;
Annons
En distributionsrörledning startar automatiskt när du slår samman dina ändringar till standardgrenen (som vanligtvis är viktigast för nya projekt i GitLab 14.0). Använd Git för att göra dina ändringar och slå ihop dem i:
git checkout -b my-branch git add. git commit -m “Migrera befintliga GitLab-hanterade appar” git checkout main git merge my-branch git push -u origin main
Rörledningen körs. Om malländringarna var korrekta borde det inte ha någon inverkan på dina program som körs. Vissa ofarliga metadata kan ändras när distributionsmekanismen ändras.
Du är nu redo att använda klusterhanteringsprojektet för det löpande underhållet av dina appar. Som ett exempel kan du uppdatera till en ny version av en app genom att redigera versionsfältet i dess helmfile.yaml. Att slå samman ändringen till huvud skulle uppmana Helm att tillämpa ändringarna i ditt kluster.
Slutsats
GitLab Managed Apps hjälpte många användare att ta sina första steg med Kubernetes. Funktionens enkelhet visade sig i slutändan för begränsande, så det tas nu bort i en flerstegsprocess.
Lyckligtvis är det ganska enkelt att slutföra din migrering bort från hanterade appar. Det finns inget speciellt med dem & # 8211; de är helt enkelt vanliga hjälmdistributioner som råkar bo i ditt klustras namnområde för gitlab-hanterade appar. Detta innebär att dina arbetsbelastningar förblir tillgängliga även om du uppgraderar till GitLab 14.0, vilket ger dig fri övergång i din egen takt.
Framåt är klusterhanteringsprojekt det bästa sättet att använda GitLab för att installera populära appar på Kubernetes. Även om det är lite mer tekniskt krävande, ger den här modellen dig mycket mer kontroll och hjälper dig att hantera din infrastruktur som kod.