Prehľad DevOps

1. Prehľad

V tomto článku pochopíme základné princípy a postupy DevOps. Uvidíme, prečo je to pri vývoji softvéru relevantné a užitočné. Pochopíme tiež, ako môžeme zmysluplne prijať DevOps a aké nástroje sú na tejto ceste k dispozícii.

2. Historický kontext

Nebudeme schopní oceniť DevOps v jeho súčasnej podobe bez toho, aby sme sa trochu pozreli späť do histórie. Počiatočné dni vývoja softvéru boli väčšinou charakterizované tým, čo nazývame vodopádová metodológia. Čo to v skutočnosti znamená, je to softvér bol konceptualizovaný, navrhnutý, vyvinutý, testovaný a distribuovaný za sebou.

Každý krok bol čo najpodrobnejší návrat späť bol veľmi nákladný. Čo to v skutočnosti znamenalo, bolo oveľa vyššie čakacie obdobie medzi myšlienkou a činom. Nebol to však taký problém, pretože technologické prostredie bolo oveľa menej nestále a poruchy sa príliš rozšírili.

Je zaujímavé, že tento model dlho nevydržal. Keď sa tempo technológie zmenilo a často sa začali objavovať poruchy, začali podniky pociťovať horúčavu. Potrebovali rýchlejšie otestovať nové nápady. To znamenalo rýchlejšie zmeny vo všetkých aspektoch podnikania vrátane softvéru.

Tak sa zrodil úplne nový svet metodík vývoja softvéru, ktoré voľne vidno pod záštitou spoločnosti Agile. Agilný manifest stanovuje súbor zásad, podľa ktorých sa treba riadiť dodávka softvéru v malých krokoch s rýchlejšou spätnoväzbovou slučkou. V praxi existuje niekoľko agilných rámcov ako Scrum a Kanban.

3. Čo je DevOps?

Videli sme, že postupný vývoj s rýchlejšou spätnou väzbou sa dnes stal základným kameňom dodávania softvéru. Ako to však dosiahneme? Aj keď nás tradičné agilné metodiky vedú k rozumnému bodu, stále to nie je ideálne.

Agilné metodiky sa neustále zdokonaľujú, keď sa neustále snažia rozbíjať sily.

Tradične sme vždy mali rôzne tímy, ktoré boli zodpovedné za vývoj a dodávku softvéru. Tieto tímy často operovali vo svojich silách. To sa efektívne prenieslo do oveľa dlhšieho cyklu spätnej väzby, čo nie je niečo, po čom s agilnými metodikami túžime.

Na pochopenie toho, že dobre integrované a krížovo funkčné agilné tímy sú oveľa vhodnejšie na splnenie svojich cieľov, to nevyžaduje veľa zdôvodnení. DevOps je postup, ktorý podporuje komunikáciu, spoluprácu, integráciu a automatizáciu medzi tímami pre vývoj softvéru a operačné tímy. To nám umožňuje lepšie realizovať prírastkový vývoj s rýchlejšou spätnou väzbou.

Nasledujúci diagram vysvetľuje možný pracovný postup pri cvičení DevOps:

Aj keď si podrobnosti týchto krokov prejdeme ďalej v tomto výučbe, pochopme niektoré kľúčové princípy DevOps:

  • Prístup zameraný na hodnotu (realizovaný koncovým používateľom)
  • Kultúra spolupráce (s efektívnou komunikáciou, procesmi a nástrojmi)
  • Automatizácia procesov (na zvýšenie efektívnosti a zníženie počtu chýb)
  • Merateľné výsledky (na porovnanie s cieľmi)
  • Nepretržitá spätná väzba (s tendenciou rýchlo sa zlepšovať)

4. Ako začať cestu?

Aj keď je teória jednoduchá a príťažlivá, skutočné výzvy spočívajú v zmysluplnom cvičení DevOps. Ako sme sa doteraz zhromaždili, DevOps je väčšinou o ľuďoch, nie o tímoch.

Charakteristické znaky týchto tímov sú spoločné ciele, efektívna komunikácia a medzifunkčné schopnosti. Pretože veľká časť tejto zmeny je kultúrna, je často pomalá a nie bez trenia.

4.1. Motivácia

Len preto, že existuje populárna prax, nemusí to pre nás byť nevyhnutne vhodné. Musíme pochopiť našu motiváciu k akejkoľvek zmene - viac, ak robíme zmenu smerom k agilnosti. Je to je užitočné ustanoviť si ciele, ktoré chceme dosiahnuť.

