Procedure ottimali per la creazione di architetture distribuibili

Un' architettura distribuibile è un'unità modulare e autonoma di automazione cloud che combina una o più risorse cloud per fornire un pattern architetturale comune. Consente l'implementazione, la scalabilità e la modularità semplificate, consentendo agli utenti di eseguire facilmente il provisioning e gestire le risorse dell'infrastruttura.

Questa guida illustra le procedure ottimali per la creazione di architetture distribuibili ben progettate e manutenibili, scritte in Terraform. Concentrarsi su attributi chiave come ambito, componibilità, consumabilità e controlli di qualità aiuta a garantire soluzioni solide e affidabili. La sezione finale di questa guida fornisce riferimenti a strumenti e modelli che consentono di implementare queste pratiche.

Queste procedure ottimali si applicano alla creazione di architetture distribuibili con Terraform. Per ulteriori informazioni, vedi Creazione di un'architettura distribuibile.

Principi della progettazione

Ambito, componibilità e consumabilità sono i tre principi di progettazione principali che è necessario considerare quando si crea un'architettura distribuibile.

Nella fase di pianificazione e ricerca, è necessario valutare l'ecosistema corrente di offerte e valutare il caso di utilizzo e i requisiti di business. Utilizzare Well - Architected Framework e Architecture Design Framework per pianificare e progettare i componenti necessari per l'architettura.

Ambito

Un ambito ben definito per l'architettura distribuibile è fondamentale, poiché dovrebbe essere sufficientemente completo da includere tutte le risorse necessarie, ma sufficientemente mirato per evitare inutili complessità.

Una procedura ottimale consiste nell'includere le risorse dell'infrastruttura che vengono generalmente distribuite insieme come un'unità, richiedono autorizzazioni e diritti di accesso simili e hanno lo stesso ciclo di vita. Ad esempio, consideriamo l'VPC landing zone. Questa architettura distribuibile dispone di un ambito ben definito che comprende le seguenti risorse dell'infrastruttura:

Risorse nella zona VPC landingn DA
Risorsa	Descrizione
VPC	Crea una topologia VPC sicura
Infrastruttura di rete	Include sottoreti, gateway pubblici, ACL, gateway di transito e gruppi di sicurezza
Rete edge	Isola il traffico verso l'internet pubblico
Monitoraggio e registrazione	Integra i Flow Log per l'osservabilità e il controllo del traffico VPC

Queste risorse sono di solito distribuite insieme come un'unità, richiedono autorizzazioni e diritti di gestione di rete simili e hanno lo stesso ciclo di vita, il che significa che:

Vengono creati insieme, ad esempio quando viene eseguito il provisioning di un nuovo VPC con le relative sottoreti, gateway pubblici e gruppi di sicurezza associati.
Vengono aggiornati insieme, ad esempio quando viene effettuata una modifica alla configurazione di rete del VPC, che richiede aggiornamenti alle sottoreti, ai gateway pubblici e ai gruppi di sicurezza.
Vengono eliminati insieme, ad esempio quando un VPC viene disattivato e tutte le sue risorse associate, incluse le sottoreti, i gateway pubblici e i gruppi di sicurezza, vengono rimossi.

Componibilità

Un principio fondamentale di un'architettura implementabile è la componibilità, che consente di creare un'architettura implementabile più ampia sovrapponendo più architetture implementabili. Questo approccio modulare consente la massima flessibilità e riutilizzabilità delle risorse di automazione.

Per ottenere la componibilità, un'architettura distribuibile deve essere progettata per:

