🥇Kezdők útmutatója: DevOps-pipeline készítése

Ha új vagy a DevOps világában, nézd meg ezt az útmutatót az első öt lépcsős folyamatod megs creationéhez.

A DevOps a szoftverfejlesztési folyamatok lassú, diszpers, vagy nem működő megoldásainak javítására lett szabványos megoldás. A probléma az, hogy ha új vagy a DevOps-ban, és nem tudod, honnan kezd, akkor hiányos lehet a megértésed ezekről a módszerekről. Ebben a cikkben a DevOps-cső meghatározásáról lesz szó, és egy öt lépésből álló útmutatót kínálunk annak létrehozásához. Bár ez az útmutató nem kimerítő, alapot adhat számodra, hogy elindulj az utadon, és hogy a jövőben bővítsd a tudásodat. De kezdjük a történettel.

Az én DevOps utam

Korábban a Citi Group felhőcsapatában dolgoztam, ahol a Citi felhőinfrastruktúrájának kezelésére fejlesztettünk egy Infrastructure-as-a-Service (IaaS) webalkalmazást, de mindig is érdekelt, hogyan lehetne hatékonyabbá tenni a fejlesztési folyamatot, és pozitív kulturális változásokat hozni a fejlesztőcsapatba. A választ Greg Lavender, a Citi felhőarchitektúráért és infrastruktúráért felelős technikai igazgató által ajánlott könyvben találtam. A könyv címe „Phoenix Project” (A Főnix Projekt), és a DevOps elveit magyarázza, miközben regény formájában olvasható.

A könyv hátoldalán található táblázat megmutatja, hogy különböző cégek milyen gyakran telepítik rendszereiket a kiadási környezetbe:

Amazon: napi 23 000
Google: napi 5 500
Netflix: napi 500
Facebook: napi egyszer
Twitter: heti 3 alkalommal
Tipikus cég: 9 havonta egyszer

Hogyan lehetséges az Amazon, Google és Netflix ilyen gyakorisággal? Azért, mert ezek a cégek kitalálták, hogyan lehet szinte tökéletes DevOps folyamatot létrehozni.

Messze jártunk ettől, amíg be nem vezettük a DevOps-ot a Citinél. Akkor a csapatomban különböző környezetek voltak, de a fejlesztési szerverre való telepítés teljesen kézi volt. Minden fejlesztő csak egy IBM WebSphere Application Server Community Edition alapú fejlesztési szerverhez férhetett hozzá. A probléma az volt, hogy a szerver minden alkalommal leállt, amikor több felhasználó egyszerre próbált telepítést végezni, így a fejlesztőknek értesíteniük kellett egymást a szándékaikról, ami meglehetősen fájdalmas volt. Ezenkívül problémák merültek fel az alacsony szintű kódtesztelési lefedettséggel, a túlzottan bonyolult kézi telepítési folyamatokkal és a kód telepítésének nyomon követésének hiányával, amely egy adott feladathoz vagy felhasználói történethez kapcsolódott.

Megértettem, hogy tennünk kell valamit, és találtam egy hasonló gondolkodású kollégát. Elhatároztuk, hogy együttműködünk egy kezdeti DevOps-vezetékmenedzsment létrehozásában – ő egy virtuális gépet és egy Tomcat alkalmazás szervert telepített, miközben én a Jenkins-en dolgoztam, integráltam az Atlassian Jirát és a BitBucket-et, és a kód tesztelési lefedettségén is dolgoztam. Ez a mellékprojekt nagyon sikeres volt: gyakorlatilag teljesen automatizáltuk sok folyamatot, szinte 100%-os működést értünk el a fejlesztési szerverünkön, biztosítottuk a nyomon követést, javítottuk a kód tesztelési lefedettségét, és lehetőséget adtunk arra, hogy a Git ágazatokat összekapcsoljuk a Jirában lévő feladatokkal vagy a telepítésekkel. A legtöbb eszköz, amit a DevOps vezetékmenedzsmentünk felépítéséhez használtunk, nyílt forráskódú volt.

Most már értem, mennyire egyszerű volt a DevOps vezetékmenedzsmentünk: nem használtunk olyan kiterjesztéseket, mint a Jenkins fájlok vagy az Ansible. Azonban ez az egyszerű vezetékmenedzsment jól működött, valószínűleg a Pareto-elvnek köszönhetően (más néven 80/20 szabály).

Rövid bevezetés a DevOps-ba és a CI/CD vezetékmenedzsmentbe

Ha megkérdezel néhány embert: "Mi az a DevOps?", valószínűleg több különböző választ kapsz. A DevOps, akárcsak az Agile, azért fejlődött, hogy sok különböző tudományágat magába foglaljon, de a legtöbb ember egyetért abban, hogy a DevOps egy szoftverfejlesztési gyakorlat vagy szoftverfejlesztési életciklus (SDLC), amelynek középpontjában a kultúra megváltoztatása áll, ahol a fejlesztők és nem-fejlesztők léteznek egy környezetben, amelyben:

