🥇Príručka pre začiatočníkov: vytvorenie DevOps pipeline

Ak ste nováčik v DevOps, pozrite sa na tento návod na vytvorenie vášho prvého pipelinu v piatich krokoch.

DevOps sa stal štandardným riešením na opravu pomalých, roztrhnutých alebo nefungujúcich procesov vývoja softvéru. Problém je v tom, že ak ste nováčik v DevOps a neviete, odkiaľ začať, môže vám chýbať pochopenie týchto metodík. V tomto článku sa zameriame na definíciu DevOps pipelinu a ponúkneme návod na jeho vytvorenie v piatich krokoch. Hoci tento tutoriál nie je vyčerpávajúci, mal by vám poskytnúť základ, aby ste mohli začať svoju cestu a nielen rozšíriť svoje vedomosti. Ale začnime s históriou.

Moja cesta v oblasti DevOps

Predtým som pracoval v cloudovom tíme Citi Group, kde som vyvíjal webovú aplikáciu Infrastructure-as-a-Service (IaaS) na správu cloudovej infraštruktúry Citi, ale vždy ma zaujímalo, ako spraviť proces vývoja efektívnejším a priniesť pozitívne kultúrne zmeny do vývojového tímu. Odpoveď som našiel v knihe, ktorú odporučil Greg Lavender, technický riaditeľ Citi pre cloudovú architektúru a infraštruktúru. Kniha sa volala „Projekt Fénix“ (The Phoenix Project), a v nej sú vysvetlené princípy DevOps, pričom sa číta ako román.

V tabuľke na zadnej strane knihy je zobrazené, ako často rôzne spoločnosti nasadzujú svoje systémy na distribučné prostredie pre vydanie verzií:

Amazon: 23 000 denne
Google: 5 500 denne
Netflix: 500 denne
Facebook: Raz denne
Twitter: 3 krát za týždeň
Typická spoločnosť: Raz za 9 mesiacov

Ako je vôbec možné, že Amazon, Google a Netflix majú takúto frekvenciu? Všetko je to preto, že tieto spoločnosti vymysleli, ako vytvoriť takmer dokonalý DevOps pipeline.

Boli sme od toho ďaleko, kým sme nezačali implementovať DevOps v Citi. Vtedy mala moja tím rôzne prostredia, avšak nasadenie na vývojový server bolo úplne manuálne. Všetci vývojári mali prístup iba k jednému vývojovému serveru založenému na IBM WebSphere Application Server Community Edition. Problém bol v tom, že server sa vždy vypol, keď sa viacerí používatelia pokúsili naraz vykonať nasadenie, takže vývojári sa museli navzájom informovať o svojich úmysloch, čo bolo dosť bolestné. Navyše existovali problémy so základným testovaním pokrytia kódu, nepraktickými manuálnymi procesmi nasadenia a nedostatkom možnosti sledovať nasadenie kódu spojeného s konkrétnou úlohou alebo používateľským príbehom.

Uvedomil som si, že je potrebné niečo urobiť, a našiel som kolegu, ktorý mal podobné názory. Rozhodli sme sa spolupracovať na vytvorení počiatočného DevOps kanála – on nainštaloval virtuálny stroj a server aplikácií Tomcat, zatiaľ čo ja som pracoval na Jenkins, integroval Atlassian Jira a BitBucket a pracoval na pokrytí testovania kódu. Tento vedľajší projekt bol veľmi úspešný: takmer sme úplne automatizovali mnoho procesov, dosiahli sme takmer 100% funkčnosť nášho vývojového servera, zabezpečili sme sledovanie a zlepšili pokrytie testovania kódu a pridali možnosť prepojiť vetvy v Gite s úlohami v Jira alebo nasadením. Väčšina nástrojov, ktoré sme použili na budovanie nášho DevOps kanála, mala otvorený zdrojový kód.

Teraz chápem, aký jednoduchý bol náš DevOps pipeline: nepoužívali sme rozšírenia ako Jenkins files alebo Ansible. Avšak tento jednoduchý kanál fungoval dobre, pravdepodobne vďaka Pareto princípu (známejšiemu ako pravidlo 80/20).

Krátke uvedenie do DevOps a pipeline CI/CD

Ak sa opýtate niekoľkých ľudí: „Čo je to DevOps?“, pravdepodobne dostanete niekoľko rôznych odpovedí. DevOps, podobne ako Agile, sa vyvinul tak, aby zahŕňal množstvo rôznych disciplín, ale väčšina ľudí súhlasí s niektorými vecami: DevOps je prax vývoja softvéru alebo životného cyklu vývoja softvéru (SDLC), ktorého centrálnym princípom je zmena kultúry, v ktorej existujú vývojári a ne-vývojári v prostredí, v ktorom:

Sú automatizované operácie, ktoré predtým vykonávali manuálne;
Každý robí to, čo najlepšie ovláda;
Zvýšuje sa počet nasadení za určité časové obdobie; Zvyšuje sa priepustnosť;
Zvyšuje sa flexibilita vývoja.

