Come si decide quale tipo di componente creare?

Come si decide se creare un modulo, un'architettura distribuibile o impilare le architetture distribuibili? Confrontiamo le differenze e valutiamo i casi d'uso nelle sezioni seguenti per aiutarti a decidere.

Confronto tra architetture e moduli distribuibili

La seguente tabella fornisce un confronto e un rapido riepilogo delle differenze chiave tra moduli e tipi di architettura distribuibili.

Confronto di concetti
Metodo	Ambito	Accoppiamento	Distribuibile	Autore
Creare un modulo	Stretto	stretto	No	Sviluppatore
Creare un'architettura distribuibile	Da medio a ampio	stretto	Sì	Sviluppatore
Architetture distribuibili su stack	Ampio	Allentato	Sì	Chiunque

La tabella seguente può aiutare a decidere se utilizzare un modulo, un'architettura distribuibile o una serie di architetture distribuibili insieme, a seconda del caso d'uso.

Aiutatemi a scegliere il componente da utilizzare
Scopo	Metodo consigliato	Note
Accelera l'automazione della codifica	Utilizzare i moduli	I moduli forniscono un'automazione riutilizzabile e curata per consentire agli sviluppatori di architetture distribuibili di codificare più velocemente. I moduli sono per gli sviluppatori, non per i clienti.
Assicurarsi che il cloud sia sicuro e conforme	Utilizzare un'architettura distribuibile	Le architetture distribuibili applicano la sicurezza e la conformità per un'architettura. Se un'architettura distribuibile è troppo piccola nell'ambito, non può applicare la conformità. Ad esempio, un'architettura distribuibile che distribuisce solo una VSI (Virtual Server Instance) non può garantire la sicurezza della rete.
Dai agli utenti una scelta con guardrails	Impilare insieme le architetture distribuibili	Impilando le architetture distribuibili, è possibile scambiare le architetture distribuibili o aggiungerne altre e offrire agli utenti più scelte. Poiché le architetture distribuibili applicano la sicurezza e la conformità, lo stack aiuta a garantire che la soluzione complessiva rimanga conforme. L'accatastamento di architetture distribuibili è un approccio eccellente per questioni come la scelta del database da utilizzare.
Soluzioni o architetture create dall'utente	Impilare insieme le architetture distribuibili	L'impilamento delle architetture implementabili consente agli utenti di creare e pubblicare i propri modelli ripetibili che sono comunque sicuri, in quanto composti da architetture implementabili sicure e conformi.
Componenti dell'architettura disaccoppiati	Impilare insieme le architetture distribuibili	Le architetture distribuibili possono essere sviluppate e versionate in modo indipendente, ma poi impilate insieme per la distribuzione.
Esperienza utente semplificata	Utilizzare un'architettura distribuibile	Le architetture distribuibili possono fornire un elenco piccolo o semplice di input all'utente anche per architetture grandi o complesse. Le architetture distribuibili sono semplici da comprendere e implementare. In confronto, l'impilamento delle architetture distribuibili è un po' più complesso in quanto le architetture distribuibili sono esposte.

I progettiIBM Cloud assicurano che le risorse siano distribuite tramite architetture distribuibili dal catalogo e operino all'interno delle protezioni di sicurezza e conformità dell'organizzazione. Garantiscono inoltre che queste risorse siano mantenute aggiornate e non si spostino.

Dipendenze per architetture distribuibili

Le dipendenze sorgono quando le risorse fornite da un'architettura distribuibile sono richieste da un'altra. Ovvero, le risorse fornite da un'architettura distribuibile vengono utilizzate durante la distribuzione di un'altra architettura, come illustrato nell'immagine seguente.

Una rappresentazione visiva di un'architettura distribuibile con una dipendenza. L'architettura distribuibile A produce risorse che vengono poi utilizzate come input nell'architettura distribuibile B. — Dipendenze dell'architettura distribuibile

