Dal 4 al 6 settembre a San Pietroburgo, nella sala conferenze di Selectel, si terrà un evento di tre giorni. .
Abbiamo costruito il programma con l'idea che i lavori teorici sul DevOps, così come i manuali degli strumenti, possano essere letti autonomamente da chiunque. Ciò che conta sono l'esperienza e la pratica: spiegazioni su come si deve e non si deve fare, e racconti su come lavoriamo noi.
Ogni azienda, ogni amministratore o sviluppatore ha un proprio livello di competenza in DevOps. Alcuni usano Git in modo errato, altri implementano SRE. Il corso è strutturato in modo che ognuno possa trovare qualcosa di pertinente da applicare qui e ora.
Iniziamo da Git, poi esaminiamo lo sviluppo dell'applicazione, l'interazione tra codice e infrastruttura, costruiamo CI/CD, descriviamo l'infrastruttura come codice (IaC), testiamo la soluzione ottenuta, configuriamo il monitoraggio, raccogliamo e analizziamo i log, e infine arriviamo a SRE: trasformiamo l'affidabilità in una storia misurabile e gestibile.
Git
Oggi solo chi ha comprato il suo primo laptop ieri non usa Git. È uno strumento triviale e diffuso, eppure spesso ne vediamo un uso scorretto: dalla forzatura del push su master, fino alla copia dei file da Git su un server tramite Ctrl-C, Ctrl-V.
Spieghiamo cosa non fare, cosa fare e come lo fanno in Southbridge.
Passiamo alla pratica: nozioni di base su Git e lavoro di squadra.
Tema n. 1: Fondamenti del lavoro con Git
- Comandi di base git init, commit, add, diff, log, status, pull, push
- Git flow, rami e tag, strategie di merge
- Lavorare con più remote repo
Tema n. 2: Lavoro di squadra con Git
- GitHub flow
- Fork, remote, pull request
- Conflitti, release, di nuovo su Gitflow e altri flow applicabili ai team
Il materiale è organizzato in modo tale che gli amministratori e gli sviluppatori possano immediatamente implementare tutte le pratiche nel lavoro.
Dal punto di vista del DevOps, un uso corretto di Git ordina e automatizza i processi di sviluppo e amministrazione, escludendo una serie di problemi ripetitivi e aumentando la produttività.
Sviluppatore DevOps
Guardiamo a DevOps attraverso gli occhi dello sviluppatore: avviamo l'ambiente locale, scriviamo un'applicazione, configurandone il monitoraggio e la registrazione, la testiamo localmente, organizziamo l'archiviazione delle variabili/segreti e il service discovery, esaminiamo il tracciamento (opentracing).
Tema n. 3: Lavorare con l'applicazione dal punto di vista dello sviluppo.
- Configurazione dell'ambiente locale: raccomandazioni pratiche.
- Scriviamo un microservizio in Python (inclusi i test).
- Applicazione di docker-compose nello sviluppo.
Tema n. 4: Interazione tra codice e infrastruttura.
- Pratica di lavoro con le configurazioni.
Alla fine, gli sviluppatori vedranno come il codice deve inviare i log, come testarlo e come verrà successivamente debugato. Gli amministratori comprenderanno le necessità degli sviluppatori: quali errori nel codice si possono presentare, come organizzare i test per gli sviluppatori, come testare il progetto autonomamente.
In questa fase, si risolve la principale sfida del DevOps: si costruisce comprensione reciproca e collaborazione tra i dev e gli ops. Questo è un passo chiave per passare dal semplice passaggio di compiti a una collaborazione responsabile.
Di conseguenza, aumenta la velocità e la qualità del lavoro.
CI/CD
L'automazione moderna implica CI/CD. Iniziamo esaminando l'automazione manuale: makefile, git hooks e script. Analizzeremo quando questi strumenti sono ancora pertinenti e quando sarebbe meglio evitarli.
In seguito, esploreremo le migliori pratiche del CI moderno attraverso l'esempio di Gitlab.
Tema n. 5: CI/CD Introduzione all'automazione
- Introduzione all'automazione
- Strumenti (bash, make, gradle)
- Utilizzo dei git hooks per automatizzare i processi
- Linee di assemblaggio industriali e la loro applicazione nell'IT
- Esempio di costruzione di un 'pipeline' comune
- Software moderno per CI/CD: Drone CI, BitBucket Pipelines, Travis, ecc.
Tema n. 6: CI/CD: Lavorare con Gitlab
- Gitlab CI - panoramica
- Gitlab Runner, i loro tipi e applicazioni
- Gitlab CI, caratteristiche di configurazione, migliori pratiche
- Fasi di Gitlab CI
- Variabili di Gitlab CI
- Compilazione, testing, deployment
- Controllo e limitazioni dell'esecuzione: only, when
- Gestione degli artefatti
- Template all'interno di .gitlab-ci.yml, riutilizzo delle azioni in diverse sezioni della pipeline
- Include - sezioni
- Gestione centralizzata di gitlab-ci.yml (un file e push automatici in altri repository)
La collaborazione tra amministratori e sviluppatori raggiunge un nuovo livello: l'amministratore scrive il template CI, mentre gli sviluppatori lo modificano, costruendo il proprio CI indipendentemente dall'amministratore.
Si riduce la dipendenza degli sviluppatori dagli amministratori, diminuisce il lavoro manuale e scompare il problema dell'«unico che sa come lavorare con il makefile». I deploy avvengono in modo affidabile e veloce.
IaC
Il tema dell'Infrastructure as Code utilizzando Terraform sarà trattato dall'amministratore del cloud di Selectel, Алексей Степаненко. Mostrerà come distribuire e scalare rapidamente i server in modo automatizzato, come impacchettare automaticamente le immagini e come usare i template di configurazione per ottenere macchine già configurate.
Una persona che ha realizzato migliaia di soluzioni IaC spiegherà come fare correttamente e cosa evitare.
La soluzione per il cloud di Selectel con modifiche minime è adatta per i cloud di Google e Amazon.
Il dipendente di Southbridge, Николай Месропян, mostrerà, utilizzando Ansible, come distribuire un'applicazione funzionante senza downtime e verificarne l'operatività.
Se gestisci l'infrastruttura manualmente (configurando server, installando librerie e pacchetti secondo necessità), quando cerchi di creare una copia dell'ambiente dovrai ricordare e riprodurre tutte le tue azioni. Questo compito richiede facilmente 3-5 giorni. Lavorare sull'infrastruttura come codice garantisce che tu abbia una descrizione aggiornata dell'ambiente che può essere distribuita in pochi minuti.
Nikolay spiegherà come scrivere playbook, quali errori possono verificarsi, perché a volte i playbook funzionano lentamente o non come previsto. Questa è l'esperienza di molti anni di utilizzo di IaC in Southbridge.
Tema n. 7: Infrastructure as Code
- IaC: approccio all'infrastruttura come codice
- Fornitori cloud come fornitori di infrastruttura
- Strumenti di inizializzazione dei sistemi, creazione di immagini (packer)
- IaC con Terraform come esempio
- Archiviazione delle configurazioni, collaborazione, automazione delle applicazioni
- Pratica nella creazione di playbook Ansible
- Idempotenza, dichiaratività
- IaC con Ansible come esempio
- Database as a Code / Fault Tolerance PostgreSQL
L'infrastruttura acquisisce dichiaratività e idempotenza.
L'amministratore impara a gestire un'infrastruttura complessa: creare rapidamente nuovi ambienti, mantenere l'uniformità di tutti gli ambienti e visualizzare la cronologia delle modifiche, che è fondamentale quando più team lavorano a un progetto.
Lo sviluppatore può esplorare l'infrastruttura e distribuire autonomamente gli ambienti.
Il bonus della sezione consiste nella creazione e configurazione di un cluster di database PostgreSQL altamente disponibile. Forniremo un playbook pronto all'uso, che utilizziamo in Southbridge, e avrai la possibilità di distribuire il cluster su un ambiente di test per implementare questa soluzione nella tua azienda.
Test dell'infrastruttura e monitoraggio
L'automazione consente di applicare un errore su mille server contemporaneamente. Ogni cambiamento richiede testing. D'altro canto, il testing manuale richiede così tanto tempo da annullare i vantaggi dell'automazione.
Mostreremo in pratica come scrivere test per i ruoli. Di conseguenza, sarai in grado di scrivere test per la tua azienda. Non dovrai più memorizzare le configurazioni, ma puoi descriverle nei test e verificare automaticamente che tutte le soluzioni precedenti e le complicazioni siano al loro posto.
Iniziamo a imparare ad aggiungere automaticamente al monitoraggio tutti i nuovi server. Esamineremo separatamente il monitoraggio dell'infrastruttura e delle applicazioni. Mostreremo le buone e le cattive pratiche.
Tema n. 8: Test del'infrastruttura
- Test e integrazione continua con Molecule e Gitlab CI
- Utilizzo di Vagrant
Tema n. 9: Monitoraggio dell'infrastruttura con Prometheus
- Perché è necessario il monitoraggio
- Tipi di monitoraggio
- Notifiche nel sistema di monitoraggio
- Come costruire un sistema di monitoraggio sano
- Notifiche leggibili per tutti
- Health Check: cosa tenere d'occhio
- Automazione basata sui dati del monitoraggio
Un monitoraggio che non funziona correttamente è assenza di monitoraggio. A un'azienda non interessa se la homepage del negozio online è accessibile, se il modulo di pagamento restituisce un errore.
Nella configurazione del monitoraggio e nella risoluzione dei problemi, sviluppatori e amministratori partecipano alla pari. Tradizionalmente, le attività di monitoraggio ricadono sugli amministratori. Il nostro corso mostrerà agli sviluppatori quale ruolo giocano nella creazione di un monitoraggio efficace. Gli amministratori apprenderanno le migliori pratiche di Southbridge. Di conseguenza, il numero di perdite causate da malfunzionamenti e rallentamenti di siti o applicazioni diminuirà rapidamente.
Bonus della sezione: automazione basata sul monitoraggio. Ad esempio, il monitoraggio segnala che è in arrivo un carico sul sito, e il ridimensionamento dei server web viene avviato automaticamente.
Log
L'errore principale nella gestione dei log è che amministratori e sviluppatori li controllano direttamente sui server. Se avete più di un server, questo diventa lungo. È insicuro: uno sviluppatore accede a un server dove non dovrebbe essere.
DevOps richiede una raccolta, elaborazione e analisi centralizzate dei log.
Tema n. 10: Registrazione delle applicazioni con ELK
- Principali applicazioni e funzionalità di elastic (ricerca, archiviazione, caratteristiche di scalabilità, flessibilità di configurazione)
- Panoramica di Kibana (principali funzionalità, linguaggio di query, gestione dei dashboard, creazione di grafici)
- Panoramica dei prodotti basati su elastic e il loro utilizzo
- Raccogliamo metriche in APM (tracciamento delle applicazioni)
- In aggiunta: Panoramica del nuovo prodotto — SIEM
L'adozione di questo approccio renderà i log uno strumento semplice e comprensibile per l'analisi, la configurazione e la messa a punto dell'applicazione e dell'infrastruttura.
SRE
Arriviamo al tema che Southbridge sta appena esplorando e per il quale altri relatori vogliono rimanere fino all'ultimo giorno di Slurm. Siamo lieti che Ivan Kruglov di Booking.com abbia accettato di leggerlo.
Il progetto vive nel mondo reale, dove l'affidabilità non è mai assoluta e ogni decisione ha un costo.
Cos'è un SLA in relazione a un progetto complesso? Ad esempio, come valutare se un sito è accessibile ma le immagini si caricano con ritardo. Quali sono le metriche SLA, dove raccoglierle, come farlo?
Come stabilire un SLA? Come mantenerli?
Tema n. 11: SRE
Definizione di SLA, SLO, Error Budget e altri termini spaventosi dal mondo SRE
SRE: Pratica di monitoraggio SLI e SLO
SRE: Pratica di applicazione dell'Error Budget
SRE: Gestione delle interruzioni e del carico operativo (apigateway, service mesh, circuit breakers)
Il business ha bisogno di SRE. Anche solo a un livello base: adottare un server di backup o ripristinare da un backup? Un solo database o un cluster? Configurare la protezione DDoS preventivamente o solo durante un attacco?
Il direttore non sarà soddisfatto di sapere che "il sito funziona" quando un cliente chiama e dice che il modulo d'ordine non si apre.
Per questo motivo, è importante che l'ingegnere DevOps comprenda, anche superficialmente, SRE per poter parlare in modo adeguato con il business riguardo alle sue necessità.
Risultato
Nel corso del tempo amministratori e sviluppatori impareranno:
— a lavorare correttamente con Git;
— a organizzare lo sviluppo locale;
— a configurare (amministratori) e utilizzare (sviluppatori) CI/CD;
— a trattare l'infrastruttura come codice;
— a testare l'infrastruttura;
— a monitorare l'infrastruttura e le applicazioni;
— a configurare il logging;
— a comprendere, e idealmente a usare, SRE.
Per i lettori attenti, con il codice promozionale habrapost si riceve uno sconto del 15%.
Prepariamo pratiche e strumenti per tutti i punti. In modo che ogni partecipante, al ritorno da Slërma, possa portare la propria azienda al livello successivo di DevOps.
Per le aziende, ciò significa ridurre i costi di amministrazione e sviluppo, ridurre i tempi di inattività, aumentare l'affidabilità, consegnare le funzionalità più rapidamente e risolvere i bug.
Fonte: habr.com
