A True Engineering-nél beállítottuk a folyamatos frissítési folyamatot a megrendelő szerverein, és szeretnénk megosztani ezt a tapasztalatot.
Kezdetnek kidolgoztunk egy online rendszert a megrendelő számára, és telepítettük azt a saját Kubernetes klaszterükbe. Most a nagy terhelésű megoldásunk átköltözött a megrendelő platformjára, amelyhez teljesen automatikus folyamatos telepítési folyamatot állítottunk be. Ennek köszönhetően felgyorsítottuk a time-to-market-t, azaz a változtatások bevezetését a termék környezetébe.
Ebben a cikkben bemutatjuk a folyamatos telepítési (CD) folyamat minden lépését, vagyis az frissítések megrendelő platformjára való szállítását:
- hogyan indul ez a folyamat,
- a megrendelő Git-tárhelyével való szinkronizálás,
- a backend és frontend összegyűjtése,
- alkalmazás automatikus telepítése a tesztkörnyezetbe,
- automatikus telepítés a Prod-ba.
A folyamat során megosztjuk a beállítás részleteit.
1. CD Indítás
A folyamatos telepítés azzal kezdődik, hogy a fejlesztő a változtatásokat a Git-tárhelyünk kiadási ágába helyezi.
Alkalmazásunk mikroszerviz architektúrára épül, és összes összetevője egyetlen tárhelyen található. Ennek köszönhetően az összes mikroszerviz összegyűjtésre és telepítésre kerül, még akkor is, ha az egyik megváltozik.
Több okból is ezen az egy tárhelyen szerveztük a munkát:
- A fejlesztés kényelme – az alkalmazás aktívan fejlődik, így az egész kóddal egyszerre lehet dolgozni.
- Egyetlen CI/CD pipeline, amely garantálja, hogy az alkalmazás mint egy egységes rendszer végigmegy minden teszten és a megrendelő prod-környezetébe kerül.
- Kizárja a verziókkal kapcsolatos zűrzavart – nem kell verziótérképet tárolnunk a mikroszervizekhez, és minden mikroszervizhez külön konfigurációt leírnunk Helm szkriptekben.
2. Szinkronizálás a megrendelő forráskódjára vonatkozó Git-tárhelyével
A végrehajtott változtatások automatikusan szinkronizálódnak a megrendelő Git-tárhelyével. Ott be van állítva az alkalmazás gyűjtése, amely a ág frissítése után indul el, és a telepítés a prod-ba. Mindkét folyamat az ő környezetükben történik a Git-tárhelyből.
Közvetlenül nem tudunk együttműködni az ügyfél tárolójával, mivel a saját fejlesztési és tesztelési környezetünkre van szükségünk. Ezekhez a célokhoz saját Git-tárolónkat használjuk, amely szinkronizálva van az ő Git-tárolójukhoz. Amint a fejlesztő közzéteszi a változtatásokat a tárolónk megfelelő ágában, a GitLab azonnal továbbítja ezeket a változtatásokat az ügyfélnek.
Ezután le kell folytatni a buildet. Ez több szakaszból áll: a backend és a frontend buildje, tesztelés és a produkcióba való szállítás.
3. A backend és a frontend buildje
A backend és a frontend buildje két párhuzamos feladat, amelyeket a GitLab Runner rendszerében végeznek. Az alap build konfigurációja ugyanabban a tárolóban található.
.
A GitLab Runner letölti a kódot a szükséges tárolóból, majd a Java alkalmazás build parancsával összegyűjti és elküldi a Docker registrybe. Itt a backend és a frontend buildjét végezzük, Docker-képeket kapunk, amelyeket az ügyfél oldalán lévő tárolóba helyezünk. A Docker-képek kezelésére .
A képeink verzióját a Dockerbe kiadott verzióval szinkronizáljuk. A zavartalan működés érdekében néhány beállítást végeztünk el:
1. A tesztkörnyezet és a termelési környezet között a konténereket nem építjük újra. Parametrizálásokat végeztünk, hogy ugyanaz a konténer újraépítés nélkül működjön minden beállítással, környezeti változókkal és szolgáltatásokkal, mind a tesztkörnyezetben, mind a produkciós környezetben.
2. Az alkalmazás frissítése a Helmen keresztül a verzió megadását igényli. A backend, a frontend buildje és az alkalmazás frissítése három külön feladat, ezért fontos, hogy mindenhol ugyanazt az alkalmazásverziót használjuk. Ehhez az adatokat a Git-történelemből nyerjük, mivel a K8S klaszter és az alkalmazás konfigurációja ugyanabban a Git-tárolóban található.
Az alkalmazás verzióját a parancs végrehajtásának eredményéből nyerjük ki
git describe --tags --abbrev=7.
4. Minden változás automatikus telepítése a tesztkörnyezetbe (UAT)
A build script következő szakaszában az K8S klaszter automatikus frissítése történik. Ez akkor történik, ha az alkalmazás teljesen felépült, és minden artefaktum közzé lett téve a Docker Registryben. Ezt követően elindul a tesztkörnyezet frissítése.
A klaszter frissítése az alábbi parancs segítségével történik . Ha valami nem a tervek szerint alakul, a Helm automatikusan és önállóan visszaállítja az összes változtatását. Munkájának figyelemmel kísérése nem szükséges.
A K8S klaszter konfigurációját a csomaggal együtt biztosítjuk. Ezért a következő lépés a konfiguráció frissítése: configMaps, deployok, szolgáltatások, titkok és bármely más K8S konfiguráció, amit megváltoztattunk.
Ezután a Helm elindítja az alkalmazás RollOut frissítését a tesztkörnyezetben, mielőtt az alkalmazást éles környezetben telepítenék. Ezt azért tesszük, hogy a felhasználók manuálisan ellenőrizhessék a tesztkörnyezetbe tett üzleti funkciókat.
5. Minden változtatás automatikus telepítése a Prod környezetbe
A frissítés éles környezetbe való telepítéséhez csak egy gombot kell megnyomni a GitLabban — és a konténerek azonnal a termelési környezetbe kerülnek.
Ugyanaz az alkalmazás újraépítés nélkül működhet különböző környezetekben — teszt és éles. Ugyanazokat az artefaktumokat használjuk, anélkül, hogy bármit is megváltoztatnánk az alkalmazáson, a paramétereket pedig kívülről állítjuk be.
Az alkalmazás beállításainak rugalmas paraméterezése attól függ, hogy az alkalmazás milyen környezetben fut. Minden környezeti beállítást kiemeltünk: az összes paraméter a K8S konfiguráción és a Helm paramétereken keresztül van paraméterezve. Amikor a Helm telepíti a csomagot a tesztkörnyezetbe, a tesztparamétereket alkalmazza, éles környezetben pedig az éles paramétereket.
A legnehezebb az volt, hogy paraméterezni tudjuk az összes használt szolgáltatást és változót, amelyek a környezettől függenek, és átalakítsuk őket környezeti változókká és konfigurációs leírásokká a Helm számára.
Az alkalmazás paramétereiben környezeti változókat használunk. Ezek értékeit a K8S configmap segítségével adjuk meg a konténerekben, amelyet Go sablonokkal sablonosítunk. Például a környezeti változó beállítása a domain nevére így lehetséges:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – ebben a változóban tároljuk a környezet nevét (prod, stage, UAT).
.Values.app.properties.app_external_domain – ebben a változóban a .Values.yaml fájlban határozzuk meg a kívánt domaint
A Helm frissítésekor a Helm sablonokból hozza létre a configmap.yaml fájlt, és kitölti az APP_EXTERNAL_DOMAIN értékét a megfelelő értékkel az adott környezettől függően, ahol a frissítést végrehajtják. Ezt a változót már a konténerben állítják be. Az alkalmazásból hozzáférhető, így az egyes környezetekben ennek a változónak más-más értéke lesz.
A közelmúltban a Spring Cloudban megjelent a K8S támogatás, beleértve a configMap-ek kezelését is: . Mivel a projekt aktívan fejlődik és alapvetően megváltozik, nem használhatjuk élesben. De folyamatosan figyelemmel kísérjük az állapotát és használjuk DEV konfigurációkban. Amint stabilizálódik, átállunk az környezeti változók használatáról rá.
Összesen
Tehát, a Continuous Deployment be van állítva és működik. Minden frissítés egyetlen gombnyomásra történik. A változások automatikusan kerülnek be a termelési környezetbe. És ami fontos, a frissítések nem állítják le a rendszer működését.
Jövőbeli tervek: automatikus adatbázis-migráció
Gondolkodtunk az adatbázis frissítéséről és a változások visszaállításának lehetőségéről. Hiszen egyszerre két különböző verzió működik: a régi verzió fut, míg az új verzió telepítés alatt áll. A régit csak akkor kapcsoljuk ki, amikor meggyőződünk arról, hogy az új verzió működik. Az adatbázis-migrációnak lehetővé kell tennie, hogy mindkét alkalmazásverzióval dolgozhassunk.
Ezért nem tudunk csak úgy módosítani egy oszlop vagy más adatok nevét. De létrehozhatunk egy új oszlopot, átmásolhatjuk az adatokat a régi oszlopból, és írhatsz trigger-eket, amelyek az adatok frissítésekor egyidejűleg átmásolják és frissítik azokat a másik oszlopban. És a új verzió sikeres telepítése után, a post launch support időszak után eltávolíthatjuk a régi oszlopot és a szükségtelenné vált triggert.
Ha az új verzió nem működik helyesen, visszaállhatunk a korábbi verzióra, beleértve az előző adatbázisverziót is. Szóval, a változtatásaink lehetővé teszik, hogy egyszerre több verzióval dolgozzunk.
Tervezünk egy automatizált adatbázis-migrációs folyamatot K8S job-on keresztül, amelyet beépítünk a CD folyamatába. És mindenképpen megosztjuk ezt a tapasztalatot a Hubon.
Forrás: habr.com
