Incluindo pré e pós scripts

Scripts são opcionais para uma oferta, mas se eles forem usados, eles precisarão estar no repositório de origem em um diretório denominado scripts. Os próprios arquivos de script devem estar em conformidade com a seguinte convenção de nomenclatura <action>-<stage>-ansible-playbook.yaml. Opções para action incluem deploy, validate e undeploy. As opções para stage incluem pre e post

Somente scripts ansible no formato de playbook são suportados atualmente

Deve-se também referenciar seus scripts no arquivo manifest ibm_catalog.json em seu repositório de origem Forneça as informações necessárias para seus scripts por variação de sua arquitetura implementável na 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."
   }
],

É possível incluir essas informações em seu arquivo manifest do catálogo no repositório de origem antes de você integrar ao IBM Cloudou incluir manualmente os scripts durante o fluxo de trabalho de integração no console. Se você incluir manualmente os scripts durante a migração, faça download do arquivo manifest e inclua-o em seu repositório de origem para manter as informações em sincronização para versões futuras.

Todos os scripts devem ser capazes de ser executados mais de uma vez sem falha Por exemplo, um script pré-implementação ou pós-implementação deve operar corretamente, mesmo se ele for executado várias vezes. Os scripts de pós-implementação podem incluir recursos em um banco de dados de gerenciamento de catálogo e devem ter certeza de não incluir recursos duplicados se executados mais de uma vez.

Exemplos de pré e pós script

A seguir há um exemplo de um pré-script que é usado para exibir uma mensagem após a arquitetura implementável ser validada Os pré-scripts são passados para todas as entradas da arquitetura implementável, incluindo as credenciais usadas para autorizar a implementação.

- 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 seguir está um exemplo de um pós-script. Os pós-scripts são passados para as saídas da arquitetura implementável.

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