Mi, a True Engineeringnél beállítottunk egy folyamatot a frissítések folyamatos eljuttatására az ügyfelek szervereire, és szeretnénk megosztani ezt a tapasztalatot.
Először is kifejlesztettünk egy online rendszert az ügyfél számára, és bevezettük a saját Kubernetes-fürtünkbe. Mostanra a nagy terhelésű megoldásunk átkerült az ügyfél platformjára, amelyhez egy teljesen automatikus Folyamatos Telepítési folyamatot állítottunk be. Ennek köszönhetően felgyorsítottuk a piacra jutás idejét – a termékkörnyezet változásainak átadását.
Ebben a cikkben a Continuous Deployment (CD) folyamat összes szakaszáról fogunk beszélni, vagy a frissítések kézbesítéséről az ügyfél platformjára:
- Hogyan kezdődik ez a folyamat?
- szinkronizálás az ügyfél Git tárházával,
- a háttér és a frontend összeszerelése,
- automatikus alkalmazástelepítés tesztkörnyezetben,
- automatikus üzembe helyezés Prod.
Útközben megosztjuk a beállítás részleteit.
1. Indítsa el a CD-t
A folyamatos üzembe helyezés azzal kezdődik, hogy a fejlesztő változtatásokat hajt végre a Git-tárházunk kiadási ágán.
Alkalmazásunk mikroszolgáltatási architektúrán fut, és minden összetevője egy tárolóban van tárolva. Ennek köszönhetően minden mikroszolgáltatás összegyűjtésre és telepítésre kerül, még akkor is, ha az egyik megváltozott.
Több okból is megszerveztük a munkát egy adattáron keresztül:
- Könnyű fejlesztés - az alkalmazás aktívan fejlődik, így egyszerre dolgozhat az összes kóddal.
- Egyetlen CI/CD-folyamat, amely garantálja, hogy az alkalmazás egyetlen rendszerként megfeleljen az összes teszten, és az ügyfél termelési környezetébe kerüljön.
- Kiküszöböljük a zavart a verziókban – nem kell tárolnunk a mikroszolgáltatás-verziók térképét, és nem kell leírnunk a konfigurációját minden egyes mikroszolgáltatáshoz Helm-szkriptekben.
2. Szinkronizálás az ügyfél forráskódjának Git tárházával
A végrehajtott változtatások automatikusan szinkronizálódnak az ügyfél Git-tárházával. Ott konfigurálják az alkalmazás-összeállítást, amely az ág frissítése után elindul, és a telepítés a folytatáshoz. Mindkét folyamat a környezetéből származik egy Git tárolóból.
Nem tudunk közvetlenül együttműködni az ügyfél adattárával, mert saját környezetre van szükségünk a fejlesztéshez és teszteléshez. Erre a célra a Git-tárunkat használjuk – szinkronizálva van a Git-tárházukkal. Amint egy fejlesztő változtatásokat tesz közzé adattárunk megfelelő ágában, a GitLab azonnal eljuttatja ezeket az ügyfelekhez.
Ezt követően el kell végezni az összeszerelést. Ez több szakaszból áll: backend és frontend összeszerelés, tesztelés és gyártásba szállítás.
3. A háttér és a frontend összeállítása
A háttér és a frontend felépítése két párhuzamos feladat, amelyeket a GitLab Runner rendszerben hajtanak végre. Az eredeti összeállítási konfiguráció ugyanabban a tárolóban található.
.
A GitLab Runner kiveszi a kódot a szükséges tárolóból, összeállítja azt a Java Application build paranccsal, és elküldi a Docker registry-nek. Itt összeállítjuk a hátteret és a frontendet, beszerezzük a Docker-képeket, amelyeket az ügyfél oldalán egy tárba helyezünk. Az általunk használt Docker-képek kezelésére .
Képeink verzióit szinkronizáljuk a Dockerben megjelenő kiadási verzióval. A zökkenőmentes működés érdekében számos beállítást hajtottunk végre:
1. A tárolók nem épülnek újra a tesztkörnyezet és az éles környezet között. A paraméterezéseket úgy végeztük, hogy ugyanaz a konténer minden beállítással, környezeti változóval és szolgáltatással működjön mind a tesztkörnyezetben, mind az éles környezetben, átépítés nélkül.
2. Egy alkalmazás Helmen keresztüli frissítéséhez meg kell adnia annak verzióját. Mi felépítjük a háttérrendszert, a frontendet és frissítjük az alkalmazást – ez három különböző feladat, ezért fontos, hogy mindenhol ugyanazt az alkalmazásverziót használjuk. Ehhez a feladathoz a Git előzményeiből származó adatokat használjuk, mivel a K8S-fürt konfigurációja és alkalmazásai ugyanabban a Git-lerakatban vannak.
Az alkalmazás verzióját a parancsvégrehajtási eredményekből kapjuk meg
git describe --tags --abbrev=7.
4. A tesztkörnyezet (UAT) összes módosításának automatikus telepítése
Az összeállítási szkript következő lépése a K8S-fürt automatikus frissítése. Ez akkor történik meg, ha a teljes alkalmazást elkészítették, és az összes mellékterméket közzétették a Docker Registry-ben. Ezt követően elindul a tesztkörnyezet frissítése.
Elindul a fürtfrissítés . Ha ennek eredményeként valami nem a tervek szerint ment, a Helm automatikusan és függetlenül visszaállítja az összes változtatást. A munkáját nem kell ellenőrizni.
A K8S fürtkonfigurációt az összeállítással együtt szállítjuk. Ezért a következő lépés a frissítés: configMaps, telepítések, szolgáltatások, titkok és minden más K8S konfiguráció, amelyet megváltoztattunk.
A Helm ezután magának az alkalmazásnak a RollOut frissítését futtatja a tesztkörnyezetben. Az alkalmazás éles üzembe helyezése előtt. Ez azért történik, hogy a felhasználók manuálisan tesztelhessék a tesztkörnyezetbe helyezett üzleti funkciókat.
5. A Prod összes módosításának automatikus telepítése
Ha frissítést szeretne telepíteni az éles környezetbe, csak egy gombra kell kattintania a GitLab-ban – és a tárolók azonnal az éles környezetbe kerülnek.
Ugyanaz az alkalmazás különböző – tesztelési és éles – környezetekben is működhet újraépítés nélkül. Ugyanazokat a melléktermékeket használjuk anélkül, hogy bármit is változtatnánk az alkalmazásban, a paramétereket pedig kívülről állítjuk be.
Az alkalmazásbeállítások rugalmas paraméterezése attól függ, hogy az alkalmazás milyen környezetben kerül végrehajtásra. Az összes környezeti beállítást kívülről helyeztük át: minden a K8S konfiguráción és a Helm paramétereken keresztül van paraméterezve. Amikor a Helm telepít egy összeállítást a tesztkörnyezetbe, a tesztbeállítások alkalmazásra kerülnek, a termékbeállítások pedig az éles környezetre.
A legnehezebb volt az összes használt szolgáltatás és környezettől függő változó paraméterezése és környezeti változókká és környezeti paraméterek leírása-konfigurációivá fordítása a Helm számára.
Az alkalmazásbeállítások környezeti változókat használnak. Értékeiket tárolókban állítják be a K8S configmap segítségével, amely Go-sablonokkal van kialakítva. Például egy környezeti változót a tartománynévhez a következőképpen állíthat be:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – ez a változó tárolja a környezet nevét (prod, stage, UAT).
.Values.app.properties.app_external_domain – ebben a változóban állítjuk be a kívánt tartományt a .Values.yaml fájlban
Egy alkalmazás frissítésekor a Helm létrehoz egy configmap.yaml fájlt a sablonokból, és kitölti az APP_EXTERNAL_DOMAIN értéket a kívánt értékkel attól függően, hogy az alkalmazásfrissítés milyen környezetben indul. Ez a változó már be van állítva a tárolóban. Az alkalmazásból érhető el, így minden alkalmazási környezet más értéket fog kapni ehhez a változóhoz.
Viszonylag nemrégiben jelent meg a K8S támogatása a Spring Cloudban, beleértve a configMaps-szel való munkát is: . Miközben a projekt aktívan fejlődik és gyökeresen változik, a termelésben nem tudjuk felhasználni. De aktívan figyeljük állapotát, és DEV konfigurációkban használjuk. Amint stabilizálódik, a környezeti változók használatáról áttérünk rá.
Összességében
Tehát a folyamatos üzembe helyezés be van állítva és működik. Minden frissítés egyetlen gombnyomással történik. A termékkörnyezet módosításainak kézbesítése automatikus. És ami fontos, a frissítések nem állítják meg a rendszert.
Jövőbeli tervek: automatikus adatbázis-migráció
Gondolkodtunk az adatbázis frissítésén és a változtatások visszaállításának lehetőségén. Hiszen az alkalmazás két különböző verziója fut egyszerre: a régi fut, és az új. A régit pedig csak akkor kapcsoljuk ki, ha biztosak vagyunk benne, hogy az új verzió működik. Az adatbázis-áttelepítésnek lehetővé kell tennie az alkalmazás mindkét verziójával való munkát.
Ezért nem tudjuk egyszerűen megváltoztatni az oszlop nevét vagy más adatokat. De létrehozhatunk egy új oszlopot, másolhatunk bele adatokat a régi oszlopból, és írhatunk triggereket, amelyek az adatok frissítésekor egyidejűleg másolják és frissítik egy másik oszlopban. Az alkalmazás új verziójának sikeres telepítése után pedig az indítás utáni támogatási időszak után törölhetjük a régi oszlopot és a feleslegessé vált triggert.
Ha az alkalmazás új verziója nem működik megfelelően, visszaléphetünk az előző verzióra, beleértve az adatbázis előző verzióját is. Röviden, változtatásaink lehetővé teszik, hogy az alkalmazás több verziójával egyidejűleg dolgozzon.
Tervezzük az adatbázis-migráció automatizálását K8S jobon keresztül, integrálva a CD folyamatba. És ezt az élményt mindenképpen meg fogjuk osztani a Habrén.
Forrás: will.com