Massimizza la quantità di informazioni emerse attraverso i valori di output, mantenendo però semplici i tipi di output. Questa pratica consente all'automazione dell'architettura distribuibile di essere riutilizzata in una vasta gamma di scenari e la rende un elemento costitutivo versatile per varie soluzioni automatizzate.
Consenti riferimenti facoltativi alle risorse distribuite esistenti, come ad esempio i gruppi di risorse, le istanze IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services e le istanze IBM Cloud Secrets Manager, tra le altre. Gli utenti possono quindi configurare le istanze esistenti o eseguire la distribuzione in gruppi di risorse esistenti, aumentando la versatilità dell'automazione. L' architettura distribuibileSecrets Manager è un ottimo esempio di questo principio in azione. Consentendo agli utenti di riutilizzare le istanze, i gruppi di risorse e la chiave di codifica KMS Secrets Manager esistenti, questa automazione fornisce un alto grado di flessibilità e adattabilità. Ad esempio, puoi:
- Configura un'istanza Secrets Manager esistente passando il suo ID e crea gruppi di segreti nell'istanza esistente.
- Integra con un sistema di gestione delle chiavi esistente come Key Protect o Hyper Protect Crypto Services.
- Distribuire in un gruppo di risorse esistente o crearne uno nuovo con convenzioni di denominazione personalizzabili.

In alternativa, questa architettura distribuibile consente anche la creazione di una nuova istanza Secrets Manager, un nuovo gruppo di risorse e altre risorse da zero, fornendo una soluzione autonoma.

Grazie alla componibilità, un'architettura distribuibile può essere facilmente integrata in un'architettura di soluzione più complessa sovrapponendola ad altre architetture distribuibili. Ad esempio, il modello Retrieval Augmented Generation dimostra come più architetture implementabili, compresa l'architettura implementabile Secrets Manager, possano essere combinate per costruire una soluzione complessa. Le architetture distribuibili, progettate tenendo conto della componibilità, costituiscono la base per queste soluzioni complesse.

Quando le architetture distribuibili sono impilate insieme, ogni architettura distribuibile membro mantiene il proprio stato di configurazione indipendente, consentendo la distribuzione, l'aggiornamento o la disinstallazione individuale. Questo approccio modulare consente di ricavare garanzie di costo, conformità, supporto e qualità dalle architetture implementabili incluse, mentre la soluzione complessiva rimane una versione unica con le proprie descrizioni e architetture di riferimento. Per ulteriori informazioni, consultare Cosa significa impilare architetture distribuibili?

Possibilità di utilizzo

Un'architettura distribuibile deve essere progettata tenendo presente la consumabilità, rendendo più semplice per gli utenti comprendere e distribuire. A tale scopo, l'architettura distribuibile deve fornire una documentazione completa che includa quanto segue:

Prerequisiti: Dipendenze software e requisiti dell'infrastruttura necessari per la distribuzione.
Descrizioni dettagliate delle variabili di input e dei valori di output: Include lo scopo, il tipo di dati e i valori predefiniti.
Autorizzazioni minime necessarie: Autorizzazioni richieste per eseguire l'automazione dell'architettura distribuibile.
Diagrammi e mappe dell'architettura: Rappresentazioni visive dei componenti e delle relazioni dell'architettura distribuibile.
Configurazione semplificata: Facile da implementare e gestire.
Requisiti di risorse ridotti: Ottimizza l'architettura distribuibile per ridurre i requisiti hardware e di risorse, riducendo i requisiti di CPU e memoria, rendendoli più economici ed efficienti.
Distribuzione semplificata: Più veloce e più facile da iniziare.

Un altro aspetto per garantire che l'architettura distribuibile sia facilmente utilizzabile consiste nel fornire più varianti, inclusa una variazione di avvio rapido. È necessario fornire una versione di avvio rapido dell'architettura distribuibile, che è più economica e più veloce da eseguire. Ad esempio, la variazione QuickStart dell'architettura distribuibile Red Hat OpenShift Container Platform on VPC landing zone crea un ambiente VPC (Virtual Private Cloud) completamente personalizzabile in una singola regione, fornendo un singolo cluster Red Hat OpenShift in un VPC sicuro per i workload. Questa variazione di avvio rapido è progettata per scopi di dimostrazione e sviluppo e costa meno di $400 al mese per l'esecuzione.

Al contrario, la versione standard dell'architettura distribuibile Red Hat OpenShift Container Platform on VPC landing zone, basata sull'architettura di riferimento IBM Cloud Framework for Financial Services, crea un carico di lavoro sicuro e conforme Red Hat OpenShift Container Platform su una rete VPC (Virtual Private Cloud), ma costa più di $4.000 al mese per l'esecuzione. Inoltre, include funzioni avanzate quali il servizio VPC di gestione, il servizio VPC del carico di lavoro, l'isolamento del VPC di gestione e del VPC del carico di lavoro e le decisioni dell'architettura di sicurezza della rete avanzata.

