Technikai igazgatónk legutóbbi beszédei alapján publikációkkal indítjuk blogunkat (Dmitrij Sztoljarov). Mindegyikre 2016-ban került sor különböző szakmai rendezvényeken, és a DevOps és a Docker témakörének szentelték őket. Már meg is készítettünk egy videót a Docker Moszkvai találkozóról a Badoo irodában Online. Az újakat a riportok lényegét közvetítő cikkek kísérik. Így…
május 31-én a konferencián A „Russian Internet Technologies” (RIT++ 2016) fesztivál részeként megrendezett „Folyamatos üzembe helyezés és telepítés” szekció a „Dokerrel való folyamatos kézbesítés legjobb gyakorlatai” című jelentéssel nyitotta meg kapuit. Összefoglalta és rendszerezte a folyamatos kézbesítési (CD) folyamat Docker és más nyílt forráskódú termékek felhasználásával történő felépítésének legjobb gyakorlatait. Ezekkel a megoldásokkal dolgozunk a gyártás során, ami lehetővé teszi számunkra, hogy a gyakorlati tapasztalatokra támaszkodjunk.
Ha van lehetőséged eltölteni egy órát , javasoljuk a teljes megtekintését. Ellenkező esetben az alábbiakban a fő összefoglaló olvasható szöveges formában.
Folyamatos szállítás a Dockerrel
Alatt Folyamatos szállítás értjük azt az eseményláncot, amelynek eredményeként a Git tárhelyből származó alkalmazáskód először élesre kerül, majd az archívumban végzi. Ez így néz ki: Git → Build → Test → Release → Operate.
A jelentés nagy része az összeállítási szakasznak (alkalmazás-összeállítás) szól, és röviden érintjük a kiadási és működési témákat. Beszélni fogunk azokról a problémákról és mintákról, amelyek lehetővé teszik azok megoldását, és ezeknek a mintáknak a konkrét megvalósítása eltérő lehet.
Egyáltalán miért van ide Docker? Nem véletlenül döntöttünk úgy, hogy ennek a nyílt forráskódú eszköznek a keretében beszélünk a folyamatos kézbesítési gyakorlatokról. Noha az egész jelentést a használatának szentelték, számos ok derül ki, ha figyelembe vesszük az alkalmazáskód kibocsátásának fő mintáját.
Fő kihúzási minta
Tehát az alkalmazás új verzióinak bevezetésekor minden bizonnyal szembe kell néznünk ezzel leállási probléma, az éles szerver váltása során keletkezik. A forgalom az alkalmazás régi verziójáról az újra nem válthat át azonnal: először is meg kell győződnünk arról, hogy az új verzió nem csak sikeresen letöltődik, hanem „bemelegszik” (azaz teljesen készen áll a kérések kiszolgálására).
Így egy ideig az alkalmazás mindkét verziója (régi és új) egyszerre fog működni. Ami automatikusan oda vezet megosztott erőforrás konfliktus: hálózat, fájlrendszer, IPC stb. A Dockerrel ez a probléma egyszerűen megoldható az alkalmazás különböző verzióinak külön tárolókban való futtatásával, amelyeknél az erőforrások elkülönítése ugyanazon a gazdagépen (kiszolgálón/virtuális gépen) belül garantált. Természetesen szigetelés nélkül is meg lehet boldogulni néhány trükkel, de ha van egy kész és kényelmes eszköz, akkor ennek ellenkezője van - nem szabad elhanyagolni.
A konténerezés számos egyéb előnnyel jár a telepítés során. Bármely alkalmazás attól függ konkrét verzió (vagy verzió tartomány) tolmács, modulok/bővítmények stb. elérhetősége, valamint azok verziói. És ez nem csak a közvetlen végrehajtható környezetre vonatkozik, hanem a teljes környezetre is, beleértve rendszer szoftver és annak verziója (a használt Linux disztribúcióig). Tekintettel arra, hogy a konténerek nem csak alkalmazáskódot tartalmaznak, hanem a szükséges verziójú előre telepített rendszer- és alkalmazásszoftvereket is, elfelejtheti a függőségekkel kapcsolatos problémákat.
Általánosítsunk fő kihelyezési minta új verziók a következő tényezők figyelembevételével:
- Először az alkalmazás régi verziója fut az első tárolóban.
- Az új verziót ezután kigördítik, és egy második tartályban „bemelegítik”. Figyelemre méltó, hogy ez az új verzió nemcsak frissített alkalmazáskódot tartalmazhat, hanem annak bármely függőségét, valamint rendszerkomponenseket (például az OpenSSL új verzióját vagy a teljes disztribúciót).
- Amikor az új verzió teljesen készen áll a kérések kiszolgálására, a forgalom az első tárolóról a másodikra vált.
- A régi verzió most leállítható.
Az alkalmazás különböző verzióinak külön tárolókban történő telepítése további kényelmet biztosít - gyors visszaállítás a régi verzióra (végül is elég a forgalmat a kívánt tárolóra kapcsolni).
Az utolsó első ajánlás úgy hangzik, mint amiben még a kapitány sem talált kivetnivalót: „[Folyamatos kézbesítés megszervezésekor a Dockerrel] Használja a Dockert [és értsd meg, mit ad]" Ne feledje, ez nem egy ezüstgolyó, amely minden problémát megold, hanem egy olyan eszköz, amely csodálatos alapot biztosít.
Reprodukálhatóság
A „reprodukálhatóság” alatt az alkalmazások működtetése során felmerülő problémák általános halmazát értjük. Ilyen esetekről beszélünk:
- A minőségügyi osztály által a gyártáshoz ellenőrzött szkripteket pontosan reprodukálni kell a gyártás során.
- Az alkalmazások olyan szervereken kerülnek közzétételre, amelyek különböző tárolótükröktől csomagokat tudnak fogadni (idővel frissülnek, és velük együtt a telepített alkalmazások verziói is).
- „Nekem helyben minden működik!” (...és a fejlesztőket nem engedik be a gyártásba.)
- Valamit ellenőrizni kell a régi (archivált) verzióban.
- ...
Általános lényegük abban rejlik, hogy a használt környezet teljes megfelelése (valamint az emberi tényező hiánya) szükséges. Hogyan garantálhatjuk a reprodukálhatóságot? Készítsen Docker képeket a Git kódja alapján, majd bármilyen feladathoz felhasználja őket: teszthelyeken, termelésben, programozók helyi gépein... Ugyanakkor fontos a végrehajtott műveletek minimalizálása után a kép összeállítása: minél egyszerűbb, annál kisebb a hibák valószínűsége.
Az infrastruktúra kód
Ha az infrastrukturális követelmények (a kiszolgálószoftver elérhetősége, verziója stb.) nincsenek formalizálva és „programozva”, akkor az alkalmazásfrissítések bevezetése katasztrofális következményekkel járhat. Például a stádiumban már átváltott a PHP 7.0-ra, és ennek megfelelően átírta a kódot – akkor a termelésben való megjelenése valami régi PHP-vel (5.5) biztosan meglep majd valakit. Lehet, hogy nem feledkezhet meg egy jelentős változásról az interpreter verzióban, de „az ördög a részletekben rejlik”: a meglepetés lehet bármilyen függőség kisebb frissítése.
A probléma megoldásának egyik megközelítése ún IaC (Infrastruktúra mint kód, „infrastruktúra mint kód”) és magában foglalja az infrastrukturális követelmények tárolását az alkalmazás kódjával együtt. Használatával a fejlesztők és a DevOps-specialisták ugyanazzal a Git-alkalmazástárral dolgozhatnak, de annak különböző részein. Ebből a kódból egy Docker lemezkép jön létre a Gitben, amelyben az alkalmazás az infrastruktúra összes sajátosságait figyelembe véve kerül telepítésre. Egyszerűen fogalmazva, a képek összeállításához szükséges szkripteknek (szabályoknak) ugyanabban a tárolóban kell lenniük a forráskóddal, és össze kell vonni őket.
Többrétegű alkalmazásarchitektúra esetén - például ott van az nginx, ami egy Docker konténerben már futó alkalmazás előtt áll - minden réteghez a Gitben található kódból Docker képeket kell létrehozni. Ekkor az első kép egy alkalmazást tartalmaz egy értelmezővel és más „közeli” függőségekkel, a második kép pedig az upstream nginx-et.
Docker képek, kommunikáció Gittel
A Gitből gyűjtött összes Docker-képet két kategóriába soroljuk: ideiglenes és kiadás. Ideiglenes képek a Gitben lévő ág nevével vannak megcímkézve, a következő véglegesítéssel felülírhatók, és csak az előnézethez kerülnek közzétételre (éleshez nem). Ez a legfontosabb különbségük a kiadási verziókhoz képest: soha nem tudhatod, melyik konkrét commit van bennük.
Érdemes ideiglenes képekbe gyűjteni: a fő ág (automatikusan kiteregetheti egy külön webhelyre, hogy folyamatosan lássa a master aktuális verzióját), kiadásokkal rendelkező ágak, konkrét újítások ágai.
Miután az ideiglenes képek előnézete a termelésbe történő fordítás szükségességéhez vezet, a fejlesztők egy bizonyos címkét helyeznek el. Címke által automatikusan gyűjtve kiadás kép (a címkéje megegyezik a Git címkéjével), és ki van állítva. Ha a minőségügyi osztály sikeresen ellenőrzi, akkor gyártásba kerül.
DAPP
Minden leírt (kiterjesztés, kép összeállítás, utólagos karbantartás) önállóan megvalósítható Bash szkriptek és más „rögtönzött” eszközök segítségével. De ha ezt megteszi, akkor a megvalósítás egy bizonyos ponton nagy bonyolultsághoz és rossz irányíthatósághoz vezet. Ennek megértésére jöttünk létre saját, speciális Workflow segédprogramunk CI/CD készítéséhez - DAPP.
Forráskódja Ruby nyelven íródott, nyílt forráskódú, és a következő napon került közzétételre . Sajnos jelenleg a dokumentáció a leggyengébb pontja az eszköznek, de dolgozunk rajta. A dappról pedig még többször fogunk írni és beszélni, mert... Őszintén alig várjuk, hogy megosszuk a képességeit az egész érdeklődő közösséggel, de addig is küldje el problémáit és kérje le és/vagy kövesse a projekt fejlődését a GitHubon.
Frissítve 13. augusztus 2019-án: jelenleg projekt DAPP átnevezte , kódja teljesen át lett írva a Go-ban, és a dokumentációja is jelentősen javult.
Kubernetes
Egy másik kész Open Source eszköz, amely már jelentős elismerést kapott a szakmai környezetben az Kubernetes,a Docker felügyeleti fürt. A Dockerre épített projektek üzemeltetésében való felhasználásának témája túlmutat a jelentés keretein, így az előadás néhány érdekesség áttekintésére szorítkozik.
A bevezetéshez a Kubernetes a következőket kínálja:
- készenléti szonda — az alkalmazás új verziójának készenlétének ellenőrzése (a forgalom átkapcsolása rá);
- gördülő frissítés - szekvenciális képfrissítés egy konténerfürtben (leállítás, frissítés, előkészítés az indításra, forgalomváltás);
- szinkron frissítés - egy fürtben lévő kép frissítése eltérő megközelítéssel: először a tárolók felén, majd a többien;
- canary releases - új kép indítása korlátozott (kis) számú konténeren az anomáliák megfigyelésére.
Mivel a Continuous Delivery nem csak egy új verzió kiadása, a Kubernetes számos lehetőséggel rendelkezik az infrastruktúra későbbi karbantartásához: beépített megfigyelés és naplózás minden tárolóhoz, automatikus méretezés stb. Mindez már működik, és csak a megfelelőre vár. megvalósítása folyamataiban.
Végső ajánlások
- Használja a Dockert.
- Hozzon létre Docker-képeket az alkalmazásokról, minden igényt kielégítve.
- Kövesse az „Infrastruktúra kód” elvet.
- Kapcsolja össze a Git-et a Dockerrel.
- Szabályozza a kiterjesztés sorrendjét.
- Használjon kész platformot (Kubernetes vagy más).
Videók és diák
Videó az előadásról (kb. egy óra) (maga a riport az 5. perctől indul - ettől a pillanattól kövesse a linket a lejátszáshoz).
A jelentés bemutatása:
PS
További beszámolók a témában blogunkon:
- «» (Dmitry Stolyarov; 27. május 2019., DevOpsConf);
- «» (Dmitry Stolyarov; 8. november 2018. a HighLoad++-on);
- «» (Dmitry Stolyarov; 7. november 2017. a HighLoad++-on);
- «» (Dmitry Stolyarov; 6. június 2017., RootConf).
Forrás: will.com