Il modello di configurazione esternalizzato rispecchia il modo in cui funziona la maggior parte del codice sorgente del software.
Alcuni ambienti di sviluppo mantengono nascosto il codice sorgente, come Visual Basic for Applications. Ma per i sistemi non banali, gli sviluppatori ritengono che mantenere il codice sorgente in file esterni sia più efficace. È difficile utilizzare pratiche di ingegneria Agile come TDD, CI e CD con strumenti di gestione dell'infrastruttura chiusi. Uno strumento che utilizza codice esterno per le sue specifiche non ti costringe a utilizzare un flusso di lavoro specifico. È possibile utilizzare un sistema di controllo del codice sorgente standard del settore, un editor di testo, un server CI e un framework di test automatizzato. Puoi creare pipeline di deploy utilizzando lo strumento che funziona meglio per te.
Gestisci il tuo codice in un sistema di controllo della versione
Se stai definendo il tuo ambiente come codice, inserire quel codice in un sistema di controllo della versione (VCS) è semplice ed efficace.
In questo modo si ottiene:
Tracciabilità
Un VCS fornisce una cronologia delle modifiche, chi le ha apportate e un contesto sul perché. Questa cronologia è utile durante il debug dei problemi.
Rollback
Quando una modifica inserisce un malfunzionamento, e soprattutto quando più modifiche introducono più malfunzionamenti, è utile essere in grado di ripristinare le cose esattamente come erano prima.
Correlazione
Mantenere gli script, le specifiche e la configurazione nel controllo della versione aiuta quando si traccia e si risolvono problemi nodosi. Puoi correlare tra di loro gli elementi con tag e numeri di versione.
Visibilità
Tutti possono vedere ogni modifica apportata al sistema di controllo della versione, fornendo al team consapevolezza della situazione. Qualcuno potrebbe notare che un cambiamento ha perso qualcosa di importante. Se si verifica un incidente, le persone sono consapevoli dei recenti commit che potrebbero averlo attivato.
Possibilità di azione
Il VCS può attivare automaticamente un'azione per ogni modifica confermata. I trigger abilitano i processi CI e le pipeline CD.
Una cosa che non dovresti mettere nel controllo del codice sorgente sono i secrets non crittografati, come password e chiavi. Anche se il tuo repository di codice sorgente è privato, la cronologia e le revisioni del codice sono trafugate troppo facilmente. I secrets trafugati dal codice sorgente sono una delle cause più comuni di violazioni della sicurezza.
Linguaggi di codifica dell'infrastruttura
Gli amministratori di sistema utilizzano da decenni script per automatizzare le attività di gestione dell'infrastruttura. Linguaggi di scripting generici come Bash, Perl, PowerShell, Ruby e Python sono ancora una parte essenziale del toolkit di un team di infrastruttura. CFEngine ha aperto la strada all'uso di linguaggi dichiarativi specifici del dominio (DSL) per la gestione dell'infrastruttura. Puppet e poi Chef sono emersi insieme alla virtualizzazione dei server mainstream e al cloud IaaS. Ansible, Saltstack e altri seguirono.
Strumenti orientati allo stack come Terraform e CloudFormation sono arrivati pochi anni dopo, utilizzando lo stesso modello DSL dichiarativo. I linguaggi dichiarativi hanno semplificato il codice dell'infrastruttura, separando la definizione di quale infrastruttura si desidera da come implementarla. Recentemente, c'è una tendenza a nuovi strumenti di infrastruttura che utilizzano linguaggi di programmazione generici esistenti per definire l'infrastruttura.
Pulumi e AWS CDK (Cloud Development Kit) supportano linguaggi come Typescript, Python e Java. Questi strumenti sono emersi per affrontare alcuni dei limiti dei linguaggi dichiarativi.
