Jak vytvořit svůj první DevOps řetězec v pěti krocích pro nováčky.
DevOps se stal všelék na příliš pomalé, roztržené a další problematické procesy vývoje. Ale je potřeba základní znalosti o DevOps. Budeme se zabývat pojmy jako DevOps řetězec a jak ho vytvořit v pěti krocích. Toto není úplný průvodce, ale pouze „ryba“, kterou lze rozšířit. Začněme historií.
Moje seznámení s DevOps
Kdysi jsem pracoval s cloudovými technologiemi ve společnosti Citi Group a vyvíjel webovou aplikaci IaaS pro správu cloudové infrastruktury Citi, ale vždy mě zajímalo, jak optimalizovat vývojový řetězec a zlepšit kulturu mezi vývojáři. Greg Lavender, náš technologický ředitel pro cloudovou architekturu a infrastrukturu, mi doporučil knihu . Skvěle vysvětluje principy DevOps a čte se jako román.
V tabulce na opačné straně je uvedeno, jak často společnosti vydávají nové verze:
Jak to, že Amazon, Google a Netflix stíhají vydávat tolik? Je to jednoduché: pochopili, jak vytvořit téměř dokonalý DevOps řetězec.
U nás ve společnosti Citi to tak úplně nebylo, dokud jsme nepřešli na DevOps. Tehdy měla má tým různá prostředí, ale dodávku na vývojový server jsme prováděli ručně. Všichni vývojáři měli přístup pouze k jednomu vývojovému serveru na základě IBM WebSphere Application Server Community Edition. Při současném pokusu o dodávku server „spadl“ a my jsme se museli vždy „bolestivě“ domlouvat mezi sebou. A také jsme měli nedostatečné pokrytí kódu testy, zdlouhavý ruční proces dodávání a žádnou možnost sledovat dodávku kódu podle určité úlohy nebo požadavku zákazníka.
Bylo jasné, že je potřeba urgentně něco udělat, a tak jsem našel kolegu-komplizera. Rozhodli jsme se společně vytvořit první řetězec DevOps – on nastavil virtuální stroj a server aplikací Tomcat, zatímco já jsem se věnoval Jenkinsu, integraci s Atlassian Jira a BitBucket a také pokrytí kódu testy. Projekt byl úspěšný: plně jsme automatizovali vývojový cyklus, dosáhli jsme téměř 100% bezproblémového chodu vývojového serveru, mohli jsme sledovat a zlepšovat pokrytí kódu testy, a větev Git byla propojena s dodávkou a úkolem Jira. A téměř všechny nástroje, kterými jsme vytvářeli řetězec DevOps, byly s otevřeným zdrojovým kódem.
Ve skutečnosti byl řetězec zjednodušený, protože jsme ani nepoužívali pokročilé konfigurace pomocí Jenkinsu nebo Ansible. Ale podařilo se nám to. Možná je to důsledek principu (také známého jako pravidlo 80/20).
Stručný popis řetězce DevOps a CI/CD
DevOps má různá definice. DevOps, stejně jako Agile, zahrnuje různé disciplíny. Většina se však shodne na následující definici: DevOps je metoda, nebo životní cyklus, vývoje softwaru, jehož hlavním principem je vytváření kultury, v níž jsou vývojáři a ostatní zaměstnanci „na stejné vlně“, manuální práce je automatizována, každý dělá to, co umí nejlépe, zvyšuje se frekvence dodávek, zvyšuje se produktivita a zvyšuje se flexibilita.
Ačkoli samotné nástroje nestačí k vytvoření prostředí DevOps, bez nich se neobejdete. Nejvýznamnějším z nich je kontinuální integrace a kontinuální dodávka (CI/CD). V řetězci existují pro každé prostředí různé fáze (například DEV (vývoj), INT (integrace), TST (testování), QA (kontrola kvality), UAT (akceptační testování uživateli), STG (příprava), PROD (použití)), manuální úkoly jsou automatizovány, vývojáři mohou vytvářet kvalitní kód, provádět jeho dodávku a mohou se snadno přizpůsobit.
Tento poznámek popisuje, jak vytvořit řetězec DevOps v pěti krocích, jak je znázorněno na obrázku níže, pomocí nástrojů s otevřeným zdrojem.
Pojďme k tomu.
Krok 1: Platforma CI/CD
Nejprve potřebujete nástroj CI/CD. Jenkins je otevřený nástroj CI/CD napsaný v Javě s licencí MIT, který začal popularizaci hnutí DevOps a který se de facto stal standardem pro CICD.
Co je to Jenkins? Představte si, že máte kouzelné ovládání pro různé služby a nástroje. Sám o sobě je nástroj CI/CD, jako je Jenkins, k ničemu, ale s různými nástroji a službami se stává všemocným.
Kromě Jenkins existuje mnoho dalších otevřených nástrojů, vyberte si jakýkoliv.
Takto vypadá proces DevOps s nástrojem CI/CD.
Máte na localhostu nástroj CI/CD, ale zatím není moc co dělat. Přejdeme k dalšímu kroku.
Krok 2: správa verzí
Nejlepší (a pravděpodobně nejjednodušší) způsob, jak si ověřit magii nástroje CI/CD, je integrovat jej s nástrojem pro správu verzí (source control management, SCM). Proč je potřebná správa verzí? Představte si, že vytváříte aplikaci. Programujete ji v Javě, Pythonu, C++, Go, Ruby, JavaScriptu nebo jakémkoli jiném jazyce, kterých je spousta. To, co píšete, se nazývá zdrojový kód. Zpočátku, zejména pokud pracujete sami, můžete všechno uchovávat v místním adresáři. Ale když projekt roste a další lidé se k němu připojují, potřebujete způsob, jak sdílet změny v kódu, přičemž se vyhnout konfliktům při sloučení změn. A navíc musíte mít nějaký způsob, jak obnovit předchozí verze bez používání záloh a metody copy-paste pro soubory s kódem.
A tady se bez SCM neobejdete. SCM uchovává kód v repozitářích, spravuje jeho verze a koordinuje jej mezi vývojáři.
Nástrojů SCM je dost, ale standardem de facto se právem stal Git. Doporučuji použít právě jeho, ale existují i jiné možnosti.
Takto vypadá pipeline DevOps po přidání SCM.
Nástroj CI/CD může automatizovat nahrávání a stahování zdrojového kódu a týmovou spolupráci. Není to špatné? Ale jak nyní z toho vytvořit funkční aplikaci, kterou milují miliardy uživatelů?
Krok 3: nástroj pro automatizaci sestavení
Všechno probíhá, jak má. Můžete nahrávat kód a zaznamenávat změny v systému správy verzí, a také si pozvat přátele, aby s vámi pracovali. Ale zatím nemáte aplikaci. Aby to byla webová aplikace, je třeba ji zkompilovat a umístit do balíčku pro dodání nebo spustit jako spustitelný soubor. (Interpretovaný programovací jazyk, jako JavaScript nebo PHP, není třeba kompilovat.)
Používejte nástroj pro automatizaci sestavení. Ať už si vyberete jakýkoli nástroj, bude shromažďovat kód ve správném formátu a automatizovat úklid, kompilaci, testování a nasazení. Existují různě zaměřené nástroje pro sestavení v závislosti na jazyce, ale obvykle se používají následující varianty s otevřeným zdrojovým kódem.
Skvěle! Teď vložíme konfigurační soubory nástroje pro automatizaci sestavení do systému správy verzí, aby je nástroj CI/CD sestavil.
Vypadá to dobře. Ale kam nyní všechno toto nasadíme?
Krok 4: server webové aplikace
Takže máte zabalený soubor, který lze vykonávat nebo nasadit. Aby aplikace skutečně přinášela užitek, musí mít nějakou službu nebo rozhraní, ale potřebujete vše někam umístit.
Webovou aplikaci lze umístit na server webových aplikací. Server aplikací poskytuje prostředí, kde lze vykonávat programovou logiku z balíčku, vykreslovat uživatelské rozhraní a otevírat webové služby přes socket. Budete potřebovat HTTP server a několik dalších prostředí (například virtuální stroj), abyste mohli nainstalovat server aplikací. Zatím si představme, že se v tom všem vyznáte (i když o kontejnerech vám povím 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!
Principiálně můžete tady skončit, dál už zvládnete sami, ale stojí za to ještě mluvit o kvalitě kódu.
Krok 5: Testovací pokrytí
Testování zabere spoustu času a úsilí, ale je lepší hned najít chyby a zlepšit kód, abyste potěšili koncové uživatele. K tomuto účelu existuje spousta otevřených nástrojů, které nejen otestují kód, ale také navrhnou, jak ho zlepš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í frameworky pro psaní a provádění testů a nástroje s doporučeními pro zlepšení kvality kódu.
Testovací frameworky
Nástroje s doporučeními pro kvalitu
Většina těchto nástrojů a frameworků je napsaná pro Java, Python a JavaScript, protože C++ a C# jsou proprietární (i když GCC má otevřený zdrojový kód).
Nástroje pokrytí testů jsme implementovali a nyní by mělo vypadat DevOps pipeline jako na obrázku na začátku příručky.
Další kroky
Kontejnery
Jak jsem již zmínil, aplikační server lze hostit na virtuálním stroji nebo serveru, 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še DevOps řetězce jsou zaměřeny na společné sestavování a dodávání aplikací, ale s nástroji DevOps lze dělat i další zajímavé věci. Například používat nástroje "infrastruktura jako kód" (IaC), které se také nazývají nástroji pro automatizaci middleware. Tyto nástroje pomáhají automatizovat instalaci, správu a další úkoly pro middleware. Například nástroj pro automatizaci může vzít aplikace (server webové aplikace, databázi, nástroje pro monitorování) s správnými konfiguracemi a nasadit je na aplikační server.
Zde je několik otevřených nástrojů pro automatizaci middleware:
Podrobnosti v článcích na :
A co teď?
To je jen špička ledovce. DevOps řetězec může udělat mnohem víc. Začněte s CI/CD nástrojem a zjistěte, co dalšího lze automatizovat pro usnadnění vaší práce. Nezapomeňte na pro efektivní spolupráci.
Zde je několik dobrých článků o DevOps pro začátečníky:
A také můžete integrovat DevOps s otevřenými nástroji pro agile:
Zdroj: habr.com
