Od 4. do 6. septembra v Sankt Peterburgu, v konferenčni dvorani Selectel, bo potekala tridnevna .
Program smo oblikovali ob misli, da si lahko vsak teoretične delavnice o DevOps in priročnike za orodja prebere sam. Zanimivi so samo izkušnje in praksa: razlaga, kako je treba in kako ni, ter pripoved, kako delamo mi.
Vsaka podjetja, vsak skrbnik ali razvijalec ima svoj nivo DevOps. Nekateri nepravilno uporabljajo Git, drugi uvajajo SRE. Tečaj je zasnovan tako, da vsak najde nekaj aktualnega, kar lahko vpelje tu in zdaj.
Začnemo z Gitom, nato preučimo razvoj aplikacije, interakcijo kode in infrastrukture, zgradimo CI/CD, opisujemo infrastrukturo kot kodo (IaC), testiramo rešitev, nastavimo spremljanje, zbiramo in preučujemo dnevnike, in na koncu pridemo do SRE: zanesljivost pretvorimo v merljivo in obvladljivo zgodbo.
Git
Danes Gita ne uporablja le tisti, ki je včeraj kupil svoj prvi prenosnik. To je trivialno in splošno orodje, kljub temu pa se pogosto srečujemo z njegovo nepravilno uporabo: od nasilnega potiska v glavno vejo do kopiranja datotek iz Gita na strežnik s Ctrl-C, Ctrl-V.
Povezujemo, kako ne izvajati, kako izvajati in kako delajo v Southbridge.
Opravimo prakso: osnove Gita, timsko delo.
Tema št. 1: Osnove dela z Gitom
- Osnovne ukaze git init, commit, add, diff, log, status, pull, push
- Git flow, veje in oznake, strategije spajanja
- Delo z več oddaljenimi repozitoriji
Tema №2: Timski rad sa Git-om
- GitHub flow
- Fork, remote, pull request
- Konflikti, izdaje, še enkrat o Gitflow in drugih tokovih v zvezi s ekipami
Gradivo je organizirano tako, da lahko skrbniki in razvijalci takoj uresničijo vse prakse v svojem delu.
Z vidika DevOps pravilno delo z Gitom ureja in avtomatizira procese razvoja in upravljanja, izključuje vrsto ponavljajočih se težav in povečuje produktivnost.
DevOps razvijalec
Gledamo na DevOps skozi oči razvijalca: zaženemo lokalno okolje, pišemo aplikacijo, nastavljamo njeno spremljanje in beleženje, jo lokalno testiramo, organiziramo shranjevanje spremenljivk/dokumentov in odkrivanje storitev, gledamo sledenje (opentracing).
Tema št. 3: Delo z aplikacijo z vidika razvoja
- Nastavitev lokalnega okolja: praktični nasveti
- Pisanje mikrorazvoda u Pythonu (uključujući testove)
- Primjena docker-compose u razvoju
Tema br. 4: Interakcija koda i infrastrukture
- Praksa rada s konfiguracijama
Na kraju, programeri će vidjeti kako kod treba slati logove, kako ga testirati, i kako će se kasnije otklanjati greške. Administratori će razumjeti potrebe programera: koje greške u kodu se javljaju, kako organizirati testiranje za programere, i kako sami testirati projekat.
U ovoj fazi se rješava glavni cilj DevOps-a: uspostavljanje međusobnog razumijevanja i saradnje između developera i operativaca. To je ključni korak ka prelasku sa prebacivanja zadataka na odgovornu interakciju.
Kao rezultat, raste brzina i kvalitet rada.
CI/CD
Moderna automatizacija podrazumijeva CI/CD. Počećemo tako što ćemo pogledati ručnu automatizaciju: makefile-ove, git hook-ove, skripte. Razmotrićemo kada su ovi alati još uvijek relevantni, a kada ih ne treba koristiti.
Zatim ćemo pogledati najbolje prakse modernog CI-a na primjeru Gitlaba.
Tema br. 5: CI/CD uvod u automatizaciju
- Uvod u automatizaciju
- Alati (bash, make, gradle)
- Korištenje git hook-ova za automatizaciju procesa
- Fabrike za montažu i njihova primjena u IT-u
- Primjer izgradnje «zajedničkog» pipeline-a
- Moderni softver za CI/CD: Drone CI, BitBucket Pipelines, Travis i dr.
Tema br. 6: CI/CD: Rad s Gitlabom
- Gitlab CI — uvod
- Gitlab Runner, njihovi tipovi i primjena
- Gitlab CI, karakteristike podešavanja, najbolje prakse
- Faze Gitlab CI-a
- Varijable Gitlab CI-a
- Izgradnja, testiranje, implementacija
- Kontrola i ograničenja izvršenja: only, when
- Rad s artefaktima
- Šabloni unutar .gitlab-ci.yml, ponovna upotreba akcija na različitim delovima pipeline-a
- Include — sekcije
- Centralizovano upravljanje gitlab-ci.yml (jedan fajl i automatski push u ostale repozitorije)
Saradnja administratora i programera dolazi na novi nivo: administrator piše CI šablon, a programeri ga prilagođavaju, gradeći svoj CI nezavisno od administratora.
Smanjuje se zavisnost programera od administratora, smanjuje se količina ručnog rada, nestaje problem «jedine osobe koja zna raditi s makefile-om». Implementacije se dešavaju pouzdano i brzo.
IaC
Na temo Infrastructure as Code na primeru Terraform bo spregovoril administrator oblakov Selectel Aleksej Stepanenko. Prikazal bo, kako hitro in avtomatizirano razporediti in skalirati strežnike, kako avtomatsko pakirati slike ter kako uporabljati predloge konfiguracij za takojšnje pridobivanje nastavljenih naprav.
Oseba, ki je ustvarila na tisoče rešitev IaC, bo razložila, kako stvari početi prav in kako ne.
Rešitev za oblak Selectel s minimalnimi spremembami ustreza oblakom Google in Amazon.
Zaposleni pri Southbridge Nikolaj Mesropyan bo na primeru Ansible pokazal, kako brez izpadov razporediti delujočo aplikacijo in preveriti njeno delovanje.
Če pridobivate infrastrukturo ročno (nastavljate strežnike, po potrebi nameščate knjižnice, pakete), se ob poskusu vzpostavitve kopije okolja boste morali spomniti in obnoviti vse svoje dejanje. Ta naloga običajno traja 3-5 dni. Delo z infrastrukturo kot kodo zagotavlja, da imate aktualen opis okolja, ki ga lahko razporedite v nekaj minutah.
Nikolaj bo razložil, kako pisati playbooke, kakšne napake se pojavljajo ter zakaj včasih playbooki delujejo počasi ali ne delujejo, kot bi pričakovali. To je izkušnja mnogih let uporabe IaC v Southbridge.
Tema št. 7: Infrastructure as Code
- IaC: pristop k infrastrukturi kot k kodi
- Oblačni ponudniki kot dobavitelji infrastrukture
- Orodja za inicializacijo sistemov, sestavljanje slik (packer)
- IaC na primeru Terraform
- Shranjevanje konfiguracij, skupno delo, avtomatizacija aplikacij
- Praksa ustvarjanja Ansible playbookov
- Idempotentnost, deklarativnost
- IaC na primeru Ansible
- Database as Code / Odporna arhitektura PostgreSQL
Infrastruktura pridobi deklarativnost in idempotentnost.
Administrator se uči upravljati zapleteno infrastrukturo: hitro ustvarjati nova okolja, vzdrževati enotnost vseh okolij, videti zgodovino sprememb, kar je ključno, ko na projektu dela več ekip.
Razvijalec lahko proučuje infrastrukturo in si samostojno vzpostavi okolja.
Bonus razdelka — ustvarjanje in nastavitev odporne baze podatkov PostgreSQL. Dali bomo pripravljen playbook, ki ga uporabljamo v Southbridge, vi pa boste razporedili zbirko na učnem stojalu in lahko to rešitev uporabite v svojem podjetju.
Testiranje infrastrukture in spremljanje
Avtomatizacija omogoča odpraviti napako takoj na tisoče strežnikov. Pri vsaki spremembi je potrebno testiranje. Po drugi strani pa ročno testiranje vzame toliko časa, da zniža prednosti avtomatizacije.
Prikazali bomo v praksi, kako pisati testiranje vlog. Tako boste lahko pisali teste za svoje podjetje. Nič več ne bo treba pomniti naredjenih nastavitev, opisujete jih v testih in samodejno preverjate, da so vsa prejšnja rešitev in 'štango' na mestu.
Naučili se bomo samodejno dodajati vse nove strežnike v monitoring. Podrobneje bomo obravnavali monitoring infrastrukture in aplikacije. Prikazali bomo slabe in dobre prakse.
Tema št. 8: Testiranje infrastrukture
- Testiranje in neprekinjena integracija z Molecule in Gitlab CI
- Uporaba Vagrant
Tema št. 9: Monitoring infrastrukture s Prometheus
- Zakaj je potreben monitoring
- Vrste monitoringa
- Obvestila v sistemu monitoringa
- Kako zgraditi zdrav sistem monitoringa
- Človeku čitljiva obvestila, za vse
- Health Check: na kaj je treba biti pozoren
- Avtomatizacija na podlagi podatkov iz monitoringa
Nepravilno delujoč monitoring — to je pomanjkanje monitoringa. Poslovanju ni mar, da je glavna stran spletne trgovine dostopna, če obrazec za plačilo daje napako.
Pri nastavitvi monitoringa in reševanju težav sodelujejo razvijalci in administratorji enakovredno. Tradicionalno so naloge monitoringa padajo na administratorje. Naš tečaj bo pokazal razvijalcem, kakšno vlogo igrajo pri ustvarjanju učinkovitega monitoringa. Administratorji bodo prejeli najboljše prakse Southbridge. Tako bo število izgub, ki jih povzročajo napake in zamude spletnih mest ali aplikacij, hitro upadlo.
Bonus dela: avtomatizacija na podlagi monitoringa. Na primer, monitoring sporoča, da je prišla obremenitev na spletno stran, in samodejno se sproži skaliranje spletnih strežnikov.
Zapisovanje
Glavna napaka pri delu z dnevniki je, da administratorji in razvijalci gledajo le-te neposredno na strežnikih. Če imate več kot en strežnik, to traja dolgo. To ni varno: razvijalec dostopa do strežnika, kjer ne bi smel biti.
DevOps zahteva centralizirano zbiranje, obdelavo in analitiko dnevnikov.
Tema št. 10: Dnevniki aplikacije z ELK
- Glavne uporabe in možnosti elastic (iskanje, shranjevanje, značilnosti skaliranja, prilagodljivost nastavitve)
- Pregled kibane (glavne možnosti, jezik poizvedb, upravljanje nadzornimi ploščami, ustvarjanje grafikonov)
- Pregled izdelkov na temelju elastic in njihova uporaba
- Zbiramo metrike v APM (sledenje aplikacijam)
- Dodatno: Pregled novega izdelka — SIEM
Uvedba tega pristopa bo naredila dnevnike preprosto in razumljivo orodje za analizo, nastavitev in prilagoditev aplikacije ter infrastrukture.
SRE
In prišli bomo do teme, ki jo Southbridge le opazuje in zaradi katere drugi govorniki želijo ostati zadnji dan Slërma. Veselimo se, da bo to bral Ivan Kruglov iz Booking.com.
Projekt živi v resničnem svetu, kjer zanesljivost nikoli ni absolutna, in vsaka odločitev stane denar.
Kaj je SLA v kontekstu zapletenega projekta? Recimo, kako oceniti, da je spletna stran dostopna, ampak slike se nalagajo s zamudo. Kakšne so metrike SLA, kje jih meriti, kako jih meriti?
Kako vzpostaviti SLA? Kako jih vzdrževati?
Tema št. 11: SRE
Opredelitev SLA, SLO, Error Budget in drugi strašljivi izrazi iz sveta SRE
SRE: Praksa spremljanja SLI in SLO
SRE: Praksa uporabe Error Budget
SRE: Upravljanje prekinitev in operativne obremenitve (apigateway, service mesh, circuit breakers)
Poslovanje želi SRE. Vsaj na osnovni ravni: vzeti rezervni strežnik ali obnoviti iz varnostne kopije? Ena baza podatkov ali grozd? Namestiti zaščito pred DDoS preventivno ali samo v trenutku napada?
Direktorju ne bo dovolj, da mu povemo, da 'spletna stran deluje', ko mu stranka pokliče in sporoči, da obrazec za naročilo ne odpre.
Zato je za inženirja DevOps pomembno, da vsaj površinsko razume SRE, da lahko ustrezno komunicira s podjetjem o njegovih potrebah.
Zaključek
V času administratori in razvijalci se bodo naučili:
— pravilno delati z Git;
— organizirati lokalni razvoj;
— nastaviti (administratorji) in uporabljati (razvijalci) CI/CD;
— delati z infrastrukturo kot s kodo;
— testirati infrastrukturo;
— spremljati infrastrukturo in aplikacijo;
— nastaviti beleženje;
— razumeti, v idealnem primeru — uporabljati SRE.
Za pozorne bralce — s promocijsko kodo habrapost popust 15%.
Na vseh točkah pripravljamo prakso in orodja. Tako bomo vsakemu udeležencu po vrnitvi s Slyerma omogočili, da svojo podjetje dvigne na naslednjo raven DevOps.
Za podjetja to pomeni znižanje stroškov upravljanja in razvoja, zmanjšanje časa nedelovanja, povečanje zanesljivosti, hitrejšo dostavo funkcij in odpravljanje napak.
Izvor: habr.com
