Nella nostra azienda è in corso il processo di onboarding del team SRE. Sono entrato in questa storia dal punto di vista dello sviluppo. Durante il processo, ho avuto delle idee e degli spunti che voglio condividere con altri sviluppatori. In questo articolo di riflessione parlo di cosa sta succedendo, come sta accadendo e come tutti noi possiamo convivere con tutto ciò.
Continuazione di una serie di articoli scritti ispirati agli interventi del nostro evento interno :
2. L'infrastruttura come codice. (Sei qui)
3. Generazione di contratti Typescript da modelli C#. (In corso…)
4. Introduzione all'algoritmo di consenso Raft. (In corso…)
…
Abbiamo deciso di formare un team SRE, concretizzando le idee . Abbiamo selezionato programmatori tra i nostri sviluppatori e li abbiamo inviati a formarsi per alcuni mesi.
La squadra aveva i seguenti obiettivi formativi:
- Descrivere la nostra infrastruttura, che si trova principalmente su Microsoft Azure, sotto forma di codice (Terraform e tutto ciò che ne concerne).
- Insegnare agli sviluppatori a lavorare con l'infrastruttura.
- Preparare gli sviluppatori per i turni di guardia.
Introduciamo il concetto di Infrastructure as code
Nella normale visione del mondo (amministrazione classica), le conoscenze relative all'infrastruttura si trovano in due posti:
- O in forma di conoscenze nelle teste degli esperti.
- Oppure queste informazioni sono su alcune macchine, parte delle quali sono conosciute dagli esperti. Ma non è detto che una persona esterna (nel caso in cui tutto il nostro team dovesse improvvisamente scomparire) possa capire cosa e come funziona. sulla macchina possono esserci molte informazioni: accessi, cronjob, disco montato (vedi ) e semplicemente un elenco infinito di ciò che può accadere. È difficile capire cosa accade realmente.
In entrambi i casi ci troviamo intrappolati, diventando dipendenti:
- o da una persona, che è mortale, soggetta a malattie, innamoramenti, sbalzi d'umore e semplici licenziamenti;
- o da una macchina fisicamente funzionante, che altrimenti può guastarsi, essere rubata, presentare sorprese e inconvenienti.
È naturale chiedersi che, idealmente, tutto debba essere tradotto in codice leggibile dall'uomo, mantenibile e ben scritto.
In questo modo, 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 trasformarlo in infrastruttura reale.
Perché tradurre tutto in codiceLe persone non sono macchine. Non possono ricordare tutto. La reazione di un essere umano è diversa da quella di una macchina. Tutto ciò che è automatizzato potenzialmente funziona 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 vengono nuovi ingegneri SREAllora, abbiamo deciso di coinvolgere nuovi ingegneri SRE, ma da dove trovarli? Un libro con le risposte corrette () ci dice: dagli sviluppatori. Infatti, loro lavorano con il codice e tu raggiungi uno stato ideale.
Abbiamo cercato a lungo e intensamente nel mercato del lavoro al di fuori della nostra azienda. Ma dobbiamo ammettere di non aver trovato nessuno in linea con le nostre richieste. È stato necessario setacciare tra i nostri.
Problemi dell'Infrastructure as Code
Ora diamo un'occhiata ad alcuni esempi di come l'infrastruttura può essere incorporata nel codice. Il codice è ben scritto, di qualità, con commenti e indentazioni.
Esempio di codice da Terraform.
Esempio di codice da Ansible.
Gentili signori, ma se solo tutto fosse così semplice! Siamo nel mondo reale, e questo è sempre pronto a sorprendervi, portandovi sorprese e problemi. Non mancano neanche qui.
1. Il primo problema è che nella maggior parte dei casi IaC è un qualche tipo di DSL.
E un DSL, a sua volta, è una descrizione della struttura. Più precisamente, di ciò che devi avere: Json, Yaml, modifiche fatte da alcune grandi aziende che hanno inventato il proprio DSL (in Terraform si usa HCL).
Il problema è che potrebbe facilmente non contenere quelle cose familiari, come:
- variabili;
- condizioni;
- in alcuni casi mancano i commenti, ad esempio in Json, che per impostazione predefinita non li prevede;
- funzioni;
- e non parlo ancora di cose ad alto livello come classi, ereditarietà e simili.
2. Il secondo problema di quel codice è che molto spesso si tratta di un ambiente eterogeneo. Di solito lavori e ti occupi di C#, cioè con un solo linguaggio, un unico stack, un'unica ecosistema. E qui hai una grande varietà di tecnologie.
Una situazione del tutto reale in cui un bash con Python avvia un qualche processo, nel quale viene introdotto Json. Lo analizzi, poi qualche altro generatore produce altri 30 file. Tutto ciò riceve variabili in ingresso da Azure Key Vault, che vengono estratte tramite un plugin per drone.io, scritto in Go, e queste variabili passano attraverso un yaml, generato da un motore di template jsonnet. È piuttosto complicato avere un codice ben definito quando hai un ambiente così variegato.
Nello sviluppo tradizionale, ci si occupa di un compito alla volta con un'unica lingua. Qui lavoriamo con un gran numero di lingue.
3. Il terzo problema è il tooling. Siamo abituati a editor avanzati (Ms Visual Studio, Jetbrains Rider), che fanno tutto per noi. E anche se commettiamo un errore, ci dicono che non abbiamo ragione. Sembra che sia normale e naturale.
Ma accanto c'è VSCode, che ha alcuni plugin, che vengono installati e supportati oppure no. Sono uscite nuove versioni che non sono state supportate. Un banale passaggio all'implementazione di una funzione (anche se esiste) diventa un problema complesso e non banale. Un semplice rinominare una variabile richiede una sostituzione nel progetto di una decina di file. Sarà fortunato se sostituisce ciò che serve. Certo, in certi casi c'è evidenziazione, c'è completamento automatico, in alcuni casi c'è formattazione (anche se su Terraform non funziona su Windows).
Al momento della scrittura di questo 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.
- Completamento automatico.
- Rilevamento di errori in fase di compilazione.
È ridicolo, ma questo aumenta il tempo di sviluppo e il numero di errori che inevitabilmente si verificano.
La cosa più spaventosa è che siamo costretti a non pensare a come progettare, organizzare i file, decomporre, rendere il codice manutenibile, leggibile e così via, bensì a come scrivere correttamente questo comando, perché l'ho scritto in modo sbagliato.
Come principiante stai cercando di comprendere Terraform, ma l'IDE non ti aiuta affatto. Quando c'è documentazione, ci vai e dai un'occhiata. Ma se stai entrando in un nuovo linguaggio di programmazione, l'IDE suggerirebbe che esiste un certo tipo, mentre un altro no. Almeno a livello di int o string. Questo può rivelarsi utile.
E i test?
Chiederete: «E i test, gentili programmatori?» I ragazzi seri testano tutto in produzione, ed è un approccio rigoroso. 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 alla formazione. Ma non è necessario essere zio Bob per capire che qui non c'è codice ideale. Fate attenzione alla validazione spostata a destra.
Il problema dell'unit test è che possiamo verificare la correttezza del JSON in uscita. Ho lanciato 5 parametri, e ho ricevuto una risposta JSON di 2000 righe. Posso analizzare cosa sta succedendo, convalidare il risultato del test…
È difficile analizzare il JSON in Go. Ma bisogna scrivere in Go, perché Terraform in Go è una buona pratica, testare nella lingua in cui si scrive. L'organizzazione del codice è molto debole. Tuttavia, è la miglior libreria per i test.
La stessa Microsoft scrive i suoi moduli, testandoli in questo modo. Certo, è Open Source. Tutto ciò di cui parlo puoi venire e sistemarlo. Posso sedermi e sistemare tutto in una settimana, rendere open source i plugin di VS Code, Terraform, fare un plugin per Rider. Magari scrivere un paio di analizzatori, aggiungere i linter, contribuire a una libreria per i test. Posso fare tutto questo. Ma non è ciò che devo fare.
Le migliori pratiche per l'Infrastructure as Code
Andiamo avanti. Se nell'IaC non ci sono test, c'è poca integrazione con IDE e strumenti, allora dovrebbero esserci almeno le migliori pratiche. Sono semplicemente andato su Google Analytics e ho confrontato due query di ricerca: Terraform best practices e c# best practices.
Cosa vediamo? Una statistica impietosa non a nostro favore. Per quantità di materiale è la stessa cosa. Nello sviluppo C# siamo semplicemente sopraffatti dai materiali, abbiamo pratiche eccezionali, ci sono libri scritti da esperti, e anche libri scritti da altri esperti che criticano quei libri. Un mare di documentazione ufficiale, articoli, corsi di formazione, ora c'è anche lo sviluppo open source.
Per quanto riguarda la query sull'IaC: qui stai cercando di raccogliere informazioni da relazioni di eventi come HashiConf, dalla documentazione ufficiale e numerosi issue su GitHub. Come distribuire questi moduli, cosa farne? Sembra un problema reale… C'è una community, signori, dove per ogni domanda ti daranno 10 commenti su GitHub. Ma non è detto.
Purtroppo, al momento gli esperti stanno appena iniziando a comparire. Ce ne sono ancora troppo pochi. E la comunità stessa è a un livello embrionale.
Dove sta andando tutto questo e cosa fare
Si può abbandonare tutto e tornare a C#, nel mondo del rider. Ma no. Perché dovresti occupartene, se non trovi una soluzione. Di seguito riporto le mie conclusioni soggettive. Puoi discutere con me nei commenti, sarà interessante.
Personalmente, scommetto su alcune cose:
- Lo sviluppo in questo campo sta avvenendo molto rapidamente. Riporto un grafico delle ricerche su DevOps.
Può darsi che sia un tema di moda, ma il fatto che il settore stia crescendo dà una certa speranza.Se qualcosa cresce così rapidamente, ci saranno sicuramente persone intelligenti che diranno come fare e come non fare. L'aumento della popolarità porta al fatto che qualcuno avrà il tempo di completare finalmente un plugin per jsonnet per vscode, che permetta di passare all'implementazione della funzione, invece di cercarla tramite ctrl+shift+f. Quando tutto si sviluppa, appare più materiale. Lo stesso rilascio del libro di Google su SRE è un ottimo esempio di ciò.
- Ci sono metodologie e pratiche sviluppate nello sviluppo tradizionale che possiamo applicare con successo qui. Sì, ci sono sfide legate ai test e a un ambiente eterogeneo, strumenti insufficienti, ma abbiamo accumulato un'enorme quantità di pratiche che possono tornare utili e aiutare.
Un esempio banale: lavoro collaborativo tramite pair programming. Aiuta notevolmente a capire. Quando hai un vicino che sta cercando di capire qualcosa, insieme comprenderete meglio.
La comprensione di come si effettua il refactoring aiuta anche in una situazione del genere. Cioè, puoi cambiare non tutto in una volta, ma cambiare i nomi, poi cambiare la posizione, poi magari estrarre una parte, oh, ma qui mancano dei commenti.
Conclusione
Nonostante le mie riflessioni possano sembrare pessimistiche, guardo al futuro con speranza e spero sinceramente che ce la faremo (e che anche voi ce la farete).
A breve verrà pubblicata la seconda parte dell'articolo. In essa parlerò di come abbiamo provato ad applicare pratiche di sviluppo agile per migliorare il nostro processo di apprendimento e il lavoro con l'infrastruttura.
Fonte: habr.com
