Slurm DevOps: fra Git til SRE med alle stoppene

4-6 september i Saint Petersburg, i konferansesalen til Selectel, vil det bli en tre-dagers Slurm DevOps.

Vi har bygget programmet med tanke på at teoretiske arbeider om DevOps, akkurat som manualer for verktøy, kan leses av alle på egen hånd. Det som er interessant er erfaring og praksis: forklaringer på hva man bør og ikke bør gjøre, samt hvordan vi gjør det.

I hvert selskap, hos hver administrator eller utvikler, finnes det et bestemt nivå av DevOps. Noen bruker Git feil, mens andre implementerer SRE. Kurset er organisert slik at alle finner noe relevant som kan implementeres her og nå.

Vi begynner med Git, ser deretter på applikasjonsutvikling, samspillet mellom kode og infrastruktur, bygger CI/CD, beskriver infrastruktur som kode (IaC), tester den resulterende løsningen, setter opp overvåkning, samler inn og analyserer logger, og til slutt kommer vi til SRE: vi gjør pålitelighet til en målbar og håndterbar historie.

Git

Nå er det bare de som kjøpte sin første laptop i går som ikke bruker Git. Det er et trivielt og allestedsnærværende verktøy, og likevel møter vi ofte feil bruk: fra å tvinge push til master til å kopiere filer fra Git til serveren med Ctrl-C, Ctrl-V.

Vi forklarer hva man ikke skal gjøre, hva man skal gjøre, og hvordan de gjør det i Southbridge.
Vi går gjennom praksis: grunnleggende Git, samarbeid i team.

Tema 1: Grunnleggende arbeid med Git

• Grunnleggende git-kommandoer: init, commit, add, diff, log, status, pull, push
• Git flow, grener og etiketter, strategier for sammenslåing
• Jobb med flere remote repositorier

Tema 2: Teamarbeid med Git

• GitHub flow
• Fork, remote, pull request
• Konflikter, utgivelser, mer om Gitflow og andre flow i forhold til team

Materialet er organisert slik at administratorer og utviklere umiddelbart kan implementere alle praksiser i arbeidet.

Fra et DevOps-perspektiv organiserer riktig bruk av Git og automatiserer utviklings- og administrasjonsprosesser, eliminerer en rekke gjentagende problemer, og øker arbeidsproduktiviteten.

DevOps utvikler

Vi ser på DevOps fra en utviklers synspunkt: starter et lokalt miljø, skriver applikasjonen, setter opp overvåkning og logging, tester den lokalt, organiserer lagring av variabler/secrets og service discovery, ser på tracing (opentracing).

Tema 3: Arbeid med applikasjonen fra utviklingsperspektiv

• Innstilling av lokalt miljø: praktiske anbefalinger
• Vi skriver en mikrotjeneste på Python (inkludert tester)
• Bruken av docker-compose i utviklingen

Tema nr. 4: Samhandling mellom kode og infrastruktur

• Praktisk arbeid med konfigurasjoner

Utviklere vil se hvordan koden skal sende logger, hvordan den skal testes, og hvordan den senere vil bli feilsøkt. Administratorer forstår utviklernes behov: hvilke feil som kan oppstå i koden, hvordan organisere testing for utviklerne, hvordan teste prosjektet selv.

I dette trinnet løses hovedoppgaven innen DevOps: kommunikasjon og samarbeid mellom utviklere og driftsavdelingen etableres. Dette er et nøkkeltrinn for å gå fra å kaste oppgaver til ansvarlig samarbeid.

Som et resultat øker hastigheten og kvaliteten på arbeidet.

CI/CD

Moderne automatisering innebærer CI/CD. Vi begynner med å se på manuell automatisering: makefiler, git hooks, skript. Vi vil analysere når disse verktøyene fortsatt er relevante, og når de ikke bør brukes.

Deretter ser vi på beste praksis innen moderne CI med eksempler fra Gitlab.

Tema nr. 5: CI/CD introduksjon til automatisering

• Introduksjon til automatisering
• Verktøy (bash, make, gradle)
• Bruken av git-hjul for automatisering av prosesser
• Fabrikklinjer for bygging og deres anvendelse i IT
• Eksempel på oppbygging av en 'felles' pipeline
• Moderne programvare for CI/CD: Drone CI, BitBucket Pipelines, Travis osv.

Tema nr. 6: CI/CD: Arbeide med Gitlab

