Slørm DevOps: fra Git til SRE med alle stop

4.-6. september i Sankt Petersborg, i konferencelokalet Selectel, afholdes en tre-dages Slørm DevOps.

Vi har bygget programmet med tanken om, at teoretiske værker om DevOps, ligesom manualer til værktøjer, kan læses selv. Det interessante er kun erfaring og praksis: forklaringen på, hvordan man skal og ikke skal gøre, samt historien om, hvordan vi gør.

I hver virksomhed har hver administrator eller udvikler sit eget niveau af DevOps. Nogle bruger Git forkert, andre implementerer SRE. Kurset er organiseret således, at alle kan finde noget relevant, der kan implementeres her og nu.

Vi starter med Git, ser derefter på applikationsudvikling, interaktionen mellem kode og infrastruktur, opbygger CI/CD, beskriver infrastruktur som kode (IaC), tester den fremkomne løsning, sætter overvågning op, samler og studerer logfiler, og til sidst når vi til SRE: gør pålidelighed til en målbar og håndterbar historie.

Git

Lige nu er der kun dem, der brugte deres første bærbare computer i går, der ikke bruger Git. Det er et trivielt og udbredt værktøj, og alligevel støder vi ofte på dets forkerte brug: fra at tvinge push til master til at kopiere filer fra Git til serveren via Ctrl-C, Ctrl-V.

Vi fortæller, hvordan man ikke skal gøre, hvordan man skal gøre, og hvordan de gør i Southbridge.
Vi gennemgår praktiske aspekter: grundlæggende Git, teamarbejde.

Emne nr. 1: Grundlæggende arbejde med Git

• Grundlæggende kommandoer git init, commit, add, diff, log, status, pull, push
• Git flow, grene og tags, strategier for merge
• Arbejder med flere remote repo

Emne nr. 2: Teamarbejde med Git

• GitHub flow
• Fork, remote, pull request
• Konflikter, versioner, endnu engang om Gitflow og andre flows i relation til teams

Materialet er organiseret, så administratorer og udviklere straks kan implementere alle praksisser i deres arbejde.

Set fra DevOps-synspunkt organiserer korrekt arbejde med Git og automatiserer udviklings- og administrationsprocesserne, eliminerer en række gentagne problemer og øger produktiviteten.

DevOps udvikler

Vi ser på DevOps gennem udviklerens øjne: vi sætter et lokalt miljø op, skriver en applikation, konfigurerer dens overvågning og logning, tester den lokalt, organiserer opbevaring af variabler/hemmeligheder og service discovery, ser på tracing (opentracing).

Emne nr. 3: Arbejde med applikationen set fra udviklingsperspektivet

• Opsætning af lokalt miljø: praksisråd
• Vi skriver en mikroservice i Python (inklusive tests)
• Anvendelse af docker-compose i udviklingen

Tema nr. 4: Interaktion mellem kode og infrastruktur

• Praksis med konfigurationer

Som resultat vil udviklerne se, hvordan koden skal sende logs, hvordan den skal testes, og hvordan den senere vil blive debugget. Administratorer vil forstå udviklernes behov: hvilke fejl i koden, der kan opstå, hvordan man organiserer tests for udviklerne, og hvordan man selv tester projektet.

På dette tidspunkt løses hovedopgaven for DevOps: der etableres gensidig forståelse og samarbejde mellem udviklere og operations. Dette er et nøgleskridt i overgangen fra at kaste opgaver til ansvarlig interaktion.

Som følge heraf stiger hastigheden og kvaliteten af arbejdet.

CI/CD

Moderne automatisering indebærer CI/CD. Vi starter med at se på manuel automatisering: make-filer, git-hooks, scripts. Vi vil afdække, hvornår disse værktøjer stadig er relevante, og hvornår de ikke bør bruges.

Derefter ser vi på de bedste praksisser for moderne CI med eksemplet Gitlab.

Tema nr. 5: CI/CD introduktion til automatisering

• Introduktion til automatisering
• Værktøjer (bash, make, gradle)
• Brug af git-hooks til at automatisere processer
• Fabriks samlebånd og deres anvendelse i IT
• Eksempel på opbygning af 'fælles' pipeline
• Moderne software til CI/CD: Drone CI, BitBucket Pipelines, Travis mv.

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

