Sembrerebbe che gli sviluppatori Terraform offrano best practice abbastanza convenienti per lavorare con l'infrastruttura AWS. Solo c'è una sfumatura. Nel tempo, il numero di ambienti aumenta, le funzionalità compaiono in ciascuna. Sembra quasi una copia dello stack dell'applicazione nella regione vicina. E il codice Terraform deve essere accuratamente copiato e modificato in base ai nuovi requisiti o per creare un fiocco di neve.
Il mio rapporto riguarda i modelli in Terraform per combattere il caos e la routine manuale su progetti grandi e lunghi.
Video:
Ho 40 anni, lavoro nell'IT da 20 anni. Lavoro in Ixtens da 12 anni. Siamo impegnati nello sviluppo guidato dall'e-commerce. E pratico le pratiche DevOps da 5 anni.
La mia storia parlerà dell'esperienza in un progetto in un'azienda di cui non dirò il nome, nascondendosi dietro un patto di riservatezza.
I numeri sulla diapositiva sono indicati per comprendere la portata del progetto. E tutto ciò che dirò dopo è legato ad Amazon.
Ho aderito a questo progetto 4 anni fa. E il refactoring dell'infrastruttura era in pieno svolgimento, perché il progetto era cresciuto. E quei modelli che sono stati usati, non si adattano più. E data tutta la crescita pianificata del progetto, era necessario inventare qualcosa di nuovo.
Grazie a Matvey, che ieri ci ha raccontato cosa è successo al Dodo Pizza. Questo è quello che è successo a noi 4 anni fa.
Gli sviluppatori sono arrivati e hanno iniziato a creare il codice dell'infrastruttura.
Il motivo più ovvio per cui ciò era necessario era il tempo di commercializzazione. Era necessario assicurarsi che il team DevOps non costituisse un collo di bottiglia durante l'implementazione. E tra le altre cose, Terraform e Puppet sono stati usati al primo livello.
Terraform è un progetto open source di HashiCorp. E per coloro che non sanno affatto cosa sia, le prossime diapositive.
Infrastruttura come codice significa che possiamo descrivere la nostra infrastruttura e chiedere ad alcuni robot di assicurarsi di ottenere le risorse che abbiamo descritto.
Ad esempio, abbiamo bisogno di una macchina virtuale. Descriveremo, aggiungeremo alcuni parametri richiesti.
Successivamente, configureremo l'accesso ad Amazon nella console. E chiedi il piano Terraform. Il piano Terraform dirà: "Ok, per la tua risorsa, possiamo fare queste cose". E verrà aggiunta almeno una risorsa. E non sono previste modifiche.
Dopo che tutto ti si addice, puoi chiedere a Terraform di candidarsi e Terraform creerà un'istanza per te e otterrai una macchina virtuale nel tuo cloud.
Inoltre, il nostro progetto si sviluppa. Stiamo aggiungendo alcune modifiche lì. Chiediamo più istanze, aggiungiamo 53 voci.
E ripetiamo. Si prega di pianificare. Vediamo quali cambiamenti sono previsti. Fare domanda a. E così la nostra infrastruttura cresce.
Terraform utilizza cose come i file di stato. Cioè, salva tutte le modifiche che vanno ad Amazon in un file, dove per ogni risorsa che hai descritto, ci sono risorse corrispondenti che sono state create in Amazon. Pertanto, quando si modifica la descrizione di una risorsa, Terraform sa esattamente cosa deve essere modificato in Amazon.
Questi file di stato erano originariamente solo file. E li abbiamo archiviati in Git, il che è stato estremamente scomodo. Costantemente qualcuno si dimenticava di apportare modifiche e c'erano molti conflitti.
Ora è possibile utilizzare il backend, ad es. Terraform è indicato in quale bucket, con quale chiave deve essere salvato il file di stato. E la stessa Terraform si occuperà di ottenere questo file di stato, facendo tutta la magia e riportando il risultato finale.
La nostra infrastruttura sta crescendo. Ecco il nostro codice. E ora non vogliamo solo creare una macchina virtuale, vogliamo avere un ambiente di test.
Terraform ti consente di creare qualcosa come un modulo, ad es. descrivere la stessa cosa in una cartella.
E, ad esempio, durante i test, chiama questo modulo e ottieni la stessa cosa come se stessimo applicando Terraform nel modulo stesso. Ecco il codice per il test.
Per la produzione, possiamo inviare alcune modifiche lì, perché nei test non abbiamo bisogno di istanze di grandi dimensioni, in produzione le istanze di grandi dimensioni torneranno utili.
E poi tornerò al progetto. È stato un compito difficile, l'infrastruttura è stata pianificata molto grande. Ed era necessario in qualche modo posizionare tutto il codice in modo che fosse conveniente per tutti: per chi esegue la manutenzione su questo codice e per chi apporta modifiche. Ed era previsto che qualsiasi sviluppatore potesse andare a riparare l'infrastruttura secondo necessità per la sua parte della piattaforma.
Questo è un albero di directory consigliato da HashiCorp se hai un progetto di grandi dimensioni e ha senso dividere l'intera infrastruttura in alcuni piccoli pezzi e descrivere ogni pezzo in una cartella separata.
Avendo una vasta libreria di risorse, puoi chiamare più o meno la stessa cosa nei test e nella produzione.
Nel nostro caso, questo non era del tutto adatto, perché lo stack di test per gli sviluppatori o per i test doveva essere ottenuto in qualche modo più semplice. E non volevo passare attraverso le cartelle e applicare nella giusta sequenza, e preoccuparmi che la base aumentasse, e quindi l'istanza che utilizza questa base aumentasse. Pertanto, tutti i test sono stati avviati da una cartella. Gli stessi moduli sono stati chiamati lì, ma tutto è andato a buon fine in un'unica esecuzione.
Terraform si occupa di tutte le dipendenze. E crea sempre risorse in quella sequenza in modo che tu possa ottenere un indirizzo IP, ad esempio, da un'istanza appena creata e ottenere questo indirizzo IP nella voce route53.
Inoltre, la piattaforma è molto grande. Ed eseguire uno stack di test, anche se per un'ora, anche se per 8 ore, è un'attività piuttosto costosa.
E abbiamo automatizzato questa attività. E il lavoro di Jenkins ha consentito l'esecuzione dello stack. Era necessario avviare una richiesta pull con le modifiche che lo sviluppatore desidera testare, specificare tutte le opzioni, i componenti e le dimensioni necessarie. Se desidera test delle prestazioni, può prendere più istanze. Se ha solo bisogno di controllare che qualche modulo si apra, potrebbe iniziare dal salario minimo. E indicare anche se è necessario o meno un cluster, ecc.
E poi Jenkins ha inviato uno script di shell che ha leggermente modificato il codice nella cartella Terraform. File non necessari rimossi, aggiunti i file necessari. E poi, con una corsa di applicazione di Terraform, lo stack è salito.
E poi ci sono stati altri passaggi in cui non voglio entrare.
A causa del fatto che per i test avevamo bisogno di un po' più di opzioni rispetto alla produzione, abbiamo dovuto fare delle copie dei moduli in modo che in queste copie potessimo aggiungere quelle funzionalità che sono necessarie solo nei test.
Ed è successo così che durante i test sembra che tu voglia testare quei cambiamenti che alla fine andranno in produzione. Ma in effetti, una cosa è stata testata e nella produzione è stata utilizzata una cosa leggermente diversa. E c'è stata una piccola interruzione nello schema secondo cui in produzione tutte le modifiche venivano applicate dal team operativo. E a volte si è scoperto che quei cambiamenti che avrebbero dovuto passare dal test alla produzione, sono rimasti in un'altra versione.
Inoltre, c'era un tale problema che è stato aggiunto un nuovo servizio, leggermente diverso da quello esistente. E invece di modificare un modulo esistente, dovevi farne una copia e aggiungere le modifiche necessarie.
In effetti, Terraform non è un vero e proprio linguaggio. Questa è una dichiarazione. Se dobbiamo dichiarare qualcosa, allora lo dichiariamo. E funziona tutto.
Ad un certo punto, discutendo di una delle mie richieste pull, uno dei miei colleghi ha affermato che non è necessario produrre fiocchi di neve. Mi chiedevo cosa volesse dire. C'è un fatto così scientifico che nel mondo non ci sono due fiocchi di neve identici, sono tutti leggermente, ma diversi. E non appena l'ho sentito, ho subito sentito tutto il peso del codice Terraform. Perché quando è stato necessario passare da una versione all'altra, Terraform ha richiesto un cambio di catena di rottura, ovvero il codice non era più compatibile con la versione successiva. E ho dovuto fare una richiesta pull, che copriva quasi la metà dei file nell'infrastruttura, per portare l'infrastruttura alla versione successiva di Terraform.
E dopo che è apparso un tale fiocco di neve, tutto il codice Terraform che avevamo trasformato in un grande, grande mucchio di neve.
Per uno sviluppatore esterno che è fuori servizio, non gli importa molto, perché ha fatto una richiesta pull, la sua risorsa è stata avviata. E questo è tutto, non è una sua preoccupazione. E il team DevOps che si assicura che tutto vada bene deve apportare tutte queste modifiche. E il costo di questi cambiamenti è aumentato moltissimo con ogni fiocco di neve aggiuntivo.
C'è una storia su come uno studente in un seminario disegna due cerchi perfetti con il gesso su una lavagna. E l'insegnante è sorpreso di come sia riuscito a disegnare così bene senza una bussola. Lo studente risponde: "È molto semplice, ho trasformato un tritacarne per due anni nell'esercito".
E dei quattro anni in cui sono stato su questo progetto, ho fatto Terraform per circa due anni. E, naturalmente, ho alcuni trucchi, alcuni suggerimenti su come semplificare il codice Terraform, lavorare con esso come un linguaggio di programmazione e ridurre l'onere per gli sviluppatori che devono mantenere aggiornato questo codice.
La prima cosa con cui vorrei iniziare sono i collegamenti simbolici. Terraform ha molto codice ripetitivo. Ad esempio, chiamare un provider in quasi ogni punto in cui creiamo un pezzo di infrastruttura è lo stesso. Ed è logico metterlo in un papà separato. E ovunque sia richiesto al provider di creare collegamenti simbolici a questo file.
Ad esempio, si utilizza assume role in production, che consente di ottenere i diritti di accesso a un account Amazon esterno. E modificando un file, tutti i file rimanenti che si trovano nell'albero delle risorse avranno i diritti richiesti in modo che Terraform sappia a quale segmento Amazon accedere.
Dove i collegamenti simbolici non funzionano? Come ho detto, Terraform ha file di stato. E sono molto, molto fighi. Ma il fatto è che Terraform inizializza il backend nel primissimo. E non può usare alcuna variabile in questi parametri, devono sempre essere scritti nel testo.
Di conseguenza, quando qualcuno crea una nuova risorsa, copia parte del codice da altre cartelle. E può sbagliare con la chiave o con il secchio. Ad esempio, crea una sandbox da una sandbox e poi la realizza in produzione. E così potrebbe risultare che il secchio in produzione verrà utilizzato dalla sandbox. Certo, lo troveranno rapidamente. Sarà possibile in qualche modo risolvere questo problema, ma è comunque una perdita di tempo e, in una certa misura, di risorse.
Cosa possiamo fare dopo? Prima di lavorare con Terraform, devi inizializzarlo. Al momento dell'inizializzazione, Terraform scarica tutti i plug-in. Ad un certo punto, sono passati da un monolite a un'architettura più a microservizi. E devi sempre eseguire Terraform init in modo che estragga tutti i moduli, tutti i plug-in.
E puoi usare uno script di shell, che, in primo luogo, può ottenere tutte le variabili. Lo script Shell è illimitato. E, in secondo luogo, il modo. Se utilizziamo sempre il percorso che si trova nel repository come chiave per il file di stato, quindi, di conseguenza, l'errore verrà escluso qui.
Dove ottenere i dati? file JSON. Terraform ti consente di scrivere l'infrastruttura non solo in hcl (HashiCorp Configuration Language), ma anche in JSON.
JSON è facile da leggere da uno script di shell. Di conseguenza, puoi inserire un file di configurazione con un bucket da qualche parte. E usa questo bucket sia nel codice Terraform che nello script della shell per l'inizializzazione.
Perché è importante avere un secchio Terraform? Perché esiste qualcosa come i file di stato remoti. Cioè, quando creo una risorsa, per dire ad Amazon: "Per favore solleva un'istanza", devo specificare molti parametri richiesti.
E questi identificatori sono memorizzati in un'altra cartella. E posso prenderlo e dire: "Terraform, per favore corri al file di stato di quella stessa risorsa e procurami questi identificatori". E quindi c'è una sorta di unificazione tra diverse regioni o ambienti.
Non è sempre possibile utilizzare un file di stato remoto. Ad esempio, hai creato manualmente un VPC. E il codice Terraform che crea il VPC crea un VPC così diverso che ci vuole molto tempo e devi adattarti l'uno all'altro, quindi puoi usare il seguente trucco.
Cioè, per creare un modulo che, per così dire, crea VPC e ti fornisce identificatori, ma in realtà c'è solo un file con valori hardcoded che possono essere utilizzati per creare la stessa istanza.
Non è sempre necessario salvare il file di stato nel cloud. Ad esempio, durante il test dei moduli, è possibile utilizzare l'inizializzazione back-end, quando il file verrà salvato solo su disco al momento del test.
Ora un po 'di test. Cosa può essere testato in Terraform? Probabilmente molto è possibile, ma parlerò di queste 4 cose.
HashiCorp sa come formattare il codice Terraform. E Terraform fmt ti consente di formattare il codice che modifichi in base a tale convinzione. Di conseguenza, i test devono necessariamente verificare se la formattazione corrisponde a quella lasciata in eredità da HashiCorp, in modo da non dover modificare la posizione delle parentesi, ecc.
Il prossimo è la convalida di Terraform. Fa poco più di un controllo della sintassi - ala, tutte le parentesi sono accoppiate. Cosa è importante qui? Abbiamo un'infrastruttura molto sottile. Ha un sacco di cartelle diverse. E in ognuno è necessario eseguire Terraform validate.
Di conseguenza, per accelerare i test, eseguiamo diversi processi in parallelo utilizzando Parallel.
Il parallelo è una cosa molto interessante, usalo.
Ma ogni volta che Terraform viene inizializzato, va a HashiCorp e chiede: "Quali sono gli ultimi plugin? E il plugin che ho nella cache - è quello o no? E ha rallentato ad ogni passo.
Se Terraform ti dice dove sono i plugin, Terraform dirà: “OK, questa è probabilmente la cosa più fresca che ci sia. Non andrò da nessuna parte, inizierò subito a convalidare il tuo codice Terraform."
Per riempire la cartella con i plugin necessari, abbiamo un codice Terraform molto semplice che deve solo essere inizializzato. Qui, ovviamente, devi specificare tutti i provider che in qualche modo partecipano al tuo codice, altrimenti Terraform dirà: "Non conosco nessun provider, perché non è nella cache".
Il prossimo è il piano Terraform. Come ho detto, lo sviluppo è ciclico. Creiamo codice con modifiche. E poi devi scoprire quali modifiche sono previste per l'infrastruttura.
E quando l'infrastruttura è molto, molto grande, puoi cambiare un modulo, correggere un ambiente di test o una regione specifica e romperne uno vicino. Pertanto, è necessario creare un piano Terraform per l'intera infrastruttura e mostrare quali modifiche sono previste.
Puoi farlo in modo intelligente. Ad esempio, abbiamo scritto uno script Python che risolve le dipendenze. E a seconda di cosa è stato modificato: un modulo Terraform o solo un componente specifico, pianifica tutte le cartelle dipendenti.
Il piano Terraform deve essere fatto su richiesta. Almeno questo è quello che facciamo.
I test, ovviamente, sono buoni da fare per ogni modifica, per ogni commit, ma i piani sono una cosa piuttosto costosa. E diciamo nella richiesta pull: "Per favore, dammi i piani". Il robot si avvia. E invia ai commenti o per allegare tutti i piani che sono attesi dalle tue modifiche.
Il piano è una cosa piuttosto costosa. Ci vuole tempo perché Terraform si rivolga ad Amazon e chieda: "Questa istanza esiste ancora? Questo ridimensionamento automatico ha esattamente gli stessi parametri?". E per velocizzarlo, puoi usare un parametro come refresh=false. Ciò significa che Terraform sgonfierà lo stato S3. E crederà che lo stato corrisponderà esattamente a ciò che è in Amazon.
Tale piano Terraform è molto più veloce, ma lo stato deve corrispondere alla tua infrastruttura, ovvero da qualche parte, prima o poi deve iniziare l'aggiornamento di Terraform. L'aggiornamento di Terraform fa esattamente questo, in modo che lo stato corrisponda a ciò che si trova nell'infrastruttura reale.
E devo dire sulla sicurezza. È qui che avrebbe dovuto iniziare. Dove esegui Terraform e Terraform funziona con la tua infrastruttura, c'è una vulnerabilità. Cioè, stai essenzialmente eseguendo del codice. E se la richiesta pull contiene una sorta di codice dannoso, può essere eseguita su un'infrastruttura che ha troppo accesso. Pertanto, fai attenzione a dove avvii il piano Terraform.
La prossima cosa di cui vorrei parlare è il test dei dati utente.
Cosa sono i dati utente? In Amazon, quando creiamo un'istanza, possiamo inviare una sorta di lettera dall'istanza: i metadati. Quando viene avviata un'istanza, in genere cloud init è sempre presente su tali istanze. Cloud init legge questa lettera e dice: "OK, oggi sono un bilanciatore del carico". E secondo questi precetti, compie alcune azioni.
Ma, sfortunatamente, quando eseguiamo il piano Terraform e applichiamo Terraform, i dati dell'utente assomigliano a questo miscuglio di numeri. Cioè, ti manda solo un hash. E tutto ciò che puoi vedere nel piano è se ci saranno cambiamenti o se l'hash rimarrà lo stesso.
E se non presti attenzione a questo, alcuni file di testo battuti potrebbero andare su Amazon, nell'infrastruttura reale.
In alternativa, è possibile specificare non l'intera infrastruttura durante l'esecuzione, ma solo il modello. E nel codice, dì: "Per favore, mostrami questo modello". Di conseguenza, puoi ottenere una stampa di come appariranno i tuoi dati su Amazon.
Un'altra opzione è utilizzare un modulo per generare dati utente. Applicherai questo modulo. Scarica il file su disco. Confrontalo con il riferimento. E quindi, se qualche jun decide di correggere alcuni dati utente, i tuoi test diranno: "OK, ci sono alcuni cambiamenti qua e là - questo è normale".
La prossima cosa di cui vorrei parlare è l'applicazione di Automate Terraform.
Certo, è abbastanza spaventoso applicare Terraform in modalità automatica, perché chissà quali cambiamenti sono arrivati lì e quanto possono essere dannosi per un'infrastruttura vivente.
Per un ambiente di test, va tutto bene. Cioè, un lavoro che crea un ambiente di test è ciò di cui hanno bisogno tutti gli sviluppatori. E un'espressione come "tutto ha funzionato per me" non è un meme divertente, ma la prova che una persona si è confusa, ha alzato una pila, ha lanciato alcuni test su questa pila. E si è assicurato che lì andasse tutto bene e ha detto: "OK, il codice che rilascio è stato testato".
In produzione, sandbox e altri ambienti più critici per l'azienda, è sicuro utilizzare parzialmente alcune risorse perché non provoca la morte di nessuno. Questi sono: gruppi di scalabilità automatica, gruppi di sicurezza, ruoli, route53 e lì l'elenco può essere piuttosto grande. Ma tieni d'occhio cosa sta succedendo, leggi i report delle applicazioni automatizzate.
Laddove è pericoloso o spaventoso da utilizzare, ad esempio, se si tratta di alcune risorse persistenti, da un database, ottenere rapporti che indicano che ci sono modifiche non applicate in alcune parti dell'infrastruttura. E l'ingegnere è già supervisionato nell'eseguire lavori da applicare o farlo dalla sua console.
Amazon ha qualcosa come Terminate protection. E può proteggere in alcuni casi da modifiche che non sono necessarie per te. Quindi Terraform è andato su Amazon e ha detto "Devo uccidere questa istanza per crearne un'altra". E Amazon dice: “Scusa, non oggi. Abbiamo la protezione dalla cessazione.
E la ciliegina sulla torta è l'ottimizzazione del codice. Quando lavoriamo con il codice Terraform, dobbiamo passare un numero molto elevato di parametri al modulo. Questi sono i parametri necessari per creare un qualche tipo di risorsa. E il codice si trasforma in lunghi elenchi di parametri che devono essere passati da modulo a modulo, da modulo a modulo, soprattutto se i moduli sono nidificati.
Ed è molto difficile da leggere. È molto difficile recensire questo. E molto spesso si scopre che alcuni parametri vengono rivisti e non sono proprio quelli necessari. E costa tempo e denaro per ripararlo in seguito.
Pertanto, ti suggerisco di utilizzare qualcosa come un parametro complesso che includa un certo albero di valori. Cioè, hai bisogno di una sorta di cartella in cui hai tutti i valori che vorresti avere su un qualche tipo di ambiente.
E chiamando questo modulo, puoi ottenere un albero che viene generato in un modulo comune, ovvero in un modulo comune che funziona allo stesso modo per l'intera infrastruttura.
In questo modulo, puoi eseguire alcuni calcoli utilizzando una funzionalità così nuova in Terraform come i locali. E poi in un output, emetti una sorta di parametro complesso, che può includere hash, array, ecc.
Su questo, tutte le migliori scoperte che ho finito. E vorrei raccontare una storia su Colombo. Quando cercava soldi per la sua spedizione alla scoperta dell'India (come pensava allora), nessuno gli credeva e credeva che fosse impossibile. Poi ha detto: "Assicurati che l'uovo non cada". Tutti i banchieri, persone molto ricche e probabilmente in gamba, hanno provato a mettere l'uovo in qualche modo, ed è caduto continuamente. Poi Colombo prese l'uovo, lo premette un po'. Il guscio si accartocciò e l'uovo rimase immobile. Dissero: "Oh, è troppo facile!" E Colombo rispose: “Sì, è troppo semplice. E quando aprirò l'India, tutti useranno questa rotta commerciale".
E quello che ti ho appena detto è probabilmente cose abbastanza semplici e banali. E quando li scopri e inizi a usarli, è nell'ordine delle cose. Quindi usalo. E se queste sono cose abbastanza normali per te, almeno sai come mettere un uovo in modo che non cada.
Riassumendo:
- Cerca di evitare i fiocchi di neve. E meno fiocchi di neve, meno risorse saranno necessarie per apportare modifiche all'intera grande infrastruttura.
- Cambiamento costante. Cioè, quando si sono verificati alcuni cambiamenti nel codice, è necessario allineare la propria infrastruttura a questi cambiamenti il prima possibile. Non dovrebbe esserci una situazione in cui qualcuno arriva tra due o tre mesi per guardare Elasticsearch, fa un piano Terraform e ci sono molti cambiamenti che non si aspettava. E ci vuole molto tempo per rimettere tutto in ordine.
- Test e automazione. Più il tuo codice è coperto di test e chip, maggiore è la fiducia che hai di fare tutto bene. E la consegna automatica aumenterà la tua fiducia molte volte.
- Il codice per gli ambienti di test e di produzione dovrebbe essere quasi lo stesso. In pratica, perché in fondo la produzione è un po' diversa e ci saranno comunque delle sfumature che andranno oltre l'ambiente di test. Tuttavia, può essere fornito più o meno.
- E se hai molto codice Terraform e ci vuole molto tempo per mantenerlo aggiornato, allora non è mai troppo tardi per il refactoring e portarlo in buona forma.
- infrastruttura immutabile. Consegna AMI nei tempi previsti.
- Struttura per route53 quando hai molte voci e vuoi che siano in un ordine coerente.
- Lotta contro i limiti di velocità API. Questo è quando Amazon dice: "Ecco fatto, non posso accettare altre richieste, per favore aspetta". E metà dell'ufficio sta aspettando di poter lanciare la propria infrastruttura.
- istanze spot. Amazon non è un evento economico e gli spot ti permettono di risparmiare parecchio. E lì puoi raccontare un intero rapporto a riguardo.
- Ruoli di sicurezza e IAM.
- Cerca risorse perdute, quando hai istanze di origine sconosciuta in Amazone, mangiano soldi. Anche se le istanze costano $ 100-150 al mese, sono più di $ 1 all'anno. Trovare tali risorse è un affare redditizio.
- E istanze riservate.
Questo è tutto per me. Terraform è molto bello, usalo. Grazie!
domande
Grazie per la segnalazione! Hai un file di stato in S3, ma come risolvi il problema che diverse persone possono prendere questo file di stato e provare a distribuire?
Innanzitutto, non abbiamo fretta. In secondo luogo, ci sono flag, in cui segnaliamo che stiamo lavorando su un pezzo di codice. Cioè, nonostante il fatto che l'infrastruttura sia molto ampia, ciò non significa che qualcuno utilizzi costantemente qualcosa. E quando c'era una fase attiva, questo era un problema, tenevamo i file di stato in Git. Questo era importante, altrimenti qualcuno avrebbe creato un file di stato e dovevamo raccoglierli manualmente in un mucchio per continuare ulteriormente. Ora non c'è questo problema. In generale, Terraform ha risolto questo problema. E se qualcosa cambia costantemente, puoi usare i lucchetti che impediscono ciò che hai detto.
Stai usando open source o enterprise?
Nessuna impresa, cioè tutto ciò che puoi andare e scaricare gratuitamente.
Mi chiamo Stanislav. Volevo fare una piccola aggiunta. Hai parlato della funzione Amazon che ti consente di rendere un'istanza inarrestabile. Questo è anche nello stesso Terraform, nel blocco Life Second, puoi prescrivere un divieto di modifica o un divieto di distruzione.
Era limitato nel tempo. Buon punto.
Volevo anche chiedere due cose. Innanzitutto, hai parlato di test. Hai usato strumenti di test? Ho sentito parlare del plug-in Test Kitchen. Forse c'è qualcos'altro. E vorrei chiedere informazioni sui valori locali. In cosa differiscono sostanzialmente dalle variabili di input? E perché non posso parametrizzare qualcosa solo attraverso i valori locali? Ho provato ad affrontare questo argomento, ma in qualche modo non l'ho capito da solo.
Possiamo parlare in modo più dettagliato dietro questa sala. Gli strumenti di test sono completamente autoprodotti. Non c'è niente da testare. In generale, ci sono opzioni quando i test automatici sollevano l'infrastruttura da qualche parte, controllano che sia a posto e poi distruggono tutto con un rapporto che la tua infrastruttura è ancora in buone condizioni. Non ce l'abbiamo perché gli stack di test vengono eseguiti ogni giorno. E questo è abbastanza. E se qualcosa inizia a rompersi, allora inizierà a rompersi senza che noi lo controlliamo da qualche altra parte.
Per quanto riguarda i valori locali, continuiamo la conversazione fuori dal pubblico.
Ciao! Grazie per la segnalazione! Molto informativo. Hai detto che hai molto dello stesso tipo di codice per descrivere l'infrastruttura. Hai pensato di generare questo codice?
Ottima domanda, grazie! Il punto è che quando usiamo l'infrastruttura come codice, assumiamo di guardare il codice e di capire che tipo di infrastruttura si cela dietro questo codice. Se il codice viene generato, allora dobbiamo immaginare quale codice verrà generato per capire che tipo di infrastruttura ci sarà. Oppure generiamo il codice, lo committiamo e, di fatto, otteniamo la stessa cosa. Pertanto, siamo andati come abbiamo scritto, l'abbiamo ottenuto. Inoltre, i generatori sono apparsi poco dopo, quando abbiamo iniziato a creare. Ed era troppo tardi per cambiare.
Hai sentito parlare di jsonnet?
No.
Guarda, questa è roba davvero fantastica. Vedo un caso specifico in cui puoi applicarlo e generare una struttura dati.
I generatori sono buoni quando li hai, come nella battuta sulla macchina da barba. Cioè, la prima volta la faccia è diversa, ma poi tutti hanno la stessa faccia. I generatori sono molto belli. Ma, sfortunatamente, le nostre facce sono un po' diverse. Questo è un problema.
Guarda. Grazie!
Mi chiamo Maxim, vengo da Sberbank. Hai detto poco che hai provato a portare Terraform a un analogo di un linguaggio di programmazione. Non è più facile usare Ansible?
Queste sono cose molto diverse. Ansible può creare risorse e Puppet può creare risorse in Amazon. Ma Terraform è decisamente affilato.
Hai solo Amazon?
Non è che abbiamo solo Amazon. Abbiamo quasi solo Amazon. Ma la caratteristica fondamentale è che Terraform ricorda. In Ansible, se dici: "Prendimi 5 istanze", allora aumenterà, e poi dirai: "E ora ne ho bisogno di 3". E Terraform dirà: "Ok, ne ucciderò 2", e Ansible dirà: "Ok, eccone 3 per te". Totale 8.
Ciao! Grazie per la tua segnalazione! È stato molto interessante conoscere Terraform. Voglio solo fare un piccolo commento sul fatto che Terraform non ha ancora una versione stabile, quindi fai molta attenzione con Terraform.
Bel cucchiaio per cena. Cioè, se hai bisogno di una soluzione, a volte rimandi ciò che è instabile, ecc., Ma funziona e ci ha aiutato.
La domanda è. Stai usando il backend remoto, stai usando S 3. Perché non stai usando il backend ufficiale?
Ufficiale?
Terraformare la nuvola.
Quando è apparso?
Circa 4 mesi fa.
Se fosse apparso 4 anni fa, probabilmente avrei risposto alla tua domanda.
C'è già una funzione e blocchi incorporati e puoi memorizzare un file di stato. Provalo. Ma non ho nemmeno testato.
Siamo su un grande treno che si muove ad alta velocità. E non puoi semplicemente prendere e buttare via alcune macchine.
Stavi parlando di fiocchi di neve, perché non hai usato il ramo? Perché non è andata così?
Abbiamo un approccio tale che l'intera infrastruttura si trova in un repository. Terraform, Puppet, tutti gli script che in qualche modo si riferiscono a questo, sono tutti in un unico repository. In questo modo possiamo garantire che le modifiche incrementali vengano testate una per una. Se si trattasse di un mucchio di rami, un progetto del genere sarebbe quasi impossibile da mantenere. Passano sei mesi e divergono così tanto che è solo una specie di punizione. Questo è ciò da cui volevo scappare prima del refactoring.
cioè non funziona?
Non funziona affatto.
Nel ramo, ho ritagliato la diapositiva della cartella. Cioè, se lo fai per ogni pila di test, ad esempio, la squadra A ha il suo papà, la squadra B ha il suo papà, anche questo non funziona. Abbiamo creato un codice per l'ambiente di test unificato che fosse abbastanza flessibile da soddisfare tutti. Cioè, abbiamo servito un codice.
Ciao! Mi chiamo Jura! Grazie per la segnalazione! Domanda sui moduli. Dici che stai usando i moduli. Come si risolve il problema se sono state apportate modifiche in un modulo che non sono compatibili con la modifica di un'altra persona? In qualche modo moduli di versioning o cercando di portare un prodigio per soddisfare due requisiti?
Questo è il grande problema del cumulo di neve. Questo è ciò di cui soffriamo quando un cambiamento innocuo può rompere una parte dell'infrastruttura. E sarà evidente solo dopo molto tempo.
Cioè, non è stato ancora deciso?
Realizzi moduli universali. Evita i fiocchi di neve. E tutto funzionerà. La seconda metà del rapporto riguarda come evitarlo.
Ciao! Grazie per la segnalazione! Vorrei chiarire. Dietro le quinte c'era una grande pila, per la quale sono venuto. Come si integrano Puppet e la distribuzione dei ruoli?
dati utente.
Cioè, sputi semplicemente il file e in qualche modo esegui su di esso?
I dati dell'utente sono una nota, ad es. quando creiamo un clone dell'immagine, Daemon si alza lì e cercando di capire chi è, legge una nota che è un bilanciatore del carico.
Cioè, è una sorta di processo separato che viene dato via?
Non l'abbiamo inventato noi. Lo usiamo.
Ciao! Ho solo una domanda sui dati utente. Hai detto che ci sono problemi lì, che qualcuno potrebbe inviare qualcosa nel posto sbagliato. C'è un modo per archiviare i dati utente nello stesso Git, in modo che sia sempre chiaro a cosa si riferiscono i dati utente?
Generiamo i dati utente dal modello. Cioè, vi ricorre un certo numero di variabili. E Terraform genera il risultato finale. Pertanto, non puoi semplicemente guardare il modello e dire cosa succede, perché tutti i problemi sono legati al fatto che lo sviluppatore pensa di passare una stringa in questa variabile, e quindi viene utilizzato un array. E lui - bang e io - così e così, così e così, la riga successiva, e tutto si è rotto. Se questa è una nuova risorsa e una persona la solleva, vede che qualcosa non funziona, allora questo viene risolto rapidamente. E se questo gruppo di scalabilità automatica è stato aggiornato, a un certo punto le istanze nel gruppo di scalabilità automatica iniziano a essere sostituite. E applaudi, qualcosa non funziona. Fa male.
Si scopre che l'unica soluzione è testare?
Sì, vedi il problema, aggiungi passaggi di prova lì. Cioè, anche l'output può essere testato. Forse non così conveniente, ma puoi anche mettere dei segni - controlla che i dati dell'utente siano inchiodati qui.
Mi chiamo Timur. È molto interessante che ci siano rapporti su come organizzare correttamente Terraform .
Non ho nemmeno iniziato.
Penso che nella prossima conferenza, forse ci sarà. Ho una semplice domanda. Perché stai codificando il valore in un modulo separato anziché utilizzare tfvars, ovvero un modulo con valori migliori di tfvars ?
Cioè, dovrei scrivere qui (diapositiva: Production/environment/settings.tf): domain = variable, domain vpcnetwork, vpcnetwork variable e stvars - ottieni la stessa cosa?
Facciamo esattamente questo. Ci riferiamo, ad esempio, al modulo sorgente delle impostazioni.
In effetti, questo è un tale tfvars. Tfvars è molto utile in un ambiente di test. Ho tfvars per istanze grandi, per quelle piccole. E ho gettato un file nella cartella. E ho ottenuto quello che volevo. Quando abbiamo visto le infrastrutture, vogliamo essere in grado di vedere e capire immediatamente tutto. E quindi risulta che devi guardare qui, quindi guardare in tfvars.
Si scopre che tutto era in un posto?
Sì, tfvars è quando hai un codice. Ed è utilizzato in molti luoghi diversi con sfumature diverse. Quindi lanceresti tfvars e otterresti le tue sfumature. E noi siamo l'infrastruttura come codice nella sua forma più pura. Guardato e capito.
Ciao! Ti sei imbattuto in situazioni in cui il fornitore di servizi cloud interferisce con ciò che hai fatto con Terraform? Diciamo che modifichiamo i meta-dati. Ci sono chiavi ssh. E Google fa scivolare costantemente lì i suoi metadati, le sue chiavi. E Terraform scrive sempre che ha dei cambiamenti. Dopo ogni corsa, anche se non cambia nulla, dice sempre che aggiornerà questo campo ora.
Con le chiavi, ma - sì, parte dell'infrastruttura è interessata da una cosa del genere, ad es. Terraform non può cambiare nulla. Non possiamo nemmeno cambiare nulla con le nostre mani. Finché ci conviviamo.
Cioè, ti sei imbattuto in questo, ma non hai trovato nulla, come lo fa e lo fa da solo?
Sfortunatamente sì.
Ciao! Mi chiamo Stanislav Starkov. Posta. it Gruppo. Come risolvi il problema con la generazione di un tag su ..., come lo passi all'interno? A quanto ho capito, attraverso i dati dell'utente, per specificare il nome host, incitare Puppet? E la seconda parte della domanda. Come risolvi questo problema in SG, ovvero quando generi SG, un centinaio di istanze dello stesso tipo, come nominarle correttamente?
Quei casi che sono molto importanti per noi, li chiameremo magnificamente. Quelli che non sono necessari, c'è un post scriptum che si tratta di un gruppo di scalabilità automatica. E in teoria può essere inchiodato e ottenerne uno nuovo.
Per quanto riguarda il problema con il tag, non esiste un problema del genere, ma esiste un compito del genere. E usiamo i tag molto, molto pesantemente, perché l'infrastruttura è ampia e costosa. E dobbiamo guardare per cosa vengono spesi i soldi, quindi i tag ci consentono di capire cosa e dove sono andati. E, di conseguenza, la ricerca di qualcosa qui è un sacco di soldi spesi.
Cos'altro riguardava la domanda?
Quando SG crea cento istanze, devono essere distinte in qualche modo?
No, non farlo. Ogni istanza ha un agente che mi dice che ho un problema. Se l'agente segnala, allora l'agente sa di lui e, almeno, il suo indirizzo IP esiste. Puoi già correre. In secondo luogo, usiamo Consul for Discovery, dove non c'è Kubernetes. E Consul mostra anche l'indirizzo IP dell'istanza.
Cioè, stai prendendo di mira esattamente l'IP e non il nome host?
È impossibile navigare per nome host, ad es. ce ne sono molti. Esistono identificatori di istanza: AE, ecc. Puoi trovarlo da qualche parte, puoi inserirlo nella ricerca.
Ciao! Mi sono reso conto che Terraform è una buona cosa, adattata alle nuvole.
Non solo.
Questa è la domanda che mi interessa. Se decidi di passare, diciamo, al Bare Metal in massa con tutte le tue istanze? Ci saranno problemi? O devi ancora utilizzare altri prodotti, ad esempio lo stesso Ansible menzionato qui?
Ansible parla un po' di qualcos'altro. Cioè, Ansible è già in esecuzione quando l'istanza è stata avviata. E Terraform funziona prima dell'avvio dell'istanza. Il passaggio a Bare Metal non lo è.
Non ora, ma gli affari verranno e diranno: "Dai".
Passare a un altro cloud: sì, ma qui c'è una funzionalità leggermente diversa. Devi scrivere il codice Terraform in modo tale da poter passare a qualche altro cloud con meno spargimento di sangue.
Inizialmente, il compito era che la nostra intera infrastruttura fosse agnostica, ad es. qualsiasi cloud dovrebbe andare bene, ma a un certo punto l'azienda si è arresa e ha detto: "OK, nei prossimi N anni non andremo da nessuna parte, puoi utilizzare i servizi da Amazzonia".
Terraform ti consente di creare lavori front-end, configurare PagerDuty, documenti di dati, ecc. Ha molte code. Può praticamente controllare il mondo intero.
Grazie per la segnalazione! Faccio anche girare Terraform da 4 anni ormai. Nella fase di una transizione graduale a Terraform, all'infrastruttura, a una descrizione dichiarativa, ci siamo trovati di fronte a una situazione in cui qualcuno stava facendo qualcosa a mano e tu stavi cercando di fare un piano. E ho avuto qualche errore lì. Come affronti problemi del genere? Come trovi le risorse perdute che sono state indicate?
Principalmente con le nostre mani e i nostri occhi, se vediamo qualcosa di strano nel rapporto, allora analizziamo cosa sta succedendo lì, o semplicemente lo uccidiamo. In generale, le richieste pull sono una cosa comune.
Se c'è un errore, fai il rollback? Hai provato a fare questo?
No, questa è una decisione di una persona nel momento in cui vede il problema.
Fonte: habr.com