Slurm DevOps: van Git tot SRE met alle tussenstops

Van 4-6 september in Sint-Petersburg, in de conferentiezaal van Selectel, zal een driedaagse Slurm DevOps.

We hebben het programma opgebouwd met de gedachte dat theoretische werken over DevOps, net als handleidingen voor tools, door iedereen zelf gelezen kan worden. Alleen ervaring en praktijk zijn interessant: uitleg over hoe het moet en hoe het niet moet, en een verhaal over hoe wij het doen.

In elk bedrijf, bij elke administrator of ontwikkelaar, is er een eigen niveau van DevOps. Sommigen gebruiken Git verkeerd, anderen voeren SRE in. De cursus is georganiseerd zodat iedereen iets relevants vindt dat hier en nu geïmplementeerd kan worden.

We beginnen met Git, kijken dan naar de ontwikkeling van de applicatie, de interactie tussen code en infrastructuur, bouwen CI/CD, beschrijven infrastructuur als code (IaC), testen de ontwikkelde oplossing, stellen monitoring in, verzamelen en bestuderen logs, en uiteindelijk komen we bij SRE: maken betrouwbaarheid meetbaar en beheersbaar.

Git

Tegenwoordig gebruikt alleen degene die gisteren zijn eerste laptop kocht geen Git. Het is een triviaal en alomtegenwoordig hulpmiddel, en toch ontmoeten we vaak het verkeerde gebruik ervan: van geforceerd pushen naar master, tot het kopiëren van bestanden van Git naar de server via Ctrl-C, Ctrl-V.

We vertellen hoe het niet moet, hoe het moet, en hoe ze het bij Southbridge doen.
We doorlopen de praktijk: de basisprincipes van Git, teamwerk.

Thema 1: Basisprincipes van werken met Git

• Basiscommando's git init, commit, add, diff, log, status, pull, push
• Git flow, branches en tags, merge strategieën
• Werken met meerdere remote repositories

Thema 2: Teamwerk met Git

• GitHub flow
• Fork, remote, pull request
• Conflicten, releases, opnieuw over Gitflow en andere flows voor teams

Het materiaal is zo georganiseerd dat administrators en ontwikkelaars alle praktijken onmiddellijk in hun werk kunnen implementeren.

Vanuit DevOps perspectief ordent en automatiseert het juiste gebruik van Git de processen van ontwikkeling en administratie, elimineert het verschillende terugkerende problemen en verhoogt het de productiviteit.

DevOps ontwikkelaar

We kijken naar DevOps vanuit het perspectief van de ontwikkelaar: we starten de lokale omgeving, schrijven de applicatie, stellen monitoring en logging in, testen deze lokaal, organiseren het opslaan van variabelen/secreten en service discovery, en kijken naar tracing (opentracing).

Thema 3: Werken met de applicatie vanuit het ontwikkelingsperspectief

• Instellen van een lokale omgeving: praktische aanbevelingen
• Een microservice schrijven in Python (inclusief tests)
• Toepassing van docker-compose in ontwikkeling

Onderwerp nr. 4: Interactie tussen code en infrastructuur

• Praktijk met configuraties

Uiteindelijk zullen ontwikkelaars zien hoe de code logs moet verzenden, hoe deze te testen en hoe deze vervolgens moet worden gedebugd. Beheerders zullen begrijpen wat de ontwikkelaars nodig hebben: welke fouten in de code ontstaan, hoe ze testen kunnen organiseren en hoe ze hun eigen projecten kunnen testen.

In deze fase wordt de belangrijkste taak van DevOps opgelost: er ontstaat wederzijds begrip en samenwerking tussen developers en operators. Dit is de cruciale stap om van het doorgeven van taken naar verantwoordelijk samenwerken te gaan.

Het resultaat is een toename in snelheid en kwaliteit van het werk.

CI/CD

Moderne automatisering omvat CI/CD. We beginnen met het bekijken van handmatige automatisering: makefiles, git hooks, scripts. We bespreken wanneer deze tools nog relevant zijn en wanneer ze niet moeten worden gebruikt.

Daarna kijken we naar de beste praktijken van moderne CI aan de hand van Gitlab.

Onderwerp nr. 5: CI/CD introductie in automatisering

• Inleiding tot automatisering
• Tools (bash, make, gradle)
• Gebruik van git-hooks voor het automatiseren van processen
• Fabrieksassemblagelijnen en hun toepassing in IT
• Voorbeeld van het bouwen van een "gemeenschappelijke" pipeline
• Moderne software voor CI/CD: Drone CI, BitBucket Pipelines, Travis, enz.

Onderwerp nr. 6: CI/CD: Werken met Gitlab