Variabili di input

rendere più semplice per gli utenti configurare le variabili di input dell'architettura distribuibile utilizzando le seguenti procedure ottimali:

Esponi solo argomenti modificati comunemente: Esponi solo le variabili che la maggior parte degli utenti dovrà modificare, evitando le architetture distribuibili con un numero elevato di variabili di input che sovraccaricano gli utenti. Per gli utenti avanzati, considerare la possibilità di fornire un singolo campo di input JSON per un'ulteriore personalizzazione. Come esempio, l'architettura distribuibile della zona di destinazione VPC presenta un singolo campo denominato override_json_string che fornisce il controllo completo agli utenti avanzati sulla topologia distribuita. Per ulteriori informazioni, vedi la guida alla distribuzione della zona di destinazione VPC.
Utilizza denominazione chiara e descrittiva per le risorse esistenti: Quando si fa riferimento a risorse esistenti, utilizzare nomi che indicano chiaramente a cosa si riferiscono, ad esempio existing_cluster_name invece di cluster_name, per evitare ambiguità.
Preferisci nomi a ID: Quando si fa riferimento a risorse esistenti, utilizzare i nomi invece degli ID per una migliore fruibilità da parte dell'utente.
Evita acronimi: Invece di utilizzare gli acronimi, utilizzare i nomi dei prodotti completi per rendere più semplice per le persone che non hanno familiarità con i prodotti o i servizi comprendere a cosa si riferiscono. Ad esempio, secrets_manager invece di sm o key_management invece di kms.
Utilizza funzionalità di digitazione avanzate: Per abilitare il servizio Progetti IBM Cloud a eseguire il rendering dei widget di input appropriati per le variabili, il che rende più semplice per gli utenti configurare i valori. Ad esempio:

Regione VPC: un elenco a discesa di tutte le regioni VPC disponibili su IBM Cloud.
Chiave SSH VPC: un campo di input sicuro per la gestione delle chiavi SSH.
Cluster: un elenco a discesa dei cluster disponibili su IBM Cloud.

Per ulteriori informazioni, vedi Modifica locale dei valori manifest del catalogo.

Seguendo queste linee guida, l'architettura distribuibile può essere resa più utilizzabile, consentendo agli utenti di comprenderla e distribuirla rapidamente.

Qualità

Per garantire che l'architettura distribuibile sia affidabile e coerente, è essenziale implementare e automatizzare i controlli di qualità. Questi controlli devono coprire vari aspetti dell'architettura distribuibile, inclusa la qualità del codice, la convalida della configurazione, il test e l'integrazione continua.

qualità codice

Sfrutta il linting e la formattazione del codice. Applica stili di codifica e formattazione coerenti per semplificare la lettura e la manutenzione del codice. Rileva errori e avvertenze nel codice per evitare problemi durante la distribuzione. Considera di andare oltre il semplice codice Terraform, ma incorpora tutti gli strumenti pertinenti a tutte le risorse nella tua architettura distribuibile, come gli script Bash, gli script Python, i file YAML e JSON e Golang.

Esempi:

terraform_fmt per formattare il codice Terraform.
go-fmt per formattare il codice Go.
black per formattare il codice Python.
isort per ordinare le importazioni Python.
flake8 per verificare la presenza di errori e avvertenze nel codice Python.
shellcheck per verificare la presenza di errori e avvertenze negli script della shell.
golangci-lint per verificare la presenza di errori e avvertenze nel codice Go.

Convalida della configurazione

Utilizzare la convalida statica per verificare che la sintassi e la configurazione dell'architettura distribuibile siano corrette e congruenti. Convalidare la configurazione dell'architettura distribuibile per evitare errori durante la distribuzione. Di nuovo, considera di andare oltre il semplice codice Terraform e incorporare qualsiasi strumento pertinente a tutte le risorse nella tua architettura distribuibile, come gli script Bash, gli script Python, i file YAML e JSON e Golang.

Esempi:

