🥇Průvodce pro začátečníky: vytváříme DevOps pipeline

Pokud jste nováček v DevOps, podívejte se na tento návod, jak vytvořit svůj první pětistupňový pipeline.

DevOps se stal standardním řešením pro opravu pomalých, roztržených nebo nefunkčních procesů vývoje softwaru. Problém je v tom, že pokud jste nováček v DevOps a nevíte, jak začít, můžete mít nedostatek porozumění těmto metodám. V tomto článku se budeme zabývat definicí DevOps pipeline a nabídneme návod na její vytvoření v pěti krocích. Ačkoli tento návod není vyčerpávající, měl by vám poskytnout základy, abyste mohli začít svou cestu a rozšířit své znalosti v budoucnu. Ale začneme historií.

Moje cesta k DevOps

Dříve jsem pracoval v cloudovém týmu Citi Group, kde jsem vyvíjel webovou aplikaci Infrastructure-as-a-Service (IaaS) pro správu cloudové infrastruktury Citi, ale vždy mě zajímalo, jak učinit proces vývoje efektivnějším a přinést pozitivní kulturní změny do týmu vývojářů. Odpověď jsem našel v knize, kterou doporučil Greg Lavender, technický ředitel Citi pro cloudovou architekturu a infrastrukturu. Kniha se jmenovala „Projekt Fénix“ (The Phoenix Project), a vysvětluje principy DevOps, přičemž se čte jako román.

V tabulce na zadní straně knihy je uvedeno, jak často různé společnosti nasazují své systémy v prostředí pro uvolnění verzí:

Amazon: 23 000 denně
Google: 5 500 denně
Netflix: 500 denně
Facebook: Jednou denně
Twitter: 3krát týdně
Typická společnost: Jednou za 9 měsíců

Jak je vůbec možné, že Amazon, Google a Netflix mají takové frekvence? Je to proto, že tyto společnosti vymyslely, jak vytvořit téměř dokonalý DevOps pipeline.

Byli jsme od toho daleko, dokud jsme ve společnosti Citi nezavedli DevOps. V té době měla má skupina různá prostředí, ale nasazení na vývojovém serveru bylo zcela ruční. Všichni vývojáři měli přístup pouze k jednomu vývojovému serveru založenému na IBM WebSphere Application Server Community Edition. Problém byl v tom, že server se vypnul pokaždé, když se několik uživatelů pokusilo provést nasazení, takže se vývojáři museli navzájem informovat o svých záměrech, což bylo dost nepříjemné. Kromě toho byly problémy s nízkou úrovní testovacího pokrytí kódu, těžkopádnými procesy ručního nasazení a absencí možnosti sledovat nasazení kódu spojeného s konkrétním úkolem nebo uživatelskou historií.

Uvědomil jsem si, že je potřeba něco podniknout, a našel jsem kolegu, který měl stejný názor. Rozhodli jsme se spolupracovat na vytvoření počátečního DevOps kontejneru – on nainstaloval virtuální stroj a server aplikací Tomcat, zatímco já pracoval na Jenkinsu, integrování Atlassian Jira a BitBucket a také na testovacím pokrytí kódu. Tento vedlejší projekt byl velmi úspěšný: téměř jsme zcela automatizovali mnoho procesů, dosáhli jsme téměř 100% funkčnosti našeho vývojového serveru, zajistili jsme sledování a zlepšili testovací pokrytí kódu a také jsme přidali možnost spojovat větve v Gitu s úkoly v Jira nebo nasazením. Většina nástrojů, které jsme použili k výstavbě našeho DevOps kontejneru, měla otevřený zdrojový kód.

Nyní rozumím, jak jednoduchý byl náš DevOps pipeline: nepoužívali jsme rozšíření jako Jenkins files nebo Ansible. Tento jednoduchý kontejner však dobře fungoval, možná díky principu Pareto (známému také jako pravidlo 80/20).

Stručné úvod do DevOps a CI/CD pipeline

Pokud se zeptáte několika lidí: „Co je to DevOps?“, pravděpodobně dostanete několik různých odpovědí. DevOps, podobně jako Agile, se vyvíjel, aby pokryl řadu různých disciplín, ale většina lidí se shodne na několika věcech: DevOps je praxe vývoje softwaru nebo životní cyklus vývoje softwaru (SDLC), jehož centrálním principem je změna kultury, ve které existují vývojáři a ne-vývojáři v prostředí, kde:

Byly automatizovány operace, které byly dříve prováděny ručně;
Každý dělá to, co umí nejlépe;
Zvyšuje se počet nasazení za určité časové období; roste propustnost;
Zvyšuje se flexibilita vývoje.

