Od 4. do 6. rujna u Sankt Peterburgu, u konferencijskoj dvorani Selectel održat će se trodnevni .

Program smo gradili s mišlju da teoretske radove o DevOps-u, kao i priručnike za alate, svatko može pročitati sam. Zanimljivi su jedino iskustvo i praksa: objašnjenje kako to raditi ispravno i pogrešno, i priča o tome kako mi radimo.
Svaka tvrtka, svaki administrator ili programer ima svoj nivo DevOps-a. Neki pogrešno koriste Git, drugi implementiraju SRE. Tečaj je organiziran tako da svatko pronađe nešto relevantno, što može implementirati odmah.
Počinjemo s Gitom, zatim gledamo na razvoj aplikacije, interakciju koda i infrastrukture, gradimo CI/CD, opisujemo infrastrukturu kao kod (IaC), testiramo dobiveno rješenje, postavljamo monitoring, prikupljamo i proučavamo logove, i na kraju dolazimo do SRE-a: pretvaramo pouzdanost u mjerljivu i upravljivu priču.
Git
Danas Git ne koristi samo onaj tko je jučer kupio svoj prvi laptop. To je trivijalan i sveprisutan alat, i ipak često nalazimo njegovu pogrešnu upotrebu: počevši od forsiranja push-a u master, pa do kopiranja datoteka iz Gita na server putem Ctrl-C, Ctrl-V.
Objašnjavamo što ne treba raditi, što treba raditi, i kako to rade u Southbridge-u.
Prolazimo kroz praksu: osnove Gita, timski rad.
Tema br. 1: Osnove rada s Gitom
- Osnovne git naredbe init, commit, add, diff, log, status, pull, push
- Git flow, grane i oznake, strategije merge-a
- Rad s više remote repozitorija
Tema br. 2: Timski rad s Gitom
- GitHub flow
- Fork, remote, pull request
- Konflikti, izdanja, još jednom o Gitflow-u i drugim flow-ovima u timovima
Materijal je organiziran tako da administratori i programeri mogu odmah implementirati sve prakse u radu.
Iz perspektive DevOps-a, pravilno upravljanje Git-om uređuje i automatizira procese razvoja i administracije, isključuje niz ponavljajućih problema, te povećava produktivnost.
DevOps programer
Gledamo na DevOps kroz oči programera: pokrećemo lokalno okruženje, pišemo aplikaciju, postavljamo njen monitoring i logiranje, lokalno je testiramo, organiziramo pohranu varijabli/tajni i otkrivanje usluga, pratimo tracing (opentracing).
Tema br. 3: Rad s aplikacijom iz perspektive razvoja
- Postavljanje lokalnog okruženja: praktične preporuke
- Pisanje mikroservisa u Pythonu (uključujući testove)
- Primjena docker-compose u razvoju
Tema br. 4: Interakcija koda i infrastrukture
- Praksa rada s konfiguracijama
Na kraju će programeri vidjeti kako kod treba slati logove, kako ga testirati i kako će se dalje otklanjati greške. Administratori će razumjeti potrebe programera: koje greške u kodu se javljaju, kako organizirati testiranje za programere i kako sami testirati projekt.
Na ovoj etapi se rješava osnovni zadatak DevOps-a: uspostavlja se međusobno razumijevanje i suradnja između devova i ops-a. Ovo je ključni korak prema prelasku s prebacivanja zadataka na odgovornu suradnju.
Kao rezultat, raste brzina i kvaliteta rada.
CI/CD
Moderna automatizacija podrazumijeva CI/CD. Počet ćemo s pregledom ručne automatizacije: makefile-ova, git hook-ova, skripti. Razjasnit ćemo kada su ti 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 konvejerih linija za izgradnju i njihova primjena u IT-u
- Primjer izgradnje "općeg" pipeline-a
- Moderni softver za CI/CD: Drone CI, BitBucket Pipelines, Travis itd.
Tema br. 6: CI/CD: Rad s Gitlabom
- Gitlab CI — opće informacije
- Gitlab Runner, njihovi tipovi i primjena
- Gitlab CI, značajke postavljanja, najbolje prakse
- Faze Gitlab CI-a
- Varijable Gitlab CI
- Izrada, testiranje, implementacija
- Kontrola i ograničenja izvođenja: only, when
- Rad s artefaktima
- Šabloni unutar .gitlab-ci.yml, ponovna upotreba akcija na različitim dijelovima pipeline-a
- Include — sekcije
- Centralizirano upravljanje gitlab-ci.yml (jedna datoteka i automatski push u ostale repozitorije)
Suradnja administratora i programera prelazi na novu razinu: administrator piše CI šablon, a programeri ga uređuju, gradeći svoj CI neovisno od administratora.
Smanjuje se ovisnost programera o administratorima, smanjuje se količina ručnog rada, nestaje problem "jedine osobe koja zna raditi s makefile-om". Implementacije se odvijaju pouzdano i brzo.
IaC
Tema Infrastructure as Code na primjeru Terraform predstavit će administrator oblaka Selectel Aleksej Stepanenko. On će pokazati kako brzo i automatizirano postaviti i skalirati poslužitelje, kako automatski pakirati slike, te kako koristiti predloške konfiguracije za brzo dobivanje postavljenih mašina.
Osoba koja je napravila tisuće IaC rješenja ispričat će kako to raditi ispravno i što ne raditi.
Rješenje za oblake Selectel s minimalnim izmjenama odgovara za Google i Amazon oblake.
Zaposlenik Southbridge Nikolaj Mesropjan na primjeru Ansiblea pokazat će kako bez zastoja postaviti funkcionalnu aplikaciju i provjeriti njezinu iskorištenost.
Ako ručno mijenjate infrastrukturu (postavljate poslužitelje, instalirate biblioteke i pakete po potrebi), prilikom pokušaja podizanja kopije okruženja morat ćete se sjetiti i reproducirati sve svoje radnje. Ova zadaća lako može potrajati 3-5 dana. Rad s infrastrukturom kao s kodom osigurava da imate ažurirani opis okruženja koji se može podići za nekoliko minuta.
Nikolaj će reći kako pisati playbooke, koje greške se javljaju, zašto ponekad playbooki rade sporo ili ne onako kako se očekivalo. Ovo je iskustvo višegodišnjeg korištenja IaC u Southbridge.
Tema br. 7: Infrastructure as Code
- IaC: pristup infrastrukturi kao kodu
- Oblačni provajderi kao dobavljači infrastrukture
- Alati za inicijalizaciju sistema, izrada slika (packer)
- IaC na primjeru Terraform
- Skladištenje konfiguracija, timski rad, automatizacija aplikacija
- Praksa stvaranja Ansible playbooka
- Idempotentnost, deklarativnost
- IaC na primjeru Ansible
- Database as a Code / Otpornost PostgreSQL
Infrastruktura dobiva deklarativnost i idempotentnost.
Administrator uči upravljati složenom infrastrukturom: brzo stvarati nova okruženja, održavati jedinstvo svih okruženja, vidjeti povijest promjena, što je ključno kada na projektu radi više timova.
Programer može proučavati infrastrukturu, samostalno postavljati okruženja.
Bonus ovog dijela — stvaranje i postavljanje otpornog klastera baza podataka PostgreSQL. Dat ćemo vam gotov playbook koji koristimo u Southbridge, postavit ćete klaster na učiteljskom standu i moći ćete koristiti ovo rješenje u svojoj kompaniji.
Testiranje infrastrukture i praćenje
Automatizacija omogućava brzo širenje greške na hiljadu servera. Sa svakom izmenom potrebno je testiranje. S druge strane, ručno testiranje oduzima toliko vremena da ukida prednosti automatizacije.
Pokažimo u praksi kako pisati testiranje uloga. Kao rezultat toga, moći ćete da pišete testove za svoju kompaniju. Više ne morate pamtiti izvršene postavke, opisujete ih u testovima i automatski proveravate da li su sve prethodne odluke i rešenja na mestu.
Nakon toga, naučićemo kako automatski dodavati sve nove servere u monitoring. Razmatraćemo posebno monitoring infrastrukture i aplikacija. Pokažimo loše i dobre prakse.
Tema №8: Testiranje infrastrukture
- Testiranje i kontinuirana integracija sa Molecule-om i Gitlab CI-jem
- Primena Vagranta
Tema №9: Monitoring infrastrukture sa Prometheus-om
- Zašto je potreban monitoring
- Tipovi monitoringa
- Obaveštenja u sistemu monitoringa
- Kako izgraditi zdrav sistem monitoringa
- Čitljiva obaveštenja, za sve
- Health Check: na šta obratiti pažnju
- Automatizacija zasnovana na podacima iz monitoringa
Neispravno funkcionisanje monitoringa — to je odsustvo monitoringa. Biznis nije zainteresovan za to što je početna stranica internet prodavnice dostupna, ako forma plaćanja daje grešku.
U postavkama monitoringa i rešavanju problema učestvuju i programeri i administratori ravnopravno. Tradicionalno, zadatke monitoringa preuzimaju administratori. Naš kurs će pokazati programerima koju ulogu igraju u stvaranju efikasnog monitoringa. Administratori će dobiti najbolje prakse Southbridge-a. Kao rezultat, broj gubitaka uzrokovanih prekidima i usporenjima sajta ili aplikacije brzo će opasti.
Bonus sekcija: automatizacija zasnovana na monitoringu. Na primer, monitoring javlja da je došlo do opterećenja na sajtu, i skaliranje web servera se automatski pokreće.
Logiranje
Greška u radu sa logovima — administratori i programeri ih gledaju direktno na serverima. Ako imate više od jednog servera, to traje dugo. To nije sigurno: programer ulazi na server gde ne bi trebao biti.
DevOps zahteva centralizovano prikupljanje, obradu i analizu logova.
Tema №10: Logovanje aplikacije sa ELK
- Glavne primjene i mogućnosti elastic-a (pretraživanje, pohrana, značajke skaliranja, fleksibilnost konfiguracije)
- Pregled kibane (glavne mogućnosti, jezik upita, upravljanje nadzornim pločama, izrada grafova)
- Pregled proizvoda temeljenih na elastic-u i njihova primjena
- Prikupljanje metrika u APM-u (tracenje aplikacija)
- Dodatno: Pregled novog proizvoda — SIEM
Implementacija ovog pristupa učinit će logove jednostavnim i razumljivim alatom za analizu, konfiguraciju i postavljanje aplikacija i infrastrukture.
SRE
I dolazimo do teme koju Southbridge tek prati i zbog koje drugi predavači žele ostati na posljednji dan Slërma. Drago nam je što je Ivan Kruglov iz Booking.com-a pristao govoriti o tome.
Projekt živi u stvarnom svijetu, gdje pouzdanost nikada nije apsolutna, a svaka odluka košta novac.
Što je SLA u kontekstu složenog projekta? Recimo, kako procijeniti da je web stranica dostupna, ali se slike učitavaju s kašnjenjem. Koje su metrik SLA, gdje ih uzimati, kako ih uzimati?
Kako postaviti SLA? Kako ih ispuniti?
Tema br. 11: SRE
Definicija SLA, SLO, Error Budget i drugi zastrašujući pojmovi iz svijeta SRE-a
SRE: Praksa praćenja SLI i SLO
SRE: Praksa korištenja Error Budget-a
SRE: Upravljanje prekidima i operativnim opterećenjem (apigateway, service mesh, circuit breakers)
Poslovanje želi SRE. Bar na osnovnoj razini: uzeti rezervni server ili podići iz rezervne kopije? Jedna baza podataka ili klaster? Postaviti DDoS zaštitu preventivno ili samo u trenutku napada?
Direktoru neće biti dovoljno reći da "web stranica funkcionira", kada ga klijent nazove i javi da se obrazac za narudžbu ne otvara.
Zbog toga je DevOps inženjeru važno barem površno razumjeti SRE, kako bi adekvatno razgovarao s poslovanjem o njegovim potrebama.
Zaključak
Tijekom administratori i programeri će naučiti:
— pravilno raditi s Git-om;
— organizirati lokalni razvoj;
— postavljati (administratori) i koristiti (programeri) CI/CD;
— raditi s infrastrukturom kao kodom;
— testirati infrastrukturu;
— nadzirati infrastrukturu i aplikaciju;
— postavljati logiranje;
— razumjeti, a u idealnom slučaju — koristiti SRE.
Za pažljive čitatelje — uz promotivni kod habrapost popust od 15%.
Za sve aspekte pripremamo praksu i alat. Tako će svaki sudionik po povratku sa Sljerma moći unaprijediti svoju tvrtku na sljedeću razinu DevOps-a.
Za poslovanje to znači smanjenje troškova administracije i razvoja, smanjenje vremena zastoja, povećanje pouzdanosti, bržu isporuku funkcionalnosti i otklanjanje grešaka.
Izvor: habr.com