• Gitlab CI - overordnet
• Gitlab Runner, deres typer og anvendelse
• Gitlab CI, konfigurationsmuligheder, bedste praksisser
• Faser i Gitlab CI
• Gitlab CI-variabler
• Bygning, test, deployment
• Kontrol og begrænsninger af udførelsen: only, when
• Arbejdet med artefakter
• Skabeloner indenfor .gitlab-ci.yml, genbrug af handlinger på forskellige områder af pipelinen
• Include - sektioner
• Centraliseret styring af gitlab-ci.yml (én fil og automatiske push til andre repositories)

Samarbejdet mellem administratorer og udviklere når et nyt niveau: administratoren skriver CI-skabelonen, mens udviklerne retter den, så de kan opbygge deres CI uafhængigt af administratoren.

Afhængigheden mellem udviklere og administratorer mindskes, mængden af manuelt arbejde reduceres, og problemet med 'den eneste person, der ved, hvordan man arbejder med make-filen', forsvinder. Udrulninger sker pålideligt og hurtigt.

IaC

Emnet for Infrastructure as Code med eksemplet Terraform præsenteres af skyadministrator Alexey Stepanenko fra Selectel. Han vil vise, hvordan man hurtigt og automatisk kan implementere og skalere servere, hvordan man automatisk pakker billeder, og hvordan man bruger konfigurationsskabeloner til straks at få konfigurerede maskiner.

Manden, der har lavet tusindvis af IaC-løsninger, vil fortælle, hvordan man gør det rigtigt, og hvordan man ikke bør gøre det.

Løsningen for Selectel Cloud, med minimalt behov for ændringer, er velegnet til Google og Amazon clouds.

Medarbejderen Nikolai Mesropyan fra Southbridge vil ved hjælp af Ansible vise, hvordan man kan implementere en fungerende applikation uden nedetid og teste dens funktionalitet.

Hvis du håndterer infrastrukturen manuelt (konfigurerer servere, installerer biblioteker og pakker efter behov), skal du huske og reproducere alle dine handlinger, når du forsøger at rejse en kopi af miljøet. Denne opgave kan let tage 3-5 dage. At arbejde med infrastruktur som kode garanterer, at du har en opdateret beskrivelse af miljøet, som kan implementeres på få minutter.

Nikolai vil fortælle, hvordan man skriver playbooks, hvilke fejl der kan opstå, og hvorfor playbooks sommetider kører langsomt eller ikke fungerer som forventet. Dette er erfaring fra mange års brug af IaC i Southbridge.

Emne nr. 7: Infrastructure as Code

• IaC: tilgang til infrastruktur som kode
• Cloududbydere som infrastrukturnudbydere
• Systeminitieringsværktøjer, opbygning af billeder (packer)
• IaC med eksemplet Terraform
• Opbevaring af konfigurationer, samarbejde, automatisering af implementeringer
• Praktik i oprettelse af Ansible playbooks
• Idempotens, deklarativitet
• IaC med eksemplet Ansible
• Database as a Code / Failover for PostgreSQL

Infrastrukturen opnår deklarativitet og idempotens.
Administratoren lærer at håndtere kompleks infrastruktur: hurtigt skabe nye miljøer, opretholde ensartethed i alle miljøer, se ændringshistorikken, hvilket er kritisk, når flere teams arbejder på projektet.
Udvikleren kan studere infrastrukturen og selv implementere sine egne miljøer.

Bonus i sektionen — oprettelse og konfiguration af en failover-databaseklynge for PostgreSQL. Vi vil give en klar playbook, som vi bruger i Southbridge, så du kan implementere en klynge i dit træningsmiljø og bruge denne løsning i din virksomhed.

Testning af infrastruktur og overvågning

Automatisering gør det muligt at udrulle en fejl til tusind servere på én gang. Hver ændring kræver test. På den anden side tager manuel test så meget tid, at det underminerer fordelene ved automatisering.

Vi vil vise, hvordan man skriver tests for roller i praksis. Som resultat vil du kunne skrive tests for dit firma. Du behøver ikke længere at huske de indstillinger, du har lavet, men beskrive dem i tests og automatisk kontrollere, at alle tidligere løsninger og patches er på plads.

Derefter vil vi lære at tilføje alle nye servere til overvågning automatisk. Vi vil se separat på overvågning af infrastruktur og applikationer. Vi viser både dårlige og gode praksisser.

Emne nr. 8: Test af infrastruktur

• Test og kontinuerlig integration med Molecule og Gitlab CI
• Anvendelse af Vagrant

Emne nr. 9: Overvågning af infrastruktur med Prometheus

• Hvorfor er overvågning nødvendig?
• Typer af overvågning
• Underretninger i overvågningssystemet
• Hvordan man bygger et sundt overvågningssystem
• Menneskevenlige underretninger til alle
• Health Check: hvad man skal være opmærksom på
• Automatisering baseret på data fra overvågning

En overvågning, der ikke fungerer korrekt, betyder ingen overvågning. Virksomheden er ligeglad med, at hovedsiden af webshoppen er tilgængelig, hvis betalingsformularen giver en fejl.

I opsætningen af overvågning og fejlfinding deltager udviklere og administratorer på lige fod. Traditionelt hviler overvågningsopgaver dog på administratorernes skuldre. Vores kursus vil vise udviklere, hvilken rolle de spiller i at skabe effektiv overvågning. Administratorerne vil få de bedste praksisser fra Southbridge. Som følge heraf vil mængden af tab forårsaget af nedbrud og forsinkelser på siden eller applikationen hurtigt falde.

Bonusafsnit: automatisering baseret på overvågning. For eksempel, hvis overvågningen rapporterer, at der er kommet belastning på hjemmesiden, startes skalering af webserverne automatisk.

Logføring

Den primære fejl i arbejdet med logfiler er, at administratorer og udviklere ser dem direkte på serverne. Hvis du har mere end én server, tager det tid. Det er usikkert: udvikleren logger ind på en server, hvor han ikke skal være.

DevOps kræver centraliseret indsamling, behandling og analyse af logs.

Emne nr. 10: Logføring af applikationer med ELK

• Hovedanvendelser og muligheder for elastic (søgetjeneste, opbevaring, skaleringsfunktioner, fleksibilitet i konfiguration)
• Oversigt over kibana (hovedfunktioner, forespørgselssprog, dashboardstyring, oprettelse af diagrammer)
• Oversigt over produkter baseret på elastic og deres anvendelse
• Indsamling af metrics i APM (applikationstracing)
• Yderligere: Oversigt over det nye produkt — SIEM

Implementeringen af denne tilgang vil gøre logfiler til et simpelt og forståeligt værktøj til analyse, konfiguration og justering af applikationen og infrastrukturen.

SRE

Og vi når frem til emnet, som Southbridge kun kigger på, og som andre talere ønsker at forblive til den sidste dag af Slyrma. Vi er glade for, at Ivan Kruglov fra Booking.com har sagt ja til at tale om det.

Projektet lever i den virkelige verden, hvor pålidelighed aldrig er absolut, og hver beslutning koster penge.

Hvad er SLA i forhold til komplekse projekter? Lad os sige, hvordan vi vurderer, at hjemmesiden er tilgængelig, men billederne indlæses med forsinkelse. Hvad er SLA-metrics, hvor skal de indsamles, hvordan skal de indsamles?

Hvordan etablerer man SLA? Hvordan overholder man dem?

Emne nr. 11: SRE
Definition af SLA, SLO, Error Budget og andre skræmmende termer fra SRE-verdenen
SRE: Praksis med at overvåge SLI og SLO
SRE: Praksis med at anvende Error Budget
SRE: Håndtering af afbrydelser og driftsbelastning (apigateway, service mesh, circuit breakers)
Virksomheden ønsker SRE. I det mindste på det mest grundlæggende niveau: tage en backup-server eller genskabe fra backup? En database eller klynge? Anvende beskyttelse mod DDoS før angreb eller kun i tilfælde af angreb?

Direktører bliver ikke tilfredse med at høre, at "hjemmesiden fungerer", når kunden ringer og siger, at ordren ikke åbnes.

Derfor er det vigtigt for DevOps-ingeniøreren at forstå SRE på mindst et grundlæggende niveau for effektivt at kunne tale med virksomheden om dens behov.

Resultat

I løbet af Slyrma DevOps vil administratorer og udviklere lære:
— at arbejde korrekt med Git;
— at organisere lokal udvikling;
— at konfigurere (administratorer) og bruge (udviklere) CI/CD;
— at arbejde med infrastruktur som kode;
— at teste infrastruktur;
— at overvåge infrastruktur og applikation;
— at konfigurere logning;
— at forstå, og ideelt set — bruge SRE.

For de opmærksomme læsere — med rabatkoden habrapost får man 15% rabat.

For alle punkter forbereder vi praksis og værktøjer. På den måde kan hver deltager, når de vender tilbage fra Slørm, tage deres virksomhed til næste niveau inden for DevOps.

For virksomheder betyder det billigere administration og udvikling, mindre nedetid, øget pålidelighed, hurtigere levering af funktioner og oprettelse af fejl.

Kilde: habr.com