La nostra azienda è in procinto di assumere un team SRE. Sono entrato in tutta questa storia dal lato dello sviluppo. Nel processo, ho avuto pensieri e intuizioni che voglio condividere con altri sviluppatori. In questo articolo di riflessione parlo di ciò che sta accadendo, di come sta accadendo e di come tutti possono continuare a conviverci.
Continuazione di una serie di articoli scritti sulla base dei discorsi del nostro evento interno :
2. Infrastrutture come codice. (Tu sei qui)
3. Generazione di contratti Typescript utilizzando modelli C#. (In corso...)
4. Introduzione all'algoritmo di consenso Raft. (In corso...)
...
Abbiamo deciso di creare un team SRE, implementando le idee . Hanno reclutato programmatori tra i propri sviluppatori e li hanno mandati ad allenarsi per diversi mesi.
Il team ha avuto i seguenti compiti formativi:
- Descrivi la nostra infrastruttura, che è principalmente in Microsoft Azure sotto forma di codice (Terraform e tutto il resto).
- Insegna agli sviluppatori come lavorare con l'infrastruttura.
- Preparare gli sviluppatori al dovere.
Introduciamo il concetto di infrastruttura come codice
Nel consueto modello del mondo (amministrazione classica), la conoscenza delle infrastrutture si trova in due luoghi:
- Oppure sotto forma di conoscenza nelle teste degli esperti.
- Oppure queste informazioni si trovano su alcune macchine da scrivere, alcune delle quali sono note agli esperti. Ma non è un dato di fatto che un estraneo (nel caso in cui tutto il nostro team muoia improvvisamente) sia in grado di capire cosa funziona e come funziona. Possono esserci molte informazioni su una macchina: accessori, cronjob, intimidazione (vedi. ) disco e solo un elenco infinito di ciò che può accadere. È difficile capire cosa sta realmente accadendo.
In entrambi i casi, ci troviamo intrappolati nel diventare dipendenti:
- oppure da una persona mortale, soggetta a malattie, innamoramenti, sbalzi d'umore e semplicemente banali licenziamenti;
- oppure da una macchina fisicamente funzionante, che anch'essa cade, viene rubata e presenta sorprese e disagi.
Inutile dire che idealmente tutto dovrebbe essere tradotto in codice leggibile dall’uomo, manutenibile e ben scritto.
Pertanto, l'infrastruttura come codice (Incfastructure as Code - IaC) è una descrizione dell'intera infrastruttura esistente sotto forma di codice, nonché gli strumenti correlati per lavorare con essa e implementare l'infrastruttura reale da essa.
Perché tradurre tutto in codice?Le persone non sono macchine. Non riescono a ricordare tutto. La reazione di una persona e di una macchina è diversa. Qualsiasi cosa automatizzata è potenzialmente più veloce di qualsiasi cosa fatta da un essere umano. La cosa più importante è un’unica fonte di verità.
Da dove vengono i nuovi ingegneri SRE?Quindi abbiamo deciso di assumere nuovi ingegneri SRE, ma da dove trovarli? Prenota con le risposte corrette () ci dice: dagli sviluppatori. Dopotutto, funzionano con il codice e raggiungi lo stato ideale.
Li abbiamo cercati molto e a lungo sul mercato del personale al di fuori della nostra azienda. Dobbiamo però ammettere che non abbiamo trovato nessuno che soddisfacesse le nostre richieste. Ho dovuto cercare tra la mia gente.
Problemi Infrastruttura come codice
Ora diamo un'occhiata agli esempi di come l'infrastruttura può essere codificata nel codice. Il codice è ben scritto, di alta qualità, con commenti e rientri.
Codice di esempio da Terraforma.
Codice di esempio da Ansible.
Signori, se solo fosse così semplice! Siamo nel mondo reale, ed è sempre pronto a sorprenderti, presentarti sorprese e problemi. Non posso farne a meno neanche qui.
1. Il primo problema è che nella maggior parte dei casi IaC è una sorta di DSL.
E DSL, a sua volta, è una descrizione della struttura. Più precisamente, cosa dovresti avere: Json, Yaml, modifiche di alcune grandi aziende che hanno inventato il proprio dsl (HCL è usato in terraform).
Il problema è che potrebbe facilmente non contenere cose familiari come:
- variabili;
- condizioni;
- da qualche parte non ci sono commenti, ad esempio in Json, per impostazione predefinita non vengono forniti;
- funzioni;
- e non sto nemmeno parlando di cose di così alto livello come classi, ereditarietà e tutto il resto.
2. Il secondo problema con questo codice è che molto spesso si tratta di un ambiente eterogeneo. Di solito ti siedi e lavori con C#, ad es. con una lingua, uno stack, un ecosistema. E qui hai un'enorme varietà di tecnologie.
È una situazione molto reale quando bash con Python avvia un processo in cui è inserito Json. Lo analizzi, poi qualche altro generatore produce altri 30 file. Per tutto questo, le variabili di input vengono ricevute da Azure Key Vault, che vengono riunite da un plugin per drone.io scritto in Go, e queste variabili passano attraverso yaml, che è stato generato come risultato della generazione dal motore del modello jsonnet. È abbastanza difficile avere un codice rigorosamente ben descritto quando si ha un ambiente così diversificato.
Lo sviluppo tradizionale nell'ambito di un compito arriva con una lingua. Qui lavoriamo con un gran numero di lingue.
3. Il terzo problema è l'accordatura. Siamo abituati a fantastici editor (Ms Visual Studio, Jetbrains Rider) che fanno tutto per noi. E anche se siamo stupidi, diranno che abbiamo torto. Sembra normale e naturale.
Ma da qualche parte nelle vicinanze c'è VSCode, in cui ci sono alcuni plugin che in qualche modo sono installati, supportati o non supportati. Sono uscite nuove versioni che non erano supportate. Una banale transizione all'implementazione di una funzione (anche se esiste) diventa un problema complesso e non banale. Una semplice ridenominazione di una variabile equivale alla riproduzione di una dozzina di file in un progetto. Sarai fortunato se metterà ciò di cui hai bisogno. Ovviamente c'è la retroilluminazione qua e là, c'è il completamento automatico, da qualche parte c'è la formattazione (anche se per me non ha funzionato in Terraform su Windows).
Al momento della scrittura non sono ancora stati rilasciati per supportare la versione 0.12, sebbene sia stata rilasciata da 3 mesi.
E' tempo di dimenticare...
- Debug.
- Strumento di refactoring.
- Completamento automatico.
- Rilevamento errori durante la compilazione.
È divertente, ma questo aumenta anche i tempi di sviluppo e aumenta il numero di errori che inevitabilmente si verificano.
La cosa peggiore è che siamo costretti a pensare non a come progettare, organizzare i file in cartelle, scomporre, rendere il codice manutenibile, leggibile e così via, ma a come scrivere correttamente questo comando, perché in qualche modo l'ho scritto in modo errato .
Come principiante, stai cercando di imparare le terraforme e l'IDE non ti aiuta affatto. Quando c'è la documentazione, entra e guarda. Ma se stessi entrando in un nuovo linguaggio di programmazione, l'IDE ti direbbe che esiste un tipo del genere, ma non esiste nulla del genere. Almeno a livello di int o stringa. Questo è spesso utile.
E i test?
Chiedete: "E i test, signori programmatori?" I ragazzi seri testano tutto durante la produzione ed è dura. Ecco un esempio di test unitario per un modulo terraform dal sito Web .
Hanno una buona documentazione. Mi è sempre piaciuto Microsoft per il suo approccio alla documentazione e alla formazione. Ma non è necessario essere lo zio Bob per capire che questo non è un codice perfetto. Nota la convalida a destra.
Il problema con uno unit test è che tu ed io possiamo verificare la correttezza dell'output Json. Ho inserito 5 parametri e mi è stata data una calzatura Json con 2000 linee. Posso analizzare cosa sta succedendo qui, convalidare il risultato del test...
È difficile analizzare Json in Go. E devi scrivere in Go, perché terraformare in Go è una buona pratica per testare nella lingua in cui scrivi. L'organizzazione del codice stesso è molto debole. Allo stesso tempo, questa è la migliore libreria per i test.
La stessa Microsoft scrive i suoi moduli, testandoli in questo modo. Ovviamente è Open Source. Tutto ciò di cui sto parlando puoi venire e sistemarlo. Posso sedermi e sistemare tutto in una settimana, plug-in di codice VS open source, terraformazioni, creare un plug-in per il ciclista. Magari scrivere un paio di analizzatori, aggiungere linter, contribuire con una libreria per i test. Posso fare tutto. Ma non è quello che dovrei fare.
Migliori pratiche Infrastruttura come codice
Andiamo avanti. Se non ci sono test in IaC, l'IDE e l'ottimizzazione non sono validi, dovrebbero almeno esserci le migliori pratiche. Sono appena andato su Google Analytics e ho confrontato due query di ricerca: best practice Terraform e best practice C#.
Cosa vediamo? Le statistiche spietate non sono a nostro favore. La quantità di materiale è la stessa. Nello sviluppo in C# siamo semplicemente inondati di materiali, abbiamo pratiche eccellenti, ci sono libri scritti da esperti e anche libri scritti su libri 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 IaC: qui stai cercando di raccogliere informazioni poco a poco dai report highload o HashiConf, dalla documentazione ufficiale e da numerosi problemi su Github. Come distribuire questi moduli in generale, cosa farne? Sembra che questo sia un vero problema... C'è una comunità, signori, dove per qualsiasi domanda vi verranno dati 10 commenti su Github. Ma non è esattamente così.
Sfortunatamente, in questo momento, gli esperti stanno appena iniziando ad emergere. Ce ne sono troppo pochi finora. E la comunità stessa si trova a un livello rudimentale.
Dove sta andando tutto questo e cosa fare?
Puoi mollare tutto e tornare al C#, al mondo del rider. Ma no. Perché dovresti preoccuparti di farlo se non riesci a trovare una soluzione. Di seguito presento le mie conclusioni soggettive. Puoi discutere con me nei commenti, sarà interessante.
Personalmente scommetto su alcune cose:
- Lo sviluppo in questo settore sta avvenendo molto rapidamente. Ecco un programma delle richieste per DevOps.
L’argomento può essere esagerato, ma il fatto stesso che il settore sia in crescita dà qualche speranza.Se qualcosa cresce così rapidamente, appariranno sicuramente persone intelligenti che ti diranno cosa fare e cosa non fare. L'aumento di popolarità porta al fatto che forse qualcuno avrà il tempo di aggiungere finalmente un plugin a jsonnet per vscode, che ti permetterà di passare all'implementazione della funzione, invece di cercarla tramite ctrl+shift+f. Man mano che le cose si evolvono, compaiono più materiali. La pubblicazione di un libro di Google sull'SRE ne è un eccellente esempio.
- Esistono tecniche e pratiche sviluppate nello sviluppo convenzionale che possiamo applicare con successo qui. Sì, ci sono sfumature con i test e un ambiente eterogeneo, strumenti insufficienti, ma è stato accumulato un numero enorme di pratiche che possono essere utili e utili.
Un esempio banale: collaborazione attraverso la programmazione in coppia. Aiuta molto capirlo. Quando hai vicino un vicino che cerca di capire qualcosa, insieme capirete meglio.
Capire come viene eseguito il refactoring aiuta a eseguirlo anche in una situazione del genere. Cioè, non puoi cambiare tutto in una volta, ma cambiare la denominazione, quindi cambiare la posizione, quindi puoi evidenziare alcune parti, oh, ma non ci sono abbastanza commenti qui.
conclusione
Nonostante il mio ragionamento possa sembrare pessimistico, guardo al futuro con speranza e spero sinceramente che tutto vada bene per noi (e per voi).
Successivamente verrà preparata la seconda parte dell'articolo. In esso parlerò di come abbiamo provato a utilizzare pratiche di sviluppo agili per migliorare il nostro processo di apprendimento e lavorare con l'infrastruttura.
Fonte: habr.com