terraform_validate per convalidare la configurazione Terraform.
checkov per controllare i problemi di sicurezza e conformità nel codice Terraform.
tflint per verificare la presenza di errori e avvertenze.
detect-secrets per rilevare i segreti nel codice.
hadolint per controllare i file Docker per errori e avvertenze.
helmlint per controllare i grafici Helm per errori e avvertenze.

Esecuzione di test

Quando si tratta di testare il codice dell'infrastruttura, non c'è un puro test di unità nel modo in cui potresti pensarlo per il codice dell'applicazione. Invece, la strategia di test implica la distribuzione dell'infrastruttura in un ambiente reale, la convalida del suo funzionamento e l'annullamento della sua distribuzione.

Suite di test di convalida automatizzata

Il consiglio è di avere una suite di test automatizzata di base che copra i seguenti fondamentali:

Test di distribuzione: Verificare che il codice dell'infrastruttura possa essere distribuito correttamente in un ambiente reale. Creare tutte le risorse necessarie, come macchine virtuali, database e reti. Questi test aiutano a garantire che il codice dell'infrastruttura sia corretto e che possa essere applicato correttamente a un ambiente reale. Si consiglia di variare i parametri di input dell'architettura distribuibile in questi test per assicurare un'ampia copertura allineata all'uso comune.
Prove di distruzione: Verificare che il codice dell'infrastruttura possa essere correttamente annullato o distrutto, rimuovendo tutte le risorse create. Questi test garantiscono che il codice dell'infrastruttura possa essere rimosso in modo sicuro da un ambiente reale, senza lasciare indietro le risorse orfane o causare conseguenze indesiderate.
Test di idempotenza: Verificare che il codice dell'infrastruttura possa essere riapplicato più volte senza causare modifiche o errori indesiderati. In altre parole, il codice dovrebbe produrre lo stesso risultato indipendentemente dal numero di volte in cui viene applicato. Questi test sono critici in ambienti come IBM Cloud, dove la piattaforma controlla periodicamente la presenza di modifiche per rilevare la deviazione tra l'infrastruttura distribuita e l'origine della verità, che è il codice di automazione. I test di idempotency aiutano a garantire che il codice dell'infrastruttura possa gestire distribuzioni o aggiornamenti ripetuti senza causare problemi. Questi test consentono inoltre di garantire che le funzioni di rilevamento della deviazione possano identificare e correggere in modo accurato eventuali discrepanze tra lo stato previsto e lo stato effettivo dell'infrastruttura. Per ulteriori informazioni, vedi Gestione della deviazione.
Test di aggiornamento versione: Verificare che il codice dell'infrastruttura possa essere aggiornato correttamente da una versione all'altra, senza causare errori o modifiche indesiderate. Questi test garantiscono che il codice dell'infrastruttura possa essere aggiornato in modo sicuro, senza interrompere o distruggere le risorse esistenti o causare conseguenze indesiderate.

Scenari di test avanzati

Gli scenari di test avanzati includono scenari quali:

Distribuzione dell'architettura distribuibile più volte nello stesso account: Verifica che il codice dell'infrastruttura possa gestire più distribuzioni nello stesso account, senza causare conflitti di nomi di risorse o altri problemi.
Distribuzione dell'architettura distribuibile con un profilo attendibile: Verifica che il codice dell'infrastruttura possa essere distribuito con un profilo attendibile Cloud Identity and Access Management. Per ulteriori informazioni, consultare Definizione di un metodo di autenticazione.

Includendo questi test nella tua suite di test automatizzata, puoi garantire che il codice della tua infrastruttura sia affidabile, solido e sicuro da distribuire alla produzione.

Integrazione continua

Per garantire l'affidabilità, la congruenza e la manutenibilità dell'architettura distribuibile, si consiglia un approccio shift - left, in cui i test e i controlli di qualità sono integrati all'inizio del ciclo di sviluppo. Questo approccio consente di individuare tempestivamente errori e difetti, riducendo la probabilità di problemi a valle e migliorando la qualità complessiva.

Nell'ambito di questo approccio, si raccomandano i seguenti controlli di qualità:

