Më 4-6 shtator në Shën Petersburg, në sallën e konferencave Selectel, një treditor .
Ne e ndërtuam programin bazuar në idenë se veprat teorike në DevOps, si manualet për mjetet, mund të lexohen nga të gjithë vetë. Vetëm përvoja dhe praktika janë interesante: një shpjegim se si ta bëjmë dhe çfarë jo, dhe një histori se si e bëjmë atë.
Çdo kompani, çdo administrator ose zhvillues ka nivelin e vet të DevOps. Disa njerëz përdorin Git gabimisht, të tjerë zbatojnë SRE. Kursi është i organizuar në mënyrë që të gjithë të gjejnë diçka të rëndësishme që mund të zbatohet këtu dhe tani.
Ne fillojmë me Git, pastaj shikojmë zhvillimin e aplikacionit, ndërveprimin midis kodit dhe infrastrukturës, ndërtojmë CI/CD, përshkruajmë infrastrukturën si kod (IaC), testojmë zgjidhjen që rezulton, vendosim monitorimin, mbledhim dhe studiojmë regjistrat, dhe në fund vijmë për SRE: duke e kthyer besueshmërinë në një histori të matshme dhe të menaxhueshme.
git
Në ditët e sotme, të vetmit njerëz që nuk përdorin Git janë ata që blenë laptopin e tyre të parë dje. Ky është një mjet i parëndësishëm dhe i kudondodhur, dhe megjithatë shpesh shohim keqpërdorimin e tij: nga shtytja e detyruar te masteri, te kopjimi i skedarëve nga Git në server përmes Ctrl-C, Ctrl-V.
Ne ju themi se çfarë nuk duhet të bëni, si duhet ta bëni, siç bëjnë në Southbridge.
Ne po bëjmë praktikë: bazat e Gita-s, puna në grup.
Tema #1: Bazat e Git
- Komandat bazë git init, commit, add, diff, log, status, pull, push
- Rrjedha e Git, degët dhe etiketat, strategjitë e bashkimit
- Duke punuar me shumë depo në distancë
Tema #2: Puna ekipore me Git
- Rrjedha e GitHub
- Kërkesë për pirun, telekomandë, tërheqje
- Konflikte, lëshime, edhe një herë rreth Gitflow dhe flukseve të tjera në lidhje me ekipet
Materiali është i organizuar në mënyrë që administratorët dhe zhvilluesit të mund të zbatojnë menjëherë të gjitha praktikat në punën e tyre.
Nga pikëpamja e DevOps, puna e duhur me Git riorganizon dhe automatizon proceset e zhvillimit dhe administrimit, eliminon një sërë problemesh të përsëritura dhe rrit produktivitetin.
Zhvilluesi i DevOps
Ne e shikojmë DevOps përmes syve të një zhvilluesi: hapim një mjedis lokal, shkruajmë një aplikacion, konfigurojmë monitorimin dhe regjistrimin e tij, e testojmë atë në nivel lokal, organizojmë ruajtjen e variablave/sekreteve dhe zbulimin e shërbimit, shikojmë hapjen e gjurmimit.
Tema #3: Puna me aplikacionin nga pikëpamja e zhvillimit
- Krijimi i mjedisit lokal: rekomandime praktike
- Shkrimi i një mikroshërbimi në Python (përfshirë testet)
- Përdorimi i docker-compose në zhvillim
Tema #4: Ndërveprimi ndërmjet kodit dhe infrastrukturës
- Praktikoni punën me konfigurimet
Si rezultat, zhvilluesit do të shohin se si kodi duhet të dërgojë regjistrat, si ta testojnë atë dhe si do të korrigjohet në të ardhmen. Administratorët do të kuptojnë nevojat e zhvilluesve: çfarë gabimesh ka në kod, si të organizoni testimin për zhvilluesit, si të testoni vetë projektin.
Në këtë fazë, detyra kryesore e DevOps është zgjidhur: ndërtohet mirëkuptimi i ndërsjellë dhe puna e përbashkët midis Devs dhe Ops. Ky është një hap kyç për të kaluar nga ndarja e detyrave në bashkëpunim të përgjegjshëm.
Si rezultat, shpejtësia dhe cilësia e punës rritet.
CI / CD
Automatizimi modern përfshin CI/CD. Ne do të fillojmë duke parë automatizimin manual: skedarët e krijuar, githoks, skriptet. Le të shohim se kur këto mjete janë ende relevante dhe kur ato nuk duhet të përdoren.
Pastaj le të shohim praktikat më të mira të CI moderne duke përdorur Gitlab si shembull.
Tema #5: CI/CD hyrje në automatizim
- Hyrje në Automatizim
- Mjetet (bash, bëj, gradoje)
- Përdorimi i git-hooks për të automatizuar proceset
- Linjat e montimit të fabrikës dhe aplikimi i tyre në IT
- Një shembull i ndërtimit të një tubacioni "të përgjithshëm".
- Softuer modern për CI/CD: Drone CI, BitBucket Pipelines, Travis, etj.
Tema #6: CI/CD: Puna me Gitlab
- Gitlab CI - gjeneral
- Gitlab Runner, llojet dhe aplikimet e tyre
- Gitlab CI, veçoritë e konfigurimit, praktikat më të mira
- Fazat e Gitlab CI
- Variablat Gitlab CI
- Ndërtoni, testoni, vendosni
- Kontrolli i ekzekutimit dhe kufizimet: vetëm, kur
- Puna me artefakte
- Modele brenda .gitlab-ci.yml, duke ripërdorur veprime në pjesë të ndryshme të tubacionit
- Përfshi - seksione
- Menaxhimi i centralizuar i gitlab-ci.yml (një skedar dhe shtytje automatike në depo të tjera)
Bashkëpunimi midis administratorëve dhe zhvilluesve arrin një nivel të ri: administratori shkruan një shabllon CI dhe zhvilluesit e modifikojnë atë, duke ndërtuar CI-në e tyre pavarësisht nga administratori.
Varësia e zhvilluesve nga administratorët zvogëlohet, sasia e punës manuale zvogëlohet dhe problemi i "personit të vetëm që di të punojë me një skedar make" zhduket. Përhapja ndodh në mënyrë të besueshme dhe të shpejtë.
IaC
Tema e Infrastrukturës si kod, duke përdorur Terraform si shembull, do të diskutohet nga administratori i reve Selectel Alexey Stepanenko. Ai do t'ju tregojë se si të vendosni dhe shkallëzoni shpejt dhe automatikisht serverët, si të paketoni automatikisht imazhet dhe si të përdorni shabllonet e konfigurimit për të marrë makineritë e konfiguruara menjëherë.
Një person që ka bërë mijëra zgjidhje IaC do t'ju tregojë se si ta bëni atë siç duhet dhe çfarë të mos bëni.
Zgjidhja e reve Selectel është e përshtatshme për retë e Google dhe Amazon me modifikime minimale.
Punonjësi i Southbridge, Nikolay Mesropyan, duke përdorur Ansible si shembull, do të tregojë se si të vendoset një aplikacion pune pa ndërprerje dhe të kontrollojë performancën e tij.
Nëse e redaktoni infrastrukturën manualisht (konfiguroni serverë, instaloni biblioteka dhe paketa sipas nevojës), kur përpiqeni të krijoni një kopje të mjedisit, do t'ju duhet të mbani mend dhe të riprodhoni të gjitha veprimet tuaja. Kjo detyrë merr lehtësisht 3-5 ditë. Puna me infrastrukturën si kod siguron që ju të keni një përshkrim të përditësuar të mjedisit tuaj që mund të vendoset në minuta.
Nikolay do t'ju tregojë se si të shkruani libra lojërash, çfarë gabimesh ndodhin dhe pse ndonjëherë librat e lojërave funksionojnë ngadalë ose jo siç pritej. Kjo është përvojë nga shumë vite të përdorimit të IaC në Southbridge.
Tema #7: Infrastruktura si kod
- IaC: Afrimi i Infrastrukturës si Kod
- Ofruesit e reve kompjuterike si ofrues të infrastrukturës
- Mjetet e inicializimit të sistemit, ndërtimi i imazhit (paker)
- IaC duke përdorur Terraform si shembull
- Ruajtja e konfigurimit, bashkëpunimi, automatizimi i aplikacioneve
- Praktika e krijimit të librave lojërash Ansible
- Idempotenca, deklarativiteti
- IaC duke përdorur Ansible si shembull
- Baza e të dhënave si një kod / Toleranca e gabimeve PostgreSQL
Infrastruktura bëhet deklarative dhe idempotente.
Administratori mëson të menaxhojë infrastrukturën komplekse: krijoni shpejt mjedise të reja, ruani unitetin e të gjitha mjediseve, shikoni historinë e ndryshimeve, gjë që është kritike kur disa ekipe janë duke punuar në një projekt.
Zhvilluesi mund të studiojë infrastrukturën dhe të zhvillojë në mënyrë të pavarur mjedisin e tij.
Bonusi i seksionit: krijimi dhe konfigurimi i një grupi failover të bazave të të dhënave PostgreSQL. Ne do të ofrojmë një libër lojërash të gatshëm që përdorim në Southbridge, ju do të vendosni një grup në një stendë trajnimi dhe mund ta përdorni këtë zgjidhje në kompaninë tuaj.
Testimi dhe monitorimi i infrastrukturës
Automatizimi ju lejon të hapni një gabim në një mijë serverë menjëherë. Çdo ndryshim kërkon testim. Nga ana tjetër, testimi manual kërkon aq shumë kohë sa mohon përfitimet e automatizimit.
Ne do t'ju tregojmë në praktikë se si të shkruani testimin e roleve. Si rezultat, ju do të jeni në gjendje të shkruani teste për kompaninë tuaj. Nuk keni më nevojë të mbani mend cilësimet që keni bërë; ju i përshkruani ato në teste dhe kontrolloni automatikisht nëse të gjitha zgjidhjet dhe patericat e mëparshme janë në vend.
Pastaj do të mësojmë se si të shtojmë automatikisht të gjithë serverët e rinj në monitorim. Le të shohim 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
- Duke përdorur 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 të shëndetshëm monitorimi
- Njoftime të lexueshme nga njeriu, për të gjithë
- Kontrolli shëndetësor: çfarë duhet t'i kushtoni vëmendje
- Automatizimi i bazuar në të dhënat e monitorimit
Monitorimi që nuk funksionon siç duhet nuk është monitorim. Bizneseve nuk u intereson që faqja kryesore e një dyqani online të jetë e aksesueshme nëse formulari i pagesës jep një gabim.
Zhvilluesit dhe administratorët marrin pjesë në mënyrë të barabartë në vendosjen e problemeve të monitorimit dhe zgjidhjes së problemeve. Për më tepër, tradicionalisht, detyrat e monitorimit bien mbi administratorët. 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 të Southbridge. Si rezultat, numri i humbjeve të shkaktuara nga dështimet dhe ngadalësimet e një faqe interneti ose aplikacioni do të bjerë shpejt.
Bonusi i seksionit: automatizimi i bazuar në monitorim. Për shembull, monitorimi raporton se një ngarkesë ka mbërritur në sajt dhe shkallëzimi i serverit të uebit fillon automatikisht.
Prerjet
Gabimi kryesor kur punoni me regjistrat është se administratorët dhe zhvilluesit i shikojnë ato drejtpërdrejt në serverë. Nëse keni më shumë se një server, kjo kërkon shumë kohë. Kjo nuk është e sigurt: zhvilluesi regjistrohet në një server ku nuk duhet të jetë.
DevOps kërkon mbledhje, përpunim dhe analitikë të centralizuar të regjistrave.
Tema #10: Regjistrimi i një aplikacioni me ELK
- Aplikacionet dhe aftësitë bazë të elastikës (kërkimi, ruajtja, veçoritë e shkallëzimit, fleksibiliteti i personalizimit)
- Përmbledhje e kibana (karakteristikat kryesore, gjuha e pyetjeve, menaxhimi i panelit, krijimi i grafikut)
- Rishikimi i produkteve me bazë elastike dhe aplikimet e tyre
- Mbledhja e matjeve në APM (gjurmimi i aplikacionit)
- Për më tepër: Rishikimi i produktit të ri - SIEM
Prezantimi i kësaj qasjeje do t'i bëjë regjistrat një mjet të thjeshtë dhe të kuptueshëm për analizimin, konfigurimin dhe korrigjimin e aplikacionit dhe infrastrukturës.
SRE
Dhe arrijmë te tema që Southbridge sapo po merr vëmendjen dhe për të cilën folësit e tjerë duan të qëndrojnë për ditën e fundit të Slurm. Jemi të kënaqur që Ivan Kruglov nga Booking.com pranoi ta lexonte.
Projekti jeton në botën reale, ku besueshmëria nuk është kurrë absolute dhe çdo vendim kushton para.
Çfarë është SLA në lidhje me një projekt kompleks? Le të themi se si të vlerësojmë se siti është i aksesueshëm, por imazhet ngarkohen me vonesë. Cilat janë matjet e SLA, ku t'i çoni ato, si t'i merrni ato?
Si të vendosni SLA? Si t'i rezistoni atyre?
Tema #11: SRE
Përkufizimi i SLA, SLO, Buxheti i Gabimit dhe terma të tjerë të frikshëm nga bota e SRE
SRE: Praktikat e monitorimit të SLI dhe SLO
SRE: Praktika e përdorimit të Buxhetit të Gabimeve
SRE: Ndërprerja dhe menaxhimi i ngarkesës operacionale (apigateway, rrjetë shërbimi, ndërprerës)
Bizneset duan SRE. Të paktën në nivelin më të thjeshtë: duhet të marr një server rezervë apo ta heq atë nga një rezervë? Baza e të dhënave e vetme apo grupi? A duhet të instaloni mbrojtjen DDoS në mënyrë proaktive apo vetëm në kohën e sulmit?
Drejtori nuk do të jetë i kënaqur me historinë se "faqja po funksionon" kur një klient e telefonon dhe raporton se formulari i porosisë nuk po hapet.
Prandaj, është e rëndësishme për një inxhinier DevOps që të paktën të kuptojë sipërfaqësisht SRE në mënyrë që të flasë në mënyrë adekuate me biznesin për nevojat e tij.
Total
Gjatë administratorët dhe zhvilluesit do të mësojnë:
— punoni saktë me Git;
— organizojnë zhvillimin lokal;
— konfiguroni (administratorët) dhe përdorni (zhvilluesit) CI/CD;
— punë me infrastrukturë si me kod;
— testimi i infrastrukturës;
— monitoron infrastrukturën dhe aplikimin;
— konfiguroni regjistrimin;
— kuptoni dhe në mënyrë ideale përdorni SRE.
Për lexuesit e vëmendshëm, përdorni kodin promovues të habrapost për një zbritje prej 15%.
Ne jemi duke përgatitur praktikë dhe mjete për të gjitha pikat. Kështu që çdo pjesëmarrës, pas kthimit nga Slurm, do të jetë në gjendje ta çojë kompaninë e tyre në nivelin tjetër të DevOps.
Për biznesin, kjo do të thotë administrim dhe zhvillim më i lirë, kohëzgjatje të reduktuar, rritje të besueshmërisë, shpërndarje më të shpejtë të veçorive dhe eliminim të gabimeve.
Burimi: www.habr.com
