Creazione di script per architetture distribuibili
È possibile disporre di script eseguiti per le proprie architetture distribuibili prima o dopo la convalida, la distribuzione e l'annullamento della distribuzione. Gli script sono configurati per una specifica versione della tua architettura distribuibile e devono essere eseguiti e convalidati attraverso i progetti. Per ulteriori informazioni sui progetti, consultare Creazione di un progetto.
Esistono diversi vantaggi e casi di utilizzo per l'utilizzo degli script per le architetture distribuibili:
- Esecuzione della convalida personalizzata, ad esempio, se si desidera verificare che il parametro
tagsia sempre un ID centro di costo valido. Lo script di pre - convalida potrebbe richiamare un servizio per verificare che l'ID del centro di costo sia valido. - Traccia delle distribuzioni e aggiunta di risorse, ad esempio, aggiunta a un sistema di inventario fornendo uno script di post - distribuzione che può richiamare un servizio per tenere traccia delle risorse distribuite.
- Completamento della migrazione dei dati. Uno script di pre - distribuzione può eseguire il backup dei dati. Quindi, dopo che l'architettura distribuibile ha eliminato il vecchio archivio dati e ne ha creato uno nuovo, lo script di post - distribuzione può ripristinarlo nel nuovo archivio dati.
- Installazione o configurazione del software
- Completamento delle attività di manutenzione del secondo giorno, come il backup manuale, il ripristino o le rotazioni delle chiavi.
Aggiunta di pre - script e post - script
Gli script sono facoltativi per un'offerta, ma se vengono utilizzati devono trovarsi nel repository di origine in una directory denominata scripts. I file di script devono essere conformi alla seguente convenzione di denominazione
<action>-<stage>-ansible-playbook.yaml. Le opzioni per action includono deploy, validate e undeploy. Le opzioni per stage includono pre e post.
Attualmente sono supportati solo script ansible nel formato playbook.
Devi anche fare riferimento agli script nel file manifest ibm_catalog.json nel tuo repository di origine. Fornire le informazioni richieste per gli script per variazione della propria architettura distribuibile nell'array scripts:
"scripts": [
{
"type": "ansible",
"short_description": "Short description of what your script is intended to do.",
"path": "Path to script location.",
"stage": "The stage. For example, pre.",
"action": "The action. For example, validate."
}
],
Puoi aggiungere queste informazioni al tuo file manifest del catalogo nel repository di origine prima di eseguire l'onboarding in IBM Cloudoppure puoi aggiungere manualmente gli script durante il flusso di lavoro di onboarding nella console. Se aggiungi manualmente gli script durante l'onboarding, scarica il tuo file manifest e aggiungalo al tuo repository di origine per mantenere le informazioni sincronizzate per le versioni future.
Tutti gli script devono essere in grado di essere eseguiti più di una volta senza errori. Ad esempio, uno script di pre - distribuzione o post - distribuzione deve funzionare correttamente, anche se viene eseguito più volte. Gli script di post - distribuzione potrebbero aggiungere risorse a un database di gestione del catalogo e devono essere sicuri di non aggiungere risorse duplicate se eseguite più di una volta.
Esempi pre e post - script
Di seguito viene riportato un esempio di pre - script utilizzato per visualizzare un messaggio dopo la convalida dell'architettura distribuibile. I pre - script vengono passati a tutti gli input dall'architettura distribuibile, incluse le credenziali utilizzate per autorizzare la distribuzione.
- name: Validate pre playbook
hosts: localhost
vars:
ibmcloud_api_key: "{{ lookup(`ansible.builtin.env`, `ibmcloud_api_key`)}}"
cos_instance_name: "{{ lookup(`ansible.builtin.env`, `cos_instance_name`)}}"
workspace_id: "{{ lookup(`ansible.builtin.env`, `workspace_id`)}}"
tasks:
- name: Print message
ansible.builtin.debug:
msg: "The workspace id is {{ workspace_id }}"
when: workspace_id is defined and workspace_id != ""
- name: Print message
ansible.builtin.debug:
msg: "The cos instance name is {{ cos_instance_name }}"
when: cos_instance_name is defined
- name: Print result
ansible.builtin.debug:
msg: "Received api key"
when: ibmcloud_api_key is defined
Il seguente è un esempio di post - script. I post - script vengono passati agli output dell'architettura distribuibile.
- name: Deploy post playbook
hosts: localhost
vars:
ibmcloud_api_key: "{{ lookup(`ansible.builtin.env`, `ibmcloud_api_key`)}}"
git_repo_url: "{{ lookup(`ansible.builtin.env`, `git_repo_url`)}}"
tasks:
- name: Print result
ansible.builtin.debug:
msg: "Received api key"
when: ibmcloud_api_key is defined
- name: Print result
ansible.builtin.debug:
msg: "The result is: {{ git_repo_url }}"
when: git_repo_url is defined and git_repo_url != ""