Controllo qualità lato client: Git commit hooks lato client deve essere utilizzato per eseguire i controlli sulla macchina sviluppatore prima di eseguire il commit del codice. Ciò include i controlli per gli standard di codifica, gli errori di sintassi e i dati sensibili. Strumenti come Pre - commit possono essere utilizzati per automatizzare questo processo.
Pratiche CI: Devono essere seguite le migliori pratiche per l'integrazione continua (IC). Le pratiche generali per qualsiasi prodotto di progettazione software si applicano allo sviluppo di architetture distribuibili, inclusi:

Lavorare con piccole richieste di pull (PR) mirate per facilitare revisioni tempestive e ridurre i conflitti di unione.
Integrazione delle modifiche al codice nel ramo principale su base regolare per prevenire i rami delle funzioni di lunga durata e ridurre la complessità di unione.
Implementazione di test automatizzati e revisioni del codice per garantire la coerenza e la qualità del codice.
Convalida continua della configurazione e sintassi dell'architettura distribuibile per garantire la correttezza e la coerenza.

Pipeline IC: È necessario configurare una pipeline CI per automatizzare queste pratiche, garantendo che ogni modifica del codice nell'architettura distribuibile venga sistematicamente verificata e convalidata. Questa pipeline garantisce che l'architettura distribuibile funzioni correttamente e in modo congruente e che eventuali errori o difetti vengano rilevati in anticipo.

Strumenti e risorse

Viene fornita una serie completa di strumenti e risorse per facilitare la creazione di architetture distribuibili di alta qualità. I moduli Terraform curati sono un elemento chiave, con oltre 60 + moduli riutilizzabili, sicuri e convalidati che coprono una vasta gamma di esigenze infrastrutturali. Questi moduli sono disponibili su GitHub e sono supportati e mantenuti aggiornati tramite un modello di contributo open source e supportati dai contributi dell'organizzazione di sviluppo IBM Cloud.

Oltre ai moduli Terraform curati, vengono forniti anche best practice e modelli per aiutare con l'architettura distribuibile e la creazione di moduli. Questo include la documentazione, un modello di repository di architettura distribuibileGitHub allineato con le procedure ottimali per la creazione e le linee guida per la creazione di moduli che si applicano sia ai moduli Terraform che alle architetture distribuibili basate su Terraform. Queste risorse possono essere utilizzate per iniziare rapidamente a utilizzare una nuova architettura distribuibile.

Viene inoltre fornito un framework di test automatizzato, basato sulla libreria Terratest, con test scritti in Go. Il framework copre i test di idempotenza, i test di aggiornamento e GitHub, e utilizza le funzioni di aiuto ai test della libreria https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper. Per ulteriori informazioni, vedi la nostra documentazione di test.

Per supportare lo sviluppo di pipeline CI, sono disponibili una gamma di strumenti e risorse, tra cui:

GitHub Azioniriutilizzabili.
Generazione automatizzata della documentazione.
Onboarding automatizzato per IBM Cloud.
Aggiornamenti delle dipendenze automatizzati utilizzando il rinnovo personalizzato.
Configurazione degli strumenti di configurazione dello sviluppo locale e degli hook di pre - commit, consulta la nostra Documentazione sull'impostazione dello sviluppo locale per ulteriori informazioni.

Questi strumenti e risorse sono progettati per accelerare e facilitare la creazione di architetture distribuibili di alta qualità.

Passi successivi

Ora che comprendi le procedure ottimali per la creazione di un'architettura distribuibile, puoi utilizzare gli strumenti e le risorse ed esaminare la seguente documentazione IBM Cloud prima di sviluppare il tuo codice di automazione. Questo ti aiuta a garantire di aver pianificato e progettato a fondo la tua soluzione da condividere in IBM Cloud:

Pianificazione e ricerca di un'architettura per garantire che si stia progettando un'architettura che sia un modello riutilizzabile valido che soddisfi i requisiti di business.
Come si decide quale tipo di componente creare? per assicurarsi di aver compreso le differenze tra la creazione di un modulo, la creazione di un'architettura distribuibile e l'accatastamento di architetture distribuibili.
Come decido dove condividere la mia soluzione? per assicurarti di soddisfare i requisiti in base a dove intendi condividere o pubblicare la tua soluzione.