Vytvorenie prvej DevOps reťaze v piatich krokoch pre začiatočníkov.
DevOps sa stal zázrakom pre príliš pomalé, roztrhnuté a iné problematické procesy vývoja. Ale vyžaduje si minimálne znalosti o DevOps. Tu sa preskúma takéto pojmy ako DevOps reťazec a ako ho vytvoriť v piatich krokoch. Nie je to úplný sprievodca, ale len "ryba", ktorú je možné rozšíriť. Začneme s históriou.
Moje zoznámenie s DevOps
Niekedy som pracoval s cloudmi v Citi Group a vyvíjal webovú aplikáciu IaaS na správu cloudovej infraštruktúry Citi, ale vždy ma zaujímalo, ako optimalizovať vývojový reťazec a zlepšiť kultúru medzi vývojármi. Greg Lavender, náš technický riaditeľ pre cloudovú architektúru a infraštruktúru, mi odporučil knihu . Skvele vysvetľuje princípy DevOps, pričom sa číta ako román.
V tabuľke na rubovej strane je zobrazené, ako často firmy uvoľňujú nové verzie:
Ako Amazon, Google a Netflix zvládajú toľko uvoľnení? Je to jednoduché: pochopili, ako vytvoriť takmer ideálny DevOps reťazec.
U nás v Citi to bolo úplne inak, kým sme neprešli na DevOps. Vtedy mala moja tím rôzne prostredia, ale nasadenie na vývojový server sme robili ručne. Všetci vývojári mali prístup len k jednému vývojovému serveru na báze IBM WebSphere Application Server Community Edition. Pri pokuse o súčasné nasadenie server "spadol", a museli sme sa zakaždým "bolestne" dohodnúť. A tiež sme mali nedostatočné pokrytie kódu testami, pracný ručný proces nasadenia a žiadnu možnosť sledovať nasadenie kódu podľa úlohy alebo požiadavky zákazníka.
Bolo jasné, že je potrebné urgentne niečo robiť, a našiel som spolupracovníka, ktorý mal rovnaké názory. Rozhodli sme sa spoločne vytvoriť prvú DevOps reťazec — on nastavil virtuálny stroj a server aplikácií Tomcat, zatiaľ čo som sa venoval Jenkinsu, integrácii s Atlassian Jira a BitBucket, ako aj pokrytiu kódu testami. Projekt bol úspešný: plne sme automatizovali reťazec vývoja, dosiahli sme takmer 100% bezporuchovú prevádzku vývojového servera, mohli sme sledovať a zlepšovať pokrytie kódu testami, a vetvu Git bolo možné priradiť k nasadeniu a úlohe Jira. A takmer všetky nástroje, ktorými sme vytvárali DevOps reťazec, boli s otvoreným zdrojovým kódom.
V skutočnosti bola reťazec zjednodušený, pretože sme ani nepoužívali rozšírené konfigurácie pomocou Jenkinsa alebo Ansibla. Ale podarilo sa nám to. Možno je to dôsledok princípu (takzvané pravidlo 80/20).
Stručný popis reťazca DevOps a CI/CD
DevOps má rôzne definície. DevOps, podobne ako Agile, zahŕňa rôzne disciplíny. Ale väčšina súhlasí s nasledujúcou definíciou: DevOps je metóda, alebo životný cyklus vývoja softvéru, ktorého hlavným princípom je vytvorenie kultúry, kde sú vývojári a ostatní zamestnanci "na jednej vlne", ručná práca je automatizovaná, každý sa zaoberá tým, čo najlepšie ovláda, zvyšuje sa frekvencia dodávok, zvyšuje sa produktivita a zlepšuje sa flexibilita.
A hoci samotné nástroje nestačia na vytvorenie prostredia DevOps, bez nich sa nezaobídeme. Najdôležitejším z nich je nepretržitá integrácia a nepretržité dodávanie (CI/CD). V reťazci existujú pre každé prostredie rôzne fázy (napríklad DEV (vývoj), INT (integrácia), TST (testovanie), QA (kontrola kvality), UAT (akceptačné testovanie používateľmi), STG (príprava), PROD (používanie)), manuálne úlohy sú automatizované, vývojári môžu vytvárať kvalitný kód, realizujú jeho dodávku a môžu sa ľahko prispôsobovať.
Tento článok popisuje, ako vytvoriť reťazec DevOps v piatich krokoch, ako je zobrazené na obrázku nižšie, pomocou nástrojov s otvoreným zdrojom.
Prejdime k veci.
Krok 1: Platforma CI/CD
Najprv potrebujete nástroj CI/CD. Jenkins je otvorený nástroj CI/CD napísaný v Jave s licenciou MIT, ktorý začal popularizáciu hnutia DevOps a stal sa de facto štandardom pre CI/CD.
A čo je to Jenkins? Predstavte si, že máte čarovný ovládač pre najrôznejšie služby a nástroje. Sám o sebe je nástroj CI/CD, ako Jenkins, bezcenný, ale s rôznymi nástrojmi a službami sa stáva všemocným.
Okrem Jenkinsa existuje mnoho ďalších otvorených nástrojov, vyberte si ktorýkoľvek.
Takto vyzerá proces DevOps s nástrojom CI/CD
Na vašom localhoste máte nástroj CI/CD, ale zatiaľ nie je veľa čo robiť. Prejdime k nasledujúcemu kroku.
Krok 2: správa verzií
Najlepší (a asi aj najjednoduchší) spôsob, ako overiť mágiu nástroja CI/CD, je integrovať ho s nástrojom na správu verzií (source control management, SCM). Prečo je potrebná správa verzií? Predpokladajme, že vyvíjate aplikáciu. Píšete ju v Jave, Pythone, C++, Go, Rubyn, JavaScripte alebo v akomkoľvek inom jazyku, ktorých je skutočne veľa. To, čo píšete, sa nazýva zdrojový kód. Na začiatku, najmä ak pracujete osamotene, môžete všetko uchovávať v lokálnom adresári. Ale keď projekt narastie a pripojí sa k nemu viac ľudí, potrebujete spôsob, ako zdieľať zmeny v kóde, ale pritom sa vyhnúť konfliktom pri zlúčení zmien. A navyše, potrebujete nejaký spôsob, ako obnoviť predchádzajúce verzie bez použitia záloh a bez metódy copy-paste pre súbory s kódom.
A tu sa bez SCM nezaobídete. SCM uchováva kód v repozitároch, spravuje jeho verzie a koordinuje ho medzi vývojármi.
Nástrojov SCM je množstvo, ale de facto štandardom sa právom stal Git. Odporúčam používať práve ten, ale existujú aj iné možnosti.
Takto vyzerá DevOps pipeline po pridaní SCM.
Nástroj CI/CD môže automatizovať nahrávanie a sťahovanie zdrojového kódu a spoluprácu v tíme. Nie je to zlé? Ale ako túto situáciu premeniť na funkčnú aplikáciu, obľúbenú miliardami používateľov?
Krok 3: nástroj automatizácie zostavenia
Všetko ide ako má. Môžete nahrávať kód a zaznamenávať zmeny v systéme správy verzií, a tiež pozvať priateľov, aby s vami pracovali. Ale zatiaľ nemáte žiadnu aplikáciu. Aby to bola webová aplikácia, treba ju skompilovať a zabaliť do balíka na dodanie alebo spustiť ako spustiteľný súbor. (Interpretovaný programovací jazyk, ako JavaScript alebo PHP, skompilovať netreba.)
Použite nástroj automatizácie zostavenia. Nezáleží na tom, ktorý nástroj si vyberiete, on zostaví kód do požadovaného formátu a automatizuje čistenie, kompiláciu, testovanie a dodanie. Nástroje na zostavovanie sa líšia v závislosti od jazyka, ale zvyčajne sa používajú nasledujúce open-source možnosti.
Skvele! Teraz vložíme konfiguračné súbory nástroja automatizácie zostavenia do systému správy verzií, aby ich nástroj CI/CD zozbieral.
Vyzerá to, že všetko je v poriadku. Ale kam to teraz všetko nasadiť?
Krok 4: server webovej aplikácie
Tak, máte zabalenej soubor, který lze spustit nebo nasadit. Aby aplikace skutečně byla užitečná, musí mít nějakou službu nebo rozhraní, ale potřebujete ji někam umístit.
Webovou aplikaci můžete umístit na server webových aplikací. Server aplikací poskytuje prostředí, kde se může spustit programová logika z balíčku, vykreslit rozhraní a otevřít webové služby přes socket. Potřebujete HTTP server a několik dalších prostředí (například virtuální stroj), abyste nainstalovali server aplikací. Zatím si představme, že se s tím vším vyznáte v průběhu (ačkoli o kontejnerech budu mluvit níže).
Existuje několik otevřených serverů webových aplikací.
Už máme téměř funkční DevOps řetězec. Skvělá práce!
Vlastně se tady můžete zastavit, dál to zvládnete sami, ale stojí za to ještě probrat kvalitu kódu.
Krok 5: Testovací pokrytí
Testování zabírá spoustu času a sil, ale je lepší najít chyby hned a vylepšit kód, aby se uživatelé potěšili. K tomuto účelu existuje mnoho otevřených nástrojů, které nejen že otestují kód, ale také vám poradí, jak ho vylepšit. Většina nástrojů CI/CD se může připojit k těmto nástrojům a automatizovat proces.
Testování je rozděleno na dvě části: testovací rámce, které se používají k psaní a provádění testů, a nástroje s doporučeními ke zlepšení kvality kódu.
Testovací rámce
Nástroje s doporučeními pro kvalitu
Většina těchto nástrojů a rámců byla napsána pro Java, Python a JavaScript, protože C++ a C# jsou proprietární (i když GCC má otevřený zdrojový kód).
Nástroje pro testovací pokrytí jsme aplikovali, a nyní by pipeline DevOps měla vypadat jako na obrázku na začátku průvodce.
Ďalšie kroky
Kontajnery
Jak už jsem řekl, server aplikací lze umístit na virtuální stroj nebo server, ale kontejnery jsou populárnější.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Pro kontejnery se obvykle používá Docker a Kubernetes, i když existují i jiné možnosti.
Přečtěte si články o Dockeru a Kubernetes na :
Nástroje pro automatizaci middleware
Naša DevOps reťazec je zameraný na spoluprácu pri zostavovaní a dodávaní aplikácie, ale pomocou nástrojov DevOps môžete robiť aj ďalšie zaujímavé veci. Napríklad používať nástroje "infrastruktúra ako kód" (IaC), ktoré sa taktiež nazývajú nástroje na automatizáciu middleware. Tieto nástroje pomáhajú automatizovať inštaláciu, správu a ďalšie úlohy pre middleware. Napríklad nástroj na automatizáciu môže brať aplikácie (server webových aplikácií, databázu, nástroje na monitorovanie) s správnymi konfiguráciami a nasadiť ich na server aplikácií.
Tu je niekoľko možností otvorených nástrojov na automatizáciu middleware:
Podrobnosti nájdete v článkoch na :
A čo teraz?
To je len špička ľadovca. DevOps reťazec môže robiť omnoho viac. Začnite s nástrojom CI/CD a zistite, čo ďalšie môžete automatizovať, aby ste si uľahčili prácu. Nezabudnite na pre efektívnu spoluprácu.
Tu je niekoľko ďalších dobrých článkov o DevOps pre začiatočníkov:
A ešte môžete integrovať DevOps s otvorenými nástrojmi pre agile:
Zdroj: habr.com
