Creazione di un'architettura distribuibile

Dopo aver eseguito la procedura per pianificare e progettare la tua architettura e decidere quale tipo di componente creare, puoi avviare la creazione di codice automatico che dà vita all'architettura. Questo argomento guida l'utente attraverso la creazione di un'architettura distribuibile composta da moduli.

Per creare un'architettura distribuibile, è necessario definire i file richiesti, creare una versione in GitHub, e quindi inserirlo in un catalogo privato in modo da poterlo condividere con altri all'interno o all'esterno della tua organizzazione.

Ci sono alcune opzioni per creare un'architettura distribuibile:

Costruire la propria: Utilizzate le seguenti istruzioni per costruire da zero la vostra architettura distribuibile.
Modificare il codice esistente: Scaricate il codice di un'architettura esistente, modificatelo per adattarlo alle vostre esigenze e create una nuova architettura distribuibile con le vostre modifiche.
Impilare le architetture: È anche possibile impilare le architetture distribuibili in un progetto, se queste architetture sono già disponibili in un catalogo.

Informazioni sulla struttura di un'architettura distribuibile

Un'architettura distribuibile, che questa documentazione descrive, è composta da 1 o più moduli. Un'architettura distribuibile è composta da quanto segue nel repository di origine:

dell'architettura dispiegabile*Anatomia dell'architettura — di un'

dispiegabile basata su terraform*

Codice Terraform: Il tuo repository di origine include File Terraform. Questi file dichiarano l'infrastruttura desiderata (stato finale) e si basano sui provider Terraform che eseguono le richieste API effettive per creare, aggiornare ed eliminare l'infrastruttura. Alcuni dei provider più utilizzati sono il provider Terraform IBM Cloud® e il provider API Helm/Kubernetes/Rest.
Script (facoltativo): Utilizzato come interruzione per funzioni che potrebbero non esistere (Bash/Python) o per attività operative ad hoc (Ansible). Per ulteriori informazioni, consultare Creazione di script per architetture distribuibili.
Test automatizzati: Test di convalida utilizzati per distribuire, verificare e distruggere l'infrastruttura. Per un esempio, vedi la directory tests nel repository di esempio sample - deployable - architectures.
Documentazione: Un diagramma dell'architettura e un file readme devono essere inclusi nel tuo repository di origine.
File manifest di catalogo: Definisce come viene esposta l'architettura distribuibile nel catalogo IBM Cloud. Oltre ai dettagli generali del catalogo, quali nome, descrizione e caratteristiche, include le definizioni delle varianti che rimandano alla configurazione Terraform sottostante, le dichiarazioni di conformità verificate durante l'inserimento nel catalogo tramite IBM Cloud® Security and Compliance Center Workload Protection e le autorizzazioni IAM necessarie per l'esecuzione dell'architettura implementabile. Per ulteriori informazioni, vedi Modifica locale del manifest di catalogo.
Varianti: Un'architettura distribuibile può includere variazioni di funzionalità o complessità. Ad esempio, è possibile creare una variazione di avvio rapido con funzionalità di base per una distribuzione semplice e a basso costo, quindi si potrebbe avere una variazione standard con un'architettura più complessa che verrebbe utilizzata in produzione. Ognuna di queste variazioni è di per sé un'architettura distribuibile, che viene caricata e configurata per apparire insieme in un catalogo. Queste variazioni hanno origine nello stesso repository in directory di lavoro differenti e sono definite nel tuo file ibm_catalog.json. Per ulteriori informazioni, vedere Creazione di una variante.

Specificare le dipendenze ed estendere l'architettura

Se l'architettura distribuibile dipende da un'altra, è possibile includere informazioni su tale dipendenza quando si inserisce l'architettura distribuibile in un catalogo. È inoltre possibile includere architetture opzionali per estendere le proprie per diversi casi d'uso. Il risultato è una soluzione personalizzabile per gli utenti, che possono scegliere quali architetture includere insieme alla propria. Per ulteriori informazioni, vedere Estensione di un'architettura distribuibile durante l'onboarding.

È anche possibile fornire informazioni su altre architetture che si desidera includere con la propria nel file manifest del catalogo per l'architettura distribuibile prima dell'onboarding.

Utilizzate la sezione dependencies nel file manifest del catalogo per creare una soluzione personalizzabile con architetture opzionali e richieste. Assicurarsi che dependency_version_2 sia impostato su true nel file manifest del catalogo. Il modo precedente di lavorare con le dipendenze nel file manifest del catalogo è ancora supportato. Con dependency_version_2 impostato su false, è possibile impostare install_type su extension e fornire informazioni sulle dipendenze nella sezione dependencies. In questo caso, ogni architettura dell'elenco delle dipendenze è necessaria per distribuire la propria. Per ulteriori informazioni e per l'impostazione di questi valori, vedere Modifica locale del manifest del catalogo.

Creazione di un'architettura distribuibile

Puoi aspettarti di completare le seguenti attività di alto livello durante la creazione della tua architettura distribuibile:

