Vor-und Nachscripts hinzufügen

Scripts sind für ein Produktangebot optional, wenn sie jedoch verwendet werden, müssen sie sich im Quellenrepository in dem Verzeichnis scripts befinden. Die Scriptdateien selbst müssen der folgenden Namenskonvention entsprechen: <action>-<stage>-ansible-playbook.yaml. Optionen für action sind deploy, validate und undeploy. Optionen für stage sind pre und post.

Derzeit werden nur ansible Scripts im Playbook-Format unterstützt.

Sie müssen auch auf Ihre Scripts in der Manifestdatei ibm_catalog.json in Ihrem Quellenrepository verweisen. Geben Sie die erforderlichen Informationen für Ihre Scripts pro Variante Ihrer implementierbaren Architektur im Array scripts an:

"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."
   }
],

Sie können diese Informationen zu Ihrer Katalogmanifestdatei im Quellenrepository hinzufügen, bevor Sie das Onboarding in IBM Clouddurchführen, oder Sie können die Scripts während des Onboarding-Workflows in der Konsole manuell hinzufügen. Wenn Sie die Scripts beim Onboarding manuell hinzufügen, laden Sie Ihre Manifestdatei herunter und fügen Sie sie zu Ihrem Quellenrepository hinzu, um die Informationen für zukünftige Versionen synchron zu halten.

Alle Scripts müssen mehrmals ausgeführt werden können, ohne dass ein Fehler auftritt. Beispielsweise muss ein Script vor oder nach der Implementierung ordnungsgemäß funktionieren, auch wenn es mehrmals ausgeführt wird. Scripts nach der Implementierung können Ressourcen zu einer Katalogverwaltungsdatenbank hinzufügen und dürfen keine doppelten Ressourcen hinzufügen, wenn sie mehrmals ausgeführt werden.

Beispiele für Vor-und Nachscripts

Das folgende Beispiel zeigt ein Vorscript, das verwendet wird, um eine Nachricht anzuzeigen, nachdem die implementierbare Architektur validiert wurde. Vorscripts werden an alle Eingaben aus der implementierbaren Architektur übergeben, einschließlich der Berechtigungsnachweise, die zur Autorisierung der Bereitstellung verwendet werden.

- 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

Das folgende Beispiel zeigt ein Nachscript. Nachscripts werden an die Ausgaben der implementierbaren Architektur übergeben.

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