Slërm DevOps: nga Git deri në SRE me të gjitha ndalesat

4-6 Shtator në Shën Peterburg, në sallën e konferencave Selectel do të zhvillohet një ngjarje tre ditore Sleurm DevOps.

Ne e ndërtuam programin duke u nisur nga mendimi se studimet teorike mbi DevOps, si dhe manualet për mjetet, secili mund t’i lexojë vetë. Të rëndësishme janë vetëm përvoja dhe praktika: shpjegimi se si duhet dhe si nuk duhet ta bëjmë, dhe tregimi se si veprojmë ne.

Në çdo kompani, çdo administrator ose zhvillues ka nivelin e tij të DevOps. Disa e përdorin gabimisht Git, të tjerë implementojnë SRE. Kursi është organizuar në mënyrë që çdo person të gjejë diçka relevante që mund të zbatohet këtu dhe tani.

Ne fillojmë me Git, ndjekim më pas zhvillimin e aplikacioneve, ndërveprimin e kodit dhe infrastrukturës, ndërtojmë CI/CD, përshkruajmë infrastrukturën si kod (IaC), testojmë zgjidhjen e arritur, konfigurojmë monitorimin, grumbullojmë dhe studiojmë logot, dhe në fund arrijmë te SRE: e kthejmë besueshmërinë në një histori të matshme dhe të menaxhueshme.

Git

Sot, vetëm ata që blenë laptopin e parë dje nuk e përdorin Git. Ky është një mjet banale dhe i përhapur, dhe megjithatë ne shpesh hasim përdorimin e tij të gabuar: duke filluar nga forcimi i push-it në master dhe përfunduar me kopjimin e skedarëve nga Git në server përmes Ctrl-C, Ctrl-V.

Ne tregojmë se si nuk duhet të bëhet, si duhet të bëhet, si bëhet në Southbridge.
Shkojmë në praktikë: bazat e Git, punën ekipore.

Tema nr. 1: Bazat e punës me Git

• Komandat bazë git init, commit, add, diff, log, status, pull, push
• Git flow, degët dhe etiketat, strategjitë e bashkimit
• Puna me disa repo remote

Tema nr. 2: Puna ekipore me Git

• GitHub flow
• Fork, remote, pull request
• Konfliktet, lëshimet, një herë tjetër për Gitflow dhe flukset e tjera në lidhje me ekipet

Materiali është organizuar në mënyrë që administratorët dhe zhvilluesit të mund të zbatojnë menjëherë të gjitha praktikat në punë.

Nga këndvështrimi i DevOps, përdorimi i duhur i Git organizon dhe automatizon proceset e zhvillimit dhe administratës, e eliminon një sërë problemeve të përsëritura, dhe rrit produktivitetin e punës.

DevOps për zhvillues

Shikojmë DevOps me sytë e zhvilluesit: aktivizojmë ambientin lokal, shkruajmë aplikacionin, konfigurojmë monitorimin dhe logimin e tij, e testojmë atë lokal, organizojmë ruajtjen e variablave/sekreteve dhe zbulimin e shërbimeve, shikojmë gjurmimin (opentracing).

Tema nr. 3: Puna me aplikacionin nga këndvështrimi i zhvillimit

• Konfigurimi i ambientit lokal: rekomandime praktike
• Shkrimi i një mikrosistemi me Python (duke përfshirë testet)
• Përdorimi i docker-compose në zhvillim

Tema №4: Ndërveprimi i kodit dhe infrastrukturës

• Praktika e punës me konfigurime

Si rezultat, zhvilluesit do të shohin se si kodi duhet të dërgojë logje, si të testohet, si do të depurohet më vonë. Administratorët do të kuptojnë nevojat e zhvilluesve: çfarë gabimesh ka në kod, si t'i organizojnë testimet për zhvilluesit, si të testojnë vetë projektin.

Në këtë fazë, zgjidhet detyra kryesore e DevOps: krijimi i një mirëkuptimi dhe bashkëpunimi midis zhvilluesve dhe administratorëve. Kjo është një hap kyç për të kaluar nga kalimi i detyrave në një bashkëpunim të përgjegjshëm.

