Sleurm DevOps: Gitist SRE-ni kõigi peatustega

4-6 septemberil Peterburis toimuvas Selectel'i konverentsisaalis toimub kolmek дневine Sleurm DevOps.

Oleme koostanud programmi arvestades, et DevOpsi teoreetilistest töödest ja tööriistade käsiraamatutest saab igaüks ise lugeda. Huvi pakuvad just kogemused ja praktika: selgitused, kuidas teha ja mitte teha, ning jutud, kuidas meie teeme.

Igas ettevõttes, iga admini või arendaja puhul on DevOpsi tase erinev. Ühed kasutavad Git'i valesti, teised rakendavad SRE-d. Kursus on korraldatud nii, et igaüks leiaks midagi asjakohast, mida saaks kohe rakendada.

Alustame Git'ist, seejärel vaatame rakenduse arendust, koodi ja infrastruktuuri koostööd, ehitame CI/CD, kirjeldame infrastruktuuri koodina (IaC), testime saadud lahendust, seadistame jälgimise, kogume ja analüüsime logisid, ning lõpuks jõuame SRE-ni: muudame usaldusväärsuse mõõdetavaks ja hallatavaks.

Git

Praegu ei kasuta Git'i ainult see, kes eile ostis enda esimese süle- või tahvelarvuti. See on triviaalne ja ülipopulaarne tööriist, ning ometigi kohtame me sageli selle vale kasutamist: alustades sundpush'ist masterisse ja lõpetades failide kopeerimise Git'ist serverisse Ctrl-C, Ctrl-V abil.

Räägime, kuidas ei tohi teha, kuidas tohib teha ja kuidas teevad Southbridge'is.
Käime läbi praktika: Git'i põhialused, meeskonnatöö.

Teema nr 1: Git'i töö põhialused

• Põhikommandod git init, commit, add, diff, log, status, pull, push
• Git flow, harud ja sildid, ühinemise strateegiad
• Töötamine mitme kaugrepo'ga

Teema nr 2: Meeskonnatöö Git'iga

• GitHub flow
• Fork, remote, pull request
• Konfliktid, väljaanded, uuesti Gitflow ja muud flow'd meeskondadele rakendamiseks

Materjal on korraldatud nii, et adminnid ja arendajad saaksid kohe kõik praktikaid töösse rakendada.

DevOpsi seisukohalt korralik Git'i kasutamine struktureerib ja automatiseerib arenduse ja haldamise protsesse, välistab mitmed korduvad probleemid, suurendab töö efektiivsust.

DevOps arendaja

Vaatame DevOps'i arendaja silmade läbi: käivitame kohaliku keskkonna, kirjutame rakenduse, seadistame selle jälgimise ja logimise, testime seda kohalikult, korraldame muutujate/saladuste ja teenuste avastamise hoidmise, vaatame jälgimist (opentracing).

Teema nr 3: Rakenduse töö arenduse vaatenurgast

• Kohaliku keskkonna seadistamine: praktilised soovitused
• Kirjutame mikroteenuse Pythonis (kaasaarvatud testid)
• Docker-compose kasutamine arenduses

Teema nr 4: Koodi ja infrastruktuuri koostoime

• Praktika konfiguratsioonide kasutamisel

Lõpuks näevad arendajad, kuidas kood peab logisid saatma, kuidas seda testida ja kuidas seda hiljem siluda. Administratorid mõistavad arendajate vajadusi: milliseid vigu koodis esineb, kuidas korraldada arendajatele testimist ja kuidas ise projekti testida.

Selles etapis lahendatakse DevOps'i peamine ülesanne: arendajate ja administraatorite vaheliste suhete loomine. See on võtme samm, et liikuda ülesannete edasiviimiselt vastutustundlikule koostööle.

Tulemusena suureneb töö kiirus ja kvaliteet.

CI/CD

Kaasaegne automatiseerimine hõlmab CI/CD-d. Alustame sellest, et vaatame käsitsi automatiseerimist: make-failid, git hookid, skriptid. Arutame, millal need tööriistad on ikka veel asjakohased ja millal neid ei tohiks kasutada.

Seejärel vaatame kaasaegse CI parimaid praktikaid Gitlabi näitel.

Teema nr 5: CI/CD - sissejuhatus automatiseerimisse

• Sissejuhatus automatiseerimisse
• Tööriistad (bash, make, gradle)
• Git-hookide kasutamine protsesside automatiseerimiseks
• Tööstuslikud tootmisliinid ja nende rakendamine IT-s
• Näide 'ühise' pipeline'i ülesehitamisest
• Kaasaegne CI/CD tarkvara: Drone CI, BitBucket Pipelines, Travis jne.

Teema nr 6: CI/CD: Töö Gitlabiga