• Gitlab CI - algemeen
• Gitlab Runner, hun types en toepassingen
• Gitlab CI, instelkenmerken, beste praktijken
• Fasen van Gitlab CI
• Gitlab CI variabelen
• Bouwen, testen, deployen
• Controle en beperkingen van uitvoering: only, when
• Werken met artefacten
• Sjablonen binnen .gitlab-ci.yml, herbruikbaarheid van acties op verschillende plaatsen van de pipeline
• Include - secties
• Gecentraliseerd beheer van gitlab-ci.yml (één bestand en automatische push naar andere repositories)

Samenwerking tussen beheerders en ontwikkelaars bereikt een nieuw niveau: de beheerder schrijft het CI-sjabloon, en de ontwikkelaars passen het aan, waardoor ze hun CI onafhankelijk van de beheerder kunnen inrichten.

De afhankelijkheid van ontwikkelaars van beheerders neemt af, het aantal handmatige taken vermindert, en het probleem van de "enige persoon die weet hoe te werken met makefiles" verdwijnt. Deployments verlopen betrouwbaar en snel.

IaC

Het onderwerp Infrastructure as Code aan de hand van Terraform wordt behandeld door cloudbeheerder Alexey Stepanenko van Selectel. Hij laat zien hoe je snel en geautomatiseerd servers kunt uitrollen en schalen, hoe je afbeeldingen automatisch kunt inpakken en hoe je configuratiesjablonen kunt gebruiken om direct geconfigureerde machines te krijgen.

Een persoon die duizenden IaC-oplossingen heeft gemaakt, vertelt hoe je het goed doet en hoe je het vooral niet moet doen.

De oplossing van Selectel voor de cloud is met minimale aanpassingen geschikt voor Google en Amazon clouds.

Nikolay Mesropyan van Southbridge toont met Ansible hoe je een werkende applicatie zonder downtime kunt uitrollen en de functionaliteit kunt controleren.

Als je de infrastructuur handmatig aanpast (servers configureert, bibliotheken en pakketten installeert wanneer nodig), moet je bij het opzetten van een kopie van de omgeving al je acties herinneren en reproduceren. Deze taak kost gemakkelijk 3-5 dagen. Werken met infrastructuur als code garandeert dat je een actuele beschrijving van de omgeving hebt die je in minuten kunt uitrollen.

Nikolay vertelt hoe je playbooks schrijft, welke fouten er kunnen optreden, en waarom playbooks soms traag of niet zoals verwacht werken. Dit is de ervaring van vele jaren gebruik van IaC bij Southbridge.

Onderwerp №7: Infrastructure as Code

• IaC: Een benadering van infrastructuur als code
• Cloud providers als infrastructuurleveranciers
• Systeeminitialisatietools, beeldopbouw (packer)
• IaC aan de hand van Terraform
• Configuratieopslag, samenwerking, en automatisering van toepassingen
• Praktijk voor het maken van Ansible-playbooks
• Idempotentie, declarativiteit
• IaC aan de hand van Ansible
• Database as Code / Failover van PostgreSQL

Infrastructuur krijgt declarativiteit en idempotentie.
Een beheerder leert hoe hij complexe infrastructuren moet beheren: snel nieuwe omgevingen creëren, uniformiteit in alle omgevingen handhaven, en de geschiedschrijving van wijzigingen zichtbaar maken, wat cruciaal is wanneer meerdere teams aan een project werken.
Een ontwikkelaar kan de infrastructuur bestuderen en zelfstandig omgevingen uitrollen.

Bonus van deze sectie - het creëren en configureren van een failover-cluster van PostgreSQL-databases. We geven een kant-en-klaar playbook dat we in Southbridge gebruiken, je zult een cluster op een trainingsstand opzetten en deze oplossing in je bedrijf kunnen toepassen.

Infrastructuur testen en monitoren

Automatisering maakt het mogelijk om een fout direct op duizend servers uit te rollen. Bij elke wijziging is testen noodzakelijk. Aan de andere kant kost handmatig testen zoveel tijd dat het de voordelen van automatisering tenietdoet.

We laten in de praktijk zien hoe je rollen test. Hierdoor kun je tests schrijven voor jouw bedrijf. Je hoeft voortaan niet meer de gemaakte instellingen te onthouden; je beschrijft ze in tests en controleert automatisch of alle eerdere oplossingen en tijdelijke oplossingen aanwezig zijn.

Daarna leren we hoe we automatisch alle nieuwe servers aan de monitoring kunnen toevoegen. We bespreken afzonderlijk de monitoring van infrastructuur en applicaties. We zullen slechte en goede praktijken demonstreren.

Thema #8: Infrastructuurtesten

• Testen en continue integratie met Molecule en Gitlab CI
• Toepassing van Vagrant

Thema #9: Infrastructuurmonitoring met Prometheus

