A Docker, Jenkins, Kubernetes és hasonlók csak olyan cégnél használhatók igazán, ahol fejlesztés is folyik?

Jenkins az lényegében, ha nagyon leegyszerűsítjük egy lépés sorozat végrehajtó. De számos ilyen eszköz van még. Azure DevOps, GitLab-nak a CI-a és sorolhatnám. Ennek a szakiránynak a neve a DevOps vagy más néven CI/CD. Ezt a CI és a CD-t érdemes külön venni.

Míg a CI (Continous Integration) inkább:

- git-ről checkout-olja a kódot

- lebuildeli

- leteszteli (ennyi)

Míg a CD (Continous Delivery) inkább, ami a CI folytatása:

- az adott kódbázis állapotát verziózza

- kiteszi valamely repository/artifact-ba (pl. a docker image-t)

- ezzel a kitett image-el indít egy deploy-t egy adott környezeten

Persze ez a hivatalos modelje, de te határozod meg (sciptek által), hogy meddig menjen. Ha csak egy image-t akarsz, akkor odáig. Majd egy másik folyamaton (pipeline-on) meg kiteszed teszt környezetre vagy élesbe. Rajtad áll, konfiguráció függő.

Ezeknek a folyamatoknak van egy kelezője vagy vezérlője, ha úgy jobban tetszik. Számos rendszer létezik rá, pl. Jenkins is egy a sok közül. Persze minden ilyen terméknek meg van az előnye/hátránya. Én a munkám során Azure DevOps-ot használom, de házi projektben inkább a GitLab CI-át. Én személy szerint Jackins nélkül is jól megvagyok.

---

Kubernetes-t ha nagyon leakarom egyszerűsíteni, akkor az nem más mint docker container menedzser, saját DNS/Network/Ingress/LoadBalance rendszerrel több gépen futtatva clustert alkotva. A legkisebb egysége a POD, ami több docker image is foglalhat helyet (egymást localhost-on érik el). Minden POD kap egy IP-t a Kubernetes cluster-ben és egy DNS címet a POD nevéből, amit te adsz meg. Tehát, ha két különböző POD-ban van 1-1 image-t, akkor egy DNS névvel kell hivatkoznod a másikra. De a POD elhelyezkedését (hogy melyik szerveren fut), azt a Kubernetes dönti el a terhelés elosztás végett, amiről neked nem is kell tudni.

Továbbá támogatja a skálázást. Pl. tegyük fel 300MB vagy 5%-ot kapott a CPU-ból egy POD, akkor vegyük ezeket a POD szemszögéből 100%-nak. Tehát, ha kubernetes azt látja, hogy elérte a rendelkezésre állás 70%-át, akkor létrehoz még egy POD-ot ugyanazzal a beállítással. Ez majdnem olyan, mint ha 2 docker containert futtatnál ugyanazzal az image-el. Csak itt, ő kezeli network szinten is, hogy csak 1 portot mutat kifele (vagy csak belülre, de külvilágnak nem), és majd a LoadBalance eldönti, hogy mely fele menjen tovább a kérés. Mindezt automatikusan a beállítás függvényében teszi. Ha ezek után nincs már terhelés, akkor a feleslegessé vált POD-okat eldobja.

Persze számos más jó feature-je van még.

---

Ezeket én első sorban Udemy-n tanultam. Másodsorban youtube és dokumentáció.

A munkafolyamat az, hogy csapatban fejlesztünk, akkor készítünk egy új branch-et git-ben, ahol fejlesztem a saját részem elkülönülve a többiektől. Mikor végzek, készítek egy git commit-ot amit felpusholok.

Ezt észreveszi a CI, és elkezdi buildelni, tesztelni. Ha minden sikeres, ad rá egy zöld pipát. Közben készítek egy PullRequest-et vagy MergeRequest-et (mikor hol hogyan hívják), hogy ez készen áll bekerülni a main, master, next-be (mikor melyikbe).

Nyilván úgy biztonságos, hogy más is átnézi a kódot. Így a reviewer kolléga látja, hogy minden általam írt teszt átment és buildelhető is a kód. Akkor elkezdi átnézni, hogy ő mit vesz észre, amit én nem. Persze, fordított szerep is van, mikor én kapok mástól PullRequest-tet.