Ciele DevOps v akejkoľvek organizácii závisia od ambícií, kultúry a vyspelosti tejto organizácie. Tu uvádzame niektoré z najbežnejších cieľov DevOps:

  • Lepší zážitok pre koncových používateľov
  • Rýchlejší čas uvedenia na trh
  • Vylepšený stredný čas na zotavenie

4.2. Prijatie

Pamätajte, že DevOps nie je konečný stav, ale nepretržitý proces zlepšovania na dosiahnutie cieľov. Všetci v tíme sa preto musia snažiť identifikovať prekážky a rýchlo ich odstrániť. Tu je niekoľko aktivít, ktoré nám môžu pomôcť začať:

  • Jasne pochopiť súčasný stav tvorby výrobného cyklu
  • Zhromaždite niektoré zjavné prekážky a používajte metriky na prijímanie faktických rozhodnutí
  • Stanovte prioritu úzkych miest, ktoré po odstránení dodajú najväčšiu hodnotu
  • Definujte iteračný plán na postupné poskytovanie hodnoty pre prioritné položky
  • Na dosiahnutie cieľov postupujte podľa krátkych cyklov vývoja, nasadenia a merania

5. Postupy DevOps

Existuje niekoľko postupov, ktoré treba dodržať, ale táto myšlienka by ako zlatý štandard nemala používať žiadnu. Mali by sme starostlivo preskúmať každú prax na pozadí nášho stavu a cieľov a potom robiť informované rozhodnutia. Avšak takmer všetky postupy majú tendenciu sa čo najviac zameriavať na automatizáciu procesov.

5.1. Agilné plánovanie

Agilné plánovanie je prax definovania práce v krátkych krokoch. Konečný cieľ by mal byť jasný, nie je potrebné vopred definovať a podrobne uviesť celú aplikáciu. Kľúč je tu uprednostniť prácu na základe hodnoty, ktorú môže priniesť.

Potom by to malo byť rozdelené na iteráciu krátkych, ale funkčných prírastkov.

5.2. Infraštruktúra ako kód (IaC)

To je prax riadenia a zabezpečenia infraštruktúry prostredníctvom strojovo čitateľných konfiguračných súborov. Tieto konfigurácie tiež spravujeme v systéme riadenia verzií, ako je to v prípade našej kódovej základne. Na deklaratívne vytvorenie týchto konfiguračných súborov je k dispozícii veľa jazykov špecifických pre doménu.

5.3. Automatizácia testov

Testovanie softvéru bolo tradične ručným úsilím, ktoré sa často uskutočňovalo v silách. S agilnými princípmi sa to nespája dobre. Preto je nevyhnutné, aby sme sa o to pokúsili automatizovať testovanie softvéru na všetkých úrovniach, ako je testovanie jednotiek, funkčné testovanie, testovanie bezpečnosti a testovanie výkonu.

5.4. Nepretržitá integrácia (CI)

Nepretržitá integrácia je prax častého zlučovania pracovného kódu v malých prírastkoch do zdieľaného úložiska. Na tomto zdieľanom úložisku zvyčajne prebiehajú automatizované zostavenia a kontroly, ktoré nás čo najskôr upozornia na akékoľvek prerušenia kódu.

5.5. Nepretržité dodanie / nasadenie (CD)

Nepretržité dodávky sú prax uvoľňovania softvéru v malých krokoch, akonáhle prejde všetkými kontrolami. Toto sa často praktizuje spolu s kontinuálnou integráciou a môže profitovať z automatizovaného uvoľňovacieho mechanizmu (označovaného ako kontinuálne nasadenie).

5.6. Nepretržité monitorovanie

Monitorovanie - možno centrum DevOps - umožňuje rýchlejšie slučky spätnej väzby. Identifikačné správna metrika na monitorovanie všetkých aspektov softvéru vrátane infraštruktúry je rozhodujúca. Správne metriky spolu s efektívnymi analytickými údajmi v reálnom čase môžu pomôcť rýchlejšie identifikovať a vyriešiť problémy. Okrem toho sa priamo napája na agilné plánovanie.

Tento zoznam nie je ani zďaleka úplný a neustále sa vyvíja. Tímy trénujúce DevOps neustále vymýšľajú lepšie spôsoby, ako dosiahnuť svoje ciele. Niektoré z ďalších postupov, ktoré stoja za zmienku, sú Containerization, Cloud-Native Development a Microservices.

6. Obchodné nástroje

Žiadna diskusia o DevOps nemôže byť úplná bez toho, aby ste hovorili o nástrojoch. V tejto oblasti došlo v posledných rokoch k výbuchu. V čase, keď dočítame tento návod, môže byť vonku nový nástroj! Aj keď je to lákavé a ohromujúce zároveň, je potrebné postupovať opatrne.