• Waarom is monitoring nodig?
• Types van monitoring
• Notificaties in het monitoringsysteem
• Hoe een gezonde monitoringsysteem op te zetten
• Menselijke notificaties voor iedereen
• Health Check: waar je op moet letten
• Automatisering op basis van gegevens van monitoring

Een verkeerd functionerende monitoring betekent geen monitoring. Voor het bedrijf maakt het niet uit dat de homepage van de webshop toegankelijk is, als het betalingsformulier een foutmelding geeft.

Bij het instellen van monitoring en probleemoplossing zijn ontwikkelaars en beheerders gelijkwaardig betrokken. Traditioneel liggen de monitoringstaken bij de beheerders. Onze cursus laat ontwikkelaars zien welke rol zij spelen bij het creëren van een effectieve monitoring. Beheerders krijgen de beste praktijken van Southbridge. Hierdoor zal het verlies als gevolg van uitval en vertragingen van de website of applicatie snel afnemen.

Bonussectie: automatisering op basis van monitoring. Bijvoorbeeld, de monitoring geeft aan dat er belasting op de website komt, en de schaalvergroting van de webservers wordt automatisch gestart.

Logging

De grootste fout in het werken met logs is dat beheerders en ontwikkelaars deze rechtstreeks op de servers bekijken. Als je meer dan één server hebt, kost dit tijd. Het is onveilig: een ontwikkelaar logt in op een server waar hij niet zou moeten zijn.

DevOps vereist gecentraliseerde verzameling, verwerking en analyse van logs.

Thema #10: Applicatielogging met ELK

• De belangrijkste toepassingen en mogelijkheden van elastic (zoeken, opslag, schaalbaarheid, configuratiemogelijkheden)
• Overzicht van Kibana (hoofdfunctionaliteiten, querytaal, dashboardbeheer, grafiekcreatie)
• Overzicht van producten op basis van elastic en hun toepassingen
• Metrics verzamelen in APM (applicatietracing)
• Extra: Overzicht van het nieuwe product – SIEM

De implementatie van deze benadering maakt logs een eenvoudig en gemakkelijk te begrijpen instrument voor de analyse, configuratie en afstemming van de applicatie en infrastructuur.

SRE

En dan komen we bij het onderwerp waar Southbridge alleen een blik op werpt en waarvoor andere sprekers tot de laatste dag van Sleerma willen blijven. We zijn blij dat Ivan Kruglov van Booking.com bereid is dit te presenteren.

Het project leeft in de echte wereld, waar betrouwbaarheid nooit absoluut is en elke beslissing geld kost.

Wat is SLA in de context van een complex project? Stel, hoe evalueer je dat de website toegankelijk is, maar de afbeeldingen met vertraging laden. Wat zijn de SLA-metrics, waar haal je ze vandaan, hoe meet je ze?

Hoe stel je SLA's in? Hoe houd je je eraan?

Thema #11: SRE
Definitie van SLA, SLO, Error Budget en andere angstaanjagende termen uit de wereld van SRE
SRE: Praktijk van monitoring SLI en SLO
SRE: Praktijk van het toepassen van Error Budget
SRE: Beheer van onderbrekingen en operationele belasting (apigateway, service mesh, circuit breakers)
Het bedrijfsleven wil SRE. Ten minste op het eenvoudigste niveau: een reserve server nemen of een back-up herstellen? Eén database of een cluster? Preventief DDoS-bescherming installeren of alleen tijdens een aanval?

De directeur zal niet tevreden zijn met een verhaal dat 'de website werkt', wanneer hij een klant aan de telefoon heeft die meldt dat het bestelformulier niet opent.

Daarom is het belangrijk voor een DevOps-engineer om ten minste oppervlakkig SRE te begrijpen om adequaat met het bedrijfsleven over zijn behoeften te kunnen praten.

Conclusie

Tijdsduur Sleerma DevOps beheerders en ontwikkelaars leren:
— correct werken met Git;
— lokale ontwikkeling organiseren;
— CI/CD configureren (beheerders) en gebruiken (ontwikkelaars);
— werken met infrastructuur als code;
— infrastructuur testen;
— infrastructuur en applicaties monitoren;
— logging configureren;
— begrijpen, en idealiter — SRE gebruiken.

Voor oplettende lezers — met de promo code habrapost 15% korting.

Voor alle punten bereiden we praktijkervaring en tools voor. Hierdoor kan elke deelnemer, na zijn terugkeer van de Slurm, zijn bedrijf naar het volgende niveau van DevOps tillen.

Voor bedrijven betekent dit goedkopere administratie en ontwikkeling, vermindering van downtime, verhoogde betrouwbaarheid, snellere levering van functies en het oplossen van bugs.

Bron: habr.com