Ačkoli mít správné softwarové nástroje není jedinou podmínkou pro vytvoření prostředí DevOps, některé nástroje jsou nezbytné. Klíčovým nástrojem je kontinuální integrace a kontinuální nasazení (CI/CD). V tomto potrubí má prostředí různé fáze (např. DEV, INT, TST, QA, UAT, STG, PROD), mnohé operace jsou automatizovány a vývojáři mohou psát vysoce kvalitní kód, dosahovat flexibility vývoje a vysoké frekvence nasazení.

Článek popisuje pětistupňový přístup k vytvoření DevOps potrubí, podobného tomu zobrazenému na následující diagramu, s využitím nástrojů s otevřeným zdrojovým kódem.

Krok 1: Metody CI/CD

První věc, kterou potřebujete, je nástroj pro CI/CD. Jenkins, open-source nástroj založený na Javě a distribuovaný pod licencí MIT, je tímto prostředkem, který popularizoval směr DevOps a stal se de facto standardem.

Co tedy Jenkins je? Považujte ho za jakýsi magický univerzální dálkový ovladač, který může komunikovat s různými službami a nástroji a organizovat je. Sám o sobě je nástroj CI/CD, jako je Jenkins, k ničemu, ale stává se silnějším, když se propojí s různými nástroji a službami.

Jenkins je pouze jedním z mnoha open-source nástrojů pro CI/CD, které můžete použít k vytvoření DevOps pipeline.

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

Takto vypadají DevOps procesy s nástrojem CI/CD:

Máte nástroj CI/CD běžící na vašem localhostu, ale zatím s ním toho moc neuděláte. Pojďme se posunout na další etapu cesty do světa DevOps.

Krok 2: Správa systémů pro správu verzí

Nejlepší (a možná nejjednodušší) způsob, jak ověřit, že váš nástroj CI/CD umí kouzlit – je integrace s nástrojem pro správu verzí (SCM). Proč potřebujete správu verzí? Představte si, že vyvíjíte aplikaci. Kdykoli vytváříte aplikaci, programujete, a nezáleží na tom, zda používáte Java, Python, C++, Go, Ruby, JavaScript nebo nějaký z miliard programovacích jazyků. Kód, který píšete, se nazývá zdrojový kód. Na začátku, zvlášť pokud pracujete sami, je pravděpodobně možné všechno uložit do místního adresáře. Ale když projekt roste a pozvete další lidi ke spolupráci, potřebujete způsob, jak zabránit konfliktům při efektivní výměně modifikací. Také potřebujete způsob, jak obnovit předchozí verze, protože vytváření záloh a jejich kopírování/vkládání se už stává zastaralým. Potřebujete (a vaši kolegové) něco lepšího.

Právě tady se stává nástroj pro správu verzí prakticky nezbytným. Tento nástroj uchovává váš kód v repozitářích, sleduje verze a koordinuje práci účastníků projektu.

Ačkoli existuje spousta nástrojů pro správu verzí, Git je standard, a to platí. Silně doporučuji používat Git, přesto existují také jiné možnosti s otevřeným zdrojovým kódem.