Našu cestu DevOps nesmieme začínať nástrojmi ako prvou vecou v našej mysli. My Pred nájdením správnych nástrojov musíte preskúmať a ustanoviť naše ciele, ľudí (kultúru) a postupy. Aby sme si to ujasnili, pozrime sa, aké sú niektoré z časovo testovaných nástrojov, ktoré máme k dispozícii.

6.1. Plánovanie

Ako sme videli, vyspelý DevOps vždy začína agilným plánovaním. Aj keď sú ciele jasné, je potrebné stanoviť priority a definovať prácu len pre niekoľko krátkych iterácií. Spätná väzba z týchto prvých iterácií je neoceniteľná pri formovaní budúcich a nakoniec aj celého softvéru. Účinný nástroj, ktorý je tu k dispozícii, by nám pomohol tento proces ľahko vykonať.

Jira je najlepšie hodnotený produkt na sledovanie problémov vyvinutý spoločnosťou Atlassian. Má veľa zabudovaných agilných plánovacích a monitorovacích nástrojov. Väčšinou sa jedná o komerčný produkt, ktorý môžeme spustiť buď on-premise, alebo ho môžeme použiť ako hostenú aplikáciu.

6.2. Rozvoj

Agilnou myšlienkou je rýchlejšie prototypovať a hľadať spätnú väzbu k skutočnému softvéru. Vývojári musia vykonávať zmeny a rýchlejšie sa zlúčiť do zdieľanej verzie softvéru. Je ešte dôležitejšie, aby komunikácia medzi členmi tímu bola plynulá a rýchla.

Pozrime sa na niektoré všadeprítomné nástroje v tejto doméne.

Git je systém riadenia distribuovanej verzie. Je to pomerne populárne a existuje veľa hostovaných služieb poskytujúcich úložiská git a funkcie s pridanou hodnotou. Spolupráca medzi vývojármi softvéru, ktorú pôvodne vyvinul Linus Torvalds, je celkom pohodlná.

Confluence je nástroj na spoluprácu vyvinutý spoločnosťou Atlassian. Spolupráca je kľúčom k úspechu každého svižného tímu. Skutočná sémantika spolupráce je dosť kontextová, ale nástroj, ktorý umožňuje bezproblémové úsilie, je napriek tomu neoceniteľný. Sútok zapadá do tohto miesta presne. Navyše sa dobre integruje s Jira!

Slack je platforma pre okamžité správy vyvinutá spoločnosťou Slack Technologies. Ako sme diskutovali, svižne tímy by mali byť schopné spolupracovať a komunikovať, najlepšie v reálnom čase. Okrem okamžitých správ ponúka Slack mnoho spôsobov komunikácie s jedným používateľom alebo so skupinou používateľov - a integruje sa dobre s ďalšími nástrojmi, ako sú Jira a GitHub!

6.3. Integrácia

Zmeny zlúčené vývojármi by sa mali neustále kontrolovať z hľadiska súladu. To, čo predstavuje zhodu, je špecifické pre tím a aplikáciu. Je však bežné vidieť ako súčasť súladu statickú a dynamickú analýzu kódu, ako aj funkčné a nefunkčné metrické merania.

Pozrime sa v skratke na pár populárnych integračných nástrojov.

Jenkins je presvedčivý server s otvoreným zdrojovým kódom a automatizáciou zadarmo. V tomto priemysle pôsobí už roky a dostatočne vyzrel na to, aby slúžil širokému spektru prípadov použitia automatizácie. Ponúka deklaratívny spôsob definovania automatizačnej rutiny a množstvo spôsobov, ako ju spustiť automaticky alebo manuálne. Okrem toho má bohatú sadu doplnkov, ktoré slúžia na niekoľko ďalších funkcií na vytvorenie výkonných automatizačných potrubí.

SonarQube je open-source platforma na nepretržitú kontrolu vyvinutá spoločnosťou SonarSource. SonarQube má bohatú sadu pravidiel statickej analýzy pre mnoho programovacích jazykov. To pomáha zistiť pachy kódu čo najskôr. SonarQube navyše ponúka panel, ktorý môže integrovať ďalšie metriky, ako je pokrytie kódu, zložitosť kódu a mnoho ďalších. A funguje to dobre aj so serverom Jenkins Server.

6.4. Dodanie

Rýchle dodanie zmien a nových funkcií do softvéru je dôležité. Hneď ako zistíme, že zmeny zlúčené v úložisku zodpovedajú našim štandardom a zásadám, mali by sme byť schopní rýchlo ich doručiť koncovým používateľom. To nám pomáha zhromažďovať spätnú väzbu a lepšie formovať softvér.

