Argo CD 3.5 pievieno tīmekļa saskarni ApplicationSet resursiem. Līdz šim tos varēja apskatīt gandrīz tikai YAML failos un kubectl komandrindā. Jaunā versija dod ApplicationSet sarakstu, resursu koku, izvelkamu detaļu paneli un atsevišķu cilni, kas jau pirms izvietošanas parāda, kādas lietotnes konkrētais ApplicationSet uztaisīs. Par izmaiņām raksta Argo projekts.
Argo CD ir GitOps rīks nepārtrauktai piegādei uz Kubernetes. Tas Kubernetes klasterī ietur tieši to stāvokli, kāds aprakstīts Git repozitorijā. Novirzes tas izlīdzina pats. ApplicationSet ir šī rīka daļa, kas no viena šablona uztaisa daudzas lietotnes uzreiz.
Stabilo 3.5 laidienu Argo projekts plāno 4. augustā. Šobrīd pieejams laidiena kandidāts. Līdz ar 3.5 pati ApplicationSet funkcija kļūst stabila un to drīkst izvietot jebkurā nosaukumtelpā. Agrāk tas darbojās vienīgi Argo CD nosaukumtelpā.
Ko dod ApplicationSet saskarne
ApplicationSet noder tur, kur viens un tas pats serviss jāizvieto daudzviet, piemēram, katrai komandai vai katram klasterim. Līdz šim šablona rezultātu redzēja tikai pēc tam, kad tas jau bija nostrādājis. Jaunajā saskarnē ir Preview Apps cilne, kas iepriekš parāda, kuras lietotnes šablons ģenerēs. Kļūdu šablonā tagad var pamanīt pirms izvietošanas.
Saraksts strādā tāpat kā ierastais Argo CD lietotņu saraksts. Ir teksta meklēšana pēc apakšvirknes, filtri, veselības apļa diagramma un pārslēdzami izkārtojumi. Katra lietotne, ko radījis ApplicationSet, tagad nes vecāka nozīmīti ar tā nosaukumu. Uz šīs nozīmītes var uzklikšķināt un nonākt pie vecāka resursa. Detaļas apraksta Argo CD dokumentācija.
Vecāka nozīmīte palīdz atkļūdošanā. Ja kāda no daudzajām ģenerētajām lietotnēm ir sarkanā veselības stāvoklī, no tās uzreiz var pāriet uz šablonu, kas to radīja. Agrāk šo saikni nācās meklēt pašrocīgi pa YAML failiem. Lielās vidēs, kur viens ApplicationSet uztur desmitiem lietotņu, tas ietaupa daudz laika.
ApplicationSet izvietošana jebkurā nosaukumtelpā nozīmē, ka katra komanda var uzturēt savus ApplicationSet resursus atsevišķi, bez piekļuves centrālajai Argo CD nosaukumtelpai.
Līdz šim daļa organizāciju ApplicationSet ražošanā izmantoja piesardzīgi, jo tas ilgi stāvēja aiz atsevišķa slēdža un mainījās no versijas uz versiju. Stabils statuss nozīmē, ka Argo projekts apņemas nelauzt tā uzvedību starp laidieniem. Kopā ar izvietošanu jebkurā nosaukumtelpā tas ļauj katrai komandai pašai pārvaldīt savus šablonus, bez centrālas platformas komandas kā vārtsarga.
Iekšējais mTLS un pirmkoda integritāte
Versija 3.5 pievelk drošības skrūves ap repo-server komponenti. Iekšējā saziņa starp Argo CD komponentēm tagad iet caur savstarpēju TLS. Ja klasterī nav savu sertifikātu, repo-server pats atmiņā uztaisa pašparakstītus sertifikātus, tāpēc failu sistēmā nekas nav jāglabā. Tas noņem vienu vietu, kur sertifikāti varētu noplūst.
Otra jaunā lieta ir pirmkoda integritātes pārbaude. Lietotnes specifikācijā var uzstādīt sourceIntegrity.required: true. Tad Argo CD pirms izvietošanas pārbauda Git revīzijas parakstu. Ja paraksta nav vai tas nesakrīt, manifests uz klasteri nenonāk. InfoQ šo iespēju apraksta kā veidu apturēt sabojātus manifestus, pirms tie kļūst par darbojošos infrastruktūru.
Kopā abas izmaiņas mērķē uz vienu risku: uzbrucēju, kas iespraužas starp Git un klasteri. Signatūras pārbaude bloķē viltotu kodu, bet iekšējais mTLS apgrūtina komponenšu saziņas noklausīšanos. Šā gada npm uzbrukumi caur pakotnēm parādīja, cik viegli sabojāts kods nonāk ražošanā, tāpēc parakstu pārbaude pirms izvietošanas top par ierastu soli.
Helm 4, impersonācija un Source Hydrator
Versija 3.5 pievieno atbalstu Helm 4 un turpina strādāt arī ar Helm 3. Divas iespējas pārcēlās no alfa uz beta statusu: impersonācija un Source Hydrator. Source Hydrator GitOps plūsmā atdala avota repozitoriju no izvietošanas repozitorija ar atsevišķiem drySource.repoURL un syncSource.repoURL laukiem. Tā komanda var glabāt manifestu avotu vienā vietā un ģenerēto rezultātu citā.
Impersonācija ļauj Argo CD izvietot manifestus ar konkrētu Kubernetes servisa kontu katram mērķim. Tā piekļuves tiesības nosaka pats klasteris, nevis viens Argo CD konts ar plašām tiesībām. ApplicationSet vienlaicīguma ierobežojumi savukārt ļauj noteikt, cik lietotņu šablons apstrādā vienā reizē, lai liels ApplicationSet nepārslogo kontrolleri.
Klāt nākusi arī Azure AD Graph API integrācija grupu pieprasījumu pārpildei un Azure DevOps Service Principal autentifikācija.
Kad un kā izmēģināt
Stabilā 3.5 versija gaidāma 4. augustā. Laidiena kandidātu jau tagad var likt testa klasterī. Kas jaunina no 3.4, tam vērts iepriekš izlasīt izmaiņu sarakstu, jo daļa noklusējumu mainās, sākot ar iekšējo mTLS starp komponentēm.
Argo CD 3.5 turpina 3.x sēriju. Kandidāta piezīmes un pilnu izmaiņu sarakstu Argo projekts publicē savā blogā. Testa vidē uzreiz redzams, vai iekšējais mTLS un parakstu pārbaude netraucē esošajām izvietošanas plūsmām.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.