• Gitlab CI - kokkuvõte
• Gitlab Runner, nende tüübid ja kasutamine
• Gitlab CI, seadistamise eripära, parimad praktikad
• Gitlab CI etapid
• Gitlab CI muutujad
• Kogumine, testimine, juurutamine
• Teostuse kontroll ja piirangud: only, when
• Töö artefaktidega
• Šabloonid .gitlab-ci.yml failis, tegevuste taaskasutamine erinevates pipeline'i osades
• Include - sektsioonid
• Kes centralized gitlab-ci.yml haldamine (üks fail ja automaatsed push’id teistesse hoidlatestse)

Administratorite ja arendajate koostöö tõuseb uuele tasemele: administraator kirjutab CI šablooni, arendajad muudavad seda, ehitades oma CI iseseisvalt administraatorist.

Arendajate sõltuvus administraatoritest väheneb, käsitööde arv väheneb, kaob probleem 'ainus inimene, kes teab, kuidas make-failiga töötada'. Väljaanded toimuvad usaldusväärselt ja kiiresti.

. See on arusaadav. Lõppude lõpuks, just nemad andsid võimaluse konfigureerida täielikult virtuaalne andmekeskus: füüsilisi servereid, riiuleid, võrgu komponente ei ole ning kogu infrastruktuuri saab kirjeldada skriptide ja konfiguratsioonifailide abil.

Teema Infrastructure as Code Terraformi näitel tutvustab Selecteli pilveadministraator Aleksei Stepanenko. Ta näitab, kuidas kiiresti ja automatiseeritult seadistada ja skaleerida servereid, kuidas automaatselt pakendada pilte ning kuidas kasutada konfiguratsioonimalle, et kohe saada seadistatud masinaid.

Inimene, kes on teinud tuhandeid IaC-lahendusi, räägib, kuidas teha õigesti ja kuidas mitte teha.

Selecteli lahendus sobib minimaalse muudatusega Google'i ja Amazoni pilvede jaoks.

Southbridge'i töötaja Nikolai Mesropjan näitab Ansible'i näitel, kuidas ilma seisakuteta juurutada töötavat rakendust ja kontrollida selle töökorrasolekut.

Kui muuta infrastruktuuri käsitsi (seada servereid, vajadusel installida teeke ja pakette), peate keskkonna koopia tõstmisel meenutama ja kordama kõiki oma toiminguid. See ülesanne võtab kergesti 3-5 päeva. Töö infrastruktuuriga kui koodiga tagab, et teil on ajakohane keskkonna kirjeldus, mille saate üles seada minutitega.

Nikolai räägib, kuidas kirjutada mängukavasid, millised vead esinevad ning miks mõnikord mängukavad töötavad aeglaselt või mitte nii, nagu oodati. See on aastatepikkuse kogemuse tulemus IaC rakendamisel Southbridge'is.

Teema №7: Infrastructure as Code

• IaC: lähenemine infrastruktuurile kui koodile
• Pilveteenuse pakkujad kui infrastruktuuri tarnijad
• Süsteemide algatustööriistad, piltide koostamine (packer)
• IaC Terraformi näitel
• Konfiguratsioonide salvestamine, koostöö, rakenduste automatiseerimine
• Ansible'i mängukavade loomise praktika
• Idempotentsus, deklaratiivsuse
• IaC Ansible'i näitel
• Database as a Code / PostgreSQL'i koormuskatkestustaluvus

Infrastruktuur omandab deklaratiivsuse ja idempotentsuse.
Administraator õpib haldama keerulist infrastruktuuri: kiiresti luua uusi keskkondi, säilitada kõigi keskkondade ühtsus ning näha muudatuste ajalugu, mis on kriitilise tähtsusega, kui projekti kallal töötab mitu meeskonda.
Arendaja saab uurida infrastruktuuri, iseseisvalt seadistada endale keskkondi.

Sesse osa boonus – PostgreSQL'i koormuskatkestustaluvate andmebaasi klasside loomine ja seadistamine. Anname teile valmis mängukava, mida kasutame Southbridge'is; te seate klastri üles õppekeskkonnas ja saate kasutada seda lahendust oma ettevõttes.

Infrastruktuuri testimine ja jälgimine

Automatiseerimine võimaldab viga koheselt rakendada tuhandele serverile. Iga muudatuse juures on vajalik testimine. Teisalt nõuab käsitsi testimine nii palju aega, et see nullib automatiseerimise eelised.

Näitame praktikas, kuidas kirjutada rollide testimist. Tulemusena suudate kirjutada teste oma ettevõtte jaoks. Ei pea enam meeles pidama tehtud seadeid, vaid kirjeldage neid testides ja kontrollige automaatselt, et kõik varasemad lahendused ja kiilud on kohas.

Seejärel õpime automaatselt lisama kõik uued serverid jälgimise alla. Vaatame eraldi infrastruktuuri ja rakenduse jälgimist. Näitame halbu ja häid praktikaid.

Teema nr 8: Infrastruktuuri testimine

• Testimine ja pidev integratsioon koos Molecule'i ja Gitlab CI-ga
• Vagrant'i kasutamine

Teema nr 9: Infrastruktuuri jälgimine Prometheus'ega

