Ajout de préscripts et de post-scripts

Les scripts sont facultatifs pour une offre, mais s'ils sont utilisés, ils doivent se trouver dans le référentiel source dans un répertoire nommé scripts. Les fichiers script eux-mêmes doivent être conformes à la convention de dénomination suivante: <action>-<stage>-ansible-playbook.yaml. Les options pour action incluent deploy, validate et undeploy. Les options de stage incluent pre et post.

Seuls les scripts ansible au format playbook sont actuellement pris en charge.

Vous devez également référencer vos scripts dans le fichier manifeste ibm_catalog.json de votre référentiel source. Fournissez les informations requises pour vos scripts par variante de votre architecture déployable dans le tableau 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."
   }
],

Vous pouvez ajouter ces informations à votre fichier manifeste de catalogue dans le référentiel source avant de les intégrer à IBM Cloud, ou vous pouvez ajouter manuellement les scripts lors de l'intégration du flux de travaux dans la console. Si vous ajoutez manuellement les scripts lors de l'intégration, téléchargez votre fichier manifeste et ajoutez-le à votre référentiel source pour que les informations soient synchronisées pour les versions futures.

Tous les scripts doivent pouvoir être exécutés plusieurs fois sans échec. Par exemple, un script de pré-déploiement ou de post-déploiement doit fonctionner correctement, même s'il est exécuté plusieurs fois. Les scripts de post-déploiement peuvent ajouter des ressources à une base de données de gestion de catalogue et doivent s'assurer de ne pas ajouter de ressources en double si elles sont exécutées plusieurs fois.

Exemples de préscript et de post-script

Voici un exemple de préscript utilisé pour afficher un message après la validation de l'architecture déployable. Les préscripts sont transmis à toutes les entrées de l'architecture déployable, y compris les données d'identification utilisées pour autoriser le déploiement.

- 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

Voici un exemple de post-script. Les post-scripts sont transmis aux sorties de l'architecture déployable.

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