4-6. září v Petrohradě se v konferenčním sále Selectel uskuteční třídenní .
Program jsme sestavili s myšlenkou, že teoretické práce o DevOps a manuály k nástrojům si může každý přečíst sám. Zajímavé jsou pouze zkušenosti a praxe: vysvětlení, jak se to má dělat a jak ne, a příběh o tom, jak to děláme my.
V každé společnosti má každý administrátor nebo vývojář svou úroveň DevOps. Někteří nesprávně používají Git, jiní zavádějí SRE. Kurz je organizován tak, aby si každý našel něco aktuálního, co může zavést hned teď.
Začínáme s Gitem, poté se zaměříme na vývoj aplikace, interakci kódu a infrastruktury, budujeme CI/CD, popisujeme infrastrukturu jako kód (IaC), testujeme vyřešené řešení, nastavujeme monitoring, shromažďujeme a zkoumáme logy, a nakonec se dostáváme k SRE: přetváříme spolehlivost na měřitelný a říditelný příběh.
Git
V současnosti Git nepoužívá jen ten, kdo si včera koupil svůj první notebook. Je to triviální a rozšířený nástroj, a přesto se často setkáváme s jeho nesprávným používáním: od for pushu do masteru až po kopírování souborů z Gitu na server přes Ctrl-C, Ctrl-V.
Vysvětlujeme, jak to není potřeba dělat, jak to dělat správně, a jak to dělají v Southbridge.
Procházíme praxí: základy Gitu, týmová práce.
Téma č. 1: Základy práce s Gitem
- Základní příkazy git init, commit, add, diff, log, status, pull, push
- Git flow, větve a tagy, strategie sloučení
- Práce s několika vzdálenými repositáři
Téma č. 2: Týmová práce s Git
- GitHub flow
- Fork, remote, pull request
- Konflikty, releasy, ještě jednou o Gitflow a dalších flow aplikovatelných pro týmy
Materiál je organizován tak, aby administrátoři a vývojáři mohli okamžitě zavést všechny praktiky do své práce.
Z hlediska DevOps správná práce s Git uspořádává a automatizuje procesy vývoje a administrace, vylučuje řadu opakujících se problémů a zvyšuje produktivitu práce.
DevOps vývojář
Díváme se na DevOps očima vývojáře: spouštíme místní prostředí, píšeme aplikaci, nastavujeme její monitoring a logování, místně ji testujeme, organizujeme uchovávání proměnných/tajností a zajištění služeb, sledujeme trasování (opentracing).
Téma č. 3: Práce s aplikací z pohledu vývoje
- Nastavení místního prostředí: praktické doporučení
- Píšeme mikroservis v Pythonu (včetně testů)
- Použití docker-compose ve vývoji
Téma č. 4: Interakce kódu a infrastruktury
- Praxe práce s konfiguracemi
Na konci vývojáři uvidí, jak kód posílat logy, jak ho testovat, jak ho následně debagovat. Administrátoři porozumí potřebám vývojářů: jaké chyby v kódu se vyskytují, jak organizovat testování vývojářů, jak testovat projekt samostatně.
V této fázi je vyřešena hlavní úloha DevOps: vzniká vzájemné porozumění a spolupráce mezi devy a ops. To je klíčový krok k přechodu od přehazování úkolů k odpovědnému vzájemnému jednání.
Výsledkem je zlepšení rychlosti a kvality práce.
CI/CD
Moderní automatizace zahrnuje CI/CD. Začneme tím, že se podíváme na ruční automatizaci: make soubory, git hooks, skripty. Prozkoumáme, kdy jsou tyto nástroje stále relevantní a kdy je lepší je nepoužívat.
Pak se podíváme na nejlepší praktiky moderního CI na příkladu Gitlab.
Téma č. 5: CI/CD zavedení do automatizace
- Úvod do automatizace
- Nástroje (bash, make, gradle)
- Použití git-hooks pro automatizaci procesů
- Tovární řešení výrobních linek a jejich aplikace v IT
- Příklad vybudování „společného“ pipeline
- Moderní software pro CI/CD: Drone CI, BitBucket Pipelines, Travis atd.
Téma č. 6: CI/CD: Práce s Gitlab
- Gitlab CI — obecně
- Gitlab Runner, jejich typy a použití
- Gitlab CI, specifika nastavení, nejlepší praktiky
- Fáze Gitlab CI
- Proměnné Gitlab CI
- Sestavení, testování, nasazení
- Kontrola a omezení provádění: only, when
- Práce s artefakty
- Šablony uvnitř .gitlab-ci.yml, znovu použití akcí na různých místech pipeline
- Include — sekce
- Centralizované řízení gitlab-ci.yml (jeden soubor a automatické push do ostatních repozitářů)
Spolupráce administrátorů a vývojářů je na nové úrovni: administrátor píše šablonu CI, kterou vývojáři upravují, vytvářejí svůj CI nezávisle na administrátorovi.
Snižuje se závislost vývojářů na administrátorech, zmenšuje se množství ruční práce, zmizí problém „jediné osoby, která ví, jak pracovat s makefile“. Nasazení probíhá spolehlivě a rychle.
IaC
Téma Infrastructure as Code na příkladu Terraform přiblíží administrátor cloudu Selectel Alexej Stepanjko. Ukáže, jak rychle a automatizovaně nasadit a škálovat servery, jak automaticky balit obrazy a jak používat konfigurační šablony k okamžitému zisku nastavených strojů.
Člověk, který vytvořil tisíce řešení IaC, ukáže, jak to dělat správně a jak to dělat nemá.
Řešení pro cloud Selectel s minimálními úpravami se hodí pro cloudy Google a Amazon.
Zaměstnanec Southbridge Nikolaj Mesropjan na příkladu Ansible ukáže, jak bez výpadku nasadit funkční aplikaci a ověřit její práci.
Pokud je třeba upravit infrastrukturu ručně (nastavovat servery a podle potřeby instalovat knihovny, balíčky), při pokusu o zvednutí kopie prostředí si musíte vzpomenout a reprodukovat všechny své kroky. Tato úloha snadno zabere 3-5 dní. Práce s infrastrukturou jako s kódem zaručuje, že máte aktuální popis prostředí, které lze nasadit během minut.
Nikolaj poví, jak psát playbooky, jaké chyby se vyskytují, proč někdy playbooky fungují pomalu nebo ne tak, jak se očekávalo. Je to zkušenost mnoha let používání IaC v Southbridge.
Téma č. 7: Infrastructure as Code
- IaC: přístup k infrastruktuře jako kódu
- Cloudoví poskytovatelé jako dodavatelé infrastruktury
- Nástroje pro inicializaci systémů, sestavení obrazů (packer)
- IaC na příkladu Terraformu
- Ukládání konfigurací, spolupráce, automatizace aplikací
- Praktika vytváření Ansible playbooků
- Idempotentnost, deklarativnost
- IaC na příkladu Ansible
- Database as a Code / Odolnost PostgreSQL
Infrastruktura získává deklarativnost a idempotentnost.
Administrátor se učí spravovat složitou infrastrukturu: rychle vytvářet nová prostředí, udržovat jednotnost všech prostředí, vidět historii změn, což je kritické, když na projektu pracuje několik týmů.
Vývojář může studovat infrastrukturu, samostatně si nasazovat prostředí.
Bonus části — vytvoření a nastavení odolného klastru databází PostgreSQL. Poskytneme hotový playbook, který používáme v Southbridge, vy nasadíte cluster na učebním standu a budete moci toto řešení používat ve své společnosti.
Testování infrastruktury a monitoring
Automatizace umožňuje rozložit chybu na tisíc serverů. Při každé změně je nutné testování. Na druhou stranu, ruční testování zabírá tolik času, že znehodnocuje výhody automatizace.
Ukážeme prakticky, jak psát testování rolí. Výsledkem budete schopni psát testy pro svou společnost. Už nebude třeba pamatovat si vytvořená nastavení, popisujte je v testech a automaticky kontrolujte, že všechna předchozí řešení a záplaty jsou na svém místě.
Poté se naučíme automaticky přidávat všechny nové servery do monitoringu. Zaměříme se zvlášť na monitoring infrastruktury a aplikací. Ukážeme špatné a dobré praktiky.
Téma č. 8: Testování infrastruktury
- Testování a nepřetržitá integrace s Molecule a Gitlab CI
- Použití Vagrant
Téma č. 9: Monitoring infrastruktury s Prometheus
- Proč je monitoring potřebný
- Typy monitoringu
- Oznámení v systému monitoringu
- Jak postavit zdravý monitoringový systém
- Člověku čitelné oznámení pro všechny
- Health Check: na co si dát pozor
- Automatizace na základě dat z monitoringu
Špatně fungující monitoring — to je absence monitoringu. Firmám je jedno, že je hlavní stránka internetového obchodu dostupná, pokud forma platby hlásí chybu.
Na nastavení monitoringu a odstranění problémů se podílejí vývojáři i administrátoři rovnocenně. Tradičně ale úkoly monitoringu leží na administrátorech. Náš kurz ukáže vývojářům, jakou roli hrají při vytváření efektivního monitoringu. Administrátoři získají nejlepší praktiky od Southbridge. Výsledkem bude rychlý pokles ztrát způsobených výpadky a zpomalením webu nebo aplikace.
Bonus této části: automatizace na základě monitoringu. Například monitoring hlásí, že na web přišla zátěž, a automaticky se spustí škálování webových serverů.
Logování
Hlavní chybou ve spolupráci s logy je, že administrátoři a vývojáři je sledují přímo na serverech. Pokud máte více než jeden server, trvá to dlouho. Je to nesecure: vývojář vstupuje na server, kde by neměl být.
DevOps vyžaduje centralizované shromažďování, zpracování a analýzu logů.
Téma č. 10: Logování aplikace s ELK
- Hlavní aplikace a možnosti elastic (vyhledávání, úložiště, vlastnosti škálovatelnosti, flexibilita nastavení)
- Přehled kibany (hlavní funkce, jazyk dotazů, správa dashboardů, vytváření grafů)
- Přehled produktů na bázi elastic a jejich využití
- Shromažďujeme metriky v APM (tracování aplikací)
- Navíc: Přehled nového produktu — SIEM
Implementace tohoto přístupu učiní logy jednoduchým a srozumitelným nástrojem pro analýzu, konfiguraci a ladění aplikace a infrastruktury.
SRE
A dostáváme se k tématu, na které se Southbridge teprve dívá a kvůli kterému chtějí ostatní řečníci zůstat na poslední den Slørmu. Jsme rádi, že o něm souhlasil číst Ivan Kruglov z Booking.com.
Projekt žije v reálném světě, kde spolehlivost nikdy není absolutní a každé rozhodnutí něco stojí.
Co je to SLA ve vztahu ke složitému projektu? Řekněme, jak posuzovat, že je web dostupný, ale obrázky se načítají se zpožděním. Jaké jsou metriky SLA, kde je měřit, jak je měřit?
Jak nastavit SLA? Jak je dodržet?
Téma č. 11: SRE
Definice SLA, SLO, Error Budget a další strašidelné termíny ze světa SRE
SRE: Praktika monitorování SLI a SLO
SRE: Praktika aplikace Error Budget
SRE: Řízení přerušení a operační zátěže (apigateway, service mesh, circuit breakers)
Byznys chce SRE. Alespoň na nejzákladnější úrovni: brát záložní server nebo obnovit z backupu? Jedna databáze nebo cluster? Zavádět ochranu před DDoS preventivně nebo pouze v okamžiku útoku?
Ředitele neuspokojí vyprávění o tom, že „web funguje“, když mu volá klient a oznamuje, že se objednávkový formulář neotevírá.
Proto je pro DevOps inženéra důležité alespoň povrchně porozumět SRE, aby mohl adekvátně komunikovat s byznysem o jeho potřebách.
Výsledek
Během administrátoři a vývojáři se naučí:
— správně pracovat s Gitem;
— organizovat lokální vývoj;
— nastavit (administrátoři) a používat (vývojáři) CI/CD;
— pracovat s infrastrukturou jako s kódem;
— testovat infrastrukturu;
— monitorovat infrastrukturu a aplikaci;
— nastavit logování;
— rozumět a v ideálním případě — používat SRE.
Pro pozorné čtenáře — s promo kódem habrapost sleva 15%.
U všech bodů připravujeme praxi a nástroje. Takže každý účastník se po návratu ze Slørmu bude moci posunout svou společnost na další úroveň DevOps.
Pro byznys to znamená snížení nákladů na administraci a vývoj, snížení downtime, zvýšení spolehlivosti, rychlejší dodání funkcí a odstranění chyb.
Zdroj: habr.com
