4.-6.septembrī Sanktpēterburgā Selectel konferenču zālē trīs dienu .
Mēs izveidojām programmu, pamatojoties uz ideju, ka teorētiskos darbus par DevOps, piemēram, rīku rokasgrāmatas, ikviens var izlasīt pats. Interesanta ir tikai pieredze un prakse: skaidrojums, kā darīt un ko nedarīt, un stāsts par to, kā mēs to darām.
Katram uzņēmumam, katram administratoram vai izstrādātājam ir savs DevOps līmenis. Daži cilvēki Git izmanto nepareizi, citi ievieš SRE. Kurss tiek organizēts tā, lai katrs atrastu ko aktuālu, ko var īstenot šeit un tagad.
Mēs sākam ar Git, pēc tam aplūkojam lietojumprogrammu izstrādi, mijiedarbību starp kodu un infrastruktūru, veidojam CI/CD, infrastruktūru raksturojam kā kodu (IaC), pārbaudām iegūto risinājumu, iestatām uzraudzību, apkopojam un pētām žurnālus, un beigās mēs nonākam. SRE: pārvēršot uzticamību izmērāmā un pārvaldāmā stāstā.
Git
Mūsdienās vienīgie cilvēki, kas neizmanto Git, ir tie, kuri vakar iegādājās savu pirmo klēpjdatoru. Šis ir triviāls un visuresošs rīks, taču mēs bieži redzam tā ļaunprātīgu izmantošanu: sākot no piespiedu nosūtīšanas uz galveno failu un beidzot ar failu kopēšanu no Git uz serveri, izmantojot Ctrl-C, Ctrl-V.
Mēs jums pastāstām, kā jums nevajadzētu to darīt, kā jums tas jādara, kā viņi dara Sautbridžā.
Veicam praksi: Gitas pamati, komandas darbs.
1. tēma: Git pamati
- Pamatkomandas git init, commit, add, diff, log, status, pull, push
- Git plūsma, zari un tagi, apvienošanas stratēģijas
- Darbs ar vairākiem attāliem repo
2. tēma: komandas darbs ar Git
- GitHub plūsma
- Dakša, tālvadības pults, vilkšanas pieprasījums
- Konflikti, izlaidumi, vēlreiz par Gitflow un citām plūsmām saistībā ar komandām
Materiāls ir sakārtots tā, lai administratori un izstrādātāji varētu nekavējoties ieviest visas prakses savā darbā.
No DevOps viedokļa pareizs darbs ar Git racionalizē un automatizē izstrādes un administrēšanas procesus, novērš vairākas atkārtotas problēmas un palielina produktivitāti.
DevOps izstrādātājs
Mēs skatāmies uz DevOps ar izstrādātāja acīm: palaižam lokālo vidi, rakstām lietojumprogrammu, iestatām tās uzraudzību un reģistrēšanu, pārbaudām to lokāli, organizējam mainīgo/noslēpumu uzglabāšanu un pakalpojumu atklāšanu, skatāmies opentracing.
3. tēma: Darbs ar lietojumprogrammu no izstrādes viedokļa
- Vietējās vides iekārtošana: praktiski ieteikumi
- Mikropakalpojuma rakstīšana Python (ieskaitot testus)
- Docker-compose izmantošana izstrādē
4. tēma: koda un infrastruktūras mijiedarbība
- Praktizējiet darbu ar konfigurācijām
Rezultātā izstrādātāji redzēs, kā kodam jānosūta žurnāli, kā to pārbaudīt un kā tas tiks atkļūdots nākotnē. Administratori sapratīs izstrādātāju vajadzības: kādas kļūdas ir kodā, kā organizēt testēšanu izstrādātājiem, kā pašiem pārbaudīt projektu.
Šajā posmā tiek atrisināts galvenais DevOps uzdevums: tiek veidota savstarpēja sapratne un kopīgs darbs starp Devs un Ops. Šis ir galvenais solis, lai pārietu no uzdevumu dalīšanas uz atbildīgu sadarbību.
Līdz ar to paaugstinās darba ātrums un kvalitāte.
CI / CD
Mūsdienu automatizācija ietver CI/CD. Sāksim, aplūkojot manuālo automatizāciju: makefiles, githooks, skriptus. Apskatīsim, kad šie rīki joprojām ir aktuāli un kad tos nevajadzētu lietot.
Pēc tam apskatīsim mūsdienu CI labāko praksi, izmantojot Gitlab kā piemēru.
5. tēma: CI/CD ievads automatizācijā
- Ievads automatizācijā
- Instrumenti (bash, make, gradle)
- Git-hooku izmantošana procesu automatizēšanai
- Rūpnīcas montāžas līnijas un to pielietojums IT
- “Vispārēja” cauruļvada izveides piemērs
- Mūsdienīga programmatūra CI/CD: Drone CI, BitBucket Pipelines, Travis utt.
6. tēma: CI/CD: darbs ar Gitlab
- Gitlab CI - vispārīgi
- Gitlab Runner, to veidi un pielietojums
- Gitlab CI, konfigurācijas līdzekļi, labākā prakse
- Gitlab CI posmi
- Gitlab CI mainīgie
- Veidojiet, pārbaudiet, izvietojiet
- Izpildes kontrole un ierobežojumi: tikai, kad
- Darbs ar artefaktiem
- Veidnes .gitlab-ci.yml, atkārtoti izmantojot darbības dažādās cauruļvada daļās
- Iekļaut - sadaļas
- Centralizēta gitlab-ci.yml pārvaldība (viens fails un automātiska pārsūtīšana uz citām krātuvēm)
Administratoru un izstrādātāju sadarbība sasniedz jaunu līmeni: administrators raksta CI veidni, un izstrādātāji to rediģē, veidojot savu CI neatkarīgi no administratora.
Tiek samazināta izstrādātāju atkarība no administratoriem, samazināts manuālā darba apjoms, un pazūd problēma “vienīgā persona, kas zina, kā strādāt ar make failu”. Izlaišana notiek uzticami un ātri.
IaC
Tēmu Infrastructure as Code, izmantojot Terraform kā piemēru, apspriedīs Selectel mākoņa administrators Aleksejs Stepaņenko. Viņš parādīs, kā ātri un automātiski izvietot un mērogot serverus, kā automātiski iepakot attēlus un kā izmantot konfigurācijas veidnes, lai nekavējoties iegūtu konfigurētas iekārtas.
Cilvēks, kurš ir izstrādājis tūkstošiem IaC risinājumu, pastāstīs, kā to izdarīt pareizi un ko nedarīt.
Selectel mākoņrisinājums ir piemērots Google un Amazon mākoņiem ar minimālām modifikācijām.
Southbridge darbinieks Nikolajs Mesropjans, kā piemēru izmantojot Ansible, parādīs, kā bez dīkstāves izvietot strādājošu lietojumprogrammu un pārbaudīt tās veiktspēju.
Ja manuāli rediģējat infrastruktūru (iestatāt serverus, pēc vajadzības instalējat bibliotēkas un pakotnes), mēģinot izveidot vides kopiju, jums būs jāatceras un jāreproducē visas savas darbības. Šis uzdevums viegli aizņem 3-5 dienas. Darbs ar infrastruktūru kā kodu nodrošina, ka jums ir jaunākais vides apraksts, ko var izvietot dažu minūšu laikā.
Nikolajs pastāstīs, kā rakstīt rokasgrāmatas, kādas kļūdas notiek un kāpēc dažreiz rokasgrāmatas darbojas lēni vai ne tā, kā paredzēts. Šī ir daudzu gadu pieredze, izmantojot IaC Southbridge.
7. tēma: Infrastruktūra kā kods
- IaC: Tuvojas infrastruktūrai kā kodam
- Mākoņu nodrošinātāji kā infrastruktūras nodrošinātāji
- Sistēmas inicializācijas rīki, attēlu veidošana (iepakotājs)
- IaC, kā piemēru izmantojot Terraform
- Konfigurācijas glabāšana, sadarbība, lietojumprogrammu automatizācija
- Ansible rokasgrāmatu izveides prakse
- Idempotence, deklarativitāte
- IaC, kā piemēru izmantojot Ansible
- Datu bāze kā kods / PostgreSQL kļūdu tolerance
Infrastruktūra kļūst deklaratīva un idempotena.
Administrators mācās pārvaldīt sarežģītu infrastruktūru: ātri izveidot jaunas vides, uzturēt visu vidi vienotību, redzēt izmaiņu vēsturi, kas ir būtiski, ja pie projekta strādā vairākas komandas.
Izstrādātājs var izpētīt infrastruktūru un patstāvīgi attīstīt savu vidi.
Sadaļas bonuss: PostgreSQL datu bāzu kļūmjpārlēces klastera izveide un konfigurēšana. Mēs nodrošināsim gatavu rokasgrāmatu, ko izmantojam Southbridge, jūs izvietosit klasteru mācību stendā un varēsiet izmantot šo risinājumu savā uzņēmumā.
Infrastruktūras testēšana un uzraudzība
Automatizācija ļauj izvērst kļūdu tūkstoš serveriem vienlaikus. Katrai izmaiņai nepieciešama pārbaude. No otras puses, manuāla pārbaude aizņem tik daudz laika, ka tā noliedz automatizācijas priekšrocības.
Mēs praksē parādīsim, kā uzrakstīt lomu pārbaudes. Rezultātā varēsiet rakstīt testus savam uzņēmumam. Jums vairs nav jāatceras veiktie iestatījumi, jūs tos aprakstāt testos un automātiski pārbaudāt, vai visi iepriekšējie risinājumi un kruķi ir savās vietās.
Pēc tam mēs uzzināsim, kā visus jaunos serverus automātiski pievienot uzraudzībai. Apskatīsim infrastruktūru un lietojumprogrammu uzraudzību atsevišķi. Mēs parādīsim sliktu un labo praksi.
8. tēma: Infrastruktūras testēšana
- Testēšana un nepārtraukta integrācija ar Molecule un Gitlab CI
- Izmantojot Vagrant
9. tēma: Infrastruktūras uzraudzība ar Prometheus
- Kāpēc ir nepieciešama uzraudzība?
- Monitoringa veidi
- Paziņojumi uzraudzības sistēmā
- Kā izveidot veselīgu uzraudzības sistēmu
- Cilvēkiem lasāmi paziņojumi ikvienam
- Veselības pārbaude: kam jāpievērš uzmanība
- Automatizācija, kuras pamatā ir monitoringa dati
Uzraudzība, kas nedarbojas pareizi, nav pārraudzība. Uzņēmumiem ir vienalga, lai tiešsaistes veikala galvenā lapa būtu pieejama, ja maksājuma veidlapā ir norādīta kļūda.
Izstrādātāji un administratori vienlīdzīgi piedalās uzraudzības un traucējummeklēšanas problēmu iestatīšanā. Turklāt tradicionāli uzraudzības uzdevumi gulstas uz administratoriem. Mūsu kurss parādīs izstrādātājiem viņu lomu efektīvas uzraudzības izveidē. Administratori saņems Southbridge paraugpraksi. Tā rezultātā strauji samazināsies zaudējumu skaits, ko radīs vietnes vai lietojumprogrammas kļūmes un palēninājumi.
Sadaļas bonuss: automatizācija, kuras pamatā ir uzraudzība. Piemēram, pārraudzība ziņo, ka vietnē ir ieradusies slodze, un tīmekļa servera mērogošana sākas automātiski.
Mežizstrāde
Galvenā kļūda, strādājot ar žurnāliem, ir tā, ka administratori un izstrādātāji tos aplūko tieši serveros. Ja jums ir vairāk nekā viens serveris, tas aizņem ilgu laiku. Tas nav droši: izstrādātājs piesakās serverī, kur viņam nevajadzētu atrasties.
DevOps nepieciešama centralizēta žurnālu apkopošana, apstrāde un analīze.
10. tēma: Lietojumprogrammu reģistrēšana ar ELK
- Elastīgo elementu pamata lietojumprogrammas un iespējas (meklēšana, glabāšana, mērogošanas līdzekļi, pielāgošanas elastība)
- Kibana pārskats (galvenās funkcijas, vaicājumu valoda, informācijas paneļa pārvaldība, diagrammu izveide)
- Elastīgo izstrādājumu un to pielietojumu apskats
- Metrikas apkopošana APM (lietojumprogrammu izsekošana)
- Papildus: Jauno produktu apskats - SIEM
Šīs pieejas ieviešana padarīs žurnālus par vienkāršu un saprotamu rīku lietojumprogrammas un infrastruktūras analīzei, konfigurēšanai un atkļūdošanai.
SRE
Un mēs nonākam pie tēmas, par kuru Southbridge tikai pievērš uzmanību un par kuru citi runātāji vēlas palikt uz pēdējo Slurm dienu. Priecājamies, ka Ivans Kruglovs no Booking.com piekrita to izlasīt.
Projekts dzīvo reālajā pasaulē, kur uzticamība nekad nav absolūta un katrs lēmums maksā naudu.
Kas ir SLA saistībā ar sarežģītu projektu? Teiksim, kā novērtēt, ka vietne ir pieejama, bet attēli tiek ielādēti ar aizkavi. Kādi ir SLA rādītāji, kur tos ņemt, kā tos ņemt?
Kā iestatīt SLA? Kā tās izturēt?
11. tēma: SRE
SLA, SLO, Error Budget un citu biedējošu terminu definīcijas no SRE pasaules
SRE: SLI un SLO uzraudzības prakse
SRE: kļūdu budžeta izmantošanas prakse
SRE: pārtraukumu un darbības slodzes pārvaldība (apigateway, servisa tīkls, automātiskie slēdži)
Uzņēmumi vēlas SRE. Vismaz vienkāršākajā līmenī: vai man vajadzētu ņemt rezerves serveri vai noņemt to no dublējuma? Viena datu bāze vai klasteris? Vai DDoS aizsardzība jāinstalē aktīvi vai tikai uzbrukuma laikā?
Direktoru neapmierinās stāsts, ka “lapa strādā”, kad viņam piezvanīs klients un ziņo, ka pasūtījuma veidlapa netiek atvērta.
Tāpēc DevOps inženierim ir svarīgi vismaz virspusēji izprast SRE, lai adekvāti runātu ar uzņēmumu par tā vajadzībām.
Kopsavilkums
Laikā administratori un izstrādātāji apgūs:
— pareizi strādāt ar Git;
— organizēt vietējo attīstību;
— konfigurēt (administratori) un lietot (izstrādātāji) CI/CD;
— strādāt ar infrastruktūru kā ar kodu;
— pārbaudīt infrastruktūru;
— pārraudzīt infrastruktūru un lietojumprogrammas;
— konfigurēt reģistrēšanu;
— saprast un ideālā gadījumā izmantot SRE.
Uzmanīgiem lasītājiem izmantojiet habrapost reklāmas kodu, lai saņemtu 15% atlaidi.
Mēs gatavojam praksi un rīkus visiem punktiem. Lai katrs dalībnieks, atgriežoties no Slurm, varētu pacelt savu uzņēmumu uz nākamo DevOps līmeni.
Uzņēmējdarbībai tas nozīmē lētāku administrēšanu un izstrādi, samazinātu dīkstāvi, lielāku uzticamību, ātrāku funkciju piegādi un kļūdu novēršanu.
Avots: www.habr.com