Hoci mať správne softvérové nástroje nie je jediné, čo potrebujete na vytvorenie prostredia DevOps, niektoré nástroje sú nevyhnutné. Kľúčovým nástrojom je nepretržitá integrácia a nepretržité nasadenie (CI/CD). V tomto potrubí prostredia majú rôzne fázy (napríklad DEV, INT, TST, QA, UAT, STG, PROD), mnohé operácie sú automatizované a vývojári môžu písať kvalitný kód, dosahovať flexibilitu vývoja a vysokú frekvenciu nasadení.

V tomto článku sa opisuje päťfázový prístup k vytvoreniu DevOps kanála, podobného tomu, ktorý je zobrazený na nasledujúcej schéme, s využitím nástrojov s otvoreným zdrojom.

Krok 1: Metódy CI/CD

Prvá vec, ktorú potrebujete, je nástroj pre CI/CD. Jenkins, nástroj s otvoreným zdrojom založený na Jave a distribuovaný pod licenciou MIT, je prostriedok, ktorý popularizoval smerovanie DevOps a stal sa de facto štandardom.

Čo je teda Jenkins? Považujte to za akýsi magický univerzálny diaľkový ovládač, ktorý dokáže komunikovať s rôznymi službami a nástrojmi a organizovať ich. Sám o sebe je nástroj CI/CD, ako Jenkins, bezcenný, ale stáva sa silnejším, keď je pripojený k rôznym nástrojom a službám.

Jenkins je len jedným z mnohých nástrojov s otvoreným zdrojom pre CI/CD, ktoré môžete použiť na vytvorenie DevOps potrubia.

Jenkins: Creative Commons a MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Takto vyzerajú DevOps procesy s nástrojom CI/CD:

Máte nástroj CI/CD bežiaci na vašom localhost, ale zatiaľ s ním nemôžete veľa robiť. Prejdime na nasledujúci krok na ceste do sveta DevOps.

Krok 2: Správa systémov na kontrolu zdrojového kódu

Najlepší (a možno aj najjednoduchší) spôsob, ako overiť, že váš nástroj CI/CD dokáže vykonávať mágiu, je integrácia s nástrojom na kontrolu zdrojového kódu (SCM). Prečo potrebujete kontrolu nad zdrojovým kódom? Predpokladajme, že vyvíjate aplikáciu. Kedykoľvek vytvárate aplikáciu, programujete, a nezáleží na tom, či používate Java, Python, C++, Go, Ruby, JavaScript alebo ktorýkoľvek z nespočetných programovacích jazykov. Kód, ktorý píšete, sa nazýva zdrojový kód. Na začiatku, najmä keď pracujete sami, je pravdepodobne možné umiestniť všetko do lokálneho adresára. Ale keď projekt narastá a pozývate iných, aby sa pripojili, potrebujete spôsob, ako zabrániť konfliktom pri efektívnom zdieľaní zmien. Taktiež potrebujete spôsob, ako obnoviť predchádzajúce verzie, pretože vytváranie záloh a kopírovanie/vkladanie je už zastarané. Potrebujete (a vaši kolegovia z tímu) niečo lepšie.

Práve tu sa nástroj na kontrolu zdrojového kódu stáva prakticky nevyhnutnosťou. Tento nástroj uchováva váš kód v repozitároch, sleduje verzie a koordinuje prácu účastníkov projektu.

Aj keď existuje mnoho nástrojov na kontrolu zdrojového kódu, Git je štandardom, a to je pravda. Dôrazne odporúčam používať Git, aj keď ak chcete, sú k dispozícii aj iné možnosti s otvoreným zdrojom.

Git: GPLv2 a LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Takto vyzerá DevOps pipeline s pridaním nástrojov na kontrolu zdrojového kódu.

Nástroj CI/CD môže automatizovať procesy kontroly, získavania zdrojového kódu a spolupráce medzi členmi tímu. Nie zlé? Ale ako transformovať toto na funkčnú aplikáciu, aby ju miliardy ľudí mohli používať a oceňovať?

Krok 3: Vytvorenie nástroja na automatizáciu zostavenia

Skvele! Môžete kontrolovať kód a robiť zmeny v systéme správy zdrojového kódu, ako aj pozývať svojich priateľov na spoluprácu v rámci vývoja. Ale ešte ste nevytvorili aplikáciu. Aby ste vytvorili webovú aplikáciu, musíte ju skompilovať a zabalit' do nasaditeľného balíkového formátu alebo ju spustiť ako spustiteľný súbor. (Všimnite si, že interpretovaný programovací jazyk, ako JavaScript alebo PHP, nevyžaduje kompiláciu).

