Szeptember 4-6-án Szentpéterváron, a Selectel konferenciatermében háromnapos .
A programot úgy állítottuk össze, hogy a DevOps elméleti írásait és az eszközökhöz készült manuálokat mindenki egyedül is elolvashatja. Csak a tapasztalat és a gyakorlat érdekes: ahelyett, hogy elmondanánk, hogyan kell csinálni és hogyan nem, inkább arról beszélünk, hogyan csináljuk mi.
Minden vállalatnál, minden adminisztrátornak vagy fejlesztőnek más a DevOps szintje. Van, aki helytelenül használja a Gitet, mások SRE-t vezetnek be. A tanfolyam úgy van megszervezve, hogy mindenki találjon benne valami hasznosat, amit azonnal alkalmazhat.
A Gittel kezdjük, majd áttekintjük az alkalmazásfejlesztést, a kód és az infrastruktúra együttműködését, CI/CD-t építünk, leírjuk az infrastruktúrát kódként (IaC), teszteljük a kapott megoldást, beállítjuk a monitoringot, begyűjtjük és elemezzük a naplókat, végül eljutunk az SRE-hez: a megbízhatóságot mérhető és kezelhető történetté alakítjuk.
Konténerizálás
Jelenleg csak az nem használ Gitet, aki tegnap vásárolta meg az első laptopját. Ez egy triviális és elterjedt eszköz, mégis gyakran találkozunk helytelen használatával: kezdve a kényszerített push-tól a master ágba, egészen addig, hogy fájlokat másolnak a Gittől a szerverre Ctrl-C, Ctrl-V segítségével.
Elmondjuk, hogyan nem szabad csinálni, hogyan kell csinálni, és hogyan csinálják a Southbridge-nél.
Gyakorlatot végzünk: a Git alapjai, csapatmunka.
Téma #1: A Git használatának alapjai
- Alapvető parancsok: git init, commit, add, diff, log, status, pull, push
- Git flow, ágak és címkék, merge stratégiák
- Több távoli repo kezelése
Téma #2: Csapatmunka a Git-tel
- GitHub flow
- Fork, remote, pull request
- Konfliktusok, kiadások, még egyszer a Gitflow-ról és egyéb folyamatokról csapatra vonatkozóan
Az anyag úgy van megszervezve, hogy az adminisztrátorok és a fejlesztők azonnal be tudjanak építeni minden gyakorlatot a munkájukba.
DevOps szempontból a Git helyes használata rendszerezi és automatizálja a fejlesztési és adminisztrációs folyamatokat, kiküszöbölve számos visszatérő problémát, és növelve a termelékenységet.
DevOps fejlesztő
A DevOps-t a fejlesztő szemén keresztül nézzük: elindítjuk a helyi környezetet, alkalmazást írunk, beállítjuk a monitoringot és a naplózást, helyben teszteljük, szervezzük a változók/titkok és a service discovery tárolását, nyomon követjük a trace-öt (opentracing).
Téma #3: Az alkalmazás fejlesztési szempontból való kezelése
- Helyi környezet beállítása: gyakorlati tanácsok
- Mikroszolgáltatás írása Pythonban (beleértve a teszteket)
- A docker-compose alkalmazása a fejlesztésben
4. téma: A kód és az infrastruktúra kölcsönhatása
- Konfigurációkkal való munka gyakorlata
A fejlesztők láthatják, hogyan kell a kódnak naplókat küldenie, hogyan kell tesztelni, és hogyan fognak a jövőben hibakeresést végezni. Az adminisztrátorok megértik a fejlesztők igényeit: milyen hibák fordulhatnak elő a kódban, hogyan lehet a fejlesztők számára tesztelést szervezni, és hogyan lehet a projektet saját magunknak tesztelni.
Ebben a szakaszban megoldódik a DevOps fő feladata: a fejlesztők és üzemeltetők közötti kölcsönös megértés és együttműködés kialakítása. Ez kulcsfontosságú lépés a feladatok átdobálásáról a felelős együttműködésre való áttérése.
Ennek eredményeként nő a munka sebessége és minősége.
CI/CD
A modern automatizálás magában foglalja a CI/CD-t. Kezdetben megnézzük a manuális automatizálást: makefile-ok, git hook-ok, skriptek. Átvizsgáljuk, mikor relevánsak ezek az eszközök, és mikor nem érdemes őket használni.
Ezután a legjobb modern CI gyakorlatokat a Gitlab példáján fogjuk bemutatni.
5. téma: CI/CD, bevezetés az automatizálásba
- Bevezetés az automatizálásba
- Eszközök (bash, make, gradle)
- Git hook-ok alkalmazása a folyamatok automatizálásához
- Gyártási konvejor-gyűjtővonalak és alkalmazásuk az IT-ben
- Példa egy "általános" pipeline felépítésére
- Modern CI/CD szoftverek: Drone CI, BitBucket Pipelines, Travis, stb.
6. téma: CI/CD: Munka a Gitlab-bal
- Gitlab CI — általános áttekintés
- Gitlab Runner, típusai és alkalmazásuk
- Gitlab CI, beállítási sajátosságok, legjobb gyakorlatok
- Gitlab CI szakaszai
- Gitlab CI változók
- Build, tesztelés, telepítés
- Munkával kapcsolatos artefaktumok
- Sablonok, beillesztések és mikroszolgáltatások: megkönnyítjük a telepítést
- Sablonok a .gitlab-ci.yml fájlban, tevékenységek újrahasználása a pipeline különböző szakaszaiban
- Include — szekciók
- Központosított kezelés gitlab-ci.yml (egy fájl és automatikus push a többi repóba)
Az adminisztrátorok és fejlesztők közötti együttműködés új szintre lép: az adminisztrátor CI sablonokat ír, a fejlesztők pedig módosítják azokat, így saját CI-t alakítanak ki függetlenül az adminisztrátoroktól.
Csökken a fejlesztők adminisztrátoroktól való függősége, csökken a manuális munka mennyisége, és megszűnik az a probléma, hogy "csak egy ember tudja, hogyan kell kezelni a makefile-t". A kiadások megbízhatóan és gyorsan történnek.
IaC
A infrastruktúra kódba ágyazás témájában a Selectel felhőadminisztrátora, Alekszej Stepanyenko beszél. Meg fogja mutatni, hogyan lehet gyorsan és automatizáltan telepíteni és skálázni a szervereket, hogyan lehet automatikusan csomagolni a képeket, és hogyan lehet konfigurációs sablonokat használni, hogy azonnal beállított gépeket kapjunk.
Az ember, aki több ezer IaC megoldást készített, meg fogja mutatni, hogyan kell helyesen csinálni, és mit érdemes elkerülni.
A Selectel felhőmegoldása minimális módosításokkal alkalmazható a Google és az Amazon felhőiben.
A Southbridge munkatársa, Nyikolaj Meszropjan az Ansible példáján keresztül fogja megmutatni, hogyan lehet leállás nélkül telepíteni egy működő alkalmazást, és ellenőrizni annak működését.
Ha kézzel állítja be az infrastruktúrát (szervereket konfigurál, szükség szerint könyvtárakat, csomagokat telepít), amikor próbálja felállítani a környezet másolatát, emlékeznie kell minden lépésére, amit tett. Ez a feladat könnyen 3-5 napot igénybe vehet. Az infrastruktúra kódba ágyazása garantálja, hogy aktuális környezetleírással rendelkezik, amelyet perceken belül telepíthet.
Nyikolaj elmondja, hogyan írjunk playbookokat, milyen hibák fordulhatnak elő, és miért működnek néha lassan a playbookok, vagy nem úgy, ahogy vártuk. Ez évek tapasztalata az IaC használatával a Southbridge-nél.
Téma №7: Infrastruktúra mint kód
- IaC: megközelítés az infrastruktúra kódként való kezelésére
- Felhőszolgáltatók mint infrastruktúra szolgáltatók
- Rendszerinicializáló eszközök, képek készítése (packer)
- IaC Terraform példáján
- Konfigurációk tárolása, együttműködés, alkalmazások automatizálása
- Ansible playbookok létrehozásának gyakorlata
- Idempotencia, deklarativitás
- IaC Ansible példáján
- Adatbázis mint kód / Hibatűrő PostgreSQL
Az infrastruktúra deklaratív és idempotens jelleget nyer.
Az adminisztrátor megtanulja kezelni a bonyolult infrastruktúrát: gyorsan új környezeteket létrehozni, fenntartani az összes környezet egységességét, és nyomon követni a változások történetét, ami kritikus, amikor több csapat dolgozik a projekten.
A fejlesztő tanulmányozhatja az infrastruktúrát, és önállóan telepíthet magának környezeteket.
A szakasz bónusza — hibatűrő PostgreSQL adatbázis klaszter létrehozása és konfigurálása. Adunk egy kész playbookot, amelyet a Southbridge-nél használunk, Ön telepíteni fog egy klasztert egy oktatási környezetbe, és ezt a megoldást használhatja a cégnél.
Az infrastruktúra tesztelése és monitorozás
Az automatizálás lehetővé teszi, hogy egy hibát azonnal több ezer szerverre kiadjanak. Minden változtatás esetén tesztelni kell. Másrészről, a manuális tesztelés annyi időt igényel, hogy így elveszti az automatizálás előnyeit.
Megmutatjuk, hogyan írjunk szerepkör-tesztelést a gyakorlatban. Ennek eredményeként képes leszel teszteket írni a saját céged számára. már nem kell megjegyezni a beállításokat, hanem a tesztekben rögzíted őket, és automatikusan ellenőrzöd, hogy minden korábbi megoldás és kiskapu a helyén van-e.
Ezután megtanuljuk, hogyan adjuk automatikusan hozzá az összes új szervert a monitorozáshoz. Külön vizsgáljuk a infrastruktúra és az alkalmazás monitorozását. Megmutatjuk a rossz és a jó gyakorlatokat.
8. téma: Infrastruktúra tesztelése
- Tesztelés és folyamatos integráció Molecule-lal és Gitlab CI-vel
- Vagrant alkalmazása
9. téma: Infrastruktúra monitorozás Prometheusszal
- Miért szükséges a monitorozás
- Monitorozás típusai
- Értesítések a monitorozási rendszerben
- Hogyan építsünk egészséges megfigyelőrendszert
- Emberi olvasásra alkalmas értesítések, mindenkinek
- Health Check: Mire érdemes figyelni
- Automatizálás a monitorozásból származó adatok alapján
A nem megfelelően működő monitorozás a monitorozás hiányát jelenti. A cégeknek mindegy, ha a webáruház főoldala elérhető, ha a fizetési forma hibát jelez.
A monitorozás beállításában és a problémák elhárításában a fejlesztők és az adminisztrátorok egyaránt részt vesznek. A monitorozási feladatok hagyományosan az adminisztrátorokra hárulnak. Tanfolyamunk megmutatja a fejlesztők számára, hogy milyen szerepet játszanak hatékony monitorozás kialakításában. Az adminisztrátorok a Southbridge legjobb gyakorlatait kapják. Ennek eredményeként a weboldal vagy alkalmazás leállásából vagy akadozásából eredő veszteségek gyorsan csökkenni fognak.
A szakasz bónusza: automatizálás a monitorozás alapján. Például a monitorozás jelzi, hogy megnövekedett a terhelés a weboldalon, és a webkiszolgálók skálázása automatikusan elindul.
Naplózás
A logok kezelésének legnagyobb hibája, hogy az adminisztrátorok és a fejlesztők közvetlenül a szervereken nézik őket. Ha több mint egy szervered van, ez időigényes. Ez nem biztonságos: a fejlesztő olyan szerverre lép be, ahol nem lenne szabad.
A DevOps központosított loggyűjtést, -feldolgozást és -analitikát igényel.
10. téma: Alkalmazás loggolás ELK-val
- Az elastic fő alkalmazásai és lehetőségei (keresés, tárolás, skálázási sajátosságok, testreszabás rugalmassága)
- Kibana áttekintése (főbb funkciók, lekérdezési nyelv, irányítópultok kezelése, grafikonok készítése)
- Elastic alapú termékek áttekintése és alkalmazásuk
- Metrikák gyűjtése APM-ben (alkalmazásnyomozás)
- Továbbá: Új termék áttekintése — SIEM
Ennek a megközelítésnek a bevezetése a naplók egyszerű és világos eszközzé válik az alkalmazás és az infrastruktúra elemzésére, beállítására és finomhangolására.
SRE
Elérkeztünk ahhoz a témához, amelyet a Southbridge csak szemléz, és amely miatt más előadók az utolsó napon szeretnének maradni a Slyermán. Örömmel értesítjük, hogy e témát Ivan Kruglov, a Booking.com képviseletében elfogadta a beszédre.
A projekt valós környezetben működik, ahol a megbízhatóság sosem lehet abszolút, és minden döntés pénzbe kerül.
Mi az SLA egy komplex projekt kapcsán? Például, hogyan értékeljük, hogy a weboldal elérhető, de a képek késlekedéssel töltődnek be? Mik az SLA méretei, honnan és hogyan gyűjtjük őket?
Hogyan állítsuk be az SLA-t? Hogyan tartsuk be őket?
11. téma: SRE
Az SLA, SLO, Error Budget definíciója és más félelmetes fogalmak az SRE világából.
SRE: Az SLI és SLO monitorozási gyakorlata.
SRE: Az Error Budget alkalmazásának gyakorlata.
SRE: Megszakítások és operatív terhelés kezelése (apigateway, service mesh, körkörös brókerek).
Az üzlet SRE-t szeretne. Legalább a legegyszerűbb szinten: tartalék szervert használni vagy visszaállítani egy biztonsági mentésből? Egy adatbázis vagy klaszter? DDoS védelem telepítése előzetesen vagy csak a támadás pillanatában?
A vezetők nem fogják elfogadni azt a választ, hogy "az oldal működik", amikor az ügyfél hívja és közli, hogy a rendelési űrlap nem nyílik meg.
Ezért a DevOps mérnöknek fontos legalább felületesen értenie az SRE-t, hogy megfelelően tudjon beszélni az üzlet igényeiről.
Result
Időközben az adminisztrátorok és fejlesztők megtanulják:
— helyesen dolgozni a Gittel;
— megszervezni a helyi fejlesztést;
— beállítani (adminisztrátorok) és használni (fejlesztők) a CI/CD-t;
— infrastruktúrát kezelni mint kódot;
— tesztelni az infrastruktúrát;
— monitorozni az infrastruktúrát és az alkalmazást;
— beállítani a naplózást;
— érteni, és ideális esetben használni az SRE-t.
A figyelmes olvasók számára — a habrapost promóciós kóddal 15% kedvezmény.
Minden pontra gyakorlati anyagot és eszközöket készítünk. Így minden résztvevő a Slyermáról visszatérve képes lesz a cégét a DevOps következő szintjére emelni.
Ez az üzlet számára az adminisztráció és fejlesztés költségeinek csökkentését, a leállások minimalizálását, a megbízhatóság növelését, a funkciók gyorsabb szállítását és a hibák kiküszöbölését jelenti.
Forrás: habr.com