(A CI-on történő információk magasabb rendűek, mert hiába lefut a gépemen, de ha CI-on nem, akkor az nem stabil és valami van. Végtére is a szerveren is el kell indulnia.)

Ha a módosítás bekerül a fő branch-be (merge), akkor a CI ismét lefut azon a fő branch-en, hogy úgy is életképes-e a kód, vagy eltört-e valami. Ha átmegy, akkor érdemes adni neki egy verziót git tag-ek által pl. Vagy egy fájlt írva. Ez részlet kérdés. Majd a fő branch állapotából érdemes készíteni egy image-t amit a CI feltölt az artifact-ba. (Hogy mi az artifact providere, az is részlet kérdés. Van a Frog Artifact, de a GitLab is tud ilyet.)

Mikor úgy döntünk, hogy akkor nézzük meg, hogyan muzsikál a kód (vagy microservice esetén több kódbázis egymással) akkor deployolunk. Nyilván tudni kell mely verziót kell kitenni, szóval az adott verzióbal. Szóval a CI-t megfuttatjuk egy másik lépés sorral, ami triggerel más rendszereket (akár bash scriptek által).

Most, hogy ez a CI lépés script-je Kubernetes-t piszkál vagy Ansible-t parancsokat kezd el tolni, az részlet kérdés. Lényeg, hogy egy gombnyomásra egy rendszeres rutin feladatot megcsináljon.

Amit felvázoltam fentebb ez egy megvalósítás a végtelen + 1-ből.

De tömören a rutin és mindig ugyanazon folyamatok kiváltására szolgál a CI/CD. Meg ha 200 helyen kellene átírni a verziót, akkor nem marad ki egy helyen se. Így nincs emberi hiba se, max a script hibás.

"Építsek otthon egy komplett infrastruktúrát a gyakorláshoz?"

Lényegében igen. :) De nem kell nagyra gondolni. Ha pl. GitLab ingyenes verzióját letöltöd és feltelepíted egy VM-be akár saját gépen GitLab Runner-rel, és nagy Kubernetes helyett a Minikube-t használod (egy node-os kubernetes) akkor már kb. kész is vagy az alap szoftware telepítésekkel gyakorlásra. Már csak konfigurálni kell.

- GitLab Runner-t (vagy ha több van a Runnereket) a GitLab-ra kell authentikálni. Ez lényegében egy step-by-step

- Kubernetes-t esetünkben a Minikube-ot el kell indítani. Ez hoz magával egy cli-t is, szóval külsőleg tudod vezérelni.

- GitLab-van indítasz egy projektet és készítesz egy .gitlab-ci.yml fájlt (ez a CI config), ami minden push-kor elkezd lefutni. GitLab dokumentációban látsz leírást.

Oroszlán része a CI folyamat megalkotása lesz. :) Képzeld el úgy, hogy minden CI lépés egy külön docker containert hoz létre, és abban végzi el az adott feladatot és eldobja. Majd megy a következőre és újra felépíti, lefuttatja amit le kell, majd eldobja. Szóval, a cache-elés sokat tud segíteni. :)

De GitLab CI helyett csinálhatod Jenkins-el is akár.

---

Gyakorlásban:

- GitLab ingyenes on-premise tökéletes, én is ezt használom

- Jenkins ingyenes

- Kubernetes egy-az-egyben full ingyenes

"Szeretném megtanulni a fent írt technológiákat is, de egyszerűen a munkám során semmi szükség rájuk."

Üzemeltetőként is hasznát tudod venni a konténerizácónak (Docker) és annak menedzselésének (Kubernetes).

Ha van egy fizikai géped és azon különböző szolgáltatásokat akarsz kiszolgálni - teszem azt: tartományvezérlőt, DNS-, nyomtató-, fax-, lapolvasó-, VOIP-, fájl-, Intranetes alkalmazásszervert, stb... - akkor ezeket el tudod egymástól szeparálni, így egy esetleges, az adott szolgáltatást érintő biztonsági incidens esetén a többi szolgáltatás kevésbé lesz kitéve veszélynek; másrészt a szolgáltatások frissítése egymástól függetlenítve végrehajtható; harmadrészt egy új szolgáltatás bevezetése könnyebbé válik, nem függ (annyira) a többi szolgáltatás futásától.