Cos'è l'Infrastructure as Code?

In parole povere, Infrastructure as Code ( IaC ) consiste nell'utilizzare il codice per gestire e fornire l'infrastruttura (reti, macchine virtuali, bilanciatori di carico, cluster, servizi e topologia di connessione) in un modello descrittivo invece di processi manuali.

Con IaC, i file di configurazione definiscono l'infrastruttura, rendendo più semplice la modifica, la condivisione e il riutilizzo delle configurazioni. Codificando la tua infrastruttura, esegui il provisioning dello stesso ambiente ogni volta evitando modifiche di configurazione ad hoc non documentate.

Schematics utilizza Ansible e Terraform open source per fornire una potente serie di strumenti IaC come servizio per programmare la tua infrastruttura cloud. Con Schematics puoi utilizzare questa ricca serie di funzionalità di automazione IaC per creare stack di risorse cloud, gestirne il ciclo di vita, gestire modifiche nelle loro configurazioni, distribuire i tuoi carichi di lavoro dell'applicazione ed eseguire le operazioni day-2.

Vantaggi dell'infrastruttura come codice

L'adozione di un approccio IaC all'implementazione dell'infrastruttura risolve molti problemi comuni con il provisioning dell'infrastruttura e offre diversi vantaggi. Schematics consente di realizzare questi vantaggi senza la necessità di installare, eseguire e gestire i propri strumenti IaC.

  • Affidabilità e coerenza: viene eseguito il provisioning di nuovi ambienti o infrastrutture in modo affidabile. I processi manuali provocano errori. Con IaC le stesse configurazioni vengono distribuite più e più volte, senza differenze. IaC migliora la coerenza tra ambienti e distribuzioni.

  • Velocità: IaC ti consente di impostare rapidamente l'infrastruttura completa tramite l'automazione. Lo si applica a ogni ambiente, dallo sviluppo alla produzione, allo staging, al QA e altro ancora. Ciò può ridurre i costi man mano che diminuisce il tempo di distribuzione, gestione e manutenzione degli ambienti.

  • Traccia e responsabilità: le modifiche all'infrastruttura esistente vengono effettuate nel codice e le modifiche vengono tracciate. Come qualsiasi file di codice sorgente, si dispone della tracciabilità completa delle modifiche apportate a una configurazione.

  • Rileva e correggi la deviazione dell'ambiente: se una parte dell'infrastruttura viene modificata manualmente all'esterno del codice, può essere riportata in linea con lo stato desiderato alla prossima esecuzione. Rilevamento deviazione è una funzione degli spazi di lavoro Schematics.

Procedure consigliate

Quando si adotta IaC per il provisioning e la gestione della configurazione, ci sono alcune pratiche consigliate. Queste pratiche sono pienamente supportate quando si utilizza Schematics.

Codifica di tutto in IaC

Tutte le specifiche dell'infrastruttura devono essere esplicitamente codificate in un file di configurazione, ad esempio come configurazioni Terraform o playbook Ansible. I file di configurazione sono l'unica fonte di verità della specifica dell'infrastruttura e descrivono quali componenti dell'infrastruttura vengono utilizzati nella configurazione?

Riduci la documentazione

IaC è la documentazione. Con IaC, i file di configurazione rappresentano la documentazione e sono sempre aggiornati, il che riduce gli sforzi. La documentazione rimanente riguarda il processo. Gestire il codice in un sistema di controllo versione.

I file di configurazione IaC devono essere conservati in un VCS (version control systems), come GitHub o GitLab. Ciò fornisce una traccia di controllo per le modifiche del codice, ma offre anche l'opportunità di collaborare o di esaminare e testare le modifiche prima che siano attive.

Con questa procedura, è possibile tenere traccia, gestire e ripristinare facilmente eventuali modifiche potenziali ai sistemi, con una maggiore tracciabilità e visibilità.

Esecuzione di test

Una delle pratiche che IaC prende in prestito dallo sviluppo del software è il testing. Un test rigoroso della configurazione dell'infrastruttura svolge un ruolo nella riduzione dei problemi di post - distribuzione. Quando combinato con i sistemi di controllo della versione, il test può essere attivato automaticamente ogni volta che c'è una modifica nel codice.

Con CI (Continuous Integration) in atto, la configurazione dell'infrastruttura del template può essere implementata in più ambienti come l'ambiente development, UAT, QA o production con modifiche minime applicate in modo efficace.

Infrastruttura modulare