• Gitlab CI - generell informasjon
• Gitlab Runner, deres typer og anvendelse
• Gitlab CI, innstillinger, beste praksis
• Faser i Gitlab CI
• Gitlab CI-variabler
• Bygging, testing, distribusjon
• Kontroll og begrensninger i kjøringen: only, when
• Arbeide med artefakter
• Malene i .gitlab-ci.yml, gjenbruk av handlinger på forskjellige deler av pipelinen
• Include - seksjoner
• Sentralisert styring av gitlab-ci.yml (ett fil og automatiske push til andre repositoryer)

Samarbeidet mellom administratorer og utviklere når et nytt nivå: administratoren lager CI-malen, og utviklerne redigerer den, og bygger sin CI uavhengig av administratoren.

Utviklernes avhengighet av administratorene reduseres, mengden manuelt arbeid minsker, og problemet med 'den eneste personen som vet hvordan man arbeider med make-filen' forsvinner. Utrullinger skjer pålitelig og raskt.

IaC

Temaen om Infrastruktur som Kode vil bli presentert av skyadministrator i Selectel, Alexey Stepanenko. Han vil vise hvordan man raskt og automatisk kan sette opp og skalere servere, hvordan man automatisk pakker bilder, og hvordan man bruker konfigurasjonsmaler for å få ferdig konfigurerte maskiner umiddelbart.

Mannen som har laget tusenvis av IaC-løsninger, vil fortelle hvordan man gjør det riktig og hvordan man unngår feil.

Løsningen for Selectel-skyen, med minimalt med tilpasninger, passer for både Google- og Amazon-skyene.

Ansatt i Southbridge, Nikolay Mesropyan, vil bruke Ansible for å vise hvordan man kan lansere en fungerende applikasjon uten nedetid og sjekke dens funksjonalitet.

Hvis du endrer infrastrukturen manuelt (konfigurerer servere, installerer biblioteker og pakker etter behov), må du huske og gjenskape alle handlingene dine når du prøver å opprette en kopi av miljøet. Denne oppgaven tar lett mellom 3-5 dager. Å jobbe med infrastruktur som kode sikrer at du har en aktuell beskrivelse av miljøet som kan settes opp på minutter.

Nikolay vil fortelle hvordan man skriver spillbøker, hvilke feil som kan oppstå, og hvorfor spillbøker noen ganger fungerer sakte eller ikke som forventet. Dette er erfaringen fra mange års bruk av IaC i Southbridge.

Tema nr. 7: Infrastruktur som Kode

• IaC: tilnærming til infrastruktur som kode
• Skytilbydere som infrastrukturleverandører
• Verktøy for systeminitiering, bildebygging (packer)
• IaC med Terraform som eksempel
• Lagring av konfigurasjoner, samarbeid, automatisering av applikasjoner
• Praksis i å lage Ansible-playbooks
• Idempotens, deklarativitet
• IaC med Ansible som eksempel
• Database som Kode / Feiltoleranse for PostgreSQL

Infrastrukturen får deklarativitet og idempotens.
Administrator lærer å håndtere komplisert infrastruktur: raskt opprette nye miljøer, opprettholde konsistens mellom alle miljøer, se endringshistorikk, noe som er kritisk når flere team jobber på prosjektet.
Utvikler kan studere infrastrukturen og selv sette opp sine egne miljøer.

Boni til delen — oppretting og konfigurering av et feiltolerant PostgreSQL-databaserkluster. Vi gir deg en ferdig spillbok som vi bruker i Southbridge, du vil sette opp et kluster på læringsplattformen og kan bruke denne løsningen i din egen bedrift.

Testing av infrastrukturen og overvåking

Automatisering gjør at du kan rulle ut en feil med en gang til tusen servere. Hver gang det gjøres en endring, er testing nødvendig. På den annen side tar manuell testing så mye tid at den kansellerer fordelene med automatisering.

Vi vil vise i praksis hvordan man skriver rollestesting. Som resultat vil du være i stand til å skrive tester for ditt selskap. Du trenger ikke lenger å huske innstillingene som er gjort, du beskriver dem i testene og sjekker automatisk at alle tidligere løsninger og midlertidige tiltak er på plass.

Deretter skal vi lære å automatisk legge til alle nye servere i overvåkningen. Vi vil se nærmere på overvåkning av infrastruktur og applikasjoner. Vi viser dårlige og gode praksiser.

Tema nr. 8: Overvåking av infrastruktur

• Testing og kontinuerlig integrasjon med Molecule og Gitlab CI
• Bruk av Vagrant

Tema nr. 9: Overvåking av infrastruktur med Prometheus

