No 4-6. septembrī Sanktpēterburgā, konferenču telpā Selectel notiks trīs dienu .
Mēs veidojām programmu, pamatojoties uz domu, ka teoriskos darbus par DevOps, kā arī rīku rokasgrāmatas katrs var izlasīt pats. Interesanti ir tikai pieredze un prakse: skaidrojums, kā jādara un kā nedrīkst darī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 nepareizi izmanto Git, citi ievieš SRE. Kurss organizēts tā, lai katrs atrastu kaut ko aktuālu, ko var ieviest šeit un tagad.
Sākam ar Git, pēc tam skatāmies uz lietojumprogrammas izstrādi, kodu un infrastruktūras mijiedarbību, veidojam CI/CD, aprakstām infrastruktūru kā kodu (IaC), testējam iegūto risinājumu, iestatām uzraudzību, apkopo un pēta žurnālus, un beigās nonākam līdz SRE: pārvēršam uzticamību par izmērāmus un pārvaldāmus stāstus.
Git
Pašlaik ar Git neizmanto tikai tas, kurš vakar nopirka pirmo klēpjdatoru. Tas ir trivāls un plaši izmantots rīks, un tomēr mēs bieži sastopam tā nepareizu izmantošanu: sākot no spiediena uz master un beidzot ar failu kopēšanu no Gita serverī, izmantojot Ctrl-C, Ctrl-V.
Stāstām, kā nedrīkst darīt, kā jādara, kā to dara Southbridge.
Iziet cauri praksē: Git pamati, komanddarbs.
Tēma №1: Git pamati
- Pamata komandas git init, commit, add, diff, log, status, pull, push
- Git flow, zari un tagi, apvienošanas stratēģijas
- Darbs ar vairākiem attālinātiem repozitorijiem
Tēma №2: Komanddarbs ar Git
- GitHub flow
- Fork, attālinātais, pull pieprasījums
- Konflikti, relīzes, vēlreiz par Gitflow un citiem flow, attiecībā uz komandām
Materiāls organizēts tā, lai administratori un izstrādātāji varētu nekavējoties ieviest visas prakses darbā.
No DevOps viedokļa pareiza darbība ar Git kārto un automatizē izstrādes un administrēšanas procesus, novērš vairākas atkārtojošas problēmas, palielina darba efektivitāti.
DevOps izstrādātājs
Skatāmies uz DevOps izstrādātāja acīm: uzsākam lokālo vidi, rakstām lietojumprogrammu, iestatām tās uzraudzību un žurnālošanu, lokāli to testējam, organizējam mainīgo/sekrētu un pakalpojumu atklāšanu, skatāmies izsekošanu (opentracing).
Tēma №3: Darbs ar lietojumprogrammu no izstrādātāja viedokļa
- Lokālās vides iestatīšana: praktiski ieteikumi
- Rakstām mikroservisu Python (ieskaitot testus)
- Docker-compose izmantošana izstrādē
Tēma №4: Koda un infrastruktūras mijiedarbība
- Prakse darbā ar konfigurācijām
Izstrādātāji redzēs, kā kods jānosūta žurnālos, kā to testēt un kā to vēlāk debugs. Administratori sapratīs izstrādātāju vajadzības: kādas kļūdas kodā pastāv, kā organizēt izstrādātāju testēšanu, kā pašiem testēt projektu.
Šajā posmā tiek risināta galvenā DevOps uzdevums: tiek izveidota savstarpēja sapratne un sadarbība starp izstrādātājiem un operāciju speciālistiem. Tas ir būtisks solis pārejā no uzdevumu pārsūtīšanas uz atbildīgu mijiedarbību.
Rezultātā palielinās darba ātrums un kvalitāte.
CI/CD
Mūsdienu automatizācija nozīmē CI/CD. Sāksim ar roku automatizāciju: make faili, git hooks, skripti. Apspriedīsim, kad šie rīki joprojām ir aktuāli, un kad tos nevajadzētu izmantot.
Pēc tam iepazīsimies ar labākajām CI mūsdienu praksēm Gitlab piemēram.
Tēma №5: CI/CD ievads automatizācijā
- Ievads automatizācijā
- Rīki (bash, make, gradle)
- Git hooks izmantošana procesu automatizācijai
- Ražošanas konveijera līnijas un to pielietojums IT
- Piemērs «kopējā» pipelines izveidē
- Mūsdienu CI/CD rīki: Drone CI, BitBucket Pipelines, Travis u.c.
Tēma №6: CI/CD: Darbs ar Gitlab
- Gitlab CI — vispārīgi
- Gitlab Runner, to veidi un pielietojums
- Gitlab CI, iestatīšanas īpatnības, labākās prakses
- Gitlab CI posmi
- Gitlab CI mainīgie
- Būvēšana, testēšana, izvietošana
- Izpildes kontrole un ierobežojumi: only, when
- Darbs ar artefaktiem
- Šabloni iekš .gitlab-ci.yml, darbību atkārtota izmantošana dažādās pipelines daļās
- Include — sekcijas
- Centralizēta gitlab-ci.yml pārvaldība (viens fails un automātiski push uz pārējiem repozitorijiem)
Administratori un izstrādātāji sadarbībā sasniedz jaunu līmeni: administrators raksta CI šablonu, bet izstrādātāji to labojot veido savu CI neatkarīgi no administratora.
Samazinās izstrādātāju atkarība no administratoriem, samazinās manuālais darbs un izzūd problēma «vienīgais cilvēks, kurš zina, kā strādāt ar make failu». Izlaides notiek droši un ātri.
IaC
Tēmu Infrastructure as Code, izmantojot Terraform, izstāstīs Selectel mākonī pārvaldnieks Aleksejs Stepanenko. Viņš parādīs, kā ātri un automatizēti izvērst un palielināt serverus, kā automātiski iepakot attēlus, kā izmantot konfigurācijas veidnes, lai nekavējoties iegūtu iestatītas mašīnas.
Cilvēks, kurš izveidojis tūkstošiem IaC risinājumu, pastāstīs, kā darīt pareizi un kā nedarīt.
Selectel risinājums ar minimālām izmaiņām ir piemērots Google un Amazon mākoniem.
Darbinieks no Southbridge Nikolajs Mesropjans, izmantojot Ansible, parādīs, kā bez dīkstāves izvērst darbojošos lietotni un pārbaudīt tās darbību.
Ja jūs roka maināt infrastruktūru (iestatāt serverus, pēc vajadzības instalējat bibliotēkas, paketes), mēģinot pacelt vides kopiju, jums jāatceras un jāatjauno visas jūsu darbības. Šī uzdevums viegli aizņem 3–5 dienas. Strādājot ar infrastruktūru kā ar kodu, jūs garantējat, ka jums ir aktuāla vides apraksts, kuru var izvērst minūtēs.
Nikolajs pastāstīs, kā rakstīt playbookus, kādas kļūdas notiek, kāpēc dažreiz playbooki darbojas lēni vai ne tā, kā gaidīts. Tas ir daudzu gadu pieredze, izmantojot IaC Southbridge.
Temats Nr. 7: Infrastructure as Code
- IaC: pieeja infrastruktūrai kā kodam
- Mākonī pakalpojumu sniedzēji kā infrastruktūras piegādātāji
- Sistēmu inicializēšanas rīki, attēlu izveide (packer)
- IaC, izmantojot Terraform
- Konfigurāciju glabāšana, sadarbība, automātiska lietojumu īstenošana
- Praktika Ansible playbooku izveidē
- Idempotence, deklarativitāte
- IaC, izmantojot Ansible
- Database as a Code / PostgresQL noturība
Infrastruktūra iegūst deklarativitāti un idempotenci.
Pārvaldnieks mācās pārvaldīt sarežģītu infrastruktūru: ātri izveidot jaunas vides, uzturēt visu vidus vienotību, redzēt izmaiņu vēsturi, kas ir kritiski, kad pie projekta strādā vairākas komandas.
Izstrādātājs var izpētīt infrastruktūru, patstāvīgi izvērst sev vides.
Noderīga sadaļas bonusa daļa — izveidot un konfigurēt PostgresQL noturīgu datu bāzu klasteri. Mēs sniegsim gatavu playbooku, kuru izmantojam Southbridge, jūs izvēršat klasteri mācību stendā un varēsiet izmantot šo risinājumu savā uzņēmumā.
Infrastruktūras testēšana un uzraudzība
Automatizācija ļauj nekavējoties izplatīt kļūdu uz tūkstoš serveriem. Katru reizi, veicot izmaiņas, ir nepieciešama testēšana. No otras puses, manuālā testēšana aizņem tik daudz laika, ka tā padara automatizācijas priekšrocības nevērtīgas.
Parādīsim praksē, kā rakstīt lomu testēšanu. Rezultātā jūs varēsiet rakstīt testus savai uzņēmumam. Vairs nav nepieciešams atcerēties iepriekš veiktās konfigurācijas, jūs tās aprakstāt testos un automātiski pārbaudāt, vai visas iepriekšējās risinājumu un 'failu' vietas ir saglabātas.
Tad iemācīsimies automātiski pievienot visus jaunus serverus monitoringu. Atsevišķi apskatīsim infrastruktūras un lietotņu monitoringu. Parādīsim sliktās un labās prakses.
Tēma Nr. 8: Infrastruktūras testēšana
- Testēšana un nepārtraukta integrācija ar Molecule un Gitlab CI
- Vagrant lietojums
Tēma Nr. 9: Infrastruktūras monitorings ar Prometheus
- Kāpēc nepieciešams monitorings
- Monitoring veidi
- Paziņojumi monitoringa sistēmā
- Kā izveidot veselīgu monitoringa sistēmu
- Cilvēkam lasāmi paziņojumi, visiem
- Health Check: uz ko vērst uzmanību
- Automatizācija, balstoties uz monitoringa datiem
Nepareizi darbojošs monitorings ir monitoringa trūkums. Uzņēmumam nav svarīgi, ka galvenā lapas pieejamība internetā ir nodrošināta, ja maksājumu forma izvada kļūdu.
Monitoringa iestatīšanā un problēmu novēršanā izstrādātāji un administratoriem piedalās vienlīdzīgi. Tradicionāli uzdevumi monitoringa jomā gulstas uz administratoriem. Mūsu kurss parādīs izstrādātājiem, kādu lomu viņi spēlē efektīva monitoringa izveidē. Administratori saņems labākās prakses no Southbridge. Rezultātā zaudējumu skaits, ko izraisa vietnes vai lietotnes avārijas un kavēšanās, ātri samazināsies.
Bonuss sadaļā: automatizācija, balstoties uz monitoringu. Piemēram, monitorings informē, ka ir palielinājies slodze uz vietni, un tīmekļa serveru skalošana tiek uzsākta automātiski.
Datu pieraksts
Galvenā kļūda darbā ar žurnāliem — administratoriem un izstrādātājiem tos skatīties tieši uz serveriem. Ja jums ir vairāk nekā viens serveris, tas prasa daudz laika. Tas nav droši: izstrādātājs piekļūst serverim, kur viņam nevajadzētu būt.
DevOps prasa centralizētu žurnālu vākšanu, apstrādi un analīzi.
Tēma Nr. 10: Lietojumprogrammas žurnāla ierakstīšana ar ELK
- Galvenie elastīgo pielietojumi un iespējas (meklēšana, glabāšana, mērogošanas iezīmes, konfigurācijas elastība)
- Kibana pārskats (galvenās iespējas, vaicājumu valoda, vadības paneļu pārvaldība, grafiku izveide)
- Elastīgo produktu pārskats un to pielietojums
- Metrikas vākšana APM (lietošanas uzraudzība)
- Papildus: jaunā produkta — SIEM pārskats
Šī pieeja padarīs žurnālus par vienkāršu un saprotamu rīku analīzei, konfigurēšanai un pielāgošanai lietotnei un infrastruktūrai.
SRE
Un mēs nonākam pie tēmas, uz kuru Southbridge tikai skatās un kuras dēļ citi runātāji vēlas palikt uz pēdējo Slērmu dienu. Mēs esam priecīgi, ka to piekrita lasīt Ivans Kruglovs no Booking.com.
Projekts dzīvo reālajā pasaulē, kur uzticamība nekad nav absolūta, un katra lēmuma pieņemšana maksā naudu.
Kas ir SLA attiecībā uz sarežģītu projektu? Teiksim, kā novērtēt, ka mājas lapa ir pieejama, bet attēli ielādējas ar kavēšanos. Kādi ir SLA rādītāji, kur tos ņemt, kā tos ņemt?
Kā izveidot SLA? Kā tos izpildīt?
Tēma №11: SRE
SLA, SLO, Error Budget definīcija un citi biedējošie termini no SRE pasaules
SRE: SLI un SLO uzraudzības prakse
SRE: Error Budget pielietošanas prakse
SRE: Pārtraukumu un operatīvās slodzes pārvaldība (apigateway, pakalpojumu tīklveids, circuit brackers)
Bizness vēlas SRE. Pat elementārā līmenī: ņemt rezerves serveri vai atjaunot no dublējuma? Viena datubāze vai klasteris? Uzstādīt DDoS aizsardzību preventīvi vai tikai uzbrukuma brīdī?
Vadītājam neapmierinās stāstījums, ka «mājas lapa darbojās», kad viņam piezvana klients un ziņo, ka pasūtījuma forma neizvērtas.
Tāpēc DevOps inženierim ir svarīgi vismaz virspusēji saprast SRE, lai adekvāti runātu ar biznesu par tā vajadzībām.
Rezultāts
Laikā administratori un izstrādātāji iemācīsies:
— pareizi strādāt ar Git;
— organizēt vietējo izstrādi;
— konfigurēt (administratori) un izmantot (izstrādātāji) CI/CD;
— strādāt ar infrastruktūru kā ar kodu;
— testēt infrastruktūru;
— uzraudzīt infrastruktūru un lietotni;
— konfigurēt žurnālu veidošanu;
— saprast, bet ideālā gadījumā — izmantot SRE.
Uzmanīgiem lasītājiem — ar promo kodu habrapost atlaide 15%.
Visās jomās mēs sagatavojam praksi un rīkus. Tādēļ katrs dalībnieks, atgriežoties no Sļērma, varēs paaugstināt savas kompānijas DevOps līmeni.
Biznesam tas nozīmē samazināt administrēšanas un izstrādes izmaksas, samazināt dīkstāves, palielināt uzticamību, ātrāku funkciju piegādi un kļūdu novēršanu.
Avots: habr.com