Azok a műveletek automatizálva vannak, amelyeket korábban kézzel végeztek;
Mindenki azt csinálja, amit a legjobban tud;
Növekszik a telepítések száma egy meghatározott időintervallumban; Növekszik a kapacitás;
Növekszik a fejlesztés rugalmassága.

Bár a megfelelő szoftvereszközök megléte nem az egyetlen dolog, amire szükség van egy DevOps környezet létrehozásához, néhány eszköz elengedhetetlen. A kulcseszköz a folyamatos integráció és folyamatos telepítés (CI/CD). Ezt a folyamatot különböző szakaszok jellemzik (például DEV, INT, TST, QA, UAT, STG, PROD), sok művelet automatizált, és a fejlesztők magas minőségű kódokat írhatnak, elérhetik a rugalmasságot a fejlesztésben és a magas telepítési gyakoriságot.

Ebben a cikkben egy ötlépcsős megközelítést írok le a DevOps csővezeték létrehozására, amely hasonló a következő diagramon ábrázolthoz, nyílt forráskódú eszközök használatával.

1. lépés: CI/CD módszerek

Az első, amire szükséged van, egy CI/CD eszköz. A Jenkins, egy nyílt forráskódú eszköz, amely Java alapú és MIT licenc alatt terjesztett, az a szerszám, amely népszerűvé tette a DevOps irányzatot, és de facto standard lett.

De mi is az a Jenkins? Gondolj rá úgy, mint egy varázslatos univerzális távirányítóra, amely képes kommunikálni különböző szolgáltatásokkal és eszközökkel, valamint szervezni azokat. Maga a CI/CD eszköz, mint a Jenkins, haszontalan, de egyre erősebbé válik, ahogy csatlakozik a különböző eszközökhöz és szolgáltatásokhoz.

A Jenkins csak egy a sok nyílt forráskódú eszköz közül a CI/CD-hez, amelyet a DevOps csővezeték felépítéséhez használhatsz.

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 a CI/CD eszközzel:

Van egy CI/CD eszköze, ami a localhostján fut, de jelenleg nem sok mindent tud tenni. Lépjünk a DevOps világába következő lépésre.

2. lépés: Forráskód-kezelés

A legjobb (és valószínűleg legegyszerűbb) módja annak, hogy ellenőrizze, hogy a CI/CD eszköze varázslatos dolgokat tud csinálni – integrálni egy forráskód-kezelő eszközzel (SCM). Miért van szüksége forráskód-kezelésre? Tegyük fel, hogy alkalmazást fejleszt. Minden alkalommal, amikor egy alkalmazást készít, kódol. Nem számít, hogy Java-t, Python-t, C++-t, Go-t, Ruby-t, JavaScript-et vagy valamelyik trillió programozási nyelvet használ-e. Az Ön által írt kód forráskódnak nevezik. kezdetben, különösen ha egyedül dolgozik, valószínűleg mindent elhelyezhet egy helyi könyvtárban. De amikor a projekt nagyobbá válik és másokat hív meg együttműködni, szüksége van egy módra, hogy megszüntesse a konfliktusokat a módosítások hatékony megosztása során. Szüksége van egy módra az előző verziók visszaállítására is, mert a biztonsági mentések készítése és másolás/beillesztés már elavult. Önnek (és a csapat tagjainak) valami jobb kell.

Itt válik szinte szükségessé a forráskód-kezelő eszköz. Ez az eszköz a kódját tárolja tárolókban, nyomon követi a verziókat és koordinálja a projekt résztvevőinek munkáját.

Bár sok forráskód-kezelő eszköz létezik, a Git a szabvány, és ez igaz. Határozottan javaslom a Git használatát, habár ha úgy tetszik, léteznek más nyílt forráskódú opciók is.

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 pipeline a forráskód-kezelő eszköz hozzáadásával.

A CI/CD eszköz automatizálhatja a forráskód ellenőrzésének, helyrehozásának és a csapattagok közötti együttműködés enyhítési folyamatait. Ez nem rossz? De hogyan alakíthatjuk át ezt működő alkalmazássá, amelyet milliárdok használhatnak és értékelhetnek?

3. lépés: Automatikus összesítő eszköz létrehozása

Kiváló! Ellenőrizheti a kódot, és módosításokat végezhet a forráskód-ellenőrző rendszerben, valamint meghívhatja barátait, hogy közösen dolgozzanak a fejlesztésen. De még nem hozott létre alkalmazást. Ahhoz, hogy webalkalmazását készítsen, azt le kell fordítani és egy telepíthető csomagformátumba kell csomagolni vagy futtatható fájlként kell indítani. (Kérjük, vegye figyelembe, hogy az olyan értelmezett programozási nyelvek, mint például a JavaScript vagy a PHP, nem igényelnek fordítást).

