A projekt új verziójának élesítése alaposan figyelembe kell venni a telepítés sebessége és a megoldás megbízhatósága közötti egyensúlyt. A Slack vállalatnál értékelik a gyors iterációkat, a rövid visszajelzési ciklusokat, és a felhasználói megkeresésekre való gyors reagálást. Továbbá, a vállalatnál több száz programozó dolgozik, akik a lehető legnagyobb termelékenységre törekednek.
A cikk szerzői, akinek a fordítását ma publikáljuk, azt mondják, hogy egy olyan cégnek, amely ilyen értékek követésére törekszik, és közben növekszik, folyamatosan fejlesztenie kell a projekttelepítési rendszerét. A vállalatnak energiát kell fektetnie a munka folyamatok átláthatóságába és megbízhatóságába, azért, hogy ezek a folyamatok megfeleljenek a projekt méretének. Itt a Slack vállalatban kialakult munka folyamatokról és a néhány döntésről lesz szó, amelyek elvezették a céget a ma létező projekttelepítési rendszer használatához.
Hogyan működnek ma a projekttelepítési folyamatok
Minden PR (pull request) a Slackben kötelezően át kell esnie kódellenőrzésen, és sikeresen teljesítenie kell az összes tesztet. Csak miután ezek a feltételek teljesültek, a programozó egyesítheti a kódját a projekt master ágaival. Az ilyen kód telepítése azonban csak az észak-amerikai munkaidő alatt történik. Ennek eredményeképpen, mivel munkatársaink a munkahelyükön tartózkodnak, teljesen felkészültek vagyunk bármilyen váratlan probléma megoldására.
Naponta körülbelül 12 tervezett telepítést végzünk. Minden telepítés során a telepítési felelősséggel megbízott programozó felelős az új build élesítéséért. Ez egy több lépcsős folyamat, amely biztosítja a build zökkenőmentes üzembe helyezését. E megközelítés révén képesek vagyunk észlelni a hibákat, mielőtt azok minden felhasználónkat érintenék. Ha túl sok hiba halmozódik fel — a build visszaállítható. Ha pedig egy külön probléma merül fel a kiadás után, azt könnyen lehet javítani.
A Checkpoint rendszer interfésze, amelyet a Slack használ a projektek telepítésére
Az új verzió telepítési folyamata a termelési környezetben négy lépésből áll.
▍1. A kiadási ág létrehozása
Minden verzió egy új kiadási ággal kezdődik, a Git-történetünk egy adott pontján. Ez lehetővé teszi, hogy címkéket rendeljünk a kiadáshoz, és biztosít helyet a hiba gyorsjavításaira, amelyeket a kiadás előkészítése során találnak a termelési környezetre.
▍2. Telepítés az átmeneti környezetbe
A következő lépés az építmény telepítése az átmeneti (staging) szerverekre és az automatikus teszt futtatása a projekt általános működésének ellenőrzésére (smoke teszt). Az átmeneti környezet a termelési környezet, amelybe nem érkezik külső forgalom. Ebben a környezetben további manuális teszteléseket végzünk. Ez további bizalmat ad nekünk abban, hogy a módosított projekt helyesen működik. Az automatikus tesztekkel nem elegendő biztosítani az ehhez szükséges bizalmat.
▍3. Telepítés a dogfood- és canary-környezetekbe
A termelésben a telepítés a dogfood-környezettel kezdődik, amely egy olyan hoszthálózatot képvisel, amely a belső Slack munkahelyeket szolgálja ki. Mivel nagyon aktív Slack-felhasználók vagyunk, ez a megközelítés segített számos hibát korai fázisokban észlelni. Miután megbizonyosodtunk arról, hogy a rendszer alapvető funkciói nem sérültek, a kiadási építményt a canary-környezetbe telepítjük. Ez olyan rendszereket reprezentál, amelyek a termelési forgalom körülbelül 2%-át kapják.
▍4. Fokozatos bevezetés a termelésbe
Ha az új verzió monitoringje stabil, és a canary-környezetbe történő telepítést követően nem kaptunk panaszokat, folytatjuk a termelési szerverek fokozatos átállítását az új verzióra. A telepítési folyamat lépésről lépésre halad: 10%, 25%, 50%, 75% és 100%. Ennek köszönhetően lassan átadhatjuk a termelési forgalmat az új rendszerváltozatnak. Így időt nyerünk arra, hogy megvizsgáljuk a helyzetet, ha bármilyen anomáliát észlelünk.
▍Mi a teendő, ha a telepítés során valami nem működik megfelelően?
A kód módosítása mindig kockázatot jelent. De ezen a téren jól képzett "kihelyezési vezetőink" segítenek, akik irányítják az új verzió bevezetésének folyamatát, figyelik a monitorozási mutatókat és koordinálják a kódot kiadó programozók munkáját.
Ha valami valóban rosszul sül el, igyekszünk minél hamarabb észlelni a problémát. Megvizsgáljuk a problémát, megtaláljuk a PR-t, amely hibákat okoz, visszagörgetjük, alaposan elemezzük, majd új buildet készítünk. Igaz, néha a probléma észrevétlen marad a projekt élesítéséig. Ilyen helyzetben a legfontosabb, hogy helyreállítsuk a szolgáltatás működését. Ezért a probléma vizsgálata előtt azonnal visszagörgetjük az előző működő buildre.
A kihelyezési rendszer építőelemei
Nézzük meg azokat a technológiákat, amelyek a projektjeink kihelyezési rendszerét alkotják.
▍Gyors kihelyezések
A fent leírt munkafolyamat visszatekintve egyértelműnek tűnhet. De a kihelyezési rendszerünk nem jött létre azonnal.
Amikor a cég jelentősen kisebb volt, az egész alkalmazásunk működhetett 10 Amazon EC2 példányon. A projekt kihelyezése ilyen körülmények között az összes szerver gyors szinkronizálásának érdekében az rsync alkalmazását jelentette. Régen csak egy lépés választotta el az új kódot az éles áttól, ami a köztes környezetet jelentette. A build-eket ebben a környezetben készítették és tesztelték, majd azonnal élesbe kerültek. Egy ilyen rendszerben nagyon egyszerű volt kiismerni magát, bármely programozó bármikor ki tudta helyezni az általa írt kódot.
De ahogy nőtt az ügyfeleink száma, úgy nőtt a projekthez szükséges infrastruktúra mérete is. Hamarosan, figyelembe véve a rendszer folyamatos növekedését, a kihelyezési modellünk, amely az új kód szerverekre juttatásán alapult, már nem tudta ellátni a feladatát. Különösen, hogy minden új szerver hozzáadása megnövelte a kihelyezéshez szükséges időt. Még a párhuzamos rsync alkalmazáson alapuló stratégiák is korlátokkal rendelkeznek.
Végül megoldottuk ezt a problémát, átállva egy teljesen párhuzamos telepítési rendszerre, amely másképp működik, mint a régi. Nevezetesen, most nem küldtünk kódot a szerverekre szinkronizáló szkripttel. Most minden szerver önállóan töltötte le az új verziót, értesülve arról, hogy ezt meg kell tennie, a Consul kulcs megváltozásának figyelésével. A szerverek párhuzamosan töltötték le a kódot. Ez lehetővé tette számunkra, hogy fenntartsuk a magas telepítési sebességet a rendszer folyamatos növekedése mellett.
1. A produkciós szerverek figyelik a Consul kulcsot. 2. A kulcs megváltozik, ami jelzi a szervereknek, hogy el kell kezdeniük az új kód letöltését. 3. A szerverek alkalmazáskódot tartalmazó tarball fájlokat töltenek le.
▍Atomikus telepítések
Egy másik megoldás, amely segített eljutnunk a több szintű telepítési rendszerhez, az atomikus telepítés volt.
Az atomikus telepítések használata előtt minden telepítés jelentős számú hibaüzenetet okozhatott. A probléma az volt, hogy az új fájlok másolása a produkciós szerverekre nem volt atomikus. Ez rövid időszakot eredményezett, amikor a kód, amely új funkciókat hívott meg, elérhetővé vált, mielőtt ezek a funkciók ténylegesen elérhetők lettek volna. Amikor ezt a kódot hívták meg, belső hibák tértek vissza. Ez megnyilvánult a sikertelen API kérésekben és a "törött" weboldalakban.
A kérdéssel foglalkozó csapat megoldotta ezt a problémát a "forró" (hot) és a "hideg" (cold) könyvtárak bevezetésével. A "forró" könyvtárban lévő kód felelős a produkciós forgalom kezeléséért. A "hideg" könyvtárakban pedig a kód a rendszer működése közben csak előkészítés alatt áll. A telepítés során az új kódot a még nem használt "hideg" könyvtárba másolják. Ezután, amikor a szerveren nincsenek aktív folyamatok, azonnali könyvtárváltás történik.
1. Az alkalmazáskód kibővítése a "hideg" könyvtárba. 2. A rendszer átkapcsolása a "hideg" könyvtárra, amely "forróvá" válik (atomikus művelet).
Összegzés: a hangsúly áthelyezése a megbízhatóságra.
2018-ban a projekt olyan méreteket öltött, hogy a nagyon gyors telepítés kezdett ártani a termék stabilitásának. Volt egy elég fejlett telepítési rendszerünk, amire sok energiát és időt fordítottunk. Csak át kellett alakítanunk és tökéletesítenünk a telepítés szervezésének folyamatait. Ekkorára már egy elég nagy céggé nőttünk, amelynek fejlesztéseit világszerte használták a folyamatos kommunikáció biztosítására és fontos feladatok megoldására. Ezért a figyelmünk középpontjában a megbízhatóság állt.
A Slack új kiadásainak telepítési folyamatát biztonságosabbá kellett tennünk. Ez a szükséglet vezetett bennünket a telepítési rendszerünk tökéletesítéséhez. Valójában már korábban is tárgyaltuk ezt a továbbfejlesztett rendszert. A rendszer mélyén továbbra is alkalmazzuk a gyors és atomikus telepítési technológiákat. Megváltozott a telepítés módja. Az új rendszerünk arra készült, hogy fokozatosan hajtsa végre az új kód telepítését különböző szinteken és különböző környezetekben. Most már kifinomultabb segédeszközöket és monitorozó eszközöket használunk, mint valaha. Ez lehetővé teszi számunkra, hogy észleljük és kijavítsuk a hibákat jóval azelőtt, hogy azok eljuthatnának a végfelhasználóhoz.
De nem állunk meg itt. Folyamatosan fejlesztjük ezt a rendszert, alkalmazva korszerűbb segédeszközöket és automatizálási megoldásokat.
Használjátok a CI/CD technológiákat a projektjeitekben? Hogyan zajlik az új projektek kiadásának telepítési folyamata ott, ahol dolgozik?
Forrás: habr.com
