Slörm DevOps: Gitist SREni kõik peatustega

4-6. septembril toimub Peterburi Selecteli konverentsisaalis kolme päeva pikkune Slerm DevOps.

Oleme koostanud programmi, lähtudes mõttest, et DevOpsi teoreetilised tööd, nagu ka tööriistade juhendid, on kõikidele kergesti kätkistatavad. Huvi pakuvad vaid kogemus ja praktika: selgitus, kuidas asju õigesti ja valesti teha, ja jutt sellest, kuidas meie tegutseme.

Igas ettevõttes, igal administraatoril või arendajal on oma DevOpsi tase. Ühed kasutavad Git'i valesti, teised rakendavad SRE-d. Kursus on korraldatud nii, et igaüks leiaks midagi asjakohast, mida saab kohe rakendada.

Alustame Git'iga, seejärel vaatame rakenduse arendust, koodi ja infrastruktuuri koostoimet, ehitame CI/CD, kirjeldame infrastruktuuri koodina (IaC), testime valminud lahendust, seadistame monitooringu, kogume ja uurime logisid ning jõuame lõpuks SRE-sse: muudame usaldusväärsuse mõõdetavaks ja hallatavaks loos.

Git

Praegu ei kasuta Git'i ainult see, kes ostis eilses esimeses sülearvutis. See on triviaalne ja laialdaselt levinud tööriist, kuid sageli kohtame selle vale kasutamise juhtumeid: alustades kohesest push’ist masterisse ja lõpetades failide kopeerimise Git'ist serverisse Ctrl-C, Ctrl-V abil.

Kutsume teid üles uurima, kuidas mitte teha, kuidas teha ja kuidas seda teevad Southbridge.
Teeme praktikat: Git'i alused, meeskonnatöö.

Teema nr 1: Git'i tööalused

• Põhikäsud git init, commit, add, diff, log, status, pull, push
• Git flow, harud ja sildid, merge'i strateegiad
• Töö mitmete remote repo'dega

Teema nr 2: Meeskonnatöö Git'iga

• GitHub flow
• Fork, remote, pull request
• Konfliktid, väljaanded, veelkord Gitflow ja teised voogud meeskondade kontekstis

Materjal on organiseeritud nii, et administraatorid ja arendajad saaksid kõik praktiseerimised äärmiselt kiiresti tööle rakendada.

DevOpsi vaatenurgast tagab õige töö Git'iga arenduse ja haldamise protsesside korrastamise ja automatiseerimise, välistades mitmeid korduvaid probleeme ning suurendades töö efektiivsust.

DevOps arendaja

Vaata DevOps'i arendaja silmade kaudu: käivitame kohaliku keskkonna, kirjutame rakenduse, seadistame selle jälgimise ja logimise, testime seda kohapeal, korraldame muutuja/dekreetide salvestamise ja teenuste leidmise, vaatame jälgimist (opentracing).

Teema nr 3: Rakenduse töötamise vaade arenduselt

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

Teema nr 4: Koodi ja infrastruktuuri vaheline kooste

• Tava konfiguratsioonide korraldamise praktika

Lõpptulemusena näevad arendajad, kuidas kood peaks logisid saatma, kuidas seda testida ja kuidas seda hiljem siluda. Administratorid mõistavad arendajate vajadusi: millised vead koodis esinevad, kuidas korraldada arendajatele testimist, kuidas ise projekti testida.

Selles etapis lahendatakse DevOps'i peamine ülesanne: luuakse mõistmine ja koostöö arendajate ja administreerijate vahel. See on oluline samm ülesannete edastamise asemel vastutustundliku koostöö suunas.

Tulemusena kasvab töö kiirus ja kvaliteet.

CI/CD

Kaasaegne automatiseerimine hõlmab CI/CD-d. Alustame käsitsi automatiseerimise ülevaatamisest: make-failid, git-hookid, skriptid. Räägime, millal need tööriistad on veel asjakohased ja millal neid ei tasu kasutada.

Seejärel vaatame parimaid praktikaid kaasaegse CI osas GitLabi näitel.

Teema nr 5: CI/CD automatiseerimise sissejuhatus

• Sissejuhatus automatiseerimisse
• Tööriistad (bash, make, gradle)
• Git-hookide kasutamine protsesside automatiseerimiseks
• Tööstuslikud konveeriloodud liinid ja nende rakendamine IT-s
• Näide "üldise" vooliku ülesehitusest
• Kaasaegne tarkvara CI/CD jaoks: Drone CI, BitBucket Pipelines, Travis jne.

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