Si rezultat, rritet shpejtësia dhe cilësia e punës.

CI/CD

Automatizimi modern parashikon CI/CD. Ne do të fillojmë duke parë automatizimin manual: makefile, git hooks, skripte. Do të shqyrtojmë kur këto mjete janë akoma të rëndësishme dhe kur nuk duhet të përdoren.

Më pas do të shikojmë praktikat më të mira të CI moderne duke marrë si shembull Gitlab.

Tema №5: CI/CD hyrje në automatizim

• Hyrje në automatizim
• Mjetet (bash, make, gradle)
• Përdorimi i git-hooks për automatizimin e proceseve
• Linjat e prodhimit të fabrikës dhe aplikimi i tyre në IT
• Shembulli i ndërtimit të një pipeline 'të përbashkët'
• Software moderne për CI/CD: Drone CI, BitBucket Pipelines, Travis etj.

Tema №6: CI/CD: Punë me Gitlab

• Gitlab CI — përmbledhje
• Gitlab Runner, llojet e tyre dhe aplikimi
• Gitlab CI, veçoritë e konfigurimit, praktikat më të mira
• Hapat e Gitlab CI
• Variablat e Gitlab CI
• Ndërtimi, testimi, deploy
• Kontrolli dhe kufizimet e ekzekutimit: vetëm, kur
• Puna me artefaktet
• Modelet brenda .gitlab-ci.yml, ripërdorimi i veprimeve në pjesë të ndryshme të pipeline
• Inkluziv — seksione
• Menaxhimi qendror i gitlab-ci.yml (një skedar dhe push automate në repo të tjera)

Bashkëpunimi midis administratorëve dhe zhvilluesve arrin në një nivel të ri: Administratori shkruan modelin CI, ndërsa zhvilluesit e rregullojnë atë, duke krijuar CI të tyre pa varësi nga administratori.

Varësia e zhvilluesve nga administratorët zvogëlohet, ulet sasia e punës manuale dhe zhduket problemi i 'personit të vetëm që di si të punojë me makefile-in'. Dërgesat bëhen të sigurta dhe të shpejta.

IaC

Tema 'Infrastructure as Code' përmes Terraform do të shpjegohet nga administratori i cloud-it në Selectel, Aleksei Stepanenko. Ai do të tregojë se si të vendosni dhe të shkallëzoni serverët shpejt dhe automatikisht, si të paketoni automatikisht imazhet dhe si të përdorni shabllonat e konfigurimit për të marrë menjëherë makina të konfiguruara.

Një njeri, i cili ka bërë mijëra zgjidhje IaC, do të tregojë se si të bëni siç duhet dhe çfarë nuk duhet të bëni.

Zgjidhja për cloud-in Selectel me ndryshime minime përshtatet për cloud-et Google dhe Amazon.

Punonjësi i Southbridge, Nikolai Mesropyan, nëpërmjet Ansible do të tregojë se si të vendosni një aplikacion të punës që funksionon pa rënie të shërbimit dhe të verifikoni funksionimin e tij.

Nëse ndryshoni infrastrukturën me duar (konfiguroni serverët, instaloni biblioteka, paketa sipas nevojës), gjatë përpjekjes për të ngritur një kopje të ambientit, duhet të kujtoni dhe të riprodhoni të gjitha veprimet tuaja. Ky detyrë lehtë zë 3-5 ditë. Puna me infrastrukturën si kod garanton që keni një përshkrim të përditësuar të ambientit, i cili mund të vendoset brenda disa minutash.

Nikolai do të tregojë se si të shkruani playbooks, cilat gabime ndodhin, pse ndonjëherë playbooks punojnë ngadalë ose ndryshe nga sa pritej. Kjo është përvoja e shumë viteve të përdorimit të IaC në Southbridge.

Tema №7: Infrastructure as Code