La suddivisione dell'infrastruttura in moduli consente il riutilizzo, una maggiore affidabilità e un percorso di adozione più semplice. Simile all'uso di moduli e pacchetti nei linguaggi di programmazione. Di seguito sono riportati i vantaggi di questa pratica.

  • Le configurazioni utilizzate di frequente possono essere codificate come moduli e riutilizzate più volte tra gli ambienti.
  • L'affidabilità aumenta quando i moduli possono essere testati e induriti nel tempo con l'uso.
  • La composizione dei moduli riutilizzabili riduce la barriera delle competenze per l'adozione di IaC.
  • Le modifiche sono più semplici da apportare e da verificare a livello di modulo.
  • Il rischio di modifica si riduce man mano che le modifiche di configurazione vengono localizzate.

Sfruttare i moduli Terraform IBM

Terraform IBM Modules(TIM) fornisce componenti infrastrutturali riutilizzabili e pronti per la produzione, progettati specificamente per IBM Cloud. Questi moduli seguono le best practice per l'infrastructure-as-code e riducono in modo significativo la complessità dell'implementazione dei servizi comuni di IBM Cloud.

Esplorate il sito Moduli Terraform IBM per scoprire i moduli precostituiti per l'infrastruttura VPC, i servizi di sicurezza, l'osservabilità e altro ancora. Ogni modulo è accuratamente testato e mantenuto dagli esperti di IBM Cloud, che ne garantiscono l'affidabilità e l'aderenza alle migliori pratiche di sicurezza.

Confronto tra approcci dichiarativi e imperativi a IaC

Con l'adozione di IaC,, un aspetto da considerare è l'approccio all'utensileria. Ci sono due stili diversi, dichiarativi o imperativi, anche a volte descritti come procedurali.

Un approccio dichiarativo definisce lo stato desiderato del sistema, incluse le risorse necessarie e le proprietà che devono avere e lo strumento configura per conto dell'utente. Lo strumento stesso determina le operazioni per raggiungere lo stato desiderato da qualsiasi punto di partenza.

Un approccio imperativo definisce invece i comandi specifici necessari per ottenere la configurazione desiderata e tali comandi devono essere eseguiti nell'ordine corretto.

Chef è pensato come uno strumento imperativo. Terraform è classificato come dichiarativo. Ansible è dichiarativo ma può essere utilizzato anche con comandi imperativi.

Dichiarative Terraform e gestione del ciclo di vita

Schematics supporta sia Terraform che Ansible come strumenti IaC con spazi di lavoro e azioni Schematics. Quando la gestione del ciclo di vita è importante e gli ambienti vengono regolarmente creati e smantellati, si consiglia di usare Terraform con gli spazi di lavoro Schematics. Terraform tiene un registro dello stato attuale dell'infrastruttura cloud distribuita e Schematics è in grado di rimuovere l'infrastruttura in ordine inverso di dipendenza senza intervento manuale.

Idempotence

Un vantaggio dell'approccio dichiarativo utilizzato da Terraform e Ansible è idempotence. Le attività idempotenti possono essere eseguite più volte con lo stesso risultato finale. Indipendentemente dallo stato precedente o dalla posizione di inizio quando si riavvia dopo gli errori, l'infrastruttura e la configurazione di cui è stato eseguito il provisioning sono sempre le stesse. Questo aspetto è fondamentale per garantire la coerenza e la ripetibilità degli ambienti distribuiti utilizzando Schematics.

Il modo in cui si utilizza uno strumento e i moduli utilizzati hanno un impatto su idempotency. In genere, i moduli Terraform e Ansible sono scritti per essere idempotenti. Con entrambi gli strumenti, il codice può essere scritto che non produce un risultato idempotente. In tal caso, la configurazione potrebbe uscire dallo stato di destinazione desiderato. Con Terraform questa forma di deviazione è molto probabile quando null-resources viene utilizzata per estendere la funzionalità del provider con script personalizzati che non sono idempotenti.

L'immutabilità è una pratica IaC che riduce il rischio di deviazione dallo stato di destinazione.

Inalterabile

L'infrastruttura immutabile si riferisce alla gestione di servizi e distribuzioni software in cui le risorse come i contenitori o le macchine virtuali vengono sostituite piuttosto che modificate (utilizzando gli script). Il desiderio principale qui per l'immutabilità è evitare la deriva della configurazione. Incongruenze che si verificano a causa di modifiche locali o manuali o differenze nella sequenza delle operazioni automatizzate. Le modifiche che rendono più difficile il debug e la risoluzione dei problemi e aumentano i costi di supporto.

Per garantire l'immutabilità ed eliminare la deviazione, tutte le modifiche devono essere effettuate tramite la configurazione IaC Schematics e le risorse come le VSI devono essere ridistribuite quando devono essere aggiornate.

Passi successivi

Ora che avete capito di più su IaC, perché non rivedete l'uso di IaC in Schematics: