Slöerm DevOps: från Git till SRE med alla stopp

4-6 september i Sankt Petersburg, i konferenssalen Selectel, kommer det att hållas en tre dagar lång Slöerm DevOps.

Vi har byggt programmet med tanken att teoretiska verk inom DevOps, liksom manualer för verktyg, kan läsas av var och en på egen hand. Det som är intressant är bara erfarenhet och praktik: förklaringar om hur man ska göra och inte göra, samt berättelser om hur vi gör.

I varje företag, hos varje administratör eller utvecklare finns det en egen nivå av DevOps. Vissa använder Git felaktigt, andra implementerar SRE. Kursen är organiserad så att varje deltagare hittar något relevant som kan implementeras här och nu.

Vi börjar med Git, ser sedan på applikationsutveckling, samverkan mellan kod och infrastruktur, bygger CI/CD, beskriver infrastruktur som kod (IaC), testar den resulterande lösningen, sätter upp övervakning, samlar in och analyserar loggar, och i slutet når vi fram till SRE: vi förvandlar pålitlighet till en mätbar och hanterbar historia.

Git

Just nu är det bara de som köpte sin första laptop igår som inte använder Git. Det är ett trivialt och allmänt verktyg, och ändå stöter vi ofta på dess felaktiga användning: från att tvinga push i master till att kopiera filer från Git till servern via Ctrl-C, Ctrl-V.

Vi berättar hur man inte ska göra, hur man ska göra, hur man gör i Southbridge.
Vi går igenom praktiken: grunderna i Git, teamarbete.

Ämne nr 1: Grunderna i att arbeta med Git

• Grundläggande kommandon git init, commit, add, diff, log, status, pull, push
• Git flow, grenar och taggar, sammanslagningsstrategier
• Arbete med flera remote repo

Ämne nr 2: Teamarbete med Git

• GitHub flow
• Fork, remote, pull request
• Konflikter, releaser, en gång till om Gitflow och andra flöden som gäller team

Materialet är organiserat så att administratörer och utvecklare omedelbart kan implementera alla praktiker i sitt arbete.

Ur ett DevOps-perspektiv strukturerar och automatiserar korrekt arbete med Git utvecklings- och administrationsprocesser, utesluter ett antal återkommande problem och ökar produktiviteten.

DevOps-utvecklare

Vi ser på DevOps genom en utvecklares ögon: sätter igång en lokal miljö, skriver applikationen, ställer in övervakning och loggning, testar lokalt, organiserar lagring av variabler/hemligheter och service discovery, ser på spårning (opentracing).

Ämne nr 3: Att arbeta med applikationen ur utvecklarens perspektiv

• Inställning av lokal miljö: praktiska rekommendationer
• Vi skriver en mikrotjänst i Python (inklusive tester)
• Användning av docker-compose i utveckling

Ämne nr 4: Interaktionen mellan kod och infrastruktur

• Praktik för arbete med konfigurationer

Som resultat kommer utvecklarna att se hur koden ska skicka loggar, hur den ska testas, och hur den kommer att debuggas framöver. Administratörerna kommer att förstå utvecklarnas behov: vilka fel som kan uppstå i koden, hur man organiserar tester för utvecklarna och hur man själv testar projektet.

I detta skede löser man den huvudsakliga uppgiften för DevOps: man etablerar ömsesidig förståelse och samarbete mellan dev och ops. Detta är ett nyckelsteg mot att gå från ett utbyta av uppgifter till ett ansvarigt samarbete.

Som ett resultat ökar hastigheten och kvaliteten på arbetet.

CI/CD

Modern automatisering innebär CI/CD. Vi börjar med att titta på manuell automatisering: makefiler, git hooks, skript. Vi går igenom när dessa verktyg fortfarande är aktuella och när de inte bör användas.

Sedan ser vi på de bästa metoderna för modern CI med exempel från Gitlab.

Ämne nr 5: CI/CD introduktion till automatisering

• Introduktion till automatisering
• Verktyg (bash, make, gradle)
• Användning av git-hooks för att automatisera processer
• Fabriksbaserade konveyorlinjer och deras tillämpning inom IT
• Exempel på att bygga en "gemensam" pipeline
• Modern mjukvara för CI/CD: Drone CI, BitBucket Pipelines, Travis m.fl.

Ämne nr 6: CI/CD: Arbeta med Gitlab

