Ha még nem ismeri a DevOps-t, tekintse meg ezt az öt lépésből álló útmutatót az első folyamat létrehozásához.
A DevOps szabványos megoldássá vált a lassú, szétesett vagy hibás szoftverfejlesztési folyamatok javítására. A probléma az, hogy ha még nem ismeri a DevOps-t, és nem tudja, hol kezdje, előfordulhat, hogy nem ismeri ezeket a technikákat. Ez a cikk a DevOps-folyamat definícióját tárgyalja, és ötlépéses utasításokat ad a létrehozásához. Bár ez az oktatóanyag nem teljes körű, alapot kell adnia az utazás megkezdéséhez és tudásának bővítéséhez a jövőben. De kezdjük a történelemmel.
Saját DevOps Journey
Korábban a Citi Group felhőcsapatában dolgoztam egy Infrastructure-as-a-Service (IaaS) webalkalmazás fejlesztésén a Citi felhő infrastruktúrájának kezelésére, de mindig is érdekelt, hogyan lehet a fejlesztési folyamatot hatékonyabbá tenni és pozitív kulturális változást hozni a fejlesztői csapat. A választ Greg Lavender, a Citi Cloud Architecture and Infrastructure műszaki igazgatója által ajánlott könyvben találtam. A könyv a Főnix Projekt címet viselte.), és elmagyarázza a DevOps alapelveit, de úgy olvasható, mint egy regény.
A könyv hátulján található táblázat megmutatja, hogy a különböző vállalatok milyen gyakran telepítik rendszereiket kiadási környezetben:
Amazon: 23 000 naponta
Google: 5 naponta
Netflix: 500 naponta
Facebook: Naponta egyszer
Twitter: heti 3 alkalommal
Tipikus cég: 9 havonta egyszer
Hogyan lehetségesek az Amazon, a Google és a Netflix frekvenciái? Ez azért van, mert ezek a cégek rájöttek, hogyan hozhatnak létre egy majdnem tökéletes DevOps-folyamatot.
Távol voltunk ettől, amíg a DevOps-t be nem vezettük a Citinél. Akkoriban a csapatom különböző környezetekkel rendelkezett, de a fejlesztőszerveren a telepítés teljesen manuális volt. Minden fejlesztő csak egy IBM WebSphere Application Server Community Edition fejlesztői kiszolgálóhoz férhetett hozzá. A probléma az volt, hogy a szerver leállt, amikor több felhasználó egyszerre próbált telepíteni, így a fejlesztőknek közölniük kellett egymással szándékaikat, ami elég fájdalmas volt. Ezenkívül problémák adódtak az alacsony szintű tesztkód lefedettséggel, a nehézkes kézi telepítési folyamatokkal, valamint az egy adott feladathoz vagy felhasználói történethez kapcsolódó kód központi telepítésének nyomon követésének képtelenségével.
Rájöttem, hogy valamit tenni kell, és hasonló gondolkodású kollégát találtam. Úgy döntöttünk, hogy együttműködünk a kezdeti DevOps-folyamat felépítésében – ő beállított egy Tomcat virtuális gépet és alkalmazásszervert, míg én a Jenkins-en dolgoztam, integráltam az Atlassian Jira-t és a BitBucket-et, és a tesztkód lefedettségén dolgoztam. Ez a mellékprojekt nagyon sikeres volt: szinte teljesen automatizáltunk számos folyamatot, majdnem 100%-os rendelkezésre állást értünk el a fejlesztői szerverünkön, biztosítottuk a kód nyomon követését és javított tesztlefedettségét, valamint hozzáadtuk a Git-ágak összekapcsolásának lehetőségét a Jira-problémákkal vagy telepítésekkel. A DevOps folyamat létrehozásához használt eszközök többsége nyílt forráskódú.
Most már értem, milyen egyszerű volt a DevOps folyamat: nem használtunk olyan kiterjesztéseket, mint a Jenkins-fájlok vagy az Ansible. Ez az egyszerű csővezeték azonban jól működött, talán a Pareto-elvnek (más néven 80/20-as szabálynak) köszönhetően.
A DevOps és a CI/CD Pipeline rövid bemutatása
Ha több embertől megkérdezi: „Mi az a DevOps?”, valószínűleg többféle választ fog kapni. A DevOps, akárcsak az Agile, számos különböző tudományterületet felölelve fejlődött, de a legtöbb ember egyetért néhány dologban: A DevOps egy szoftverfejlesztési gyakorlat vagy szoftverfejlesztési életciklus (SDLC), amelynek központi tétele megváltoztatja azt a kultúrát, amelyben a fejlesztők és a nem A fejlesztők olyan környezetben léteznek, amelyben:
A korábban manuálisan végrehajtott műveletek automatizálásra kerültek;
Mindenki azt csinálja, amit a legjobban tud;
A megvalósítások száma egy bizonyos időtartam alatt nő; Növekszik az áteresztőképesség;
Fokozott fejlesztési rugalmasság.
Noha a DevOps-környezet létrehozásához nem csak a megfelelő szoftvereszközökre van szüksége, néhány eszköz elengedhetetlen. A kulcsfontosságú eszköz a folyamatos integráció és a folyamatos telepítés (CI/CD). Ebben a folyamatban a környezeteknek különböző szakaszai vannak (pl. DEV, INT, TST, QA, UAT, STG, PROD), sok művelet automatizált, és a fejlesztők kiváló minőségű kódot írhatnak, fejlesztési agilitást és magas telepítési arányt érhetnek el.
Ez a cikk egy öt lépésből álló megközelítést ír le egy DevOps-folyamat létrehozásához, például az alábbi ábrán láthatóhoz, nyílt forráskódú eszközök használatával.
1. lépés: CI/CD módszerek
Az első dolog, amire szüksége van, egy CI/CD eszköz. A Jenkins, egy nyílt forráskódú, Java-alapú és MIT-licenc alatt licencelt eszköz az az eszköz, amely népszerűsítette a DevOps-t, és de facto szabvánnyá vált.
Szóval mi az a Jenkins? Tekintsd úgy, mint valami varázslatos univerzális távirányítót, amely képes különféle szolgáltatásokkal és eszközökkel beszélgetni és rendszerezni. Önmagában egy olyan CI/CD eszköz, mint a Jenkins, haszontalan, de erősebbé válik, ahogy különböző eszközökhöz és szolgáltatásokhoz csatlakozik.
A Jenkins csak egy a sok nyílt forráskódú CI/CD-eszköz közül, amelyek segítségével felállíthatja DevOps folyamatát.
Jenkins: Creative Commons és MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Így néznek ki a DevOps folyamatok CI/CD eszközzel:
A localhost-on fut egy CI/CD eszköz, de jelenleg nem sok mindent tehetsz. Térjünk át a DevOps út következő szakaszára.
2. lépés: Forrásvezérlő rendszerek kezelése
A legjobb (és talán a legegyszerűbb) módja annak, hogy ellenőrizze, hogy a CI/CD-eszköz képes-e a varázslatára, ha integrálja a forráskód-vezérlő (SCM) eszközt. Miért van szükség forrásvezérlésre? Tegyük fel, hogy egy alkalmazást fejleszt. Amikor létrehoz egy alkalmazást, éppen programoz, és nem számít, hogy Java-t, Python-t, C++-t, Go-t, Rubyt, JavaScriptet vagy a számtalan programozási nyelv bármelyikét használja. Az Ön által írt kódot forráskódnak nevezik. Kezdetben, különösen, ha egyedül dolgozik, valószínűleg rendben van, ha mindent egy helyi könyvtárba tesz. De ahogy a projekt egyre nagyobb, és más embereket is meghív az együttműködésre, szükség van egy módra a konfliktusok megelőzésére, miközben hatékonyan megosztja a módosításokat. A korábbi verziók visszaállítására is szükség van, mert a biztonsági mentések készítése és az ezekbe való másolás/beillesztés elavulttá válik. Neked (és a csapattársaidnak) valami jobbra van szükséged.
Itt válik szinte szükségszerűvé a forráskód-vezérlés. Ez az eszköz tárolja a kódot tárolókban, nyomon követi a verziókat, és koordinálja a projekt résztvevőinek munkáját.
Noha sok forrásvezérlő eszköz létezik, a Git a szabvány, és ez így van. Erősen javaslom a Git használatát, bár vannak más nyílt forráskódú lehetőségek is, ha úgy tetszik.
Git: GPLv2 és LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Így néz ki a DevOps folyamat a forráskód-vezérlők hozzáadásával.
A CI/CD eszköz automatizálhatja az áttekintést, a forráskód-beszerzést és a tagok közötti együttműködést. Nem rossz? De hogyan lehet működő alkalmazássá tenni, hogy több milliárd ember tudja használni és értékelni?
3. lépés: Hozzon létre egy Build Automation Tool-t
Nagy! Áttekintheti a kódot, módosíthatja a forrásvezérlést, és meghívhatja barátait, hogy működjenek együtt a fejlesztésben. De még nem hozott létre alkalmazást. Webalkalmazás készítéséhez azt le kell fordítani és telepíteni kötegelt formátumba kell csomagolni, vagy futtatható fájlként kell futtatni. (Ne feledje, hogy 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. Függetlenül attól, hogy melyik felépítés-automatizálási eszközt választja, mindegyiknek ugyanaz a célja: a forráskódot valamilyen kívánt formátumba építeni, és automatizálni a tisztítási, fordítási, tesztelési és egy adott környezetbe történő telepítési feladatot. Az építési eszközök a programozási nyelvtől függően változnak, de itt van néhány általános nyílt forráskódú lehetőség.
Név
Engedély
Programozási nyelv
Maven
Apache 2.0
Jáva
Hangya
Apache 2.0
Jáva
Gradle
Apache 2.0
Jáva
Bazel
Apache 2.0
Jáva
Az elért eredményeknél hangsúlyozd:
GNÚ
N / A
röfögés
MIT
JavaScript
Korty
MIT
JavaScript
Építész
Apache
Rubin
Gereblye
MIT
Rubin
AAP
GNÚ
Piton
SCons
MIT
Piton
BitBake
GPLv2
Piton
Torta
MIT
C#
asdf
Expat (MIT)
SELYPÍT
Összeesküvés
BSD
Haskell
Nagy! Az építési automatizálási eszköz konfigurációs fájljait behelyezheti a forrásvezérlő rendszerébe, és hagyhatja, hogy a CI/CD eszköz mindent összeállítson.
Minden rendben van, nem? De hol helyezze üzembe az alkalmazást?
4. lépés: Web Application Server
Egyelőre van egy csomagolt fájlja, amely lehet futtatható vagy telepíthető. Ahhoz, hogy minden alkalmazás valóban hasznos legyen, biztosítania kell valamilyen szolgáltatást vagy interfészt, de szükség van egy tárolóra az alkalmazás tárolására.
A webalkalmazás-szerver csak egy ilyen tároló. A szerver olyan környezetet biztosít, amelyben a telepített csomag logikája meghatározható. A szerver felületet is biztosít, és webszolgáltatásokat kínál azáltal, hogy a socketeket a külvilág felé tárja. A telepítéshez szükség van egy HTTP-kiszolgálóra, valamint valamilyen környezetre (például egy virtuális gépre). Egyelőre tegyük fel, hogy többet tud meg erről (bár alább a konténerekkel foglalkozom).
Számos nyílt forráskódú webes alkalmazásszerver létezik.
Név
Engedély
Programozási nyelv
Kandúr
Apache 2.0
Jáva
móló
Apache 2.0
Jáva
WildFly
GNU Lesser Public
Jáva
Üveghal
CDDL és GNU kevésbé nyilvános
Jáva
Django
3-Clause BSD
Piton
Tornádó
Apache 2.0
Piton
puskaszarvú
MIT
Piton
Piton
MIT
Piton
Rails
MIT
Rubin
node.js
MIT
Javascript
A DevOps folyamat majdnem használatra kész. Szép munka!
Noha itt megállhat, és maga is kezelheti az integrációt, a kód minősége nagyon fontos dolog az alkalmazásfejlesztőknek.
5. lépés: Kódtesztelési lefedettség
A tesztek végrehajtása egy másik nehézkes követelmény lehet, de a fejlesztőknek korán fel kell ismerniük az alkalmazás bármely hibáját, és javítaniuk kell a kód minőségét, hogy a végfelhasználók elégedettek legyenek. Szerencsére számos nyílt forráskódú eszköz létezik a kód tesztelésére és a minőség javítására vonatkozó javaslatok megfogalmazására. Ami még jobb, hogy a legtöbb CI/CD eszköz képes csatlakozni ezekhez az eszközökhöz, és automatizálni a folyamatot.
A kódtesztelés két részből áll: kódtesztelési keretrendszerekből, amelyek segítenek a tesztek megírásában és futtatásában, valamint a javaslattevő eszközökből, amelyek segítenek javítani a kód minőségét.
Kódtesztelő rendszerek
Név
Engedély
Programozási nyelv
JUnit
Eclipse Public License
Jáva
EasyMock
Apache
Jáva
mockito
MIT
Jáva
PowerMock
Apache 2.0
Jáva
Pytest
MIT
Piton
Hipotézis
Mozilla
Piton
Tox
MIT
Piton
Ajánlórendszerek a kódjavításhoz
Név
Engedély
Programozási nyelv
Lefedettség
GNÚ
Jáva
CodeCover
Eclipse Public (EPL)
Jáva
Coverage.py
Apache 2.0
Piton
Emma
Közös nyilvános licenc
Jáva
JaCoCo
Eclipse Public License
Jáva
Hipotézis
Mozilla
Piton
Tox
MIT
Piton
Jázmin
MIT
JavaScript
Karma
MIT
JavaScript
Mohaachát
MIT
JavaScript
van
MIT
JavaScript
Vegye figyelembe, hogy a fent említett eszközök és keretrendszerek többsége Java, Python és JavaScript számára készült, mivel a C++ és a C# szabadalmaztatott programozási nyelvek (bár a GCC nyílt forráskódú).
Most, hogy bevezette a tesztlefedettségi eszközöket, a DevOps-folyamatnak hasonlónak kell lennie az oktatóanyag elején látható diagramhoz.
További lépések
konténerek
Ahogy mondtam, a szerverét virtuális gépen vagy szerveren is tárolhatja, de a konténerek népszerű megoldások.
Mik azok a konténerek? A rövid magyarázat az, hogy egy virtuális gépnek hatalmas mennyiségű operációs rendszer memóriára van szüksége, ami meghaladja az alkalmazás méretét, míg egy tárolónak csak néhány könyvtárra és konfigurációra van szüksége az alkalmazás futtatásához. Nyilvánvalóan még mindig vannak fontos felhasználási területei a virtuális gépeknek, de a konténer könnyű megoldás egy alkalmazás, beleértve az alkalmazáskiszolgálót, tárolására.
Bár vannak más konténerlehetőségek is, a legnépszerűbbek a Docker és a Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Köztes automatizálási eszközök
DevOps folyamatunk elsősorban az együttműködésen alapuló alkalmazások létrehozására és üzembe helyezésére összpontosít, de sok más dolog is elvégezhető a DevOps eszközökkel. Az egyik az Infrastructure as Code (IaC) eszközök használata, amelyek köztesszoftver-automatizálási eszközökként is ismertek. Ezek az eszközök segítenek automatizálni a köztes szoftver telepítését, kezelését és egyéb feladatait. Így például egy automatizálási eszköz ki tudja bontani az olyan alkalmazásokat, mint a webes alkalmazásszerver, egy adatbázis és egy megfigyelőeszköz a megfelelő konfigurációkkal, és telepítheti azokat az alkalmazáskiszolgálóra.
Íme néhány nyílt forráskódú köztes szoftver automatizálási eszköz:
Lehetséges: GNU Public
SaltStack: Apache 2.0
Szakács: Apache 2.0
Báb: Apache vagy GPL
Tudjon meg részleteket arról, hogyan szerezhet keresett szakmát a semmiből, vagy hogyan juthat magasabb szintre a készségek és a fizetés tekintetében, ha részt vesz a SkillFactory fizetett online tanfolyamain:
- (12 hónap)
több tanfolyamot
- (12 hét)
- (12 hónap)
- (9 hónap)
- (9 hónap)
hasznos
Forrás: will.com