Od 4. do 6. septembra u Sankt Peterburgu, u konferencijskoj sali Selectel, trodnevni .
Program smo izgradili na osnovu ideje da teoretske radove na DevOps-u, poput priručnika za alate, svako može čitati sam. Zanimljivi su samo iskustvo i praksa: objašnjenje kako se to radi, a šta ne, i priča o tome kako to radimo.
Svaka kompanija, svaki administrator ili programer ima svoj nivo DevOps-a. Neki ljudi koriste Git pogrešno, drugi implementiraju SRE. Kurs je organizovan tako da svako pronađe nešto relevantno što se može implementirati ovdje i sada.
Počinjemo s Gitom, zatim gledamo razvoj aplikacija, interakciju između koda i infrastrukture, gradimo CI/CD, opisujemo infrastrukturu kao kod (IaC), testiramo rezultirajuće rješenje, postavljamo nadzor, prikupljamo i proučavamo dnevnike i na kraju dolazimo za SRE: pretvaranje pouzdanosti u mjerljivu i upravljivu priču.
ići
Danas, jedini ljudi koji ne koriste Git su oni koji su juče kupili svoj prvi laptop. Ovo je trivijalan i sveprisutan alat, a ipak često vidimo njegovu zloupotrebu: od prisilnog pritiska na master, do kopiranja datoteka iz Gita na server preko Ctrl-C, Ctrl-V.
Govorimo vam šta ne treba da radite, kako to treba da radite, kao što rade u Southbridgeu.
Radimo praksu: osnove Gite, timski rad.
Tema #1: Osnove Gita
- Osnovne komande git init, commit, add, diff, log, status, pull, push
- Git tok, grane i oznake, strategije spajanja
- Rad sa više udaljenih repo
Tema #2: Timski rad sa Gitom
- GitHub tok
- Vilica, daljinski, zahtjev za povlačenjem
- Sukobi, izdanja, još jednom o Gitflowu i drugim tokovima u odnosu na timove
Materijal je organizovan tako da administratori i programeri mogu odmah implementirati sve prakse u svom radu.
Sa DevOps tačke gledišta, pravilan rad sa Gitom pojednostavljuje i automatizuje procese razvoja i administracije, eliminiše brojne probleme koji se ponavljaju i povećava produktivnost.
DevOps programer
Gledamo na DevOps očima programera: pokrećemo lokalno okruženje, pišemo aplikaciju, postavljamo njeno praćenje i evidentiranje, testiramo ga lokalno, organiziramo skladištenje varijabli/tajni i otkrivanje usluga, gledamo opentracing.
Tema #3: Rad sa aplikacijom sa razvojne tačke gledišta
- Uspostavljanje lokalne sredine: praktične preporuke
- Pisanje mikroservisa na Pythonu (uključujući testove)
- Korištenje docker-compose u razvoju
Tema #4: Interakcija između koda i infrastrukture
- Vježbajte rad sa konfiguracijama
Kao rezultat toga, programeri će vidjeti kako kod treba da šalje zapise, kako ga testirati i kako će se u budućnosti otklanjati greške. Administratori će razumjeti potrebe programera: koje greške postoje u kodu, kako organizirati testiranje za programere, kako sami testirati projekat.
U ovoj fazi, glavni zadatak DevOps-a je riješen: izgrađeno je međusobno razumijevanje i zajednički rad između Dev-a i Ops-a. Ovo je ključni korak u prelasku sa dijeljenja zadataka na odgovornu suradnju.
Kao rezultat, povećava se brzina i kvaliteta rada.
CI / CD
Moderna automatizacija uključuje CI/CD. Počećemo tako što ćemo pogledati ručnu automatizaciju: makefile, githooks, skripte. Pogledajmo kada su ovi alati još uvijek relevantni, a kada ih ne treba koristiti.
Zatim pogledajmo najbolje prakse modernog CI koristeći Gitlab kao primjer.
Tema #5: CI/CD uvod u automatizaciju
- Uvod u automatizaciju
- Alati (bash, make, gradle)
- Korištenje git-hookova za automatizaciju procesa
- Fabričke montažne linije i njihova primena u IT
- Primjer izgradnje "općeg" cjevovoda
- Moderni softver za CI/CD: Drone CI, BitBucket Pipelines, Travis, itd.
Tema #6: CI/CD: Rad sa Gitlabom
- Gitlab CI - general
- Gitlab Runner, njihove vrste i primjene
- Gitlab CI, funkcije konfiguracije, najbolje prakse
- Gitlab CI faze
- Gitlab CI varijable
- Izgradite, testirajte, implementirajte
- Kontrola izvršenja i ograničenja: samo, kada
- Rad sa artefaktima
- Predlošci unutar .gitlab-ci.yml, ponovno korištenje akcija u različitim dijelovima cjevovoda
- Uključuje - sekcije
- Centralizovano upravljanje gitlab-ci.yml (jedan fajl i automatsko prebacivanje u druga spremišta)
Saradnja između administratora i programera dostiže novi nivo: administrator piše CI šablon, a programeri ga uređuju, izgrađujući svoj CI nezavisno od administratora.
Smanjuje se zavisnost programera od administratora, smanjuje se količina ručnog rada, a problem „jedine osobe koja zna da radi sa make fajlom“ nestaje. Uvođenje se odvija pouzdano i brzo.
IaC
O temi Infrastruktura kao kod, koristeći Terraform kao primjer, raspravljat će Selectel cloud administrator Alexey Stepanenko. On će vam pokazati kako brzo i automatski postaviti i skalirati servere, kako automatski pakirati slike i kako koristiti konfiguracijske predloške da biste odmah dobili konfigurirane strojeve.
Osoba koja je napravila hiljade IaC rješenja će vam reći kako to učiniti kako treba, a šta ne.
Selectel cloud rješenje je pogodno za Google i Amazon oblake uz minimalne izmjene.
Zaposlenik Southbridge-a Nikolay Mesropyan, koristeći Ansible kao primjer, pokazaće kako implementirati radnu aplikaciju bez zastoja i provjeriti njene performanse.
Ako ručno uredite infrastrukturu (podesite servere, instalirate biblioteke i pakete po potrebi), kada pokušate da podignete kopiju okruženja, moraćete da zapamtite i reprodukujete sve svoje radnje. Ovaj zadatak lako traje 3-5 dana. Rad sa infrastrukturom kao kodom osigurava da imate ažuran opis vašeg okruženja koji se može implementirati za nekoliko minuta.
Nikolaj će vam reći kako da pišete knjige sa igrom, koje greške se dešavaju i zašto ponekad sveske funkcionišu sporo ili ne kako se očekuje. Ovo je iskustvo iz dugogodišnjeg korištenja IaC-a u Southbridgeu.
Tema #7: Infrastruktura kao kod
- IaC: Približavanje infrastrukturi kao kodu
- Provajderi u oblaku kao provajderi infrastrukture
- Alati za inicijalizaciju sistema, izgradnja imidža (paker)
- IaC koristeći Terraform kao primjer
- Skladištenje konfiguracija, saradnja, automatizacija aplikacija
- Praksa kreiranja Ansible playbooks-a
- Idempotencija, deklarativnost
- IaC koristeći Ansible kao primjer
- Baza podataka kao kod / PostgreSQL tolerancija grešaka
Infrastruktura postaje deklarativna i idempotentna.
Administrator uči da upravlja složenom infrastrukturom: brzo kreira nova okruženja, održava jedinstvo svih okruženja, vidi istoriju promena, što je kritično kada nekoliko timova radi na projektu.
Programer može proučavati infrastrukturu i samostalno razvijati svoje okruženje.
Bonus odeljka: kreiranje i konfigurisanje klastera za prevazilaženje greške PostgreSQL baza podataka. Mi ćemo obezbijediti gotovu knjigu koju koristimo u Southbridgeu, vi ćete postaviti klaster na štand za obuku i možete koristiti ovo rješenje u svojoj kompaniji.
Ispitivanje i praćenje infrastrukture
Automatizacija vam omogućava da objavite grešku na hiljadu servera odjednom. Svaka promjena zahtijeva testiranje. S druge strane, ručno testiranje oduzima toliko vremena da negira prednosti automatizacije.
U praksi ćemo vam pokazati kako pisati testiranje uloga. Kao rezultat, moći ćete pisati testove za svoju kompaniju. Više ne morate pamtiti postavke koje ste napravili; opisujete ih u testovima i automatski provjeravate da li su sva prethodna rješenja i štake na mjestu.
Zatim ćemo naučiti kako da automatski dodamo sve nove servere na praćenje. Pogledajmo zasebno praćenje infrastrukture i aplikacija. Pokazaćemo loše i dobre prakse.
Tema #8: Infrastrukturno testiranje
- Testiranje i kontinuirana integracija sa Molecule i Gitlab CI
- Korištenje Vagranta
Tema #9: Monitoring infrastrukture sa Prometheusom
- Zašto je potrebno praćenje?
- Vrste monitoringa
- Obavještenja u sistemu praćenja
- Kako izgraditi zdrav sistem praćenja
- Ljudski čitljiva obavještenja, za svakoga
- Pregled zdravlja: na šta treba obratiti pažnju
- Automatizacija zasnovana na podacima praćenja
Nadgledanje koje ne radi kako treba nije praćenje. Poduzećima nije stalo do toga da je glavna stranica online trgovine dostupna ako obrazac za plaćanje daje grešku.
Programeri i administratori ravnopravno učestvuju u postavljanju nadzora i rješavanju problema. Štaviše, tradicionalno, zadaci nadzora padaju na administratore. Naš kurs će pokazati programerima ulogu koju imaju u stvaranju efikasnog praćenja. Administratori će dobiti najbolje prakse Southbridge-a. Kao rezultat toga, broj gubitaka uzrokovanih kvarovima i usporavanjem web stranice ili aplikacije brzo će opasti.
Bonus sekcije: automatizacija zasnovana na praćenju. Na primjer, praćenje javlja da je došlo do opterećenja na stranicu, a skaliranje web servera počinje automatski.
Logging
Glavna greška pri radu sa evidencijama je što ih administratori i programeri gledaju direktno na serverima. Ako imate više od jednog servera, ovo traje dosta vremena. Ovo nije sigurno: programer se prijavljuje na server gdje ne bi trebao biti.
DevOps zahtijeva centralizirano prikupljanje, obradu i analitiku dnevnika.
Tema #10: Evidentiranje aplikacije pomoću ELK-a
- Osnovne aplikacije i mogućnosti elastičnosti (pretraga, pohrana, skaliranje, fleksibilnost prilagođavanja)
- Pregled kibana (glavne karakteristike, jezik upita, upravljanje kontrolnom pločom, kreiranje grafikona)
- Pregled proizvoda na bazi elastičnosti i njihove primjene
- Prikupljanje metrike u APM-u (praćenje aplikacija)
- Dodatno: Pregled novog proizvoda - SIEM
Uvođenje ovog pristupa učinit će dnevnike jednostavnim i razumljivim alatom za analizu, konfiguriranje i otklanjanje grešaka u aplikaciji i infrastrukturi.
SRE
I dolazimo do teme koju Southbridge tek baci na oko i zbog koje drugi govornici žele ostati za posljednji dan Slurma. Drago nam je da je Ivan Kruglov iz Booking.com-a pristao da ga pročita.
Projekat živi u stvarnom svijetu, gdje pouzdanost nikada nije apsolutna i svaka odluka košta.
Šta je SLA u odnosu na složen projekat? Recimo kako procijeniti da je stranica dostupna, ali se slike učitavaju sa zakašnjenjem. Koje su SLA metrike, gdje ih uzeti, kako ih uzeti?
Kako postaviti SLA? Kako im se oduprijeti?
Tema #11: SRE
Definicija SLA, SLO, Error Budget i drugih strašnih pojmova iz svijeta SRE
SRE: Praksa praćenja SLI i SLO
SRE: Praksa korišćenja budžeta za greške
SRE: Upravljanje prekidima i operativnim opterećenjem (apigateway, servisna mreža, prekidači)
Preduzeća žele SRE. Barem na najjednostavnijem nivou: da li da uzmem rezervni server ili da ga podignem iz rezervne kopije? Jedinstvena baza podataka ili klaster? Trebate li instalirati DDoS zaštitu proaktivno ili samo u trenutku napada?
Direktor neće biti zadovoljan pričom da “sajt radi” kada ga klijent pozove i javi da se narudžbenica ne otvara.
Stoga je važno da DevOps inženjer barem površno razumije SRE kako bi na adekvatan način razgovarao s poslovanjem o njegovim potrebama.
Rezultat
Tokom administratori i programeri će naučiti:
— ispravno raditi sa Gitom;
— organizovati lokalni razvoj;
— konfigurirati (administratori) i koristiti (programeri) CI/CD;
— rad sa infrastrukturom kao sa kodom;
— testirati infrastrukturu;
— nadgledanje infrastrukture i aplikacija;
— konfigurirati evidenciju;
— razumjeti, i idealno, koristiti SRE.
Za pažljive čitaoce, koristite habrapost promotivni kod za popust od 15%.
Pripremamo praksu i alate za sve tačke. Tako da će svaki učesnik po povratku iz Slurma moći svoju kompaniju odvesti na viši nivo DevOps-a.
Za poslovanje, to znači jeftiniju administraciju i razvoj, smanjeno vrijeme zastoja, povećanu pouzdanost, bržu isporuku funkcija i eliminaciju grešaka.
izvor: www.habr.com
