Creación de scripts para arquitecturas desplegables

Puede tener scripts que se ejecuten para las arquitecturas desplegables antes o después de validar, desplegar y anular el despliegue. Los scripts se configuran en una versión específica de la arquitectura desplegable y deben ejecutarse y validarse a través de proyectos. Para obtener más información sobre los proyectos, consulte Creación de un proyecto.

Existen varias ventajas y casos de uso para utilizar scripts para las arquitecturas desplegables:

  • Realizar la validación personalizada, por ejemplo, si desea asegurarse de que el parámetro tag es siempre un ID de centro de costes válido. El script de validación previa puede llamar a un servicio para comprobar que el ID del centro de costes es válido.
  • Seguimiento de despliegues y adición de recursos, por ejemplo, adición a un sistema de inventario proporcionando un script posterior al despliegue que puede llamar a un servicio para realizar un seguimiento de los recursos que se han desplegado.
  • Completando la migración de datos. Un script previo al despliegue puede realizar una copia de seguridad de los datos. A continuación, después de que la arquitectura desplegable suprima el almacén de datos antiguo y cree el nuevo, el script posterior al despliegue puede restaurarlo en el nuevo almacén de datos.
  • Instalación o configuración de software
  • Finalización de dos tareas de mantenimiento como, por ejemplo, la copia de seguridad manual, la restauración o las rotaciones de claves.

Adición de scripts anteriores y posteriores

Los scripts son opcionales para una oferta, pero si se utilizan, es necesario que estén en el repositorio de origen en un directorio denominado scripts. Los propios archivos de script deben cumplir el siguiente convenio de denominación <action>-<stage>-ansible-playbook.yaml. Las opciones para action incluyen deploy, validate y undeploy. Las opciones para stage incluyen pre y post.

Actualmente solo se da soporte a scripts ansibles en el formato de playbook.

También debe hacer referencia a los scripts en el archivo de manifiesto ibm_catalog.json en el repositorio de origen. Proporcione la información necesaria para los scripts por variación de la arquitectura desplegable en la matriz 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."
   }
],

Puede añadir esta información al archivo de manifiesto de catálogo en el repositorio de origen antes de incorporar a IBM Cloud, o puede añadir manualmente los scripts durante el flujo de trabajo de incorporación en la consola. Si añade manualmente los scripts durante la incorporación, descargue el archivo de manifiesto y añádalo al repositorio de origen para mantener la información sincronizada para futuras versiones.

Todos los scripts deben poder ejecutarse más de una vez sin fallar. Por ejemplo, un script previo o posterior al despliegue debe funcionar correctamente, aunque se ejecute varias veces. Los scripts posteriores al despliegue pueden añadir recursos a una base de datos de gestión de catálogos y deben asegurarse de no añadir recursos duplicados si se ejecutan más de una vez.

Ejemplos previos y posteriores al script

A continuación se muestra un ejemplo de un script previo que se utiliza para visualizar un mensaje después de que se valide la arquitectura desplegable. Los scripts previos se pasan a todas las entradas de la arquitectura desplegable, incluidas las credenciales utilizadas para autorizar el despliegue.

- 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

A continuación se muestra un ejemplo de un script posterior. Los scripts posteriores se pasan a las salidas de la arquitectura desplegable.

- 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 != ""