• Hvorfor er overvåking nødvendig
• Typer overvåking
• Varsler i overvåkningssystemet
• Hvordan bygge et sunt overvåkingssystem
• Menneskelig lesbare varsler for alle
• Health Check: hva du bør være oppmerksom på
• Automatisering basert på data fra overvåking

Feilaktig fungerende overvåking er ingen overvåking. Virksomheten bryr seg ikke om forsiden av nettbutikken er tilgjengelig, hvis betalingsskjemaet gir feil.

Både utviklere og administratorer er involvert i innstilling av overvåking og feilsøking likt. Tradisjonelt faller overvåkingsoppgavene på administratorene. Vår kurs vil vise utviklerne hvilken rolle de spiller i å lage effektiv overvåking. Administratorene vil motta beste praksis fra Southbridge. Som et resultat vil antallet tap forårsaket av nedetid og forsinkelser på nettsteder eller applikasjoner raskt synke.

Bonus for seksjonen: automatisering basert på overvåking. For eksempel rapporterer overvåkningen at det har vært en økning i trafikk på nettstedet, og skalering av webserverne aktiveres automatisk.

Logging

Hovedfeilen i arbeid med logger er at administratorer og utviklere ser på dem direkte på serverne. Hvis du har mer enn én server, tar det tid. Det er usikkert: utvikleren går inn på serveren der han ikke bør være.

DevOps krever sentralisert innsamling, behandling og analyse av logger.

Tema nr. 10: Logging av applikasjoner med ELK

• Hovedanvendelser og funksjoner til elastic (søk, lagring, skaleringsfunksjoner, fleksibilitet i innstillinger)
• Oversikt over kibana (hovedfunksjoner, spørrespråk, dashboardadministrasjon, lage diagrammer)
• Oversikt over produkter basert på elastic og deres anvendelse
• Vi samler inn metrikker i APM (applikasjonstracing)
• I tillegg: Oversikt over det nye produktet — SIEM

Implementeringen av denne tilnærmingen vil gjøre logger til et enkelt og forståelig verktøy for analyse, konfigurasjon og justering av applikasjonen og infrastrukturen.

SRE

Og vi kommer til emnet som Southbridge bare ser på, og som andre talere ønsker å bli til den siste dagen av Slørrma. Vi er glade for at Ivan Kruglov fra Booking.com har sagt ja til å lese dette.

Prosjektet lever i den virkelige verden, hvor pålitelighet aldri er absolutt, og hver avgjørelse koster penger.

Hva er SLA i forhold til et komplekst prosjekt? La oss si, hvordan vurderer man at nettstedet er tilgjengelig, men bildene laster med forsinkelse. Hva er SLA-metrikkene, hvor henter man dem, hvordan samler man inn dataene?

Hvordan sette opp SLA? Hvordan holde dem?

Tema nr. 11: SRE
Definisjon av SLA, SLO, Error Budget og andre skremmende begreper fra SRE-verdenen
SRE: Praksis for overvåking av SLI og SLO
SRE: Praksis for bruk av Error Budget
SRE: Håndtering av avbrudd og driftsbelastning (apigateway, service mesh, circuit breakers)
Bedriften ønsker SRE. I det minste på det enkleste nivået: bruke en backup-server eller gjenopprette fra backup? En database eller et klynge? Installere DDoS-beskyttelse preventivt eller kun i angrepets øyeblikk?

Direktøren blir ikke fornøyd med å høre at "nettsiden fungerer", når han får et anrop fra en kunde som forteller at bestillingsskjemaet ikke åpner seg.

Derfor er det viktig for DevOps-ingeniøren å forstå SRE i det minste overfladisk, for å kunne snakke riktig med virksomheten om dens behov.

Resultat

I løpet av Slørrma DevOps administratoren og utviklerne vil lære:
— å jobbe riktig med Git;
— organisere lokal utvikling;
— sette opp (administratorer) og bruke (utviklere) CI/CD;
— jobbe med infrastruktur som kode;
— teste infrastrukturen;
— overvåke infrastruktur og applikasjon;
— sette opp logging;
— forstå, og ideelt sett — bruke SRE.

For oppmerksomme lesere — med rabattkoden habrapost får du 15% avslag.

Vi forbereder praksis og verktøy for alle punkter. Så hver deltaker kan ta sin bedrift til neste nivå av DevOps når de kommer tilbake fra Slørrma.

For virksomheten betyr dette en reduksjon i administrasjons- og utviklingskostnader, mindre nedetid, økt pålitelighet, raskere levering av funksjoner og feilretting.

Kilde: habr.com