Existuje niekoľko nástrojov, ktoré nám môžu pomôcť automatizovať niektoré aspekty doručovania až do bodu, keď dosiahneme nepretržité nasadenie.

Docker je prevládajúcim nástrojom na rýchlu kontajnerizáciu ľubovoľného typu aplikácie. Využíva virtualizáciu na úrovni OS na izolovanie softvéru v balíkoch nazývaných kontajnery. Kontajnerizácia má okamžitú výhodu z hľadiska spoľahlivejšieho dodávania softvéru. Kontajnery Docker medzi sebou komunikujú prostredníctvom presne definovaných kanálov. Navyše je to veľmi ľahké v porovnaní s inými spôsobmi izolácie, ako sú Virtual Machines.

Chef / Puppet / Ansible sú nástroje na správu konfigurácie. Ako vieme, skutočná bežiaca inštancia softvérovej aplikácie je kombináciou zostavenia kódovej základne a jej konfigurácií. Aj keď je zostava kódovej základne často nemenná v rôznych prostrediach, konfigurácie nie sú. Toto je kde na ľahké a rýchle nasadenie našej aplikácie potrebujeme nástroj na správu konfigurácie. V tomto priestore je niekoľko populárnych nástrojov, z ktorých každý má svoje vtipy, ale Chef, Puppet a Ansible do značnej miery pokrývajú základy.

HashiCorp Terraform nám môže pomôcť so zabezpečením infraštruktúry, čo je od čias súkromných dátových centier zdĺhavá a časovo náročná úloha. Ale s čoraz väčším prijatím cloudu sa infraštruktúra často považuje za jednorazový a opakovateľný konštrukt. To sa však dá dosiahnuť, iba ak máme nástroj, pomocou ktorého môžeme deklaratívne definovať jednoduchú až zložitú infraštruktúru a vytvoriť ju kliknutím na tlačidlo. Môže to znieť ako snová sekvencia, ale Terraform sa aktívne snaží prekonať túto priepasť!

6.5. Monitorovanie

Nakoniec je nevyhnutné vedieť pozorovať nasadenie a merať ho proti cieľom. Môže existovať množstvo metrík, ktoré môžeme zhromaždiť zo systémov a aplikácií. Patria sem niektoré z obchodných metrík, ktoré sú špecifické pre našu aplikáciu.

Ide o to, aby sme boli schopní zhromažďovať, spravovať, ukladať a analyzovať tieto metriky takmer v reálnom čase. V tomto priestore je k dispozícii niekoľko nových produktov, otvorených aj komerčných.

Elastic-Logstash-Kibana (ELK) je zoskupenie troch open-source projektov - Elasticsearch, Logstash a Kibana. Elasticsearch je vysoko škálovateľný vyhľadávací a analytický nástroj. Spoločnosť Logstash nám poskytuje potrubie na spracovanie údajov na strane servera, ktoré je schopné konzumovať údaje z najrôznejších zdrojov. Nakoniec nám Kibana pomáha tieto údaje vizualizovať. Spoločne to môže byť slúži na agregáciu údajov, ako sú protokoly zo všetkých aplikácií, a ich analýzu v reálnom čase.

Prometheus je nástroj na monitorovanie a varovanie systému typu open-source pôvodne vyvinutý spoločnosťou SoundCloud. Dodáva sa s viacrozmerným dátovým modelom, flexibilným dotazovacím jazykom a dokáže načítať údaje časových radov cez protokol HTTP. Grafana je ďalšie open-source analytické a monitorovacie riešenie ktorý pracuje s niekoľkými databázami. Spoločne môžu Prometheus a Grafana dajte nám zvládnuť v reálnom čase takmer každú metriku, ktorú sú naše systémy schopné vytvoriť.

7. DevOps Extensions (Alebo sú naozaj!)

Videli sme, že DevOp je v zásade neustála snaha o odstránenie prekážok smerujúcich k rýchlejšiemu a iteratívnemu poskytovaniu softvéru na základe hodnoty. Jedným z okamžitých záverov je, že tu nemôže byť konečný stav.

To, čo si ľudia uvedomili ako trenie medzi vývojovými a operačnými tímami, nie je jediné trenie. Prelomenie síl v organizácii na zvýšenie spolupráce je ústrednou myšlienkou. Ľudia si to čoskoro začali uvedomovať podobné trenice existujú medzi vývojovými a testovacími tímami a medzi vývojovými a bezpečnostnými tímami. Mnoho tradičných nastavení má vyhradené tímy pre zabezpečenie a výkon.