• Gitlab CI - översikt
• Gitlab Runner, deras typer och tillämpning
• Gitlab CI, konfigurationsspecifika egenskaper, bästa metoder
• Steg i Gitlab CI
• Gitlab CI-variabler
• Bygg, testning, distribution
• Kontroll och begränsningar av körning: only, when
• Arbete med artefakter
• Mallar inuti .gitlab-ci.yml, återanvändning av åtgärder på olika delar av pipelinen
• Include - sektioner
• Centraliserad hantering av gitlab-ci.yml (en fil och automatiska pushar till andra repor)

Samarbetet mellan administratörer och utvecklare når en ny nivå: administratören skriver CI-mall, och utvecklarna justerar det, vilket bygger sin CI oberoende av administratören.

Beroendet av utvecklarna minskar från administratörerna, antalet manuella uppgifter minskar, och problemet med den "enda personen som vet hur man arbetar med make-filen" försvinner. Utrullningar sker pålitligt och snabbt.

IaC

Tema för Infrastructure as Code med exempel från Terraform kommer att presenteras av cloud-administratören på Selectel, Alexey Stepanenko. Han kommer att visa hur man snabbt och automatiskt kan installera och skala servrar, hur man automatiskt paketerar bilder, samt hur man använder konfigurationsmallar för att direkt få färdiga maskiner.

En person som har skapat tusentals IaC-lösningar kommer att berätta om hur man gör det på rätt sätt och hur man inte ska göra det.

Lösningen för cloud Selectel, med minimala justeringar, är lämplig för Google- och Amazon-moln.

Medarbetaren från Southbridge, Nikolay Mesropyan, kommer att visa hur man utan nedtid kan installera en fungerande applikation med Ansible och kontrollera dess funktionalitet.

Om du manuellt ändrar infrastrukturen (konfigurerar servrar, installerar bibliotek och paket vid behov), måste du när du försöker återuppbygga en kopia av miljön minnas och reproducera alla dina åtgärder. Denna uppgift kan lätt ta 3-5 dagar. Att arbeta med infrastrukturen som kod garanterar att du har en aktuell beskrivning av miljön som kan installeras på minuter.

Nikolay kommer att berätta hur man skriver playbooks, vilka misstag som förekommer och varför playbooks ibland arbetar långsamt eller inte fungerar som förväntat. Detta är erfarenheten från många års användning av IaC i Southbridge.

Ämne Nr 7: Infrastructure as Code

• IaC: tillvägagångssätt för att betrakta infrastruktur som kod
• Molnleverantörer som infrastrukturleverantörer
• Systeminitialiseringsverktyg, bildbyggande (packer)
• IaC med exempel från Terraform
• Lagring av konfigurationer, samarbete, automatisering av tillämpningar
• Praktik för att skapa Ansible-playbooks
• Idempotens, deklarativitet
• IaC med exempel från Ansible
• Database as Code / Fjädringsbarhet för PostgreSQL

Infrastrukturen får deklarativitet och idempotens.
Administratören lär sig att hantera en komplex infrastruktur: snabbt skapa nya miljöer, upprätthålla enhetlighet mellan alla miljöer, se ändringshistorik, vilket är kritiskt när flera team arbetar på projektet.
Utvecklaren kan studera infrastrukturen och självständigt installera sina egna miljöer.

Bonus avsnittet — skapandet och inställningen av en fjädringsbar databascluster för PostgreSQL. Vi kommer att ge dig en färdig playbook som vi använder i Southbridge, och du kommer att kunna installera en cluster på en utbildningsmiljö och använda denna lösning i ditt företag.

Testning av infrastrukturen och övervakning

Automatisering möjliggör att felsöka problem omedelbart på tusentals servrar. Varje ändring kräver testning. Å andra sidan tar manuell testning så mycket tid att det urholkar fördelarna med automatisering.

Vi visar i praktiken hur man skriver rolltester. Som resultat kommer du att kunna skriva tester för ditt företag. Du behöver inte längre komma ihåg inställningar som gjorts, du beskriver dem i testerna och kontrollerar automatiskt att alla tidigare lösningar och tillfälliga lösningar fortfarande är på plats.

Sedan lär vi oss att automatiskt lägga till alla nya servrar i övervakningen. Vi kommer att titta på övervakning av infrastruktur och applikationer separat. Vi visar dåliga och bra metoder.

Ämne nr 8: Testning av infrastruktur

• Testning och kontinuerlig integration med Molecule och Gitlab CI
• Användning av Vagrant