• GitLab CI — üldine
• GitLab Runner, nende tüübid ja rakendamine
• GitLab CI, seadistuse eripärad, parimad praktikad
• GitLab CI etapid
• GitLab CI muutujad
• Kogumine, testimine, juurutamine
• Täitmise kontroll ja piirangud: only, when
• Töötamine artefaktidega
• Mallid .gitlab-ci.yml-s, toimingute ümberkasutamine erinevates vooliku osades
• Include — sektsioonid
• Keskne haldus gitlab-ci.yml (üks fail ja automaatsed pushid teistesse hoidlatestesse)

Administraatorite ja arendajate koostöö tõuseb uuele tasemele: administraator kirjutab CI-malli ja arendajad muudavad seda, ehitades oma CI sõltumatult administraatorist.

Arendajate sõltuvus administraatoritest väheneb, käsitööde hulk kahaneb ja kaob probleem „ainus inimene, kes teab, kuidas malli kasutada“. Väljaandmised toimuvad usaldusväärselt ja kiiresti.

IaC

Teemaga Infrastructure as Code räägib Terraformi näitel Selecteli pilveadministraator Aleksei Stepanenko. Ta näitab, kuidas kiiresti ja automatiseeritult servereid käivitada ja skaleerida, kuidas automaatselt pilte pakkida ning kuidas kasutada konfiguratsioonimalle, et kohe saada seadistatud masinaid.

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

Selecteli lahendus, mis vajab minimaalseid kohandusi, sobib Google'i ja Amazoni pilvedele.

Ettevõtte Southbridge töötaja Nikolai Mesropyan näitab Ansible'i näitel, kuidas töötavat rakendust ilma katkestusteta käivitada ja selle töökindlust kontrollida.

Kui hallata infrastruktuuri käsitsi (seade serverid, installida raamatukogud ja paketid vastavalt vajadusele), peate keskkonna koopia ülesseadmise katsetamisel meeles pidama ja taastama kõik oma teod. See ülesanne võtab kergesti 3-5 päeva. Infrastruktuuri käsitsemine koodina tagab, et teil on olemas ajakohane keskkonna kirjeldus, mida saab minutitega juurutada.

Nikolai räägib, kuidas kirjutada mängureegleid, millised vead võivad esineda, miks mõnikord mängureeglid töötavad aeglaselt või mitte nii, nagu oodatud. See on aastaid kestnud kogemus IaC kasutamisest Southbridge'is.

Teema nr 7: Infrastruktuur kui Kood

• IaC: lähenemine infrastruktuurile kui koodile
• Pilveteenuse pakkujad infrastruktuuri tarnijatena
• Süsteemide initsialiseerimise tööriistad, pildikogumine (packer)
• IaC Terraformi näitel
• Konfiguratsioonide haldamine, koostöö, rakenduste automatiseerimine
• Ansible'i mänguliste loomise praktika
• Idempotentsus, deklaratiivsuse põhimõtted
• IaC Ansible'i näitel
• Andmebaas kui Kood / PostgreSQL tõrketaluvus

Infrastruktuur omandab deklaratiivsuse ja idempotentsuse.
Administrator õpib keerulise infrastruktuuri haldamise: kiiresti luua uusi keskkondi, säilitada kõigi keskkondade ühtsus, näha muudatuste ajalugu, mis on kriitilise tähtsusega, kui projekti kallal töötab mitu meeskonda.
Arendaja saab õppida infrastruktuuri, ise luua keskkondi.

Boonuse osa — PostgreSQL andmebaasi tõrke taastamise klastrite loomine ja seadistamine. Anname valmis juhendi, mida kasutame Southbridge'is, ja te seadistate klastrit õppekeskkonnas, et saaksite seda lahendust enda ettevõttes rakendada.

Infrastruktuuri testimine ja jälgimine

Automatiseerimine võimaldab koheselt vead levitada tuhandetele serveritele. Iga muudatuse korral on vajalik testimine. Teiselt poolt võtab käsitsi testimine nii palju aega, et see tühistab automatiseerimise eelised.

Kutsume teid praktiliselt üles kirjutama rollide testimist. Tulemuseks on, et saate kirjutada teste oma ettevõtte jaoks. Pole enam vaja meeles pidada tehtud seadistusi, vaid kirjeldada neid testides ja automaatselt kontrollida, et kõik varasemad lahendused ja kiirteed on endiselt kohas.

Seejärel õpime automaatselt lisama kõik uued serverid monitooringusse. Keskendume eraldi infrastruktuuri ja rakenduste jälgimisele. Tutvustame halbu ja häid praktikaid.

Teema nr 8: Infrastruktuuri testimine