Használja az automatikus build eszközkészletet. Függetlenül attól, hogy melyik build automatizáló eszközt választja, mindegyik ugyanazt a célt szolgálja: a forráskódot egy kívánt formátumba összeállítani, és automatizálni a tisztítási, fordítási, tesztelési és telepítési feladatokat egy adott környezetben. A build eszközök a programozási nyelvétől függően eltérőek, de itt van néhány általános, nyílt forráskódú lehetőség.

Név
Licenc
Programozási nyelv

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Szuper! A build automatizáló eszköz konfigurációs fájljait elhelyezheti a forráskód-kezelő rendszerben, és lehetővé teheti, hogy a CI/CD eszköze mindent összeállítson.

Minden rendben van, ugye? De hol telepítse az alkalmazását?

4. lépés: Webalkalmazás szerver

Jelenleg van egy csomagolt fájlja, amely lehet végrehajtható vagy telepíthető. Ahhoz, hogy bármilyen alkalmazás valóban hasznos legyen, szolgáltatást vagy felületet kell nyújtania, de szüksége van egy konténerre, ahol az alkalmazása elhelyezhető.

A webalkalmazás szerver éppen egy ilyen konténer. A szerver biztosítja a környezetet, amelyben a telepíthető csomag logikája meghatározható. Ezen kívül a szerver felületet biztosít, és webszolgáltatásokat kínál, megnyitva a socket-eket a külvilág számára. Szüksége van HTTP szerverre, valamint valamiféle környezetre (például virtuális gépre) annak telepítéséhez. De egyelőre tegyük fel, hogy erről majd később hallani fog (bár az alábbiakban beszélek a konténerekről).

Számos nyílt forráskódú webalkalmazás szerver létezik.

Név
Licenc
Programozási nyelv

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

A DevOps pipeline-od majdnem készen áll a használatra. Jó munka!

Bár megállhatunk itt és foglalkozhatunk az integrációval önállóan, a kód minősége fontos szempont az alkalmazásfejlesztők számára, amit figyelembe kell venni.

5. lépés: A kód tesztelésének lefedettsége

A tesztek végrehajtása önálló kötelezettség is lehet, de a fejlesztőknek már korai szakaszban fel kell fedezniük a hibákat az alkalmazásban, és javítaniuk kell a kód minőségét annak érdekében, hogy a végfelhasználók elégedettek legyenek. Szerencsére rengeteg nyílt forráskódú eszköz létezik a kód tesztelésére és a minőség javításának javaslatainak kidolgozására. Még jobb, hogy a legtöbb CI/CD eszköz csatlakozhat ezekhez az eszközökhöz és automatizálhatja a folyamatot.

A kód tesztelése két részre osztható: a tesztkeretrendszerek segítenek a tesztek írásában és futtatásában, míg a javaslattételi eszközök segítenek a kód minőségének javításában.

Kód tesztelő rendszerek

Név
Licenc
Programozási nyelv

JUnit
Eclipse Public License
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Kódjavító ajánló rendszerek

Név
Licenc
Programozási nyelv

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Felhívjuk a figyelmet arra, hogy a fent említett eszközök és keretrendszerek többsége Java, Python és JavaScript nyelvekre íródott, mivel a C++ és C# sajátos programozási nyelvek (bár a GCC nyílt forráskódú).

Most, hogy megvalósította a kód lefedettségvisszanyerő eszközöket, a DevOps csővezetéke úgy kell kinézzen, mint az útmutató elején bemutatott diagram.

További lépések

Konténerek

Ahogy már említettem, a szerverét virtuális gépen vagy szerveren helyezheti el, de a konténerek népszerű megoldásnak számítanak.

Mi az a konténer? A rövid magyarázat az, hogy a virtuális gépnek hatalmas operációs rendszermemóriára van szüksége, amely meghaladja az alkalmazás méretét, míg a konténernek csak néhány könyvtárra és konfigurációra van szüksége az alkalmazás futtatásához. Nyilvánvaló, hogy a virtuális gépnek még mindig vannak fontos alkalmazási területei, de a konténer egy könnyű megoldás az alkalmazás, köztük az alkalmazásszerverek hosztolására.

Bár léteznek más konténermegoldások 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

A DevOps-pipe-line-ünk elsősorban az alkalmazások közös fejlesztésére és telepítésére összpontosít, de számos más dolog is elvégezhető DevOps-eszközökkel. Az egyik ilyen a Cloud Infrastructure as Code (IaC) eszközök, amelyeket köztes automatizálási eszközökként is ismernek. Ezek az eszközök segítenek az köztes szoftverek telepítésének, kezelésének és egyéb feladatok automatizálásában. Például, egy automatizáló eszköz képes lehet alkalmazásokat, mint webalkalmazás szerver, adatbázis és megfigyelő eszköz megfelelő konfigurációval kinyerni és az alkalmazás szerverre telepíteni.

Íme néhány nyílt forráskódú köztes automatizálási eszköz:

Ansible: GNU Publikus
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache vagy GPL

Tudjon meg többet arról, hogyan szerezheti meg a keresett szakmát a nulláról, vagy fejlesztheti tudását és fizetését a SkillFactory fizetős online kurzusain: