DevOps eszközök, amelyeket mindenkinek meg kell tanulnia 2020-ban

Kezdje el használni a legjobb DevOps-eszközöket még ma!

A DevOps forradalom végre elfoglalta a világot, és a DevOps eszközök hihetetlenül népszerűvé váltak. A szerviz szerint Google Trends, a „DevOps eszközök” iránti kérelmek száma folyamatosan növekszik, és ez a tendencia folytatódik.

A DevOps módszertana lefedi a teljes szoftverfejlesztési életciklust, így a szakemberek sokféle eszköz közül választhatnak. De mint tudod, egyetlen eszköz sem válhat mindenki számára univerzális eszközzé. Egyes megoldások azonban olyan széles körű funkciókat kínálnak, hogy szinte bármilyen feladatot el tudnak látni.

Ossza fel a DevOps eszközöket kategóriákra, és hasonlítsa össze őket analógokkal:

• eszközök fejlesztése és összeállítása
• automatizálási eszközök tesztelése
• eszközök a telepítés megszervezéséhez
• Futásidejű eszközök
• együttműködési eszközök.

Sikeres és átgondolt megvalósítás DevOps gyakorló mind az öt fent felsorolt ​​csoport hangszereit tartalmazza. Elemezze a projekt jelenlegi eszközkészletét, hogy ne hagyja ki a CI/CD folyamat egy fontos elemét.

Fejlesztési és építési eszközök

Ez az alapja a CI/CD pipeline veremnek. Minden itt kezdődik! A kategória legjobb eszközei több eseményfolyamot is kezelhetnek, és könnyen integrálhatók más termékekkel.

A fejlesztési életciklus ezen szakaszában az eszközök három csoportja létezik:

• verziókezelő rendszer (SCM)
• folyamatos integráció (CI)
• Adatkezelés

A GIT 2020-ban pozitív eredményeket ért el, ezért az SCM-eszköznek zökkenőmentesen kell támogatnia a GIT-t. A CI esetében előfeltétel az összeépítések izolált tárolókörnyezetben történő végrehajtásának és futtatásának képessége. Ami az adatkezelést illeti, megkívánja az adatbázisséma módosításának és az adatbázis karbantartásának képességét az alkalmazás verziójának megfelelően.

SCM + CI eszköz #1

Győztes: GitLab és GitLab-CI

A 2020-as DevOps-ciklus legjobb eszköze kétségtelenül a GitLab, és minden bizonnyal a közeljövőben is az innováció élére fog állni.

A GitLab fő funkciója a Git-tárak kényelmes kezelésének biztosítása. A webes felület intuitív és könnyen használható. A GitLab mindent biztosít, amire szüksége van egy ingyenes verzióban, és SaaS-ként és on-premként érkezik (saját erőforrások használatával a szoftverek tárolására).

Egyetlen másik SCM-eszköz sem használta a folyamatos integrációt (CI) közvetlenül az adattáron, és a GitLab ezt már régóta csinálja. A GitLab-CI használatához hozzá kell adnia egy .gitlab-ci.yml fájlt a forráskód gyökeréhez, és a projekt minden módosítása pontosan a megadottak alapján indítja el a műveleteket. A GitLab és a GitLab-CI méltán elismert vezetők a folyamatos integráció (CI-as-code) területén.

Főbb előnyök

• Megbízhatóság - A termék 2013 óta van a piacon; stabil; jól támogatott.
• Nyílt forráskódú – A GitLab ingyenes verziója nem korlátozza a fejlesztőcsapatoknak szükséges alapvető funkciókat. A fizetős szolgáltatáscsomagok további hasznos szolgáltatásokat nyújtanak a különböző méretű és igényű cégek számára.
• Engrained CI – A piacon egyetlen olyan eszköz sem épített ki folyamatos integrációt közvetlenül az SCM-be, mint a GitLab-CI. A Docker használata problémamentesen biztosítja az elszigetelt buildeket, a beépített jelentések pedig megkönnyítik a hibakeresést. Nincs szükségünk több eszköz egyidejű komplex integrációjára és kezelésére.
• Korlátlan integráció – a GitLab biztosítja az összes szükséges DevOps-eszköz egyszerű integrációját. Ez biztosítja, hogy a fejlesztői és karbantartói csapatok egyetlen információforrással rendelkezzenek alkalmazásaikról bármilyen környezetben.

versenytársak

Részt vett a csatában, de nem nyert

Vannak más népszerű eszközök is ebben a kategóriában, de ezek nem olyan jók, mint a GitLab. És ezért:

GitHub — Ez egy kiváló SaaS verzióvezérlő rendszer kisvállalatok és a fejlesztés korai szakaszai számára. Azon nagyvállalatok számára, amelyek számára fontos, hogy az IP-címeket a saját hálózatukon tartsák, a GitHub egyetlen megoldása az .OVA virtuális gép volt, amely nem támogatja a magas rendelkezésre állású rendszereket. Ez megnehezíti a helyszíni karbantartást, ráadásul az .OVA csak közepes vállalkozások számára alkalmas, különben a szerver egyszerűen összeomlik nagyobb terhelés alatt. A GitHub-műveletek (a közelmúltig, és még nem az on-prem verzióban) vagy a CI-as-code hiánya azt jelenti, hogy külön CI-eszközt kell választania, majd kezelnie kell az integrációt. Végül a GitHub sokkal drágább, mint a GitLab bármelyik verziója.

Jenkins — Bár a Jenkins alapértelmezés szerint szabványnak számít a folyamatos integrációs eszközök között, mindig is hiányoztak a verziókezelési képességek. Kiderült, hogy Jenkinst és valamilyen SCM-eszközt használ. Túl nehéz, ha a GitLab mindkettőre képes. A középszerű UX kialakítás nem alkalmas egy modern webes alkalmazáshoz, és sok kívánnivalót hagy maga után.

BitBucket/Bamboo — Be kell ismernem, hogy egy automatikus vesztes: minek két eszköz, amikor a GitLab mindent teljesen függetlenül csinál. A BitBucket Cloud támogatja a GitLab-CI / GitHub Action funkciót, de egy startupnál nagyobb vállalat sem tudja könnyen megvalósítani. Az on-prem BitBucket szerver nem is támogatja a BitBucket folyamatokat!

#1 Adatkezelő eszköz

Győztes: FlywayDB

A webalkalmazások fejlesztésében általában nem tulajdonítanak jelentőséget az adatbázis-automatizálásnak. Az adatbázisséma-módosítások bevezetésének ötlete az alkalmazás új verzióihoz későn érkezik. A sémamódosítások gyakran oszlopok vagy táblázatok hozzáadását és átnevezését eredményezik. Ha az alkalmazás verziója nem egyezik a séma verziójával, az alkalmazás összeomolhat. Ezenkívül az adatbázis-változások kezelése egy alkalmazás frissítése során kihívást jelenthet, mivel két különböző rendszer létezik. A FlyWayDB mindezen problémákat megoldja.

Főbb előnyök

• Adatbázis-verziókezelés – A Flyway lehetővé teszi az adatbázis-verziók létrehozását, az adatbázis-migrálások nyomon követését, valamint a sémamódosítások egyszerű átvitelét vagy visszaállítását további eszköz nélkül.
• Bináris vagy beágyazott – Választhatjuk, hogy a Flyway-t az alkalmazás részeként vagy bináris végrehajtható fájlként futtatjuk. A Flyway indításkor ellenőrzi a verziókompatibilitást, és elindítja a megfelelő migrációt, szinkronban tartva az adatbázis- és alkalmazásverziókat. A cmd line ad-hoc parancs futtatásával rugalmasságot biztosítunk a meglévő adatbázisokhoz anélkül, hogy a teljes alkalmazást újra kellene építeni.

versenytársak

Részt vett a csatában, de nem nyert

Ezen a területen nincs sok eszköz. Nézzünk ezek közül néhányat:

LiquiBase - A Liquibase a FlywayDB-re hasonlít. Szeretném felállítani a Flyway tetejére, ha lenne a csapatomban valaki, aki több tapasztalattal rendelkezik a Liquibase-szal.

Flocker - Csak konténeres alkalmazásokhoz használható. A konténeres adatbázisok sikeres futtatásához mindent tökéletesen meg kell tervezni. Javaslom az RDS (Relational Database Service) használatát adatbázisokhoz, és nem tanácsos fontos információkat tárolóban tárolni.

Automatizálási eszközök tesztelése

Kezdjük a tesztautomatizálási eszközök tárgyalását azzal, hogy osztályozzuk őket a tesztelési piramis alapján.

A tesztelési piramisnak (teszteknek) 4 szintje van:

• Egységtesztek – Ez a teljes automatizált tesztelési folyamat alapja. Több egységtesztnek kellene lennie a többi teszttípushoz képest. A fejlesztők egységteszteket írnak és futtatnak, hogy megbizonyosodjanak arról, hogy az alkalmazás egy része (az úgynevezett "egység") megfelel a tervnek, és a várt módon viselkedik.
• Komponens tesztek – A komponens tesztelésének fő célja a tesztobjektum bemeneti/kimeneti viselkedésének ellenőrzése. Gondoskodnunk kell arról, hogy a tesztobjektum funkcionalitása a specifikációnak megfelelően megfelelően legyen implementálva.
• Integrációs tesztek – A tesztelés olyan típusa, amelyben az egyes szoftvermodulokat kombinálják és csoportosan tesztelik.
• Végpontok közötti tesztek – Ez a lépés magától értetődő. Felügyeljük a teljes alkalmazást, és gondoskodunk arról, hogy a tervek szerint működjön.

Mivel az egységteszteket és az összetevők tesztelését csak a fejlesztők végzik, és ezek gyakran programnyelv-specifikusak, ezeket az eszközöket nem értékeljük a DevOps tartományhoz.

#1 Integrációs tesztelőeszköz

Győztes: Uborka

A Cucumber egyetlen élő dokumentumban egyesíti a specifikációkat és a tesztdokumentációkat. A specifikációk mindig naprakészek, mivel az Cucumber automatikusan teszteli azokat. Ha a semmiből szeretne automatizált tesztelési keretrendszert felépíteni, és modellezni szeretné a felhasználói viselkedést egy webalkalmazásban, akkor a Selenium WebDriver Java és Cucumber BDD-vel nagyszerű módja az uborka megtanulásának és megvalósításának egy projektben.

Főbb előnyök

• BDD megközelítés (Behavior Driven Development – ​​„fejlődés viselkedésen keresztül” a „tesztvezérelt fejlesztés” megközelítéssel szemben) – Az uborkát BDD tesztelésre tervezték, eredetileg erre a feladatra hozták létre.
• Élő Dokumentáció - A dokumentálás mindig fájdalom! Mivel a tesztek kódként vannak megírva, az Cucumber teszteli az automatikusan generált dokumentációt, hogy megbizonyosodjon arról, hogy a tesztek és a dokumentáció szinkronban vannak.
• Támogatás - Számos eszköz közül választhatunk, de az Uborka rendelkezik a szükséges anyagi forrásokkal és jól szervezett támogatási rendszerrel, hogy bármilyen nehéz helyzetben segítse a felhasználókat.

versenytársak

Részt vett a csatában, de nem nyert

Az egyéb keretrendszerek és technológia-specifikus eszközök közül egyedül az Uborka tekinthető univerzális megoldásnak.

Teljes körű tesztelési eszközök

A végpontok közötti tesztelés során két kulcsfontosságú pontra kell összpontosítania:

• funkcionális tesztelés
• Stressz tesztelés.

A funkcionális tesztelés során ellenőrizzük, hogy minden, amit szeretnénk, valóban megtörténik-e. Például, amikor rákattintok az SPA-m (egyoldalas jelentkezés) egyes elemeire, kitöltöm az űrlapokat és kiválasztom a „Küldés” lehetőséget, az adatok megjelennek az adatbázisban, és a képernyőn a „Siker!” üzenet jelenik meg.

Azt is fontos ellenőriznünk, hogy bizonyos számú, ugyanazt a forgatókönyvet futtató felhasználó hibamentesen feldolgozható-e.

A kétféle tesztelés hiánya jelentős hátrányt jelent a CI/CD-folyamatban.

#1. végpontok közötti tesztelési eszköz. Funkcionális tesztelés

Győztes: SoapUI Pro

A SoapUI már régóta az API-tesztelési területen van, mióta a SOAP alapú webszolgáltatások a szabványok. Bár már nem hozunk létre új SOAP szolgáltatásokat, és az eszköz neve nem változott, ez nem jelenti azt, hogy nem fejlődött. A SoapUI kiváló keretrendszert biztosít az automatizált háttérfunkciós tesztek létrehozásához. A tesztek egyszerűen kombinálhatók a folyamatos integrációs eszközökkel, és a CI/CD folyamat részeként használhatók.

Főbb előnyök

• Részletes dokumentáció – A SoapUI meglehetősen régóta a piacon van, így számos online forrás segít megérteni, hogyan kell teszteket beállítani.
• Könnyű használat – Bár az eszköz több protokollt is támogat az API-k teszteléséhez, a SoapUI közös felülete több szolgáltatáshoz megkönnyíti a tesztek írását.

versenytársak

Részt vett a csatában, de nem nyert

Szelén egy másik nagyszerű hangszer ebben a csoportban. Javaslom a használatát, ha Java alapú alkalmazást készít és futtat. Ha azonban egy teljes webalkalmazást készít több technológiával, az nehézkessé válhat a nem Java összetevők számára.

#1. végpontok közötti tesztelési eszköz. Stressz tesztelés

Győztes: LoadRunner

Magyarázat: Amikor eljön az ideje az alkalmazás minden elemének betöltési tesztjének, csak a LoadRunner tudja végrehajtani a feladatot. Igen, kezdetben drága és nehéz, de a LoadRunner az egyetlen eszköz, amely műszaki építészként teljes bizalmat ad abban, hogy az új kód extrém terhelési körülmények között is működni fog. Emellett úgy gondolom, hogy itt az ideje, hogy a LoadRunnert inkább fejlesztőcsapatok vegyék át, mintsem tesztelőcsapatok.

Főbb előnyök

• Kiterjedt dokumentáció – A LoadRunner már jó ideje a piacon van, így számos online forrás segít megérteni, hogyan kell beállítani a terhelési teszteket.
• Protokolltámogatás – A Load Runner mindent támogat, az ODBC-től az AJAX-ig, HTTPS-ig és minden más nem triviális protokollig, amelyet az alkalmazás használhat. Igyekszünk nem több eszközt használni a terhelési teszteléshez, mivel ez csak bonyolítja a folyamatot.

versenytársak

Részt vett a csatában, de nem nyert

Ismétlem, ezen a területen nem sok univerzális eszköz létezik, ezért a legjobb megoldás az, amely bármilyen környezetben, bármilyen technológiával működik.

Telepítési eszközök

A telepítési eszközök valószínűleg a fejlesztés legkevésbé megértett aspektusai. Az alkalmazás kódjának és funkcióinak mély ismerete nélkül működő operatív csapat számára nehéz ilyen eszközöket használni. A fejlesztők számára a telepítéskezelés új feladatot jelent, így még nincs elegendő tapasztalatuk az ilyen eszközökkel való munkavégzésben.

Először is osszuk fel az összes telepítési eszközt három alkategóriára:

• műtárgykezelés
• konfiguráció-menedzsment
• telepíteni.

#1 Műtermékkezelő eszköz

Győztes: összefüggés

A Nexus műterméktár szinte minden fontosabb technológiát támogat, a Java-tól az NPM-en át a Dockerig. Ezzel az eszközzel tárolhatjuk az összes használt műterméket. A távoli csomagkezelők proxy használata szintén jelentősen felgyorsítja a CI-építési folyamatot, így a csomagok könnyebben hozzáférhetők az összeállításhoz. Egy másik előny az, hogy teljes képet kaphat több szoftverprojektben használt összes csomagról, blokkolva a nem biztonságos nyílt forráskódú csomagokat (támadási vektorként működhetnek).

Főbb előnyök

• Műszaki támogatás - Megbízható termék; jól támogatott.
• Nyílt forráskódú – Az ingyenes verzió nem korlátozza a fejlesztőcsapatoknak szükséges alapvető funkciókat.

#1 Konfigurációkezelő eszköz

Győztes: Ansible

Ansible egy egyszerű okból vezető: hontalan. Korábban a hasonló eszközök a konfigurációs állapotkezelésre összpontosítottak. Indításkor egy ilyen eszköz, miután megkapta a kívánt konfigurációt, megpróbálja kijavítani az aktuális alkalmazáskonfigurációt. Az új megközelítéssel pedig csak állapot nélküli összetevők vannak jelen. A kód új verziói olyan melléktermékek, amelyek a meglévők helyére kerülnek. Ez egyfajta mulandó, rövid távú környezetnek tekinthető.

Főbb előnyök

• Állapot nélküli – A Playbook a telepítési gépről indul, és a célkiszolgálókon fut le. Nem kell aggódnom a távoli objektum állapota miatt, ha olyan eszközt használok, mint a Packer, hogy telepíthető objektumokat hozzak létre.
• Nyílt forráskódú – A CentOS-hoz hasonlóan az Ansible-t is támogatja a RedHat. Segít fenntartani a közösséget, és kiváló minőségű, könnyen használható modulokat biztosít.
• Tesztelés Moleculával (Ansible framework) – Mivel a konfigurációkezelés kód, mint minden más, a tesztelés elengedhetetlen. A Molecule Ansible szerepkör-tesztelési keretrendszere hibátlanul működik, biztosítva, hogy a konfiguráció ugyanolyan minőségű legyen, és ugyanazt a CI/CD folyamatot kövesse, mint az alkalmazás kódja.
• YAML – Más eszközökkel összehasonlítva a YAML könnyebben érthető. Mivel a konfigurációkezelés jellemzően új kihívást jelent a DevOps gyakorlatokat megvalósítók számára, az egyszerűség az ütőkártya.

versenytársak

Részt vett a csatában, de nem nyert

OpsCode séf — Szakácskönyv-fejlesztőként kezdtem a DevOps pályafutásomat. A Ruby és a Chef természetesen nagyon kedvesek a szívemnek, de egyszerűen nem oldják meg a modern állapot nélküli, felhőalapú alkalmazások problémáit. Az OpsCode Chef nagyszerű eszköz a hagyományosabb alkalmazásokhoz, de ebben a cikkben a jövőre összpontosítunk.

Báb — A Puppetnek soha nem volt sok rajongója, főleg Chefhez és Ansible-hez képest. Kiválóan alkalmas a hardver kiépítésére és a vele való munkavégzésre, de hiányzik belőle a webalkalmazások modern konfigurációkezelési támogatása.

1. telepítési eszköz

Győztes: Terraform

A Terraform megoldja az infrastruktúra kódként való leírásának problémáját, a hálózati összetevőktől a teljes szerverképekig. Ez a termék hosszú utat tett meg a kezdeti kiadás óta, annyi beépülő modult hoztak létre, és olyan erős közösséget építettek fel, hogy minden telepítési forgatókönyv esetén biztosan kap segítséget. Bármilyen típusú környezet (helyszíni, felhőben vagy máshol) támogatása páratlan. Végül, a legújabb verzió ugyanazokat a logikai funkciókat és osztályokat kínálja a HCL-ben, mint bármely más hagyományos programozási nyelv, így a Terraform könnyen és gyorsan megragadható a fejlesztők számára.

Főbb előnyök

• Környezet-agnosztikus – A Terraform olyan funkciókat használ, amelyek interfészként működnek a Terraform-kód, az összes API és a belső logika között az infrastruktúra-szolgáltatóval való kommunikációhoz. Ez azt jelenti, hogy csak egy eszközt fogok elsajátítani, majd bárhol dolgozhatok.
• Nyílt forráskódú – Nehéz felülmúlni az ingyenes eszközöket! Közösségi támogatás a legmagasabb szinten.

versenytársak

Részt vett a csatában, de nem nyert

AWS felhőképződés — Még akkor is, ha csak az AWS felhőkörnyezetben dolgozik, előfordulhat, hogy a következő munkája más eszközt használ. Minden idejét és energiáját egyetlen platformnak szentelni rövidlátó döntés. Ezenkívül számos új AWS-szolgáltatás gyakran elérhető Terraform-modulként, mielőtt elérhetővé válna a CloudFormationben.

Futásidejű eszközök

Minden fejlesztési projekt végső célja az alkalmazás termelésbe helyezése. A DevOps világában szeretnénk teljes mértékben tisztában lenni a környezetünk minden lehetséges problémájával, és a manuális beavatkozást is minimalizálni szeretnénk. A megfelelő futásidejű eszközök kiválasztása elengedhetetlen az alkalmazásfejlesztési nirvána eléréséhez.

Futóidejű eszközök alkategóriái:

• X-as-a-service (XaaS)
• hangszerelés
• megfigyelés
• fakitermelés.

X-tool-as-a-service #1

Győztes: Az Amazon Web Services

Az Amazon mindig is vezető szerepet töltött be a felhőtechnológiák terén, de ez nem áll meg itt: a fejlesztők számára kínált új szolgáltatások sokfélesége felnyitja a szemet. Hozd bármilyen technológiát és sablont az AWS-hez, és az elkészül és fut. Az eszköz költsége meglehetősen ésszerű: hasonlítsa össze a saját adatközpontjában lévő berendezések összeszerelésével, kezelésével és karbantartásával. Az ingyenes verzió lehetővé teszi a kísérletezést és a megfelelő döntés meghozatalát, mielőtt pénzt költene.

Főbb előnyök

• Elterjedtség – Ha van tapasztalata az alkalmazások AWS-ben való építésében, bárhol dolgozhat. A vállalkozások szeretik az AWS-t, és az induló vállalkozások is értékelik az alacsony költségét.
• Az ingyenes verzió valóban jelentős tényező, amely megkülönbözteti az AWS-t társaitól. Hadd próbáljam ki a szolgáltatást és nézzem meg, hogyan működik, mielőtt vásárlási döntést hozok, nem akarok több ezer dollárt költeni valami feleslegesre. Az ingyenes verzió mindig elég ahhoz, hogy bármilyen koncepciót teszteljek.

versenytársak

Részt vett a csatában, de nem nyert

Égszínkék „Az Azure hosszú utat tett meg az első kiadás óta, és ez dicséretes. A különbözőség vágya azonban a szolgáltatások furcsa elnevezéséhez vezetett, ami gyakran megnehezíti a munkát. Mit jelent a „blob storage”? És bár a .NET kód jobban teljesít a Microsoft ökoszisztémában, nem valószínű, hogy csak .NET-et fog használni az alkalmazás minden összetevőjéhez.

Heroku — A megbízhatóság és az átláthatóság alacsony szintje miatt soha nem vezetnék mást, mint egy személyes projektet a Heroku-n, ezért a cégek ne használják platformként. A Heroku kiválóan alkalmas arra, hogy valamit demonstráljon egy blogon, de gyakorlati használatra - "Nem, köszönöm!"

#1 Hangszerelési eszköz

Győztes: openshift

Valószínűleg Dockert vagy más tárolót használ az alkalmazásveremben. A kiszolgáló nélküli alkalmazások nagyszerűek, de nem biztos, hogy minden architektúrához illeszkednek. A konténerek futtatása hangszerelési platform nélkül egyszerűen nem fog működni. A Kubernetes Core (K8s) páratlan a biztonság és a szerszámok terén. Az OpenShift az egyetlen Kubernetes-alapú platform, amely képes a Source2Image gyűjtésére, támogatja az automatizált telepítést a podokban, valamint támogatja a nyomon követést és a felügyeletet. Az OpenShift futtatható on-prem, felhőben, vagy on-prem és felhőben egyszerre.

Főbb előnyök

• Beépített biztonság – A K8s biztonságának kezelése felsőfokú végzettséget igényelhet. Minden részletet alaposan át kell gondolni és figyelembe kell venni! Az OpenShiftbe alapértelmezés szerint beépített biztonsági mechanizmusok leveszik a fejlesztők terheit, és biztonságosabb platformot biztosítanak az alkalmazások számára.
• All-in-one megoldás – Az alap K8-asokkal ellentétben, amelyek alapértelmezés szerint nem tartalmaznak terheléselosztó eszközöket, az OpenShiftben minden megtalálható. Használhatom konténerek létrehozására és tárolására, CI/CD-eszközök futtatására, külső folyamatok kezelésére, kulcsok kezelésére és még sok másra. Bár a grafikus felhasználói felület még messze van a tökéletestől, az API-alapú megközelítés azt jelenti, hogy mindent le lehet írni egy szkriptben. A K8-hoz készült többi grafikus felhasználói felülettel ellentétben az OpenShift sokkal könnyebbé teszi a Kubernetes alapjainak megtanulását. Még csak diplomát sem kell szerezned!

versenytársak

Részt vett a csatában, de nem nyert

Docker Raj - A Docker Swarm megpróbálta leegyszerűsíteni a K8-asokat azzal, hogy sok mindentől megszabadult. Nagyszerű kis alkalmazásokhoz, de vállalati alkalmazásokhoz egyszerűen nem működik. Ezenkívül az olyan megoldások, mint az AWS ECS, hasonló megközelítést alkalmaznak, de megkönnyítik a más szolgáltatásokkal való együttműködést, amelyekkel szintén kommunikálhatok (Lambda, IAM stb.).

Monitoring eszköz #1

Győztes: Új ereklye

A New Relic korai kiadásai egy dolgot jól teljesítettek: az APM (Application Performance Monitoring) figyelést. Ez most egy teljes funkcionalitású megfigyelő eszköz, amely lehetővé teszi a szerver, a tároló, az adatbázis teljesítményének, a végfelhasználói élmény figyelésének és természetesen az alkalmazások teljesítményének figyelését.

Főbb előnyök

