Dal 4 al 6 settembre a San Pietroburgo, nella sala conferenze Selectel, si terrà un evento di tre giorni .
Abbiamo costruito il programma partendo dall'idea che le opere teoriche su DevOps, così come i manuali degli strumenti, possono essere letti autonomamente da chiunque. Sono interessanti solo l'esperienza e la pratica: spiegazioni su cosa fare e cosa non fare, e racconti su come ci comportiamo noi.
In ogni azienda, ogni amministratore o sviluppatore ha il proprio livello di DevOps. Alcuni utilizzano Git in modo errato, altri implementano SRE. Il corso è organizzato in modo che ognuno possa trovare qualcosa di pertinente da applicare qui e ora.
Iniziamo con Git, poi ci concentriamo sullo sviluppo dell'applicazione, sull'interazione tra codice e infrastruttura, costruiamo CI/CD, descriviamo l'infrastruttura come codice (IaC), testiamo la soluzione risultante, configuriamo il monitoraggio, raccogliamo e analizziamo i log, e alla fine arriviamo a SRE: trasformiamo l'affidabilità in una storia misurabile e gestibile.
Git
Oggi, non usa Git solo chi ha comprato il primo laptop ieri. È uno strumento banale e onnipresente, eppure ci imbattiamo spesso nel suo utilizzo errato: dagli push forzati nel master, alla copia di file da Git su server tramite Ctrl-C, Ctrl-V.
Spieghiamo come non fare, come fare e come si fa in Southbridge.
Percorriamo la pratica: basi di Git, lavoro di squadra.
Tema n. 1: Fondamenti del lavoro con Git
- Comandi base git init, commit, add, diff, log, status, pull, push
- Git flow, branch e tag, strategie di merge
- Lavorare con più repository remote
Tema n. 2: Lavoro di squadra con Git
- GitHub flow
- Fork, remote, pull request
- Conflitti, rilasci, ancora su Gitflow e altri flow relativi ai team
Il materiale è organizzato in modo che gli amministratori e gli sviluppatori possano applicare immediatamente tutte le pratiche nel lavoro.
Dal punto di vista di 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: attiviamo un ambiente locale, scriviamo un'applicazione, configuriamo il monitoraggio e la registrazione, la testiamo localmente, organizziamo la conservazione delle variabili/secret e del service discovery, e osserviamo 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 con i file di configurazione
Al termine, gli sviluppatori vedranno come il codice deve inviare i log, come testarlo e come verrà successivamente eseguita la debug. Gli amministratori comprenderanno le esigenze degli sviluppatori: quali errori nel codice possono verificarsi, come organizzare i test per gli sviluppatori e come testare autonomamente il progetto.
In questa fase si risolve il compito principale del DevOps: si costruisce una comprensione reciproca e una collaborazione tra sviluppatori e operatori. Questo è un passaggio chiave per passare dal mero trasferimento di compiti a un'interazione responsabile.
Di conseguenza, aumenta la velocità e la qualità del lavoro.
CI/CD
L'automazione moderna implica CI/CD. Inizieremo osservando l'automazione manuale: makefile, git hooks, script. Analizzeremo quando questi strumenti sono ancora rilevanti e quando sarebbe meglio evitarli.
Successivamente, esamineremo le migliori pratiche moderne di CI usando Gitlab come esempio.
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 montaggio a nastro e il loro utilizzo 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 - introduzione generale
- Gitlab Runner, i loro tipi e applicazione
- Gitlab CI, particolarità della configurazione, migliori pratiche
- Fasi di Gitlab CI
- Variabili Gitlab CI
- Build, test, deploy
- Controllo e limitazioni di esecuzione: only, when
- Lavorare con gli artefatti
- Modelli dentro il .gitlab-ci.yml, riutilizzo delle azioni in diverse sezioni del pipeline
- Include - sezioni
- Gestione centralizzata di gitlab-ci.yml (un file con push automatici negli altri repository)
La collaborazione tra amministratori e sviluppatori raggiunge un nuovo livello: l'amministratore scrive il modello CI, mentre gli sviluppatori lo modificano, strutturando il proprio CI indipendentemente dall'amministratore.
Si riduce la dipendenza degli sviluppatori dagli amministratori, diminuisce il lavoro manuale e scompare il problema della "persona unica che sa come lavorare con il makefile". I deployment avvengono in modo affidabile e veloce.
IaC
Il tema dell'Infrastructure as Code, attraverso l'esempio di Terraform, sarà trattato dall'amministratore cloud di Selectel, Aleksey Stepanenko. Mostrerà come distribuire e scalare rapidamente i server in modo automatizzato, come confezionare le immagini automaticamente e come utilizzare i modelli di configurazione per ottenere macchine pronte all'uso.
Una persona che ha realizzato migliaia di soluzioni IaC spiegherà come farlo nel modo giusto e come non farlo.
La soluzione per il cloud Selectel, con poche modifiche, è adatta per i cloud Google e Amazon.
Il collaboratore di Southbridge, Nikolai Mesropyan, mostrerà, utilizzando Ansible, come distribuire un'applicazione in esecuzione senza tempi di inattività e come verificarne il funzionamento.
Se si modifica l'infrastruttura manualmente (configurando i server e installando librerie e pacchetti secondo necessità), quando si tenta di sollevare una copia dell'ambiente, dovete ricordare e riprodurre tutte le vostre azioni. Questo compito richiede facilmente 3-5 giorni. Lavorare con l'infrastruttura come codice garantisce che si abbia una descrizione attuale dell'ambiente, che può essere distribuita in pochi minuti.
Nikolai spiegherà come scrivere playbook, quali errori possono verificarsi e 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: un approccio all'infrastruttura come codice
- Fornitori cloud come fornitori di infrastruttura
- Strumenti di inizializzazione dei sistemi, creazione di immagini (packer)
- IaC tramite l'esempio di Terraform
- Archiviazione delle configurazioni, collaborazione, automazione delle applicazioni
- Pratica di creazione di playbook Ansible
- Idempotenza, dichiaratività
- IaC tramite l'esempio di Ansible
- Database as a Code / Alta disponibilità di 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, vedere la cronologia delle modifiche, che è cruciale quando più team lavorano su un progetto.
Lo sviluppatore può studiare l'infrastruttura e distribuire autonomamente i propri ambienti.
Il bonus della sezione è la creazione e la configurazione di un cluster di database PostgreSQL a prova di guasto. Forniremo un playbook già pronto, che utilizziamo in Southbridge, e potrete distribuire il cluster su un ambiente di formazione e utilizzare questa soluzione nella vostra azienda.
Test dell'infrastruttura e monitoraggio
L'automazione consente di diffondere un errore immediatamente su mille server. Ogni modifica richiede testing. D'altro canto, il testing manuale richiede così tanto tempo che annulla i vantaggi dell'automazione.
Dimostreremo praticamente come scrivere test per i ruoli. Di conseguenza, sarai in grado di scrivere test per la tua azienda. Non dovrai più ricordare le impostazioni fatte, le descrivi nei test e verifichi automaticamente che tutte le soluzioni e i workaround passati siano a posto.
In seguito impareremo ad aggiungere automaticamente al monitoraggio tutti i nuovi server. Esamineremo separatamente il monitoraggio dell'infrastruttura e dell'applicazione. Mostreremo le pratiche sbagliate e quelle corrette.
Argomento n. 8: Testing dell'infrastruttura
- Testing e integrazione continua con Molecule e Gitlab CI
- Applicazione di Vagrant
Argomento 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 l'uomo, per tutti
- Health Check: su cosa prestare attenzione
- Automazione basata sui dati del monitoraggio
Un monitoraggio non funzionante è l'assenza di monitoraggio. All’azienda non importa che la homepage di un negozio online sia accessibile, se il modulo di pagamento restituisce un errore.
Nella configurazione del monitoraggio e nella risoluzione dei problemi, sviluppatori e amministratori partecipano allo stesso livello. Tradizionalmente, i compiti di monitoraggio ricadono sugli amministratori. Il nostro corso mostrerà agli sviluppatori quale ruolo svolgono nella creazione di un monitoraggio efficace. Gli amministratori otterranno le migliori pratiche di Southbridge. Di conseguenza, il numero di perdite causate da malfunzionamenti e rallentamenti del sito o dell'applicazione diminuirà rapidamente.
Bonus della sezione: automazione basata sul monitoraggio. Ad esempio, il monitoraggio comunica che c'è un carico sul sito, e il ridimensionamento dei server web viene avviato automaticamente.
Registrazione
L'errore principale nella gestione dei log è che amministratori e sviluppatori li visualizzano direttamente sui server. Se hai più di un server, è lungo. Non è sicuro: uno sviluppatore accede a un server dove non dovrebbe essere.
DevOps richiede una raccolta, elaborazione e analisi centralizzate dei log.
Argomento n. 10: Logging delle applicazioni con ELK
- Principali applicazioni e possibilità di elastic (ricerca, archiviazione, caratteristiche di scalabilità, flessibilità di configurazione)
- Panoramica su kibana (funzionalità principali, linguaggio delle query, gestione dei dashboard, creazione di grafici)
- Panoramica dei prodotti basati su elastic e il loro utilizzo
- Raccolta di metriche in APM (tracciamento delle applicazioni)
- In aggiunta: Panoramica del nuovo prodotto — SIEM
L'implementazione di questo approccio renderà i log uno strumento semplice e comprensibile per analizzare, configurare e ottimizzare l'applicazione e l'infrastruttura.
SRE
E arriviamo al tema che Southbridge sta solo esaminando e per cui altri relatori vogliono rimanere fino all'ultimo giorno del Slёrma. Siamo felici che a leggere sia stato d'accordo Ivan Kruglov di Booking.com.
Il progetto vive in un 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 che il sito è disponibile, ma le immagini si caricano con ritardo? Quali sono le metriche SLA, dove si misurano, come si misurano?
Come stabilire un SLA? Come mantenerli?
Argomento 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 utilizzo dell'Error Budget
SRE: Gestione delle interruzioni e del carico operativo (apigateway, service mesh, circuit brackers)
Il business vuole SRE. Almeno a un livello base: prendere un server di riserva o ripristinare da un backup? Un database o un cluster? Installare la protezione DDoS in modo preventivo o solo al momento dell'attacco?
Il direttore non sarà soddisfatto di sentire che "il sito funziona", quando un cliente chiama e segnala che il modulo d'ordine non si apre.
Perciò, è importante per l'ingegnere DevOps comprendere almeno superficialmente SRE, per discutere in modo adeguato con il business delle sue esigenze.
Risultato
Nel corso del tempo gli amministratori e gli sviluppatori impareranno:
— lavorare correttamente con Git;
— organizzare lo sviluppo locale;
— configurare (amministratori) e utilizzare (sviluppatori) CI/CD;
— trattare l'infrastruttura come codice;
— testare l'infrastruttura;
— monitorare l'infrastruttura e l'applicazione;
— configurare il logging;
— comprendere e idealmente utilizzare SRE.
Per i lettori attenti: con il codice promozionale habrapost, sconto del 15%.
Per tutti i punti stiamo preparando pratiche e strumenti. Così ogni partecipante, al ritorno dal Slyrm, potrà portare la propria azienda al livello successivo di DevOps.
Per le aziende questo significa ridurre i costi di amministrazione e sviluppo, diminuire i tempi di inattività, aumentare l'affidabilità, consegnare le funzionalità più rapidamente e risolvere i bug.
Fonte: habr.com