Plný potenciál DevOps sa nikdy nedá realizovať, kým neprekonáme takmer všetky hranice medzi tímami a nebudeme im pomáhať spolupracovať oveľa efektívnejšie. Toto zo svojej podstaty znamená spojiť tímy ako testovanie, zabezpečenie a výkon.

Zmätok spočíva predovšetkým v jeho nomenklatúre. Vďaka aplikácii DevOps rozumieme, že ide predovšetkým o vývojové a prevádzkové tímy. Postupom času sa preto vytvorili nové pojmy, ktoré zahrnuli aj ďalšie tímy. Ale do veľkej miery je to len to, že sa DevOps realizuje efektívnejšie!

7.1. DevTestOps

Základným kameňom DevOps je poskytovanie vysoko kvalitného softvéru v malých krokoch a častejšie. Dôraz na kvalitu je tu zameraný na veľa aspektov. V istom zmysle často predpokladáme, že zavedené postupy DevOps nám pomôžu dosiahnuť to. A je tiež pravda, že veľa postupov, o ktorých sme hovorili skôr, sa zameriava na zabezpečenie vysokej kvality za každých okolností.

Ale funkčné testovanie softvéru má oveľa širší rozsah. Pomerne často máme tendenciu držať testovanie vyššieho rádu, ako napríklad end-to-end testovanie, na konci dodávania softvéru. Dôležitejšie je, že to je často zodpovednosť samostatného tímu, ktorý sa zapojí neskoro do procesu. To je miesto, kde sa veci začnú odchyľovať od princípov DevOps.

Mali by sme radšej urobiť integrovať testovanie softvéru na všetkých úrovniach od samého začiatku. Už od fázy plánovania by sa malo testovanie softvéru považovať za neoddeliteľnú súčasť dodávky. Rovnaký tím by mal byť zodpovedný za vývoj a testovanie softvéru. To je to, čo je prax DevTestOps všeobecne známa ako. Toto sa často označuje aj ako nepretržité testovanie a radenie doľava.

7.2. DevSecOps

Bezpečnosť je neoddeliteľnou súčasťou každého vývoja softvéru a má svoj podiel na zložitosti. To často znamená, že máme samostatný tím bezpečnostných špecialistov, s ktorými spolupracujeme hneď, keď sme pripravení na odoslanie produktu. Zraniteľnosti, ktoré identifikujú v tejto fáze, môžu byť nákladné. To opäť dobre nerezonuje s princípmi DevOps.

Do tejto doby by sme už mali mať riešenie, ktoré musíme použiť, a to by malo byť priviesť bezpečnostné obavy a personál na začiatku hry. Mali by sme motivovať tímy, aby v každej fáze premýšľali o bezpečnosti. Bezpečnosť je bezpochyby veľmi špecializovaná doména, a preto možno budeme musieť do tímu prizvať špecialistu. Myšlienkou však je zvážiť hneď od začiatku niektoré z najlepších postupov.

Keď ideme ďalej, existujú niekoľko dostupných nástrojov, ktoré môžu automatizovať skenovanie väčšiny zraniteľností. Môžeme to tiež zapojiť do našich cyklov nepretržitej integrácie, aby sme získali rýchlu spätnú väzbu! Teraz nemôžeme integrovať všetko do Kontinuálnej integrácie, pretože ju musíme udržiavať ľahkú, ale vždy môžu existovať ďalšie periodické kontroly, ktoré bežia osobitne.

8. Záver

V tomto článku sme prešli základmi princípov, postupov a nástrojov DevOps, ktoré sú k dispozícii na použitie. Pochopili sme kontext, v ktorom je DevOps relevantný, a dôvody, pre ktoré môže byť pre nás užitočný. Krátko sme diskutovali aj o tom, kde začať na ceste adopcie DevOps.

Ďalej sme sa dotkli niektorých populárnych postupov a nástrojov, ktoré máme k dispozícii na tejto ceste. Rozumeli sme tiež niektorým z ďalších populárnych výrazov týkajúcich sa DevOps, ako sú DevTestOps a DevSecOps.

Nakoniec musíme pochopiť, že DevOps nie je konečný stav, ale skôr cesta, ktorá sa nemusí nikdy skončiť! Zábavnou časťou tu však je samotná cesta. Po celú dobu nesmieme nikdy stratiť zo zreteľa svoje ciele a mali by sme sa zamerať na kľúčové zásady. Je celkom ľahké podľahnúť lesku populárneho nástroja alebo výrazu v priemysle. Musíme si však vždy pamätať, že čokoľvek je užitočné, iba ak nám pomôže efektívnejšie prinášať hodnotu nášmu publiku.


$config[zx-auto] not found$config[zx-overlay] not found