Koszonom az eszreveteleket. Nehany dologra reagalnek. :)
A tektonnak azon a clusteren kell futni ahol szeretnenk hasznalni termeszetesen. Alapvetoen ez semmiben nem kulonbozik egy gitlab megoldastol. Ha a gitlabot szeretned integralni a k8s clusterrel, ott is futni kell egy agentnek a clusteren. (Persze fapados modon is megoldhatod ezeket a dolgokat, hogy k8s api-n keresztul deployolod az alkalmazasokat, ha CD rol beszelunk. De pl. ha a runnereket a k8sen inditod, kell neki kulon deployment)
Szerintem erdemes kette bontani a CI/CD feladatokat. Alapvetoen szo volt a dev/staging/prod clusterekrol. En itt meg a felsorolasba oda dobnam a build clustert is, mert ugy van ertelme. Build clusteren vegezzuk a build feladatokat, ez se nagyon kulonbozik a gitlab es egyeb CI megoldastol, ott runnereket futtatunk, itt annyiban van kulonbseg, hogy a build folyamat egy namespace-ben fut escalalva egy kulon clusteren es nem egy kulon gepen egy runner segitsegevel. Persze ez overkill egy bizonyos build szam alatt.
CD feladatok lenyegeben a dev/staging/prod kornyezetekben vannak, ott mar a lebuildet kesz alkalmazast kell kitenni, amihez nem feltetlenul kell a tekton neked.
A kovetkezo kerdesedet nem tudom ertelmezni @asm: Devbol deployoljunk a Prodra?
Vegyunk egy peldat, van egy alkalmazasod, amit fejlesztenek. Egy commit hatasara elindul a build folyamat. A build folyamat soran kiesik a vegtermek (build clusteren). Lesz mondjuk egy microservice imaged es egy hozza tartozo helm chartod, amit a megfelelo repoba megtalalsz. (Ez volt a build folyamat)
Dev clusterre ki szeretned tenni ezt a microservicet, neked nincs masra szukseged mint a helm chart verziora. Erre irsz egy taskot, amit sok fele keppen triggerelhetsz. Szoval te a tasknak a kovetkezo parametereket adod. Helm chart neve, verzioja, meg mondjuk hogy melyik ns-be telepuljon ki a az alkalmazasod, itt a pipeline tartalmazhat egyeb dolgokat, de most csak foglalkozzunk a deploy feladattal.
Ezt a taskot a tobbi clusterre is kiteszed es ha prodra akarod kitenni a megfelelo verziot megirod ra a megfelelo triggert. Most hogy ez egy commit, vagy egy api post vagy akar egy piros gomb megnyomasa az mar mindegy.
Es termeszetesen a triggerek lehetnek push vagy pull iranyuak. Itt mar csak az a kerdes a security mit enged meg.
Egyebkent abban egyet ertek hogy mondjuk a gitlabbal is ugyan ezt meg lehet oldani, es ez se egy mindenre jo megoldas.
Mi ahol hasznaljuk, a cluster kozeli folyamatokat automatizaljuk ezzel az eszkozzel. Gondolok itt, ns letrehozas es a hozza tartozo integraciok beallitasa, ami 30-40 lepesbol all. Az elodje a folyamatnak gitlab volt, viszont sok cluster kozeli dolog kezeleset egyszerubb volt megoldani tektonnal.