• IaC: qasje ndaj infrastrukturës si kod
• Ofruesit e cloud si furnizues të infrastrukturës
• Mjetet e inicializimit të sistemeve, ndërtimi i imazheve (packer)
• IaC përmes Terraform
• Ruajtja e konfiguracioneve, bashkëpunimi, automatizimi i aplikacioneve
• Praktikë për krijimin e playbook-ëve Ansible
• Idempotentësi, deklarativitet
• IaC përmes Ansible
• Database as a Code / Qëndrueshmëria e PostgreSQL

Infrastruktura merr deklarativitet dhe idempotencë.
Administratorët mësojnë të menaxhojnë infrastrukturë të komplikuar: të krijojnë shpejt ambiente të reja, të mbajnë unitetin e të gjitha ambienteve, të shikojnë historinë e ndryshimeve, çka është kritik kur projekti punohet nga disa ekipe.
Programuesit mund të studiojnë infrastrukturën dhe të vendosin ambientet e tyre.

Bonus i seksionit - krijimi dhe konfigurimi i një klasteri të qëndrueshëm të bazës së të dhënave PostgreSQL. Ne do t'u japim një playbook të gatshme, të cilin e përdorim në Southbridge, ju do të vendosni klasterin në një skenë mësimore dhe do të mund ta përdorni këtë zgjidhje në kompaninë tuaj.

Testimi i Infrastrukturës dhe Monitorimi

Automatizimi lejon që një gabim të shpërndahet menjëherë në një mijë serverë. Me çdo ndryshim, testimi është i nevojshëm. Ndonjëherë, testimi manual merr kaq shumë kohë sa e anulohet përparësinë e automatizimit.

Do të tregojmë në praktikë se si të shkruani testimin e roleve. Si rezultat, do të jeni në gjendje të shkruani teste për kompaninë tuaj. Nuk do të ketë nevojë më të mbani mend parametrat që keni vendosur, do t'i përshkruani ato në teste dhe do të kontrolloni automatikisht që të gjitha zgjidhjet dhe ndihmat e kaluara janë ende në vend.

Pastaj do të mësojmë si të shtojmë automatikisht të gjitha serverët e rinj në monitorim. Do të shqyrtojmë veçmas monitorimin e infrastrukturës dhe aplikacioneve. Do të tregojmë praktika të këqija dhe të mira.

Tema №8: Testimi i infrastrukturës

• Testimi dhe integrimi i vazhdueshëm me Molecule dhe Gitlab CI
• Përdorimi i Vagrant

Tema №9: Monitorimi i infrastrukturës me Prometheus

• Pse nevojitet monitorimi
• Llojet e monitorimit
• Njoftimet në sistemin e monitorimit
• Si të ndërtoni një sistem monitorimi të shëndetshëm
• Njoftime të lexueshme nga njeriu, për të gjithë
• Kontrolli i Shëndetit: çfarë duhet të keni parasysh
• Automatizimi në bazë të të dhënave nga monitorimi

Monitorimi që funksionon keq është justifikim për të qenë pa monitorim. Biznesit nuk i intereson që faqja kryesore e dyqanit online është e qasshme, nëse forma e pagesës jep gabim.

Në konfigurimin e monitorimit dhe zgjidhjen e problemeve, zhvilluesit dhe administratorët angazhohen njësoj. Në fakt, tradicionalisht detyrat e monitorimit bien mbi administratorët. Kursi ynë do t'u tregojë zhvilluesve se çfarë roli ata luajnë në krijimin e një monitorimi efektiv. Administratorët do të marrin praktikat më të mira nga Southbridge. Si rezultat, numri i humbjeve shkaktuar nga defektet dhe vonesat e faqes ose aplikacionit do të bjerë shpejt.

Bonusi i seksionit: automatizimi në bazë të monitorimit. Për shembull, monitorimi njofton që ka ardhur ngarkesë në sit dhe skelimi i serverëve web fillohet automatikisht.

Regjistrimi

Gabimi kryesor në punën me regjistrat është se administratorët dhe zhvilluesit i shikojnë ato drejtpërdrejt në servera. Nëse keni më shumë se një server, kjo merr kohë. Kjo nuk është e sigurt: zhvilluesi hyn në server, ku nuk duhet të jetë.