Crea il tuo repository di origine e aggiungi il codice.
Crea il tuo file manifest ibm_catalog.json per prepararti a creare un tile nel catalogo.
Creare una release.
Esegui l'onboarding del codice per creare un tile del catalogo in un catalogo privato riesaminandolo e convalidandolo.
Scegliere dove si desidera condividere o pubblicare l'architettura distribuibile.

Le seguenti istruzioni per la creazione di un'architettura distribuibile utilizzano un repository di esempio pubblico per insegnare per esempio.

Creazione del tuo repository di origine

Utilizzando i requisiti definiti dalla tua organizzazione, crea un repository GitHub che puoi utilizzare per conservare il codice sorgente per la tua architettura distribuibile. Per assistenza nella creazione di un repository, consulta la documentazione diGitHub. Se si dispone già di un repository che si desidera utilizzare, è possibile ignorare questo passo. Puoi scegliere di utilizzare un'altra organizzazione per ospitare il tuo codice sorgente, ad esempio GitLab, ma ai fini di questa documentazione, GitHub si usa.

Creazione dei file Terraform richiesti

Esamina le seguenti sezioni per comprendere quali file Terraform di base sono richiesti nel tuo repository di origine GitHub per creare il file .tgz richiesto come parte dell'onboarding della tua architettura distribuibile in un catalogo privato.

`main.tf`

Il file main.tf è il punto in cui si posiziona il codice che fornisce le risorse che si desidera creare. È possibile richiamare direttamente un modulo da terraform-ibm-modules o un modulo esterno o una risorsa del provider.

Vedere gli esempi:

`outputs.tf`

Il file di outputs.tf contiene valori di output che puoi includere nella tua architettura distribuibile.

Vedere gli esempi:

`provider.tf`

Il file provider.tf contiene la configurazione del provider come il nome del provider, la chiave API e la regione prevista dal codice.

Vedere gli esempi:

`README.md`

Il file readme contiene informazioni di background e di utilizzo sull'architettura distribuibile, incluse le sezioni di requisiti, moduli, risorse, accesso richiesto, input e output.

Se il tuo repository di origine si trova nell'organizzazione terraform-ibm-modules, viene generata la maggior parte del file readme. Quindi non si aggiungono manualmente le informazioni come gli input e gli output. I nomi delle variabili e le descrizioni vengono generati nel file readme dal file variables.tf.

Vedere gli esempi:

`variables.tf`

Il file variables.tf include le variabili obbligatorie e facoltative per l'architettura distribuibile.

Vedere gli esempi:

`version.tf`

Il file version.tf memorizza le informazioni relative alla versione Terraform e alla versione del provider necessarie per eseguire l'architettura distribuibile.

Tutti i provider Terraform richiesti per l'architettura distribuibile devono essere bloccati in una versione esatta invece di utilizzare un intervallo per assicurare risultati coerenti con l'architettura distribuibile.

Vedere gli esempi:

Creazione di un file manifest del catalogo

Il manifest del catalogo è un file nella root del tuo repository denominato ibm_catalog.json. Questo file definisce i metadati necessari per creare un riquadro in un catalogo, ad esempio il nome, la descrizione, le caratteristiche, le definizioni delle variazioni che rimandano alla configurazione Terraform sottostante, le dichiarazioni di conformità che saranno verificate durante l'onboarding utilizzando Workload Protection e le autorizzazioni IAM necessarie per implementare l'architettura. Definisce anche le configurazioni che si desidera selezionare per impostazione predefinita quando un utente tenta di distribuire la propria architettura dal catalogo. Per ulteriori informazioni, consultare Associazione dei dettagli del catalogo al file manifest.

Controlla l'esempio dal repository di esempio che mostra una variazione del tipo di estensione e fullstack.

È possibile creare il proprio file manifest del catalogo utilizzando due metodi diversi:

È possibile creare questo file da zero utilizzando il template.

Puoi avviare il processo di onboarding con il seguente esempio di base nel tuo repository di origine e quindi scaricare il file manifest dopo aver apportato le modifiche durante l'onboarding della console per aggiungere il file aggiornato al tuo repository di origine.

Di seguito è riportato un file manifest di base che è possibile aggiungere al repository e modificare per iniziare a utilizzare questa opzione.

{
    "products": [
        {
            "flavors": [
                {
                    "architecture": {},
                    "compliance": {},
                    "install_type": "fullstack"
                }
            ],
            "label": "catalog-create-sample-da-0.0.1",
            "name": "catalog-create-sample-da-0.0.1",
            "offering_icon_url": "url",
            "product_kind": "solution",
            "provider_name": "Community",
            "short_description": "A simple deployable architecture.",
            "tags": [
                "dev_ops"
            ],
            "version": "0.0.1"
        }
    ]
}

Passi successivi: eseguire l'onboarding della tua architettura distribuibile in un catalogo privato

Con una release Git creata che include i file necessari nel tuo repository di origine, puoi eseguire l'onboarding di una versione della tua architettura distribuibile e di tutte le variazioni incluse. L'onboarding è il processo di creazione di un tile di catalogo in un catalogo privato esaminando i dettagli del catalogo e convalidando una distribuzione di test e le attestazioni di conformità in IBM Cloud. Per il processo dettagliato, vedi Onboarding delle architetture distribuibili.