Ämne nr 9: Övervakning av infrastruktur med Prometheus

• Varför behövs övervakning
• Typer av övervakning
• Notifieringar i övervakningssystemet
• Hur man bygger ett hälsosamt övervakningssystem
• Människovänliga notifieringar för alla
• Health Check: Vad man bör ha i åtanke
• Automatisering baserat på data från övervakningen

Felaktig övervakning är liktydigt med avsaknad av övervakning. Företaget bryr sig inte om att startsidan för e-handelsbutiken är tillgänglig om betalningsformuläret ger ett felmeddelande.

I inställningen av övervakning och problemlösning deltar utvecklare och administratörer på lika villkor. Traditionellt åvilar övervakningsuppgifterna administratörerna. Vår kurs kommer att visa utvecklarna vilken roll de spelar i att skapa effektiv övervakning. Administratörer kommer att få bästa praxis från Southbridge. Som resultat kommer mängden förluster orsakade av driftstopp och lägre prestanda för webbplatsen eller applikationen snabbt att minska.

Bonusavsnitt: automatisering baserad på övervakning. Till exempel meddelar övervakningen att belastning har kommit till webbplatsen, och skalning av webbservrar sätts igång automatiskt.

Loggning

Det största misstaget när det gäller loggar är att administratörer och utvecklare tittar på dem direkt på servrarna. Om du har mer än en server tar det tid. Det är osäkert: utvecklaren går in på en server där han inte bör vara.

DevOps kräver centraliserad insamling, bearbetning och analys av loggar.

Ämne nr 10: Loggning av applikationer med ELK

• Huvudapplikationer och funktioner för elastic (sökning, lagring, skalningsfunktioner, anpassningsbarhet)
• Översikt av kibana (huvudfunktioner, frågespråk, dashboardhantering, skapa grafer)
• Översikt av produkter baserade på elastic och deras användning
• Samlar mätvärden i APM (applikationsspårning)
• Tillägg: Översikt av den nya produkten — SIEM

Genom att implementera denna metod blir loggar ett enkelt och tydligt verktyg för att analysera, konfigura och justera applikationen och infrastrukturen.

SRE

Och vi kommer till ämnet som Southbridge just börjar titta på och som andra talare vill stanna kvar för på den sista dagen av Slyram. Vi är glada att Ivan Kruglov från Booking.com har gått med på att läsa den.

Projektet lever i den verkliga världen där pålitlighet aldrig är absolut och varje beslut kostar pengar.

Vad är SLA i förhållande till ett komplext projekt? Låt oss säga, hur bedömer man att webbplatsen är tillgänglig, men bilder laddas med fördröjning. Vad är SLA-mätvärdena, var får man dem, hur får man dem?

Hur installera SLA? Hur upprätthålla dem?

Ämne nr 11: SRE
Definition av SLA, SLO, Error Budget och andra skrämmande termer från SRE-världen
SRE: Praxis för övervakning av SLI och SLO
SRE: Praxisen för tillämpning av Error Budget
SRE: Hantering av avbrott och operationell belastning (apigateway, service mesh, circuit brackers)
Företaget vill ha SRE. Åtminstone på den enklaste nivån: ha en reservserver eller återställa från backup? En databas eller kluster? Installera DDoS-skydd proaktivt eller endast under attack?

Direktörerna blir inte nöjda med att höra att "webbplatsen fungerar" när en kund ringer och meddelar att beställningsformuläret inte öppnas.

Därför är det viktigt för DevOps-ingenjören att åtminstone ytligt förstå SRE, för att på ett adekvat sätt prata med företaget om dess behov.

Resultat

Under tiden Slyram DevOps administratörer och utvecklare kommer att lära sig:
— arbeta korrekt med Git;
— organisera lokal utveckling;
— konfigurera (administratörer) och använda (utvecklare) CI/CD;
— arbeta med infrastruktur som kod;
— testa infrastrukturen;
— övervaka infrastrukturen och applikationen;
— konfigurera loggning;
— förstå, och i idealfallet — använda SRE.

För uppmärksamma läsare — med rabattkoden habrapost får du 15% rabatt.

Vi förbereder praktik och verktyg för alla punkter. Så varje deltagare kommer efter att ha återvänt från Slurm kunna ta sitt företag till nästa nivå inom DevOps.

För företag innebär detta lägre kostnader för administration och utveckling, minskad nedtid, ökad pålitlighet, snabbare leverans av funktioner och buggfixar.

Källa: habr.com