Az első DevOps-lánc felépítése öt lépésben kezdőknek.
A DevOps csodaszer lett a túl lassú, szétkapcsolt és egyébként problémás fejlesztési folyamatok ellen. De minimális tudásra van szüksége a DevOps-ban. Olyan koncepciókat fog tartalmazni, mint például a DevOps lánc, és az öt lépésben történő létrehozás módja. Ez nem egy teljes útmutató, hanem csak egy bővíthető "hal". Kezdjük a történelemmel.
Bevezetésem a DevOps-ba
Korábban felhőkkel dolgoztam a Citi Groupnál, és IaaS webalkalmazást fejlesztettem a Citi felhő infrastruktúrájának kezelésére, de mindig is érdekelt, hogyan optimalizálhatom a fejlesztési láncot és javíthatom a fejlesztői kultúrát. Greg Lavender, a felhőarchitektúra és -infrastruktúra műszaki igazgatója ajánlotta nekem ezt a könyvet. . Gyönyörűen elmagyarázza a DevOps elveit, és regényként olvasható.
A hátoldalon található táblázat azt mutatja, hogy a vállalatok milyen gyakran vezetnek be új verziókat:
Hogyan tud az Amazon, a Google és a Netflix ennyire elterjedni? És ez egyszerű: rájöttek, hogyan hozhatnak létre egy szinte tökéletes DevOps láncot.
A Citinél egészen más volt a helyzet, amíg át nem váltottunk DevOps-ra. Akkor a csapatomnak különböző környezetei voltak, de a fejlesztői szerverre kézi úton szállítottuk. Minden fejlesztő csak egy IBM WebSphere Application Server Community Edition fejlesztőkiszolgálóhoz férhetett hozzá. Egyidejű kézbesítési kísérlettel a szerver „leesett”, és minden alkalommal „fájdalmasan” kellett tárgyalnunk egymás között. Nem volt elegendő kódlefedettségünk tesztekkel, időigényes kézi kézbesítési folyamatunk, és nem volt módunk nyomon követni a kód kézbesítését valamilyen feladat vagy ügyfélkövetelmény segítségével.
Egyértelmű volt, hogy valamit sürgősen tenni kell, és találtam egy hasonló gondolkodású kollégát. Úgy döntöttünk, hogy közösen létrehozzuk az első DevOps láncot – ő beállított egy virtuális gépet és egy Tomcat alkalmazásszervert, én pedig gondoskodtam a Jenkinsről, az Atlassian Jira és a BitBucket integrációjáról, valamint a kódlefedettségről tesztekkel. A projekt sikeres volt: teljesen automatizáltuk a fejlesztési láncot, közel 100%-os rendelkezésre állást értünk el a fejlesztőszerveren, ellenőrizni tudtuk és tesztekkel javítani tudtuk a kódlefedettséget, és egy Git-ágat is össze lehetett kötni egy Jira szállítással és kiadással. A DevOps lánc felépítéséhez használt eszközök szinte mindegyike nyílt forráskódú volt.
Valójában a lánc leegyszerűsödött, mert nem is alkalmaztunk fejlett konfigurációkat Jenkins vagy Ansible segítségével. De sikerült. Talán ez az elv következménye (más néven 80/20 szabály).
A DevOps és a CI/CD lánc rövid leírása
A DevOps különböző definíciókkal rendelkezik. A DevOps, akárcsak az Agile, különböző szakterületeket tartalmaz. De a legtöbben egyetértenek a következő definícióval: A DevOps a szoftverfejlesztés olyan módszere vagy életciklusa, amelynek fő elve egy olyan kultúra kialakítása, ahol a fejlesztők és más alkalmazottak „egy hullámhosszon vannak”, a kézi munka automatizált, mindenki azt csinálja, amiben a legjobban tud, nő a szállítások gyakorisága, nő a munka termelékenysége, nő a rugalmasság.
Bár az eszközök önmagukban nem elegendőek a DevOps környezet létrehozásához, nélkülözhetetlenek. Ezek közül a legfontosabb a folyamatos integráció és a folyamatos szállítás (CI/CD). A láncnak minden környezethez különböző szakaszai vannak (pl. DEV (fejlesztés), INT (integráció), TST (tesztelés), QA (minőségbiztosítás), UAT (felhasználói elfogadási tesztelés), STG (előkészítés), PROD (használat)) , a kézi feladatok automatizáltak, a fejlesztők minőségi kódot állíthatnak elő, kézbesíthetik, és könnyen újraépíthetik.
Ez a megjegyzés leírja, hogyan hozhat létre DevOps-láncot öt lépésben, az alábbi képen látható módon, nyílt forráskódú eszközök használatával.
Lássunk munkához.
1. lépés: CI/CD platform
Először is szüksége van egy CI/CD eszközre. A Jenkins egy MIT-licencű, nyílt forráskódú, Java nyelven írt CI/CD eszköz, amely népszerűsítette a DevOps mozgalmat, és a CICD de facto szabványává vált.
Mi az a Jenkins? Képzelje el, hogy van egy varázslatos vezérlőpultja számos szolgáltatáshoz és eszközhöz. Önmagában egy olyan CI/CD eszköz, mint a Jenkins, haszontalan, de különböző eszközökkel és szolgáltatásokkal mindenre képes.
A Jenkins mellett sok más nyílt forráskódú eszköz is létezik, válasszon bármelyiket.
Így néz ki egy DevOps folyamat egy CI/CD eszközzel
Van egy CI / CD eszközöd a localhostban, de még nincs sok tennivalód. Térjünk át a következő lépésre.
2. lépés: Verziószámítás
A CI/CD eszköz varázslatosságának tesztelésének legjobb (és vitathatatlanul legegyszerűbb) módja az, ha integrálja azt egy forrásvezérlés-kezelő (SCM) eszközzel. Miért van szükséged verziókezelésre? Tegyük fel, hogy kérelmet nyújt be. Java-ban, Python-ban, C++-ban, Go-ban, Ruby-ban, JavaScript-ben vagy bármilyen más nyelven írod, ami egy kocsi és egy kis kocsi. Amit írsz, az a forráskód. Először, különösen, ha egyedül dolgozik, mindent elmenthet egy helyi könyvtárba. De ahogy a projekt növekszik, és egyre többen csatlakoznak, szükség van egy módra a kódmódosítások megosztására, de elkerülheti az ütközéseket a módosítások összevonásakor. Valahogy vissza kell állítania a korábbi verziókat is anélkül, hogy biztonsági másolatokat készítene, és a kódfájlokhoz másolás-beillesztés módszert használna.
És itt SCM nélkül sehol. Az SCM lerakatokban tárolja a kódot, kezeli annak verzióit, és koordinálja azt a fejlesztők között.
Sok SCM-eszköz létezik, de a Git méltán vált a de facto szabvánnyá. Azt tanácsolom, hogy használja, de van más lehetőség is.
Így néz ki a DevOps folyamat az SCM hozzáadása után.
A CI/CD eszköz automatizálhatja a forráskód feltöltését és letöltését, valamint a csoportos együttműködést. Nem rossz? De most hogyan készítsünk ebből működő, több milliárd felhasználó által kedvelt alkalmazást?
3. lépés: Automatizálási eszköz létrehozása
Minden úgy megy, ahogy kell. Feltölthet kódot, módosíthatja a forrásvezérlést, és meghívhat ismerőseit, hogy dolgozzanak veled. De még nincs alkalmazásod. Ahhoz, hogy ez egy webalkalmazás legyen, le kell fordítani és csomagolni kell terjesztéshez, vagy futtatható fájlként kell futtatni. (Az olyan értelmezett programozási nyelveket, mint a JavaScript vagy a PHP, nem kell lefordítani.)
Használjon építési automatizálási eszközt. Bármelyik eszközt is választja, az összeállítja a kódot a megfelelő formátumban, és automatizálja a tisztítást, az összeállítást, a tesztelést és a kézbesítést. Az építési eszközök nyelvenként változnak, de a következő nyílt forráskódú beállításokat általában használják.
Tökéletes! Most illesszük be a build automatizálási eszköz konfigurációs fájljait a forrásvezérlésbe, hogy a CI/CD eszköz összeállítsa őket.
Jó érzés. De most hol kell ezt az egészet kiteríteni?
4. lépés: Web Application Server
Tehát van egy csomagolt fájlja, amely végrehajtható vagy kihelyezhető. Ahhoz, hogy egy alkalmazás valóban hasznos legyen, rendelkeznie kell valamilyen szolgáltatással vagy felülettel, de mindezt el kell helyezni valahova.
A webalkalmazást webalkalmazás-kiszolgálón lehet tárolni. Az alkalmazásszerver olyan környezetet biztosít, ahol csomagolt logikát hajthat végre, interfészeket jeleníthet meg, és webszolgáltatásokat tárhat fel egy socketen keresztül. Az alkalmazáskiszolgáló telepítéséhez szükség van egy HTTP-kiszolgálóra és néhány más környezetre (például egy virtuális gépre). Egyelőre tegyük fel, hogy menet közben mindezzel foglalkozol (bár alább a konténerekről lesz szó).
Számos nyílt webes alkalmazásszerver létezik.
Már van egy majdnem működő DevOps láncunk. Nagyszerű munka!
Elvileg itt meg lehet állni, utána magad is megoldhatod, de a kód minőségéről érdemes beszélni.
5. lépés: Tesztbevonat
A tesztelés sok időt és erőfeszítést igényel, de jobb, ha azonnal megtalálja a hibákat, és javítja a kódot a végfelhasználók kedvére. Erre a célra számos nyitott eszköz létezik, amelyek nemcsak tesztelik a kódot, hanem tanácsokat is adnak a fejlesztéséhez. A legtöbb CI/CD eszköz csatlakoztatható ezekhez az eszközökhöz, és automatizálhatja a folyamatot.
A tesztelés két részre oszlik: a tesztek írásához és végrehajtásához szükséges tesztelési keretrendszerek, valamint a kódminőség javítására szolgáló tippeket tartalmazó eszközök.
Tesztelési keretrendszerek
Eszközök minőségi tippekkel
A legtöbb ilyen eszköz és keretrendszer Java, Python és JavaScript nyelvre készült, mivel a C++ és a C# szabadalmaztatott (bár a GCC nyílt forráskódú).
Alkalmaztuk a tesztlefedési eszközöket, és most a DevOps folyamatnak úgy kell kinéznie, mint az oktatóanyag elején látható képen.
További lépések
konténerek
Ahogy korábban is mondtam, az alkalmazáskiszolgálót virtuális gépen vagy szerveren is el lehet helyezni, de a konténerek népszerűbbek.
? Röviden, egy virtuális gépben az operációs rendszer gyakran több helyet foglal el, mint az alkalmazás, és egy konténer általában elegendő néhány könyvtárral és konfigurációval. Bizonyos esetekben a virtuális gépek nélkülözhetetlenek, de a konténerben többletköltség nélkül elfér az alkalmazás a szerverrel együtt.
A konténereknél általában a Docker és a Kubernetes használatos, bár vannak más lehetőségek is.
Olvasson cikkeket a Dockerről és a Kubernetesről: :
Middleware automatizálási eszközök
DevOps láncunk az alkalmazások együttműködésen alapuló létrehozására és szállítására összpontosít, de vannak más érdekes dolgok is, amelyeket megtehet a DevOps eszközökkel. Például használja az Infrastructure as Code (IaC) eszközöket, más néven köztesszoftver-automatizálási eszközöket. 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ási eszköz átveheti a megfelelő konfigurációjú alkalmazásokat (webes alkalmazásszerver, adatbázis, megfigyelő eszközök), és továbbíthatja azokat az alkalmazáskiszolgálóra.
Íme néhány lehetőség a nyílt köztesszoftver-automatizálási eszközökhöz:
Részletek a cikkekben :
Most mi?
Ez csak a jéghegy csúcsa. A DevOps lánc sokkal többre képes. Kezdje egy CI/CD eszközzel, és nézze meg, mit automatizálhat még, hogy megkönnyítse munkáját. Ne feledkezz meg róla a hatékony együttműködés érdekében.
Íme néhány további jó DevOps cikk kezdőknek:
A DevOps-t nyílt agilis eszközökkel is integrálhatja:
Forrás: will.com