Un modo per lavorare con le dipendenze è impilare le architetture distribuibili e aggiungere riferimenti tra di esse in un progetto. Ad esempio, l'architettura VSI on VPC landing zone l'architettura distribuibile include una variante che estende l'architettura distribuibile di Red Hat OpenShift Container Platform su VPC landing zone. Prendi in considerazione l'idea di impilare queste architetture in un progetto. Questo approccio funziona bene se l'architettura dei prerequisiti non è ancora stata distribuita. Inoltre, non è necessario modificare il codice per impilare le architetture distribuibili.

Molte architetture distribuibili sono autonome e non sono estensioni di altre architetture, ma puoi scegliere di estendere alcune architetture distribuibili nel Architettura sezione della pagina dei dettagli del catalogo. Seleziona un'opzione da Come vuoi costruire questa architettura? menù.

Tuttavia, se hai già distribuito Red Hat OpenShift Container Platform e devi distribuire VSI, è già stato effettuato il provisioning delle risorse necessarie per VSI. Non è necessario distribuire il file Red Hat OpenShift Ancora una volta l'architettura della piattaforma container. Poiché l'architettura VSI è un'estensione di Red Hat OpenShift Container Platform, puoi distribuire VSI e l'architettura utilizza le risorse da Red Hat OpenShift Piattaforma container secondo necessità.

Architetture implementabili opzionali e intercambiabili

Quando si inserisce un'architettura distribuibile in un catalogo privato, è possibile estenderla impilandola con altre architetture. In questo modo è possibile creare una soluzione più personalizzabile per gli utenti.

Perché impilare durante l'onboarding?

L'impilamento delle architetture durante l'onboarding è simile all'impilamento delle architetture in un progetto. Quando si monta un'architettura, si possono includere le dipendenze impilando le architetture necessarie. Tuttavia, a differenza dell'impilamento delle architetture in un progetto, l'impilamento delle architetture durante l'onboarding include le seguenti funzionalità:

È possibile aggiungere architetture opzionali, adatte a diversi casi d'uso.
È possibile aggiungere architetture intercambiabili che gli utenti possono scegliere.

Architetture opzionali

Forse la vostra architettura funziona bene con un'altra architettura distribuibile, ma non è necessaria per soddisfare una dipendenza o la conformità. È possibile aggiungere l'architettura distribuibile come opzionale e gli utenti possono scegliere di includerla quando aggiungono l'architettura distribuibile a un progetto. Ad esempio, un'architettura di monitoraggio potrebbe essere utile ma non necessaria.

Architetture intercambiabili

Qualsiasi architettura impilata con la propria durante l'onboarding può essere scambiata con altre architetture. Le architetture intercambiabili offrono agli utenti la possibilità di scegliere tra più opzioni che forniscono le stesse funzionalità. Ad esempio, è possibile includere due architetture distribuibili che creano database diversi e l'utente può decidere quale opzione di database utilizzare con la vostra architettura.

Per ulteriori informazioni, vedere Estensione di un'architettura distribuibile durante l'onboarding.

Le architetture opzionali e sostituibili possono essere aggiunte man mano che si inserisce un'architettura distribuibile in un catalogo privato. Attualmente, l'impilamento delle architetture distribuibili in un progetto non supporta le architetture opzionali o intercambiabili.

Confronto tra Terraform e Ansible