• Miks on jälgimine vajalik
• Jälgimise tüübid
• Teated jälgimissüsteemis
• Kuidas luua tervislik jälgimissüsteem
• Inimesele loetavad teated, kõigile
• Health Check: millele tasub tähelepanu pöörata
• Automatiseerimine andmete põhjal jälgimisest

Vale jälgimine on jälgimise puudumine. Äri ei huvita, et internetipoe avaleht on kergesti kättesaadav, kui maksevorm annab veateate.

Jälgimise seadistamisel ja probleemide lahendamisel osalevad arendajad ja administraatorid võrdselt. Traditsiooniliselt lasuvad jälgimise ülesanded administraatoritel. Meie kursus näitab arendajatele, millist rolli nad mängivad tõhusa jälgimise loomisel. Administraatorid saavad parimaid praktikaid Southbridge'is. Tulemuseks on, et veebisaidi või rakenduse tõrgete ja aeglustuste põhjustatud kahjude hulk väheneb kiiresti.

Jaotise boonus: automatiseerimine jälgimise alusel. Näiteks jälgimine teatab, et saidile on tekkinud koormus, ja veebiserverite skaleerimine käivitub automaatselt.

Logimine

Peamine viga logide haldamisel on see, et administraatorid ja arendajad vaatavad neid otse serverites. Kui teil on rohkem kui üks server, võib see võtta kaua aega. See ei ole turvaline: arendaja siseneb serverisse, kus ta ei peaks olema.

DevOps nõuab keskset logide kogumist, töötlemist ja analüüsi.

Teema nr 10: Rakenduse logimine ELK-ga

• Põhikasutused ja võimalused Elasticis (otsing, salvestamine, skalatsioonifunktsioonid, seadistuse paindlikkus)
• Kibana ülevaade (põhifunktsioonid, päringute keel, juhtimine armatuurlaudade, diagrammide loomine)
• Toodete ülevaade, mis põhinevad Elasticus ja nende rakendamine
• Kogume mõõdikud APM-is (rakenduste jälgimine)
• Täiendav: Uue toote ülevaade — SIEM

Selle lähenemise rakendamine muudab logid lihtsaks ja arusaadavaks tööriistaks rakenduse ja infrastruktuuri analüüsimiseks, seadistamiseks ja häälestamiseks.

SRE

Ja me jõuame teema juurde, millele Southbridge alles pilku heidab ja mille pärast teised esinejad soovivad jääda Slërm'i viimasel päeval. Meil on hea meel, et selle lugemist nõustus ette võtma Ivan Kruglov Booking.com-ist.

Projekt elab reaalajas maailmas, kus usaldusväärsus ei ole kunagi absoluutne ja iga otsus maksab raha.

Mis on SLA keerulise projekti kontekstis? Oletame, kuidas hinnata, et veebisait on saadaval, kuid pildid laaditakse viivitusega. Millised on SLA mõõdikud, kust neid võtta, kuidas neid koguda?

Kuidas kehtestada SLA? Kuidas neid täita?

Teema nr 11: SRE
SLA, SLO, Error Budget määratlemine ja muud hirmuäratavad terminid SRE maailmas
SRE: SLI ja SLO jälgimise praktika
SRE: Error Budgeti rakendamise praktika
SRE: Katkestuste ja operatiivkoormuse haldamine (apigateway, teenuse mesh, circuit brackers)
Äri soovib SRE-d. Õigemini vähemalt kõige lihtsamal tasemel: võtta varuserver või taaskäivitada varukoopiast? Üks andmebaas või klaster? Kas paigaldada DDoS kaitse ennetavalt või ainult rünnaku käigus?

Direktorile ei piisa jutuajamisest, et "veebisait töötab", kui klient helistab ja teatab, et tellimisvorm ei avane.

Seepärast on DevOps-insenerile oluline vähemalt pinnapealselt mõista SRE-d, et rääkida ettevõtte vajadustest adekvaatselt.

Kokkuvõte

Aja jooksul Slërm DevOps administraatorid ja arendajad õpivad:
— õigesti töötama Gitiga;
— korraldama kohalikku arendust;
— seadistama (administraatorid) ja kasutama (arendajad) CI/CD-d;
— töötama infrastruktuuriga nagu koodiga;
— testima infrastruktuuri;
— jälgima infrastruktuuri ja rakendust;
— seadistama logimist;
— mõistma ja ideaalis — kasutama SRE-d.

Hoolikatele lugejatele — promokoodi habrapost abil 15% soodustus.

Igasuguseid punkte silmas pidades valmistame praktikat ja tööriistu. Nii et iga osaleja saab pärast Slörmi tagasi tulles viia oma ettevõtte järgmisele DevOpsi tasemele.

Ärimaailmas tähendab see haldamise ja arendamise odavnemist, seisakute vähenemist, suuremat usaldusväärsust, kiiremat funktsioonide tarnimist ja bugide kõrvaldamist.

Allikas: habr.com