• Testimine ja pidev integratsioon Molecule'i ja Gitlab CI abil
• Vagranti rakendamine

Teema nr 9: Infrastruktuuri jälgimine Prometheusega

• Miks on vajalik monitooring
• Monitooringu tüübid
• Monitooringusüsteemi teadet
• Kuidas üles ehitada terve jälgimissüsteem
• Inimesele loetavad teated, kõigile
• Health Check: millele tähelepanu pöörata
• Automatiseerimine monitooringu andmete põhjal

Vale monitooring tähendab, et monitooringut pole. Äril ei ole tähtis, et veebipoe avaleht on saadaval, kui maksevorm annab tõrke.

Monitooringu seadistamisel ja probleemide lahendamisel osalevad arendajad ja administraatorid võrdselt. Traditsiooniliselt langevad monitooringu ülesanded administraatorite õlule. Meie kursus näitab arendajatele, millist rolli nad mängivad tõhusa monitooringu loomisel. Administraatorid saavad parimaid praktikaid Southbridge'ist. Tulemuseks on, et veebisaidi või rakenduse rikete ja puhajate põhjustatud kahjumite arv väheneb kiiresti.

Jaotise boonus: automatiseerimine monitooringu põhjal. Näiteks annab monitooring teada, et veebisaidile on tekkinud koormus, ja veebiserverite skaleerimine algatakse automaatselt.

Logimine

Põhiline viga logidega töötamisel on see, et administraatorid ja arendajad vaatavad neid otse serverites. Kui teil on rohkem kui üks server, võtab see kaua aega. See on ebaturvaline: arendaja siseneb serverisse, kus ta ei peaks olema.

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

Teema nr 10: Rakenduste logimine ELK-iga

• Peamised rakendused ja funktsioonid elastics (otsing, säilitamine, skaleerimise omadused, seadistamise paindlikkus)
• Kibana ülevaade (peamised funktsioonid, päringukeel, armatuurlaudade haldamine, graafikute loomine)
• Elastici põhjal toodete ülevaade ja nende rakendamine
• Kogume mõõdikuid APM-is (rakenduste jälgimine)
• Lisaks: Uue toote ülevaade — SIEM

Selle lähenemisviisi 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 vaatab ning mille tõttu soovivad teised esinejad jääda viimasele päevadele Slërmile. Meil on hea meel, et seda teemat on nõustunud lugema Ivan Kruglov Booking.com-ist.

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

Mis on SLA keerulise projekti kontekstis? Ütleme, kuidas hinnata, et veebisait on juurdepääsetav, kuid pildid laaditakse viivitusega. Millised on SLA näitajad, kust neid võtta, kuidas neid mõõta?

Kuidas seadistada SLA? Kuidas neid pidada?

Teema nr 11: SRE
SLA, SLO, Error Budget ja muud hirmutavad terminid SRE maailmas
SRE: SLI ja SLO jälgimise praktika
SRE: Error Budgeti rakendamise praktika
SRE: Katkestuste ja operatiivkoormuse haldamine (apigateway, teenuse mesh, ringikaitsjad)
Ärimees tahab SRE-d. Isegi kõige lihtsamas vormis: kas võtta varu server või taastada varukoopiast? Üks andmebaas või klaster? Kas rakendada DDoS kaitset ennetavalt või ainult rünnaku ajal?

Direktor ei ole rahul sellega, et «veebisait töötab», kui tema helistab klient ja teatab, et tellimisvorm ei avane.

Seetõttu on DevOps inseneri jaoks oluline vähemalt pinnapealselt mõista SRE-d, et adekvaatselt rääkida äri vajadustest.

Kokkuvõte

Aja jooksul DevOps'i slõrmaar administraatorid ja arendajad õpivad:
— õigesti töötama Gitiga;
— korraldama lokaalset arendust;
— seadistama (administraatorid) ja kasutama (arendajad) CI/CD-d;
— töötama infrastruktuuriga kui koodi.
— testida infrastruktuuri;
— jälgida infrastruktuuri ja rakendust;
— seadistada logimine;
— mõista ja ideaalis — kasutada SRE-d.

Hoolikatele lugejatele — sooduskoodiga habrapost 15% allahindlus.

Kõigis punktides valmistame ette praktikat ja tööriistu. Nii et iga osaleja, kes Slørmist naaseb, saab viia oma ettevõtte DevOpsi järgmisel tasemele.

Äri jaoks tähendab see haldamise ja arendamise kulude vähenemist, katkestuste vähenemist, usaldusväärsuse kasvu, kiiremat funktsioonide tarnimist ja vigade kõrvaldamist.

Allikas: habr.com