Git: GPLv2 a LGPL v2.1
Subversion: Apache 2.0
Současný systém verzí (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Takto vypadá DevOps pipeline s přidáním systémů správy verzí.

Nástroj CI/CD může automatizovat procesy kontroly, získání zdrojového kódu a spolupráci mezi členy. Není to špatné? Ale jak z toho vytvořit funkční aplikaci, aby ji miliardy lidí mohly používat a ocenit?

Krok 3: Vytvoření nástroje pro automatizaci sestavení

Skvěle! Můžete kontrolovat kód a provádět změny v systému správy verzí a také pozvat své přátele ke spolupráci na vývoji. Ale zatím jste nevytvořili aplikaci. Abyste vytvořili webovou aplikaci, musíte ji zkompilovat a zabalit do nasaditelného formátu nebo spustit jako spustitelný soubor. (Vezměte prosím na vědomí, že interpretovaný programovací jazyk, jako je JavaScript nebo PHP, nepotřebuje kompilaci).

Využijte nástroj pro automatizaci sestavení. Bez ohledu na to, který nástroj pro automatizaci sestavení se rozhodnete použít, všechny mají stejný cíl: zkompilovat zdrojový kód do žádoucího formátu a automatizovat úkol úklidu, kompilace, testování a nasazení v konkrétním prostředí. Nástroje pro sestavení se budou lišit v závislosti na vašem programovacím jazyce, ale zde je několik obecných open-source možností.

Název
Licence
Programovací jazyk

Maven
Apache 2.0
Javy

Ant
Apache 2.0
Javy

Gradle
Apache 2.0
Javy

Bazel
Apache 2.0
Javy

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
CouchDB

SCons
MIT
CouchDB

BitBake
GPLv2
CouchDB

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Skvěle! Můžete umístit konfigurační soubory nástroje pro automatizaci sestavení do systému správy verzí a nechat váš nástroj CI/CD vše poskládat dohromady.

Všechno je v pořádku, že? Ale kde nasadíte svou aplikaci?

Krok 4: Server pro webové aplikace

Zatím máte zabalený soubor, který může být jak spustitelný, tak instalační. Aby byla jakákoli aplikace skutečně užitečná, musí poskytovat nějakou službu nebo rozhraní, ale potřebujete kontejner pro hostování vaší aplikace.

Server pro webové aplikace představuje právě takový kontejner. Server poskytuje prostředí, ve kterém může být definována logika nasaditelného balíčku. Také server poskytuje rozhraní a nabízí webové služby, otevírá sockety do vnějšího světa. Potřebujete HTTP server a také nějaké prostředí (například virtuální stroj) pro jeho instalaci. Zatím předpokládejme, že se o tom dozvíte více později (i když níže vám povím o kontejnerech).

Existuje několik open-source serverů pro webové aplikace.

Název
Licence
Programovací jazyk

Tomcat
Apache 2.0
Javy

Jetty
Apache 2.0
Javy

WildFly
GNU Lesser Public
Javy

GlassFish
CDDL & GNU Less Public
Javy

Django
3-Clause BSD
CouchDB

Tornado
Apache 2.0
CouchDB

Gunicorn
MIT
CouchDB

CouchDB
MIT
CouchDB

Rails
MIT
Ruby

Node.js
MIT
Javascript

Váš DevOps pipeline je téměř připraven k použití. Dobrá práce!

I když se můžete zastavit a začít s integrací sami, kvalita kódu je pro vývojáře aplikací důležitá a je třeba se o ni postarat.

Krok 5: Pokrytí testování kódu

Implementace testů může být dalším náročným požadavkem, ale vývojáři by měli zachytit jakékoli chyby v aplikaci v rané fázi a zlepšit kvalitu kódu, aby zajistili spokojenost koncových uživatelů. Naštěstí existuje mnoho open-source nástrojů pro testování vašeho kódu a generování doporučení pro zlepšení jeho kvality. Ještě lépe, většina nástrojů CI/CD se může propojit s těmito nástroji a automatizovat proces.

Testování kódu se skládá ze dvou částí: rámce pro testování kódu, které napomáhají při psaní a spouštění testů, a nástroje pro generování návrhů, které pomáhají zlepšit kvalitu kódu.

Systémy testování kódu

Název
Licence
Programovací jazyk

JUnit
Eclipse Public License
Javy

EasyMock
Apache
Javy

Mockito
MIT
Javy

PowerMock
Apache 2.0
Javy

Pytest
MIT
CouchDB

Hypothesis
Mozilla
CouchDB

Tox
MIT
CouchDB

Systémy doporučení pro zlepšení kódu

Název
Licence
Programovací jazyk

Cobertura
GNU
Javy

CodeCover
Eclipse Public (EPL)
Javy

Coverage.py
Apache 2.0
CouchDB

Emma
Common Public License
Javy

JaCoCo
Eclipse Public License
Javy

Hypothesis
Mozilla
CouchDB

Tox
MIT
CouchDB

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Vezměte prosím na vědomí, že většina nástrojů a rámců zmíněných výše je napsána pro Java, Python a JavaScript, protože C++ a C# jsou proprietární programovací jazyky (ačkoli GCC je open source).

Nyní, když jste implementovali nástroje pokrytí kódu testy, měl by váš DevOps pipeline vypadat jako diagram uvedený na začátku této příručky.

Další kroky

Kontejnery

Jak jsem již zmínil, můžete hostovat svůj server na virtuálním stroji nebo serveru, ale kontejnery jsou populárním řešením.

Co jsou kontejnery? Krátké vysvětlení spočívá v tom, že virtuální stroj potřebuje obrovské množství paměti operačního systému, které překračuje velikost aplikace, zatímco kontejner potřebuje pouze několik knihoven a konfigurací pro spuštění aplikace. Je zřejmé, že virtuální stroj stále má důležité oblasti použití, ale kontejner je lehkým řešením pro hostování aplikace, včetně serveru aplikací.

Ačkoliv existují i jiné možnosti kontejnerů, nejpopulárnějšími jsou Docker a Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Nástroje pro automatizaci propojovacího řetězce

Náš DevOps pipeline je převážně zaměřen na společné vytváření a nasazování aplikací, ale existuje mnoho dalších věcí, které lze dělat pomocí DevOps nástrojů. Jedním z nich je využití nástrojů Infrastructure as Code (IaC), které jsou také známy jako nástroje pro automatizaci propojovacího řetězce. Tyto nástroje pomáhají automatizovat instalaci, správu a další úkoly pro propojovací software. Například může automatizační nástroj extrahovat aplikace jako webový aplikační server, databázi a monitorovací nástroj s odpovídajícími konfiguracemi a nasadit je na aplikačním serveru.

Zde je několik nástrojů pro automatizaci propojovacího řetězce s otevřeným zdrojovým kódem:

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