Më 4-6 Shtator në Shën Petersburg, në sallën e konferencave të Selectel do të zhvillohet një seminar tre-ditor .
Ne e ndërtuam programin duke u nisur nga mendimi se punimet teorike mbi DevOps, ashtu si dhe manualet për mjetet, çdo kush mund t'i lexojë vetë. Interesante janë përvoja dhe praktika: shpjegimi se si duhet bërë dhe si nuk duhet bërë, dhe tregimi se si e bëjmë ne.
Në çdo kompani, çdo administrator ose zhvillues ka nivelin e vet të DevOps. Disa e përdorin gabimisht Git-in, të tjerë integrojnë SRE. Kursi është organizuar në mënyrë që çdo njeri të gjejë diçka relevante, që mund ta implemetojë këtu dhe tani.
Ne fillojmë me Git-in, pastaj shohim zhvillimin e aplikacioneve, ndërveprimin e kodit dhe infrastrukturës, ndërtojmë CI/CD, përshkruajmë infrastrukturën si kod (IaC), testojmë zgjidhjen e marrë, konfigurimin e monitorimit, mbledhim dhe studiojmë logjet, dhe në fund arrijmë te SRE: duke e kthyer besueshmërinë në një histori të matshme dhe të menaxhueshme.
Git
Tani Giti përdoret vetëm nga ai që bleu laptopin e parë dje. Ky është një mjet tërësisht i zakonshëm dhe i njohur, megjithatë shpesh e hasim përdorimin e gabuar të tij: duke filluar nga forcimi i dërgesës në master dhe duke përfunduar me kopjimin e skedarëve nga Giti në server përmes Ctrl-C, Ctrl-V.
Do të tregojmë se si nuk duhet të bëhet, se si duhet të bëhet, si bëjnë në Southbridge.
Përparojmë praktikat: bazat e Gitit, punën në grup.
Tema №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 №2: Puna në grup me Git
- GitHub flow
- Fork, remote, pull request
- Konfliktet, lëshimet, përsëri për Gitflow dhe flow të tjera në lidhje me ekipet
Materiali është organizuar në mënyrë që administratorët dhe zhvilluesit të mund ta zbatojnë menjëherë të gjitha praktikat në punë.
Nga këndvështrimi i DevOps, puna e saktë me Git rregullon dhe automatizon proceset e zhvillimit dhe administratës, përjashton një sërë problemesh të përsëritura, rrit produktivitetin.
Zhvilluesi DevOps
Shikojmë DevOps nga syte e programuesit: aktivizojmë ambientin lokal, shkruajmë aplikacionin, konfiguroni monitorimin dhe regjistrimin e tij, testojmë lokal, organizojmë ruajtjen e variablave/sekreteve dhe zbuluarjen e shërbimeve, shikojmë ndjekjen (opentracing).
Tema №3: Të punosh me aplikacionin nga pikëpamja e zhvillimit
- Konfigurimi i ambientit lokal: rekomandime praktike
- Shkruajmë një mikrosherbim në Python (duke përfshirë testet)
- Përdorimi i docker-compose në zhvillim
Tema №4: Bashkëveprimi i kodit dhe infrastrukturës
- Praktika e punës me konfigurimet
Pas përfundimit, zhvilluesit do të shohin si duhet të dërgojë kodin loge, si ta testojnë atë, si do të debugohen më vonë. Administratorët do të kuptojnë nevojat e zhvilluesve: cilat gabime në kod ndodhin, si të organizojnë testimin për zhvilluesit, si të testojnë vetë projektin.
Në këtë fazë zgjidhet detyra kryesore e DevOps: krijohet një mirëkuptim i ndërsjellë dhe bashkëpunim mes zhvilluesve dhe administratorëve. Ky është një hap thelbësor drejt kalimit nga kalimi i detyrave në një bashkëpunim përgjegjës.
Si rezultat, rritet shpejtësia dhe cilësia e punës.
CI/CD
Automatizimi modern përfshin CI/CD. Ne do të fillojmë duke shqyrtuar automatizimin manual: makefiles, git hooks, skripte. Do të diskutojmë se kur këto mjete janë ende të dobishme dhe kur nuk duhet t'i përdorim.
Më pas, do të shohim praktikat më të mira të CI moderne përmes shembujve të 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 montimit të fabrikave dhe përdorimi i tyre në IT
- Shembulli i ndërtimit të një ‘pipeline’ të zakonshëm
- Softueri modern për CI/CD: Drone CI, BitBucket Pipelines, Travis etj.
Tema №6: CI/CD: Punë me Gitlab
- Gitlab CI — një përmbledhje
- Gitlab Runner, llojet dhe përdorimi i tyre
- Gitlab CI, veçoritë e konfigurimit, praktikat më të mira
- Hapat e Gitlab CI
- Variablat e Gitlab CI
- Ndërtimi, testimi, shpërndarja
- Kontrolli dhe kufizimet e ekzekutimit: only, when
- Punë me artefaktet
- Shabllonet brenda .gitlab-ci.yml, rimbushja e aktiviteteve në pjesë të ndryshme të pipeline-it
- Include — seksionet
- Menaxhimi qendror i gitlab-ci.yml (një skedar dhe push automatik në repos të tjera)
Bashkëpunimi midis administratorëve dhe zhvilluesve arrin një nivel të ri: administratorët shkruajnë një shabllon CI, ndërsa zhvilluesit e modifikojnë atë, duke ndërtuar CI-në e tyre pavarësisht administratorit.
Pavarësia e zhvilluesve nga administratorët bie, zvogëlohet sasija e punës manuale, dhe zhduket problemi i «njeriut të vetëm që di si të punojë me mейk-fайl». Publikimet ndodhin me besueshmëri dhe shpejtësi.
IaC
Tema Infrastrukturë si Kod me shembullin Terraform do të diskutohet nga administrator i cloud-it në Selectel, Alexei Stepanenko. Ai do të tregojë se si të shpërndahen dhe skalohet shpejt dhe automatikisht serverat, si të paketohen automatikisht imazhet, dhe si të përdoren shabllonat e konfiguracionit për të marrë menjëherë makina të konfigurara.
Një person që ka zhvilluar mijëra zgjidhje IaC do të tregojë se si të bëhet në mënyrë të duhur dhe çfarë nuk duhet bërë.
Zgjidhja për cloud-in Selectel me modifikime minimale është e përshtatshme për cloud-et Google dhe Amazon.
Punonjësi i Southbridge, Nikolai Mesropyán, do të tregojë me shembullin e Ansible se si të shpërndahen aplikacione funksionale pa ndërprerje dhe të kontrollohet funksionaliteti i përketit.
Nëse po e menaxhoni infrastrukturën manualisht (konfiguroni serverët, instaloni libra, paketa sipas nevojës), gjatë përpjekjes për të krijuar një kopje të ambientit, do t'ju duhen të kujtoni dhe të riprodhoni të gjitha veprimet tuaja. Kjo detyrë lehtë zë 3-5 ditë. Puna me infrastrukturën si kod garanton që keni një përshkrim të azhurnuar të ambientit, të cilin mund ta zhvilloni brenda disa minutash.
Nikolai do të flasë për mënyrën se si të shkruani playbooks, cilat gabime ndodhin, pse ndonjëherë playbooks funksionojnë ngadalë ose ndryshe nga sa pritej. Kjo është një përvojë e shumë viteve përdorimi të IaC në Southbridge.
Tema №7: Infrastruktura si Kod
- IaC: qasja ndaj infrastrukturës si kod
- Ofruesit e cloud si furnizues të infrastrukturës
- Mjetet e inicializimit të sistemeve, ndërtimi i imazheve (packer)
- IaC me shembullin Terraform
- Ruajtja e konfiguracioneve, bashkëpunimi, automatizimi i aplikacioneve
- Praktika e krijimit të playbooks Ansible
- Idempotencë, deklarativitet
- IaC me shembuj Ansible
- Database si Kod / Qëndrueshmëria e PostgreSQL
Infrastruktura fiton deklarativitet dhe idempotencë.
Administratori mëson si të menaxhojë një infrastrukturë komplekse: të krijojë shpejt ambiente të reja, të mbajë njësi të gjitha ambienteve, të shohë historinë e ndryshimeve, e cila është kritike kur shumë ekipe punojnë mbi një projekt.
Zhvilluesi mund të studiojë infrastrukturën, të krijojë autonomisht ambiente për veten e tij.
Bonus i seksionit — krijimi dhe konfigurimi i një klasteri të qëndrueshëm të bazës së të dhënave PostgreSQL. Ne do t’ju ofrojmë një playbook të gatshëm, të cilin e përdorim në Southbridge, ju do të krijoni klasterin në një studiues 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ë. Çdo ndryshim kërkon testim. Nga ana tjetër, testimi manual merr kaq shumë kohë, saqë anulon përparësitë e automatizimit.
Të tregojmë praktikisht se si të shkruani teste për rolet. Si rezultat, do të jeni në gjendje të shkruani teste për kompaninë tuaj. Nuk do të duhet më të mbani mend konfigurimet e bëra, por t’i përshkruani ato në teste dhe të kontrolloni automatikisht që të gjitha zgjidhjet dhe improvizimet e kaluara janë në vend.
Më pas do të mësojmë si të shtojmë automatikisht në monitorim të gjitha serverat e rinj. Do të shqyrtojmë veçmas monitorimin e infrastrukturës dhe aplikacioneve. Do të tregojmë praktikat e këqija dhe të mira.
Temë nr. 8: Testimi i infrastrukturës
- Testimi dhe integrimi i vazhdueshëm me Molecule dhe Gitlab CI
- Përdorimi i Vagrant
Temë nr. 9: Monitorimi i infrastrukturës me Prometheus
- Pse është e nevojshme monitorimi
- Llojet e monitorimit
- Njoftimet në sistemin e monitorimit
- Si të ndërtoni një sistem monitorimi të shëndetshëm
- Njoftime të lehta për t'u lexuar, për të gjithë
- Kontrolli i Shëndetit: çfarë duhet të kushtoni vëmendje
- Automatizimi mbi të dhënat nga monitorimi
Monitorimi i gabuar — është mungesë monitorimi. Biznesit nuk i bëhet vonë nëse faqja kryesore e dyqanit online është e aksesueshme, nëse forma e pagesës jep një gabim.
Në konfigurimin e monitorimit dhe zgjidhjes së problemeve, zhvilluesit dhe administratorët marrin pjesë në mënyrë të barabartë. Tradicionalisht, detyrat e monitorimit i takojnë administratorëve. Kursi ynë do t’u tregojë zhvilluesve rolin që ata luajnë në krijimin e një monitorimi efektiv. Administratorët do të marrin praktikat më të mira nga Southbridge. Si rezultat, numri i humbjeve të shkaktuara nga defektet dhe ngadalësimet në faqe ose aplikacione do të bjerë shpejt.
Bonus i seksionit: automatizimi bazuar në monitorim. Për shembull, monitorimi njofton se një ngarkesë ka mbërritur në faqe, dhe shkallëzimi i serverëve të uebit aktivizohet automatikisht.
Logimi
Gabimi kryesor në punën me logët është se administratorët dhe zhvilluesit i shikojnë ato drejtpërdrejt në serverë. Nëse keni më shumë se një server, kjo është e ngadaltë. Kjo është e pasigurt: zhvilluesi hyn në serverin ku nuk duhet të jetë.
DevOps kërkon grumbullim, përpunim dhe analizë të centralizuar të logjeve.
Temë nr. 10: Logimi i aplikacioneve me ELK
- Përdorimet dhe mundësitë kryesore të elastic (kërkimi, ruajtja, veçoritë e shkallëzimit, fleksibiliteti i konfigurimit)
- Pasqyrë e kibana (mundësitë kryesore, gjuha e pyetjeve, menaxhimi i panelëve, krijimi i grafikëve)
- Përmbledhja e produkteve të bazuar në elastic dhe përdorimi i tyre
- Grupimi i metrikave në APM (gjurmimi i aplikacioneve)
- Shtesë: Përmbledhja e produktit të ri — SIEM
Implementimi i këtij qasjeje do ta bëjë logun një mjet të thjeshtë dhe të kuptueshëm për analizimin, konfigurimin dhe rregullimin e aplikacioneve dhe infrastrukturës.
SRE.
Dhe arrijmë te tema që Southbridge vetëm po e sheh dhe për të cilën folësit e tjerë duan të qëndrojnë deri në ditën e fundit të Slyërm. Jemi të lumtur që e ka pranuar ta lexojë Ivan Kruglov nga Booking.com.
Projekti jeton në një botë reale, ku besueshmëria kurrë nuk është absolute, dhe çdo vendim ka një kosto.
Çfarë është SLA në lidhje me një projekt të ndërlikuar? Le të themi, si të vlerësojmë që website-i është i aksesueshëm, por imazhet ngarkohen me vonesë. Cilat janë metrikat SLA, ku t'i marrim ato, si t'i marrim?
Si të vendosim SLA? Si t'i mbajmë ato?
Tema №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 përdorimit të Error Budget
SRE: Menaxhimi i ndërprerjeve dhe ngarkesës operative (apigateway, shërbimi i rrjetit, bllokuesit e qarkut)
Biznesi ka nevojë për SRE. Të paktën në nivelin më të thjeshtë: të merret një server rezervë ose të ringjallet nga backupi? Një bazë të dhënash apo një grumbull? Të instalosh mbrojtje DDoS parandalueshëm apo vetëm në momentin e sulmit?
Drejtori nuk do të kënaqet me një tregim që "faqja është në funksion" kur ai merr një telefonatë nga një klient që informon se forma e porosisë nuk hapet.
Prandaj, është e rëndësishme për inxhinierin DevOps të kuptojë të paktën në mënyrë të sipërme SRE-në për të komunikuar në mënyrë adekuate me biznesin për nevojat e tij.
Përfundimi
Gjatë 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ë regjistrimin;
— të kuptojnë, e në një ideali — të përdorin SRE.
Për lexuesit e kujdesshëm — me kodin promocional habrapost, një zbritje prej 15%.
Për të gjitha pikat ne po përgatisim praktikë dhe mjete. Kështu që çdo pjesëmarrës, pas kthimit nga Slërma, do të jetë në gjendje të çojë kompaninë e tij në një nivel të ri në DevOps.
Për biznesin, kjo do të thotë ulje të kostove për administrimin dhe zhvillimin, reduktim të kohës pa shërbim, rritje të besueshmërisë, dorëzimin më të shpejtë të veçorive dhe eliminimin e defekteve.
Burimi: habr.com
