Formularios de varios pasos

Ejecuta varios playbooks o plantillas en secuencia desde un solo formulario


multistep está obsoleto desde la 7 y se elimina en la 8: usa un workflow en su lugar. Un workflow hace todo lo que hace un multistep, con condiciones, valores propios por nodo, nodos de aprobación y ramas que se ejecutan en paralelo.

Deprecated since 7, removed in 8: use workflow. A workflow does all a multistep does - its nodes run on any runner (runner:), with a condition (if_extra_var, as ifExtraVar) and their own values (extra_vars_key, as key), with approval nodes - and runs branches side by side. Until 8 a multistep runs as it did, and the log says it is deprecated.

Executes multiple jobs sequentially.
Each step can be a different type (ansible, awx, semaphore, rundeck, jenkins …).

Multistep form

- name: Create VM
  roles:                                         # reference to roles defined earlier
  - vmware
  description: Create and start a vm
  image: https://picsum.photos/64                # an image url (can be base64)
  categories:                                    # reference to categories defined earlier
  - Demo
  - Vmware
  tileClass: bg-danger                           # a bootstrap background color style (https://getbootstrap.com/)
  type: multistep                                # type is awx, ansible or multistep
  steps:
  - type: awx
    name: Create vm
    template: Create VM
    key: vmInfo
  - type: awx
    name: Start vm
    template: Start VM
    key: vmInfo
  - type: ansible
    name: Email results
    playbook: email.yaml
    always: true                                 # always run this task, even if others failed
  fieldGroupClasses:                             # give fieldgroups a custom background
    groupname1: bg-info-subtle
    groupname2: bg-success-subtle    
  fields:                                        # list of field objects
    - name: vm_name
      type: text

Propiedad a nivel de formulario

Un formulario de varios pasos define sus pasos en una única propiedad a nivel de formulario:

Atributo Comentarios
steps
array / obligatorio

Multistep steps

Deprecated since 7, removed in 8, with the multistep type: a workflow’s nodes do what steps do.
A multistep form is basically an array of multiple form type destinations, defined here as steps.

Además de steps, un formulario de varios pasos acepta estas propiedades a nivel de formulario, documentadas en la página Formularios de Ansible: roles (obligatoria), categories, showHelp, icon, iconColor, iconSize, overlayIcon, overlayIconTransform, overlayIconColor, overlayIconCircle, overlayIconText, overlayIconTextPosition, overlayIconTextColor, image, tileClass, fieldGroupClasses, wizard, userExtravars, abortable, allowRelaunch, launchValidation, enableForChat, order, approval, notifications, onSubmit, onSuccess, onFailure, onAbort, onFinish.


Propiedades de los pasos

Each step is a new form destination. And steps are executed sequentially.
Use specific properties like continue, always and ifExtraVar to control the flow of a multistep form.

When a step has type: ansible, all ansible-specific form properties apply to that step (e.g. playbook, playbookSubPath, ansibleCredentials, vaultCredentials, inventory, check, diff, tags, varsFiles, approval, notifications, …).
When a step has type: awx, the awx-specific form properties apply to that step (e.g. template, job, awx, awxCredentials, inventory, check, diff, tags, approval, notifications, …), except executionEnvironment, instanceGroups and scm_branch: a step does not accept them.

Atributo Comentarios
basic
name
string / obligatorio

The name of the form
alphanumeric + dash + underscore + space

The name of the step. Used for logging and visualization.

type
string

Step type

Every step runs an Ansible playbook (ansible), or a template or job on a runner (awx, aap, ascender, semaphore, rundeck, jenkins).

Opciones:
  • ansible
  • awx
  • aap
  • ascender
  • semaphore
  • rundeck
  • jenkins

Ejemplos:

1) Run AWX Template Helloworld

name: Create vm
type: awx
template: Create VM

2) Run Ansible playbook

name: Delete vm
type: ansible
playbook: delete_vm.yaml
workflow
key
string

Extravar key
valid extravar reference