• Könnyű használhatóság – Amikor rendszermérnökként dolgoztam, számos megfigyelőeszközt használtam, de még soha nem találkoztam olyan egyszerű és könnyen használható eszközzel, mint a New Relic. SaaS, tehát nem kell saját kezűleg telepítenie.
• Végpontok közötti láthatóság – Más eszközök az alkalmazás egy adott elemét próbálják figyelni. Például a processzorhasználat vagy a hálózati forgalom mérőszáma, de mindezt átfogóan kell figyelni, hogy az alkalmazás megfelelően működjön. Az új Relic lehetővé teszi, hogy összes adatát egyesítse, hogy átfogó képet kapjon arról, mi történik.

versenytársak

Részt vett a csatában, de nem nyert

Zabbix — Az első és kedvenc felügyeleti rendszerem, de a felhőtechnológiák és az APM-alkalmazások teljesítményének felügyelete terén való fejlődés elmaradása miatt a múltban maradt. A Zabbix továbbra is jól végzi a hagyományos szerver-infrastruktúra-figyelést, de nagyjából ennyi.

DataDog — Túlságosan az alkalmazás éles környezetének kezelési folyamatára összpontosított, nem magára a kódra. A fejlesztőket bevonó DevOps csapatokkal nem kell nehezen használható eszközökre hagyatkoznunk a csúcsminőségű támogatás biztosításához.

Naplóeszköz #1

Győztes: Splunk

Splunk-kal nehéz felvenni a versenyt! Sokáig vezető szerepet tölt be a fakitermelésben, és továbbra is jobban csinálja, mint bárki más. Az on-prem és SaaS ajánlatokkal bárhol használhatja a Splunkot. A nagy hátránya az ára: a Splunk még mindig rohadt drága!

Főbb előnyök

• Átterjedtség – A vállalkozások szeretik a Splunk-ot, és a cégeknek van pénzük megvenni.
• Bár a startupok igyekeznek megtéríteni a költségeket, számos funkció megoldható a nyílt forráskódú analógoknak köszönhetően.
• Karbantarthatóság – Egyszerűen fogalmazva, a Splunk működik és jól teszi. Számos alapértelmezett beállítással és használatra kész funkcióval rendelkezik. Nem kell időt vesztegetni a dokumentáció olvasására és a Splunk működésére vagy bármi megfejtésére.

versenytársak

Részt vett a csatában, de nem nyert

ELK Stack (ElasticSearch, LogStash és Kibana) "Úgy tűnik, ezek az eszközök a kedvencek, mert még a máját sem kell eladnia használatukhoz." A naplók készletének növekedésével és a fedélzeten lévő alkalmazások számának növekedésével azonban a munka egyre nehezebbé válik. A Splunkhoz képest az ELK Stack használatával sokkal több időt töltöttem az eszközök beállításával, mielőtt bármilyen irányítópultot létrehoztam volna, mint valaha.

Együttműködési eszközök

A DevOps elsősorban a szervezet kultúrájának megváltoztatásáról szól. Egyetlen eszköz megvásárlása sem változtatja meg egyik napról a másikra a jelenlegi gyakorlatot, de mindenképpen ösztönözheti az együttműködést és az interakció új módjait.

Az együttműködési eszközök alkategóriái:

• feladatkövetés
• ChatOps
• dokumentáció.

#1 Problémakövető eszköz

Győztes: Jira

A Jira megőrzi vezető pozícióját, bár a verseny ezen a területen fokozódik. A Jira hihetetlen rugalmassága lehetővé teszi a fejlesztő és karbantartó csapatok számára a projekt- és sprintfeladatok kezelését. Az Agile terminológiát használó beépített szabványok megkönnyítik a hagyományos munkamódszerekről a hatékonyabb folyamatokra való áttérést.

Főbb előnyök

• Népszerűség – Sok más eszközhöz hasonlóan a Jira-t is szinte mindenhol használják. A kis csapatok az olcsóbb, könnyebben elérhető verziót használják, és mindent megkapnak, amire szükségük van, míg a nagyobb cégek megengedhetik maguknak a drágább licencet.
• Integrációk – A Jira úttörő a maga területén. Ez a tény és a termék gyors fejlődése oda vezet, hogy más cégek a Jira-t választják saját integrációik létrehozására, ezzel is növelve az eszköz értékét. A Jira-t az ebben a cikkben felsorolt ​​összes eszközzel egy kis konfigurációval azonnal integrálhatjuk.

versenytársak

Részt vett a csatában, de nem nyert

Trello — A Trello gyorsan népszerűvé vált ingyenes Kanban eszközének köszönhetően. Amint azonban a folyamatok méreteződnek, és a feladatok tucatjairól több ezerre vált, a Trellóban nehéz lesz navigálni, keresni és jelentést készíteni róla.

Pivotal Tracker — Nagy rajongója voltam ennek az eszköznek, amikor egy startupnál dolgoztam. A Pivotal Tracker azonban inkább a termékmenedzsmentre összpontosít, nem pedig a technikai feladatokra. Bár a Jira termékkezelése kissé összetettebb, ott is megvalósítható további eszköz használata nélkül.

ChatOps eszköz #1

Győztes: MatterMost

Magyarázat: Talán a legnagyobb meglepetés számodra a válogatásomban, és ez jó hír! A MatterMost azáltal vált népszerűvé, hogy kivette a legjobbat a korábbi eszközökből, de azokat azonnali használatra helyezte. Ez nagyon fontos a vállalatok számára: a MatterMost lehetővé teszi az adatok vezérlését, és segít integrálni azokat helyileg futó eszközökkel. Többé nem kell kimennünk a tűzfalon, hogy ellenőrizzük a munkahelyi csevegéseket.

Főbb előnyök

• Nyílt forráskódú – A MatterMost nyílt forráskódú verziója kiválóan működik közepes és nagy csapatok számára egyaránt. Ellentétben a Slack ingyenes csomagjával, amely törli az üzenetelőzményeket, a saját szerver futtatása azt jelenti, hogy minden adatát megőrzi.
• Integrációk – Mivel az API majdnem 100%-ban a Slack API-n alapul, szinte minden Slack-integráció közvetlenül használható a MatterMosttal.

versenytársak

Részt vett a csatában, de nem nyert

Laza — Slack menő, de ezek a srácok annyira megnőttek, hogy elkezdtek profitot keresni. Közeledik a vállalkozás megtérülési szakasza, ami elveszi fő értéküket: a Slack ingyenesen nyújtott szolgáltatásokat; Az ingyenes verzió legfontosabb hátránya a csevegési előzmények törlése.

Microsoft csapatok — Próbáljon meg egy Microsoft-terméket integrálni olyasmivel, ami nem a Microsoft tulajdona... Sok sikert! Ennyit tudok mondani erről az eszközről!

Dokumentációs eszköz #1

Győztes: Összefolyásánál

A minőségi műszaki dokumentáció elkészítése és karbantartása összetett folyamat, függetlenül attól, hogy milyen eszközt használ. Bár a közelmúltban számos SaaS-dokumentációs eszköz jelent meg a piacon, nehezen tudnám kiszervezni a kritikus fontosságú alkalmazások műszaki dokumentációjának tárolását harmadik félre. Célszerű az adatokat és dokumentumokat on-prem tárolni, és ezt a Confluence így oldja meg.

Főbb előnyök

• Könnyen kezelhető – A legtöbb önálló eszköz beállítása és működtetése kissé bonyolult lehet, és karbantartása némi tudást igényel. A Confluence Server 10 vagy 10,000 XNUMX felhasználó számára kiválóan működik.
• Bővítmények – Elismerés a Confluence-nek a gyönyörű, könnyen használható navigációért, és a plugin hozzáadásának lehetősége szinte mindenhez felszabadítja a Wiki-szerű lehetőségeket.

versenytársak

Részt vett a csatában, de nem nyert

Olvasd el a dokumentumokat — Menő a nyílt forráskódhoz, de ne is gondoljon arra, hogy itt tárolja a kritikus tudást.

Árleszállítás - Kiválóan alkalmas kód dokumentálására, de nehéz feladni az architektúrát, folyamatokat vagy más típusú dokumentációt a MarkDown specifikus formázása miatt.

Jekyll — A műszaki ismeretek dokumentálásakor nem akarok új statikus oldalt létrehozni, amely minden változásnál kitelepül. A Confluence egyszerű verziókezelő rendszere nagyban leegyszerűsíti a belső dokumentációt.

Összefoglalva:

Szó szerint több száz DevOps-eszköz van a piacon, ami megnehezíti annak meghatározását, hogy melyiket kell használni, és mikor kell azokat implementálni. Kövesse ezt az egyszerű útmutatót a DevOps eszközök kiválasztásához egy teljes CI/CD folyamathoz.

Ügyeljen arra, hogy mind az öt kategóriából válasszon eszközöket:

• eszközök fejlesztése és összeállítása
• automatizálási eszközök tesztelése
• telepítési eszközök
• Futásidejű eszközök
• együttműködési eszközök.

Fő ajánlás: Automatizálj mindent!

Köszönöm Zach Shapiro!

Forrás: will.com