Využite nástroj na automatizáciu zostavovania. Bez ohľadu na to, ktorý nástroj na automatizáciu zostavovania sa rozhodnete použiť, všetky sledujú rovnaký cieľ: zostaviť zdrojový kód do nejakého požadovaného formátu a automatizovať úlohy čistenia, kompilácie, testovania a nasadzovania v určitej prostredí. Nástroje zostavovania sa budú líšiť v závislosti od vášho programovacieho jazyka, ale tu sú niektoré bežné možnosti s otvoreným zdrojom.

Názov
Licencia
Programovací jazyk

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

Super! Môžete umiestniť konfiguračné súbory nástroja na automatizáciu zostavovania do systému správy zdrojového kódu a umožniť svojmu CI/CD nástroju všetko poskladať dohromady.

Všetko je v poriadku, nie? Ale kde nasadiť vašu aplikáciu?

Krok 4: Server pre webové aplikácie

Zatiaľ máte zabalený súbor, ktorý môže byť buď spustiteľný, alebo inštalovateľný. Aby aplikácia bola skutočne užitočná, musí poskytovať nejakú službu alebo rozhranie, ale potrebujete kontajner na umiestnenie vašej aplikácie.

Server pre webové aplikácie je presne takýmto kontajnerom. Server poskytuje prostredie, v ktorom môže byť definovaná logika nasaditeľného balíka. Taktiež server poskytuje rozhranie a ponúka webové služby, otvárajúc sokety pre vonkajší svet. Potrebujete HTTP server, ako aj nejaké prostredie (napríklad virtuálnu mašinu) na jeho inštaláciu. A zatiaľ predpokladajme, že sa o tom dozviete ďalej (aj keď o kontajneroch poviem nižšie).

Existuje niekoľko serverov pre webové aplikácie s otvoreným zdrojom.

Názov
Licencia
Programovací jazyk

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

Váš DevOps pipeline je takmer pripravený na použitie. Dobrá práca!

Aj keď sa tu môžete zastaviť a zaoberať sa integráciou sami, kvalita kódu je pre vývojárov aplikácií dôležitá a je potrebné sa o ňu starať.

Krok 5: Pokrytie testovania kódu

Implementácia testov môže byť ďalším náročným požiadavkom, ale vývojári by mali zachytiť akékoľvek chyby v aplikácii v raných fázach a zlepšiť kvalitu kódu, aby zabezpečili, že koneční užívatelia budú spokojní. Našťastie existuje množstvo nástrojov s otvoreným zdrojovým kódom na testovanie vášho kódu a na generovanie odporúčaní na zlepšenie jeho kvality. Ešte lepšie je, že väčšina nástrojov CI/CD sa môže pripojiť k týmto nástrojom a automatizovať proces.

Testovanie kódu pozostáva z dvoch častí: rámce na testovanie kódu, ktoré pomáhajú písať a spúšťať testy, a nástroje na generovanie návrhov, ktoré pomáhajú zlepšiť kvalitu kódu.

Systémy testovania kódu

Názov
Licencia
Programovací jazyk

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

Systémy odporúčaní na zlepšenie kódu

Názov
Licencia
Programovací jazyk

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

Všimnite si, že väčšina nástrojov a rámcov uvedených vyššie je napísaná pre Java, Python a JavaScript, pretože C++ a C# sú proprietárne programovacie jazyky (aj keď GCC má otvorený zdrojový kód).

Teraz, keď ste implementovali nástroje na pokrytie kódu testami, mal by váš DevOps pipeline vyzerať ako diagram zobrazený na začiatku tejto príručky.

Ďalšie kroky

Kontajnery

Ako som už povedal, môžete hostiť svoj server na virtuálnom stroji alebo servery, ale kontajnery sú populárnym riešením.

Čo sú kontajnery? Stručné vysvetlenie je také, že virtuálny stroj potrebuje obrovské množstvo pamäte operačného systému, ktorý prevyšuje veľkosť aplikácie, zatiaľ čo kontajner potrebuje len niekoľko knižníc a konfigurácií na spustenie aplikácie. Je zrejmé, že virtuálny stroj má stále dôležité oblasti aplikácie, ale kontajner je ľahké riešenie na hosting aplikácie, vrátane aplikačného servera.

Aj keď existujú aj iné varianty kontajnerov, najpopulárnejšie sú Docker a Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Prostredky automatizácie

Náš DevOps pipeline je prevažne zameraný na spoločné vytváranie a nasadzovanie aplikácií, ale existuje množstvo ďalších vecí, ktoré možno robiť pomocou DevOps nástrojov. Jednou z nich je používanie nástrojov Infrastructure as Code (IaC), ktoré sú tiež známe ako prostriedky medzi automatizáciou. Tieto nástroje pomáhajú automatizovať inštaláciu, správu a ďalšie úlohy pre medziserverový softvér. Napríklad automatizačný nástroj môže extrahovať aplikácie ako server webových aplikácií, databázu a monitorovací nástroj s správnymi konfiguráciami a nasadiť ich na aplikačnom serveri.

Tu sú niektoré nástroje medzi automatizáciou s otvoreným zdrojovým kódom:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache alebo GPL