TL; DR
si terrà a Mosca dal 30 gennaio al 1 febbraio.
Anche in questo caso analizzeremo gli strumenti DevOps nella pratica.
Dettagli e programma sotto il taglio.
SRE è stato rimosso dal programma perché insieme a Ivan Kruglov stiamo preparando uno Slurm SRE separato. L'annuncio arriverà più tardi.
Grazie a Selectel, nostro sponsor fin dal primo Slurm!
Di filosofia, scetticismo e successi inaspettati
Ho partecipato alla DevOpsConf a Mosca alla fine di settembre.
Riassunto di quello che ho sentito:
— DevOps è necessario per la maggior parte dei progetti di qualsiasi dimensione;
— DevOps è una cultura e, come ogni cultura, deve provenire dall'interno dell'azienda. Non puoi assumere un ingegnere DevOps e sognare che migliorerà i processi.
— All'estremità dell'elenco di ciò che è necessario per la trasformazione DevOps c'è la tecnologia, ovvero gli stessi strumenti DevOps che insegniamo.
Mi sono reso conto che avevamo ragione a non includere la filosofia e la cultura DevOps nel corso, perché non possono essere insegnate in modo sistematico. Chi ne avrà bisogno lo leggerà nei libri. Oppure troverà un allenatore super cool che convincerà tutti con il suo carisma e la sua autorità.
Personalmente sono sempre stato un sostenitore del “movimento dal basso”, la guerriglia che implementa la cultura attraverso gli strumenti. Qualcosa di simile a quello descritto in The Phoenix Project. Se abbiamo impostato correttamente il lavoro di squadra con Git, possiamo lentamente integrarlo con le normative e poi si arriverà ai valori.
Tuttavia, quando stavamo preparando DevOps Slurm, dove parlavamo esclusivamente di strumenti, avevo paura della reazione dei partecipanti: “Hai detto cose meravigliose. È un peccato, non potrò mai realizzarli”. C'era così tanto scetticismo che abbiamo immediatamente interrotto la ripetizione del programma.
Tuttavia, la maggior parte dei partecipanti al sondaggio ha risposto che le conoscenze acquisite erano applicabili nella pratica e che avrebbero implementato qualcosa nel proprio paese nel prossimo futuro. Allo stesso tempo, tutto ciò che abbiamo spiegato è stato incluso nell'elenco delle cose utili: Git, Ansible, CI/CD e SRE.
Varrebbe la pena ricordare che all'inizio dicevano anche di Slurm Kubernetes che è impossibile spiegare k3 in 8 giorni.
Con Ivan Kruglov, che ha guidato il tema SRE, abbiamo concordato un programma separato. Stiamo discutendo i dettagli, presto farò un annuncio.
Cosa accadrà allo Slurm DevOps?
Programma
Argomento n.1: Lavoro di squadra con Git
- Comandi di base git init, commit, add, diff, log, status, pull, push
- Flusso Git, rami e tag, strategie di unione
- Lavorare con più rappresentanti remoti
- Flusso GitHub
- Richiesta fork, remota, pull
- Conflitti, rilasci, ancora una volta su Gitflow e altri flussi in relazione ai team
Argomento n. 2: lavorare con l'applicazione dal punto di vista dello sviluppo
- Scrivere un microservizio in Python
- variabili ambientali
- Integrazione e test unitari
- Utilizzo di docker-compose in fase di sviluppo
Argomento n.3: CI/CD: introduzione all'automazione
- Introduzione all'automazione
- Strumenti (bash, make, gradle)
- Utilizzo di git-hook per automatizzare i processi
- Linee di assemblaggio di fabbrica e loro applicazione nell'IT
- Un esempio di costruzione di una pipeline “generale”.
- Software moderno per CI/CD: Drone CI, BitBucket Pipelines, Travis, ecc.
Argomento n. 4: CI/CD: lavorare con Gitlab
- CI Gitlab
- Gitlab Runner, loro tipologie e applicazioni
- Gitlab CI, funzionalità di configurazione, best practice
- Fasi CI di Gitlab
- Variabili CI Gitlab
- Costruisci, testa, distribuisci
- Controllo e restrizioni dell'esecuzione: solo, quando
- Lavorare con gli artefatti
- Modelli all'interno di .gitlab-ci.yml, riutilizzando le azioni in diverse parti della pipeline
- Includi - sezioni
- Gestione centralizzata di gitlab-ci.yml (un file e push automatico ad altri repository)
Argomento n. 5: Infrastruttura come codice
- IaC: approccio all'infrastruttura come codice
- I fornitori di servizi cloud come fornitori di infrastrutture
- Strumenti di inizializzazione del sistema, creazione di immagini (packer)
- IaC utilizza Terraform come esempio
- Archiviazione della configurazione, collaborazione, automazione delle applicazioni
- Pratica di creazione di playbook Ansible
- Idempotenza, dichiaratività
- IaC utilizzando Ansible come esempio
Argomento n. 6: test dell'infrastruttura
- Test e integrazione continua con Molecule e Gitlab CI
- Utilizzando Vagrant
Argomento n. 7: 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: a cosa prestare attenzione
- Automazione basata sui dati di monitoraggio
Argomento n. 8: registrazione dell'applicazione con ELK
- Migliori pratiche di registrazione
- Pila ELK
Argomento n. 9: Automazione dell'infrastruttura con ChatOps
- DevOps e ChatOps
- ChatOps: punti di forza
- Slack e alternative
- Bot per ChatOps
- Hubot e alternative
- sicurezza
- Le migliori e le peggiori pratiche
luogo: Mosca, sala conferenze dell'hotel Sebastopoli.
date: dal 30 gennaio al 1 febbraio, 3 giorni di duro lavoro.
Fonte: habr.com