In IBM Cloud, un'architettura distribuibile deve utilizzare Terraform per dichiarare gli input e gli output dell'architettura distribuibile (l'interfaccia) poiché Ansible non dispone di una definizione di interfaccia leggibile dalla macchina. Altrimenti, l'autore di un'architettura distribuibile potrebbe utilizzare qualsiasi combinazione di pre - script o post - script Ansible e Terraform per eseguire il lavoro dell'architettura distribuibile. Quindi, come fa uno sviluppatore a decidere quale tecnologia utilizzare e per cosa?

Confronto tra i linguaggi di configurazione
La prima colonna è costituita dalle categorie utilizzate per confrontare Terraform e Ansible. La seconda colonna fornisce informazioni su come Terraform si correla alla categoria set nella colonna uno e la terza colonna fornisce informazioni su come Ansible si correla alla categoria set nella colonna uno.
	Terraform	Ansible
Lingua	Dichiarativo	Procedurale
Sintassi	HCL (simile a JSON)	YAML (e callout ad altri script)
Approccio predefinito	Infrastruttura mutabile	Infrastruttura immutabile
Focus	Infrastruttura	Configurazione
Deviazione	Confronto con lo stato desiderato	Attività idempotenti

Terraform è eccellente nella creazione e nella gestione dell'infrastruttura, mentre Ansible è eccellente nella configurazione del software e dei sistemi operativi in esecuzione su tale infrastruttura. Poiché Ansible è procedurale, è anche possibile eseguire lo script di operazioni singole. Le attività di manutenzione, come il ripristino dal backup, sono semplici in Ansible.

Aiutatemi a scegliere la lingua di configurazione da utilizzare
Scopo	Lingua di configurazione consigliata	Note
Distribuisci servizi o infrastrutture cloud	Terraform	Terraform è indirizzato a questo caso d'uso ed è migliore nella gestione di infrastrutture in evoluzione. IBM Cloud fornisce moduli Terraform e architetture distribuibili supportate per accelerare i modelli di infrastruttura sicuri e conformi. Il modello di stato Terraform consente agli sviluppatori di visualizzare in anteprima le modifiche. Tali modifiche possono essere sottoposte a scansione per verificarne la conformità.
Installare o configurare il software	Ansible	Se un contenitore precostruito o un'immagine della macchina virtuale non è adatta per il caso d'uso, Ansible è migliore nella gestione dell'installazione e della configurazione del software. Ansible ha un supporto esteso per le operazioni automatizzate come le modifiche di configurazione, la gestione dei package e i riavvii dei processi. Una grande libreria di moduli Ansible e playbook è disponibile per semplificare la configurazione di migliaia di pacchetti software comunemente utilizzati.
Integrazione CCDB	Ansible	Una chiamata dinamica a un servizio in loco come un CCDB può essere effettuata in Terraform o Ansible, ma è più semplice da eseguire in un linguaggio procedurale o di script.
Convalida input	Terraform o Ansible	Terraform ha una capacità limitata di eseguire la convalida dell'input, ma è dichiarativo e può essere utilizzato dalle interfacce utente. Ansible aggiunge la capacità di eseguire la convalida dell'input dinamico in cui gli input per un'architettura distribuibile vengono controllati rispetto a un servizio remoto.
Azioni di manutenzione del giorno 2	Ansible	La manutenzione del giorno 2 è generalmente di natura procedurale e meglio completata in Ansible. Gli esempi includono il backup manuale, il ripristino o le rotazioni delle chiavi.
Gestione della deviazione	Terraform Ansible	Terraform può essere utilizzato per determinare se si è verificata la deviazione e cosa è quella deviazione, che può aiutare a decidere come gestire la deviazione. Le informazioni sulla deviazione sono potenti perché potrebbero indicare che è possibile aggiungere una modifica all'automazione. Ansible non può rilevare la deviazione. Ma riapplicando regolarmente uno script ansible idempotente, è possibile prevenire la deriva.

Per ulteriori informazioni sull'inclusione di pre - script o post - script con le tue architetture distribuibili, vedi Creazione di script per l'architettura distribuibile.

Passi successivi: Decidere dove pubblicare

Dopo aver pianificato la propria architettura e deciso quale tipo di componente creare, è necessario considerare dove si prevede di condividere o pubblicare la propria soluzione, in modo che altri utenti possano trarre vantaggio dalla soluzione creata. A seconda del punto in cui si intende condividere o pubblicare, è possibile che si disponga di diversi livelli di requisiti o approvazioni da completare.