Nella nostra azienda è in corso il processo di onboarding del team SRE. Sono entrato in tutta questa storia dal lato dello sviluppo. Durante il percorso ho avuto idee e intuizioni che voglio condividere con altri sviluppatori. In questo articolo di riflessione parlo di ciò che sta accadendo, come avviene e come tutti noi possiamo viverci in futuro.
Continuazione della serie di articoli ispirati agli interventi del nostro evento interno :
2. Infrastructure as code. (Sei qui)
3. Generazione di contratti Typescript da modelli C#. (In corso…)
4. Introduzione all'algoritmo di consenso Raft. (In corso…)
…
Abbiamo deciso di creare un team SRE, realizzando le idee di . Abbiamo selezionato programmatori tra i nostri sviluppatori e li abbiamo inviati a formazione per diversi mesi.
Il team aveva le seguenti sfide formative:
- Descrivere la nostra infrastruttura, che per la maggior parte si trova in Microsoft Azure, sotto forma di codice (Terraform e tutto ciò che ne riguarda).
- Insegnare ai programmatori come lavorare con l'infrastruttura.
- Preparare i programmatori per i turni di guardia.
Introduciamo il concetto di Infrastructure as code
Nel modello tradizionale del mondo (amministrazione classica), la conoscenza dell'infrastruttura risiede in due posti:
- O sotto forma di conoscenza nelle menti degli esperti.
- O queste informazioni si trovano su alcune macchine, parte delle quali sono conosciute dagli esperti. Ma non c'è garanzia che qualcuno esterno (nel caso in cui tutta la nostra squadra decidesse all'improvviso di non esistere più) possa capire cosa e come funziona. Su una macchina possono esserci molte informazioni: accessi, cron job, dischi montati (vedi ) e semplicemente un elenco infinito di ciò che può accadere. È difficile comprendere cosa stia realmente succedendo.
In entrambi i casi ci troviamo intrappolati, diventando dipendenti da:
- o da una persona, che è mortale, soggetta a malattie, innamoramenti, sbalzi d'umore e semplici licenziamenti;
- o da una macchina fisicamente operante, che può anch'essa guastarsi, essere rubata, e presentare sorprese e inconvenienti.
Sorge naturalmente la soluzione che, idealmente, tutto deve essere trasformato in codice leggibile dagli esseri umani, mantenibile, scritto con qualità.
Pertanto, l'infrastruttura come codice (Infrastructure as Code - IaC) è la descrizione di tutta l'infrastruttura esistente sotto forma di codice, insieme agli strumenti associati per lavorarci e per tradurla in infrastruttura reale.
Perché tradurre tutto in codiceLe persone non sono macchine. Non possono ricordare tutto. La reazione di un umano e di una macchina è differente. Tutto ciò che è automatizzato funziona potenzialmente più velocemente di tutto ciò che fa una persona. La cosa più importante è avere un'unica fonte di verità (single source of truth).
Da dove provengono i nuovi ingegneri SREQuindi, abbiamo deciso di coinvolgere nuovi ingegneri SRE, ma da dove trovarli? Il libro con le risposte corrette () ci dice: dai programmatori. Infatti, loro lavorano con il codice mentre voi raggiungete uno stato ideale.
Abbiamo cercato a lungo e a fondo nel mercato del lavoro al di fuori della nostra azienda. Ma dobbiamo ammettere che non abbiamo trovato neanche uno che corrispondesse alle nostre richieste. Abbiamo dovuto dare un'occhiata tra i nostri.
Problemi dell'infrastruttura come codice
Ora diamo un'occhiata a esempi su come l'infrastruttura può essere incorporata nel codice. Il codice è ben scritto, di qualità, con commenti e rientri.
Esempio di codice da Terraform.
Esempio di codice da Ansible.
Signori, ma se fosse tutto così semplice! Noi siamo nel mondo reale, e questo è sempre pronto a sorprendervi con sorprese e problemi. Non mancano nemmeno qui.
1. Il primo problema è che, nella maggior parte dei casi, IaC è un tipo di DSL.
E un DSL, a sua volta, è una descrizione della struttura. Più precisamente, ciò che dovrebbe esserci: Json, Yaml, modifiche da alcune grandi aziende che hanno creato il proprio DSL (in Terraform si usa HCL).
Il problema è che potrebbe facilmente mancare di quelle cose familiari come:
- variabili;
- condizioni;
- in alcuni casi mancano commenti, ad esempio in Json, non sono previsti per default;
- funzioni;
- e non parlo nemmeno di cose ad alto livello come classi, ereditarietà e simili.
2. Il secondo problema di questo codice è che, molto spesso, si tratta di un ambiente eterogeneo.Di solito lavorate con C#, quindi con un linguaggio, uno stack, un ecosistema. Ma qui avete una vasta gamma di tecnologie.
È una situazione del tutto realistica quando un Bash con Python avvia un processo, nel quale viene iniettato un JSON. Lo analizzi, poi un altro generatore produce altri 30 file. Per tutto ciò, le variabili di input provengono da Azure Key Vault, estratte tramite un plugin per drone.io scritto in Go, e queste variabili vengono elaborate attraverso un YAML generato da un template jsonnet. È abbastanza difficile avere un codice ben definito quando hai un ambiente così variegato.
Nello sviluppo tradizionale, si lavora in un unico linguaggio per ogni compito. Qui, invece, ci occupiamo di un gran numero di linguaggi.
3. Il terzo problema riguarda gli strumenti.Siamo abituati a ottimi editor (Ms Visual Studio, Jetbrains Rider) che fanno quasi tutto per noi. E anche se commettiamo un errore, ci avviseranno che non abbiamo ragione. Sembra normale e naturale.
Ma da qualche parte c'è VSCode, che ha dei plugin che si installano e si supportano, oppure no. Sono uscite nuove versioni, e non sono state supportate. Un banale passaggio all'implementazione di una funzione (anche se esiste) diventa un problema complesso e non triviale. Un semplice rinominare una variabile significa effettuare un replace in un progetto di decine di file. Fortunatamente, se fa quello che deve riguardare il replace. Ci sono, ovviamente, alcuni posti con colorazione, ci sono delle completazioni automatiche, alcuni posti hanno il formattazione (anche se a me in Terraform su Windows non ha funzionato).
Al momento della scrittura dell'articolo non hanno ancora rilasciato il supporto per la versione 0.12, anche se è stata rilasciata già da 3 mesi.
È giunto il momento di dimenticare…
- Il debugging.
- Strumento di refactoring.
- Complettamento automatico.
- Rilevamento degli errori durante la compilazione.
È divertente, ma questo aumenta il tempo di sviluppo e aumenta il numero di errori che inevitabilmente si verificano.
La cosa più spaventosa è che siamo costretti a pensare non a come progettare, organizzare file in cartelle, decomporre, rendere il codice mantenibile, leggibile e così via, ma a come scrivere correttamente questo comando, perché l'ho scritto in modo errato.
Come principiante, stai cercando di comprendere Terraform, ma l'IDE non ti aiuta affatto. Quando c'è documentazione, puoi andare a guardarla. Ma se stessi entrando in un nuovo linguaggio di programmazione, l'IDE ti indicherebbe che c'è un certo tipo, mentre un altro non esiste. Almeno a livello di int o string. Questo è spesso molto utile.
E per i test?
Potresti chiedere: «E per i test, signori programmatori?» I professionisti seri testano tutto in produzione, e questo è severo. Ecco un esempio di unit test per un modulo Terraform dal sito. .
Hanno una buona documentazione. A Microsoft è sempre piaciuto il loro approccio alla documentazione e all'istruzione. Ma non c'è bisogno di essere zio Bob per capire che qui non c'è un codice perfetto. Fai attenzione alla validazione, che è spostata a destra.
Il problema dell'unit test è che possiamo verificare la correttezza del JSON in uscita. Ho passato 5 parametri e ho ottenuto un JSON di 2000 righe. Posso analizzare cosa sta succedendo qui, validare i risultati del test...
È difficile analizzare JSON in Go. Ma bisogna scrivere in Go, perché Terraform in Go è una buona pratica per testare nel linguaggio in cui si scrive. L'organizzazione del codice è molto debole. Tuttavia, è la migliore libreria per i test.
Anche Microsoft scrive i propri moduli testandoli in questo modo. Certo, è Open Source. Tutto ciò di cui parlo potete venire a ripararlo. Posso sedermi e sistemare tutto in una settimana, open source i plugin di VS Code, Terraform, creare un plugin per Rider. Potrei anche scrivere un paio di analizzatori, integrare i linter, contribuire a una libreria per i test. Posso fare tutto. Ma non è questo su cui dovrei concentrarmi.
Le migliori pratiche Infrastructure as Code
Andiamo avanti. Se in IaC non ci sono test, si è carenti in IDE e tooling, allora devono esserci almeno le migliori pratiche. Sono andato semplicemente a Google Analytics e ho fatto un confronto tra due query di ricerca: Terraform best practices e C# best practices.
Cosa vediamo? Dati implacabili che non giocano a nostro favore. La quantità di materiale è la stessa. Nello sviluppo C# siamo semplicemente sommersi da risorse, abbiamo le migliori pratiche, ci sono libri scritti da esperti e anche testi scritti da altri esperti che criticano quei libri. Un mare di documentazione ufficiale, articoli, corsi di formazione, e ora anche sviluppo open source.
Per quanto riguarda la richiesta su IaC: qui stai cercando di raccogliere informazioni dai discorsi di HashiConf o da conferenze simili, dalla documentazione ufficiale e da numerosi issue su GitHub. Come distribuire questi moduli? Cosa farne? Sembra una vera problematica... C'è una comunità, signori, dove per ogni domanda ricevi 10 commenti su GitHub. Ma non è garantito.
Sfortunatamente, in questo momento gli esperti stanno appena iniziando a emergere. Sono ancora troppo pochi. E la comunità è ancora a un livello embrionale.
Verso dove si sta muovendo tutto questo e cosa fare?
Si può tutto abbandonare e tornare a C#, nel mondo di Rider. Ma no. Perché lo faresti mai se non per trovare una soluzione? Qui di seguito, le mie conclusioni soggettive. Puoi contestare nei commenti, sarà interessante.
Personalmente, punto su alcune cose:
- Lo sviluppo in questo settore avviene molto rapidamente. Ecco un grafico delle query su DevOps.
Può sembrare un tema alla moda, ma il fatto stesso che il settore stia crescendo infonde una certa speranza.Se qualcosa cresce così rapidamente, arriveranno sicuramente persone intelligenti che diranno come fare e come non fare. L'aumento della popolarità porta a vedere che qualcuno avrà finalmente il tempo di completare un plugin per jsonnet per vscode, che permetterà di passare all'implementazione della funzione senza cercarla attraverso ctrl+shift+f. Quando tutto si sviluppa, ci sono più materiali disponibili. Lo stesso rilascio del libro di Google su SRE è un ottimo esempio.
- Esistono metodologie e pratiche consolidate nello sviluppo tradizionale che possiamo applicare con successo qui. Certo, ci sono alcune sfide legate al testing e all'ambiente eterogeneo, così come una carenza di strumenti, ma abbiamo accumulato un'enorme quantità di pratiche che possono rivelarsi utili.
Un esempio banale è il lavoro collaborativo attraverso il pair programming. Questo metodo aiuta molto a comprendere meglio le problematiche. Quando hai vicino qualcuno che sta cercando di capire, insieme arriverete a delle soluzioni migliori.
La comprensione del refactoring aiuta anche in queste situazioni a realizzarlo. Puoi scegliere di non cambiare tutto subito, ma prima di cambiare i nomi, poi riorganizzare, e infine isolare alcune parti; oh, e qui mancano dei commenti.
Conclusione
Anche se le mie riflessioni possono sembrare pessimistiche, guardo al futuro con speranza e spero sinceramente che noi (e voi) possiamo ottenere buoni risultati.
In seguito preparerò la seconda parte dell'articolo. In essa parlerò di come abbiamo provato ad applicare le pratiche di sviluppo agile per migliorare il nostro processo di apprendimento e il lavoro con l'infrastruttura.
Fonte: habr.com