DevOps kërkon mbledhjen, përpunimin dhe analitikën e centralizuar të regjistrave.

Tema №10: Regjistrimi i aplikacioneve me ELK

• Përdorimet dhe mundësitë kryesore të elastic (kërkimi, ruajtja, veçoritë e shpërndarjes, fleksibiliteti në konfigurim)
• Përmbledhje e kibana (mundësitë kryesore, gjuha e kërkimeve, menaxhimi i paneleve, krijimi i grafikëve)
• Përmbledhje e produkteve të bazuara në elastic dhe përdorimi i tyre
• Mblidhen metrikat në APM (ndjekja e aplikacioneve)
• Shtesë: Përmbledhje e produktit të ri — SIEM

Implementimi i këtij qasje do ta bëjë logun një mjet të thjeshtë dhe të kuptueshëm për analizimin, konfigurimin dhe optimizimin e aplikacionit dhe infrastrukturës.

SRE

Dhe ne arrijmë te tema, për të cilën Southbridge është duke u përgatitur dhe për të cilën folësit e tjerë dëshirojnë të qëndrojnë deri në ditën e fundit të Slerma. Ne jemi të lumtur që Ivan Kruglov nga Booking.com pranoi të flasë për të.

Projekti jeton në botën reale, ku besueshmëria kurrë nuk është absolute dhe çdo vendim ka një kostos.

Çfarë është SLA në kontekstin e një projekti të ndërlikuar? Le të themi, si mund të vlerësojmë se faqja është e aksesueshme, por imazhet ngarkohen me vonesë. Cilat janë metrikat e SLA, ku duhet të merren ato, si duhen marrë?

Si të vendosim SLA? Si t'i përmbushim ato?

Tema Nr. 11: SRE
Përcaktimi i SLA, SLO, Error Budget dhe terma të tjerë të frikshëm nga bota e SRE
SRE: Praktika e monitorimit të SLI dhe SLO
SRE: Praktika e aplikimit të Error Budget
SRE: Menaxhimi i ndërprerjeve dhe ngarkesës operative (apigateway, service mesh, circuit brakers)
Biznesi dëshiron SRE. Edhe në nivelin më të thjeshtë: të marrë një server rezervë ose të rikthejë nga backup? Një bazë të dhënash apo kluster? Të vendosë mbrojtje nga DDoS në mënyrë parandalueshëm apo vetëm në momentin e sulmit?

Drejtorët nuk do të përqafonin një histori të thënë se "faqja funksionon", kur një klient i telefonon dhe thotë se forma e porosisë nuk hapet.

Prandaj, është e rëndësishme që inxhinieri DevOps të ketë të paktën një kuptim të përgjithshëm të SRE, për të folur saktësisht me biznesin për nevojat e tij.

Përfundimi

Gjatë kohës Slerma DevOps administratorët dhe zhvilluesit do të mësojnë:
— të punojnë siç duhet me Git;
— të organizojnë zhvillimin lokal;
— të konfigurojnë (administratorët) dhe të përdorin (zhvilluesit) CI/CD;
— të punojnë me infrastrukturën si kod;
— të testojnë infrastrukturën;
— të monitorojnë infrastrukturën dhe aplikacionin;
— të konfigurojnë logimin;
— të kuptojnë, dhe në ideali — të përdorin SRE.

Për lexuesit e kujdesshëm — me kodin promocional habrapost ka një zbritje prej 15%.

Për të gjitha pikat ne po përgatisim praktikë dhe mjete. Kështu që çdo pjesëmarrës pas kthehjes nga Slerma do të jetë në gjendje të çojë kompaninë e tij në nivelin e ardhshëm të DevOps.

Për biznesin, kjo do të thotë ulje të kostos së administratës dhe zhvillimit, reduktimin e kohës së papunësisë, rritjen e besueshmërisë, dorëzimin më të shpejtë të funksioneve dhe zgjidhjen e defekteve.

Burimi: habr.com