Az első DevOps lánc létrehozása öt lépésben kezdőknek.
A DevOps a lassú, szétszórt és egyéb problémás fejlesztési folyamatok panaceájává vált. De minimális ismeretek szükségesek a DevOps világában. Itt olyan fogalmakkal foglalkozunk, mint a DevOps lánc, és azt, hogy hogyan lehet azt öt lépésben létrehozni. Ez nem egy átfogó útmutató, hanem egy "hal", amely lehetőséget ad a további bővítésre. Kezdjük a történelemmel.
Első találkozásom a DevOps-szal
Egyszer a Citi Group-nál dolgoztam felhőmegoldásokkal, és egy IaaS webalkalmazást fejlesztettem a Citi felhőinfrastruktúrájának kezelésére, de mindig is érdekelt, hogyan lehet optimalizálni a fejlesztési láncot és javítani a kultúrát a fejlesztők között. Greg Lavender, felhőarchitektúráért és infrastruktúráért felelős műszaki igazgatónk, ajánlotta nekem a könyvet . Ez szépen magyarázza el a DevOps alapelveit, és úgy olvasódik, mint egy regény.
A hátoldalon található táblázatban látható, hogyan gyakran adnak ki új verziókat a cégek:
Hogyan tud annyi új verziót kiadni az Amazon, a Google és a Netflix? Nagyon egyszerű: megértették, hogyan lehet létrehozni egy szinte tökéletes DevOps láncot.
A Citi-nél nálunk ez teljesen másképp zajlott, amíg nem váltottunk DevOps-ra. Akkor a csapatomnak különböző környezetei voltak, de a fejlesztési szerverre történő kiadásokat kézzel végeztük. Minden fejlesztő csak egyetlen IBM WebSphere Application Server Community Edition alapú fejlesztési szerverhez fért hozzá. Amikor egyszerre próbáltunk kiadni, a szerver "összeomlott", és nekünk minden alkalommal "fájdalmasan" meg kellett állapodnunk egymással. Emellett nem volt elegendő tesztelési lefedettség, a kiadási folyamat munkaigényes volt, és nem volt lehetőség a kód kiadásának nyomon követésére egy adott feladathoz vagy kliensigényhez.
Nyilvánvalóvá vált, hogy sürgősen tennünk kell valamit, és találtam egy hasonszőrű kollégát. Együtt döntöttünk úgy, hogy létrehozzuk az első DevOps láncot - ő beállította a virtuális gépet és a Tomcat alkalmazás szervert, míg én a Jenkins-t, az Atlassian Jira és BitBucket integrációt, valamint a tesztelési lefedettséget kezeltem. A projekt sikeres volt: teljesen automatizáltuk a fejlesztési láncot, közel 100%-os folyamatos üzemelést értünk el a fejlesztési szerveren, nyomon tudtuk követni és javítani a tesztelési lefedettséget, és a Git ágat lehetett kötni a kiadáshoz és a Jira feladathoz. Ráadásul szinte minden eszköz, amellyel a DevOps láncot felépítettük, nyílt forráskódú volt.
Valójában a folyamat egyszerűsített volt, hiszen még csak nem is alkalmaztunk kiterjesztett konfigurációkat Jenkins vagy Ansible segítségével. De végül jól sikerült. Lehet, hogy ez a principiális következménye. (más néven 80/20 szabály).
A DevOps és CI/CD folyamat rövid leírása
A DevOpsnak különböző meghatározásai léteznek. A DevOps, akárcsak az Agile, különböző területeket foglal magában. De a legtöbben egyetértenek a következő definícióval: a DevOps egy módszertan vagy szoftverfejlesztési életciklus, amelynek fő elve a kultúra kialakítása, ahol a fejlesztők és más munkatársak "egy hullámhosszon" vannak, a manuális feladatok automatizáltak, mindenki azt csinálja, amiben a legjobb, növekszik a szállítások gyakorisága, nő a munka termelékenysége és növekszik a rugalmasság.
Bár önmagukban az eszközök nem elegendőek a DevOps környezet létrehozásához, nélkülük nem lehet megoldani. A legfontosabb közülük a folyamatos integráció és folyamatos szállítás (CI/CD). A folyamatban minden környezethez különböző szakaszok tartoznak (például DEV (fejlesztés), INT (integráció), TST (tesztelés), QA (minőségellenőrzés), UAT (felhasználói elfogadási tesztelés), STG (előkészítés), PROD (használat)), a manuális feladatokat automatizálják, a fejlesztők képesek minőségi kódot írni, szállítják azt, és könnyedén átalakíthatják.
Ez a cikk öt lépésben mutatja be, hogyan lehet létrehozni egy DevOps folyamatot, ahogy az az alábbi képen látható, nyílt forráskódú eszközök segítségével.
Lássunk neki.
1. lépés: CI/CD platform
Először is szükséged van egy CI/CD eszközre. A Jenkins egy nyílt forráskódú CI/CD eszköz, amely Java nyelven készült, MIT licenc alatt, és amely elindította a DevOps mozgalom népszerűsítését, és de facto a CI/CD szabványává vált.
Mi is az a Jenkins? Képzeld el, hogy van egy varázspultod a legkülönbözőbb szolgáltatások és eszközök számára. A CI/CD eszköz, mint a Jenkins, önmagában haszontalan, de különböző eszközökkel és szolgáltatásokkal együtt mindenhatónak bizonyul.
A Jenkinsen kívül számos más nyílt forráskódú eszköz is létezik, válassz bármelyiket.
Így néz ki a DevOps folyamat CI/CD eszközzel
Localhoston van egy CI/CD eszközöd, de még nem sok mindent tudsz csinálni. Lépjünk a következő lépésre.
2. lépés: verziókezelés
A legjobb (és valószínűleg legkönnyebb) módja annak, hogy ellenőrizd a CI/CD eszköz varázsát, az, ha integrálod egy verziókezelő eszközzel (source control management, SCM). Miért van szükség verziókezelésre? Tegyük fel, hogy készítesz egy alkalmazást. Java, Python, C++, Go, Ruby, JavaScript vagy bármely más nyelven írsz, amiből rengeteg van. Amit írsz, azt forráskódnak hívják. Eleinte, különösen ha egyedül dolgozol, az összes fájlt tárolhatod egy helyi könyvtárban. De amikor a projekt nőni kezd és több ember csatlakozik, szükséged van egy módra, hogy megoszd a kódbeli módosításokat, miközben elkerülöd a konfliktusokat a változások egyesítésekor. Ezen kívül szükséged van arra is, hogy vissza tudd állítani a korábbi verziókat anélkül, hogy biztonsági másolatokat kellene használnod, vagy copy-paste módszert alkalmaznád a kódfájloknál.
Itt jön a képbe az SCM. Az SCM a kódot tárolja a repóban, kezeli a verzióit, és koordinálja a fejlesztők között.
Számos SCM eszköz létezik, de a de facto szabvány szervesen a Git lett. Én ezt ajánlom használatra, de vannak más lehetőségek is.
Így néz ki a DevOps pipeline, miután hozzáadtuk az SCM-et.
A CI/CD eszköz automatizálhatja a forráskód feltöltését és letöltését, valamint a csapatmunkát. Jól hangzik? De hogyan tudunk most ebből működő alkalmazást készíteni, amit milliárdok kedvelnek?
3. lépés: az automatikus építőeszköz
Minden a tervek szerint halad. Ki tudod tölteni a kódot és rögzíteni a változtatásokat a verziókezelő rendszerben, valamint barátokat meghívni, hogy dolgozzanak veled. De még nincs alkalmazásod. Ahhoz, hogy webalkalmazás legyen, azt le kell fordítani és csomagba kell tenni, vagy futtatni kell, mint egy végrehajtható fájlt. (Az értelmezett programozási nyelveket, mint a JavaScript vagy PHP, nem kell lefordítani.)
Alkalmazd az automatikus építőeszközt. Bármilyen eszközt is választasz, összegyűjti a kódot a megfelelő formátumban, és automatizálja a tisztítást, fordítást, tesztelést és kiadást. A különböző nyelvekhez eltérő építőeszközök léteznek, de általában az alábbi nyílt forráskódú lehetőségeket használják.
Kiváló! Most illesszük a build automatizáló eszköz konfigurációs fájljait a verziókezelő rendszerbe, hogy a CI/CD eszköz összegyűjthesse azokat.
Úgy tűnik, minden rendben van. De hova kell most mindezt kiadni?
4. lépés: webalkalmazás szerver
Tehát van egy csomagolt fájl, amely végrehajtható vagy telepíthető. Ahhoz, hogy az alkalmazás valóban hasznot nyújtson, szüksége van valamilyen szolgáltatásra vagy felületre, de mindezt valahol el kell helyezni.
A webalkalmazásokat alkalmazásszervereken lehet elhelyezni. Az alkalmazásszerver biztosítja azt a környezetet, ahol végrehajtható a csomag programlogikája, megvalósítható a felület, és megnyithatóak a webszolgáltatások socketen keresztül. Szüksége van egy HTTP-szerverre és néhány más környezetre (például virtuális gépre), hogy telepíthessen alkalmazásszervert. Jelenleg tegyük fel, hogy ezzel a folyamat során megbirkózik (bár a tartályokról később beszélek).
Több nyílt forráskódú alkalmazásszerver is létezik.
Már szinte működő DevOps láncot alakítottunk ki. Szép munka!
Elvileg itt megállhatunk, a következő lépéseket egyedül is meg tudja oldani, de még érdemes szót ejteni a kód minőségéről.
5. lépés: Tesztelési lefedettség
A tesztelés időigényes és fárasztó, de jobb azonnal felfedezni a hibákat és javítani a kódot, hogy az végfelhasználókat boldogítsa. Erre sok nyílt forráskódú eszköz áll rendelkezésre, amelyek nemcsak tesztelik a kódot, hanem azt is javasolják, hogyan lehetne javítani. A legtöbb CI/CD eszköz képes kapcsolódni ezekhez és automatizálni a folyamatot.
A tesztelés két részre van osztva: tesztelési keretrendszerek az írásra és a tesztek futtatására, valamint eszközök a kódminőség javítására vonatkozó ajánlásokkal.
Tesztelési keretrendszerek
Kódminőség javító eszközök
Ezeknek az eszközöknek és keretrendszereknek a többsége Java, Python és JavaScript nyelvekhez készült, mivel a C++ és C# zárt forráskódú (bár a GCC nyílt forráskódú).
A tesztelési lefedettségének eszközeit alkalmaztuk, és most a DevOps pipeline-nak úgy kell kinéznie, mint a képen a kézikönyv elején.
További lépések
Konténerek
Ahogy már említettem, az alkalmazásszerver egy virtuális gépen vagy szerveren is elhelyezhető, de a tartályok népszerűbbek.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
A tartályokhoz általában a Dockert és a Kubernetes-t használják, de vannak más lehetőségek is.
Olvasson el cikkeket a Dockerről és a Kubernetesről a :
Köztes szoftver automatizálási eszközök
A DevOps láncunk a közös alkalmazásépítésre és -szállításra összpontosít, de a DevOps eszközökkel más izgalmas dolgokat is lehet csinálni. Például alkalmazhatjuk az infrastruktúra mint kód (IaC) eszközöket, amelyeket a köztes szoftver automatizálásának eszközeinek is neveznek. Ezek az eszközök segítenek automatizálni a köztes szoftver telepítését, kezelését és egyéb feladatait. Például egy automatizáló eszköz képes lehet az alkalmazásokat (webalkalmazás-szerver, adatbázis, monitoring eszközök) a megfelelő konfigurációkkal összegyűjteni, és kihelyezni őket az alkalmazás szerverre.
Íme néhány nyílt köztes szoftver automatizáló eszköz:
További részletek a cikkekben találhatók a :
És most mi következik?
Ez csupán a jéghegy csúcsa. A DevOps lánc sokkal többre képes. Kezdje el a CI/CD eszközzel, és fedezze fel, hogy mit lehet még automatizálni a munka megkönnyítése érdekében. Ne feledkezzen meg a a hatékony együttműködéshez.
Íme néhány további jó cikk a DevOps-ról kezdőknek:
Továbbá integrálhatjuk a DevOps-ot nyílt eszközökkel az agilishoz:
Forrás: habr.com