AnsibleForms can model the extravars into objects using the formfield model attribute. In a multistep form, by default, every step gets the full extravars payload. However, using this key attribute you can choose which step receives which part of the extravars.
Study the example below to understand how the key property works.

Ejemplos:

1) Resize volume

name: Resize volume
type: multistep
roles:
  - default
steps:
- name: Create datastore
  type: awx
  template: create_datastore
  key: datastore        # to create the datastore, we only send the datastore info        
- name: Create vm
  type: awx
  template: create_vm
fields:
  - name: datastore
    type: text
    model: datastore.name
  - name: datastore_size
    type: number
    model: datastore.size
  - name: vm
    type: text
    model: vm.name
  - name: vm_size
    type: number
    model: vm.size

# the extravars of the above example will be somewhat like this:
# datastore: 
#     name: ds1
#     size: 123
# vm:        
#     name: vm1
#     size: 100

# Step 1 will not receive the full set of extravars, due to the 'key: datastore'  
#        it will receive only 'name' (ds1) and 'size' (123) (the contents of key 'datastore')
# Step 2 has no key set, and will receive the full extravars
# Extra: Every step can reference its own key and thus send a piece of the extravars
ifExtraVar
extravar reference

Run step if ...

In a mulitstep form, by default, AnsibleForms will try to run every step sequentially one after the other.
Using this property you choose if a step should be run or not by setting the property to a part of the extravars that resolves into a boolean (expression or checkbox). This way you can dynamically skip steps.

Ejemplos:

1) Run step based on checkbox

name: Create something
type: multistep
roles:
  - default
steps:
- name: Create
  type: awx
  template: create
- name: Send email
  type: awx
  template: send mail
  ifExtraVar: sendmail
fields:
- name: name
  type: text
  label: What to create ?
- name: sendmail
  type: checkbox
  label: Should I send an email ?
continue
boolean

Continue on fail

In a mulitstep form, by default, if 1 step fails, the multistep is stopped. However, if you want to continue to the next step, even if the current step failed, use this attribute and set it to true and the multistep will goto the next step. If this happens the status becomes ‘partially success’.

Valor predeterminado:
false

Ejemplos:

1)

name: Resize volume
type: multistep
roles:
  - default
fields: []
steps:
- name: Send email
  type: awx
  template: email
  continue: true       # if email send fails, we still continue
- name: Resize volume
  type: awx
  template: volume resize
always
boolean

Always run

In a mulitstep form, by default, if 1 step fails, the multistep is stopped. However, if you always want to run a certain step, even if a step failed somewhere, use this attribute and set it to true and the specific step will always run.

Valor predeterminado:
false

Ejemplos:

1)

name: Resize volume
type: multistep
roles:
  - default
fields: []
steps:
- name: Load cmdb
  type: awx
  template: load cmdb
- name: Resize volume
  type: awx
  template: volume resize
- name: Send email
  type: awx
  template: email
  always: true       # whether step 1 or 2 fails, this step always runs          

Ejemplo

Un formulario de varios pasos ejecuta varios trabajos en secuencia, y cada paso lanza su propio playbook o plantilla de AWX. Todos los pasos comparten los campos del formulario: por defecto, cada paso recibe las extravars completas, y la key de un paso lo limita a esa parte de ellas.

Crear y configurar un servidor

Cada paso recibe su propia parte de las extravars: un paso de AWX crea el servidor, un paso de Ansible configura su red y un último paso siempre envía un informe:

name: Server Provisioning
type: multistep
roles:
  - default
categories:
  - Setup
steps:
  - name: Create server
    type: awx
    template: Create VM
    key: server              # receives only the `server` part of the extravars
  - name: Configure network
    type: ansible
    playbook: configure_network.yml
    key: network             # receives only the `network` part of the extravars
  - name: Send report
    type: ansible
    playbook: email.yml
    always: true             # runs even when an earlier step failed
fields:
  - name: server_name
    type: text
    model: server.name
  - name: environment
    type: enum
    values:
      - dev
      - prod
    model: server.environment
  - name: ip_address
    type: text
    model: network.ip
  - name: gateway
    type: text
    model: network.gateway