Our wait step is in a different playbook downstream in a workflow. The
upstream step in the workflow can create an EC2 or an ESX VM. We did it
this way to be universally applicable. We have a workflow step to create a
vm, a workflow step to create a DNS record for that VM, then a workflow
step to customize that VM based on parameters coming into the workflow -
apache, nginx, tomcat, mysql, etc. The create-vm step is a wrapper playbook
that sources other playbooks based on IaaS platform (location) the user
selected. We support ESX and AWS, but with this method could easily add
Azure and Google and other cloud service providers or hypervisor platforms.
CREATE-VM.YML
---
##
## NOTES:
##
## this playbook provides a common interface to launching VMs in any IaaS
provider service
##
## we use a common location variable with three-letter prefix for provider:
##
## - aws - amazon
## - azr - azure
## - esx - vmware
## - gcp - google
## - ora - oracle
##
## using this prefix we source a provider-specific vars and tasks file.
## first we have to insure we have a valid provider prefix in location.
##
- name: validate provider / location
hosts: localhost
gather_facts: no
vars_files:
- "server-specs.yml" # shared
provisioning vars
tasks:
- name: this task will skip if provider is valid
fail: msg="Invalid provider {{ location[0:3] }}"
when: location[0:3] not in providers_keys
##
## now we can safely provision because we can source a valid vars and tasks
file
##
- name: provision new {{ os_type }} machine
hosts: localhost
gather_facts: no
vars:
my_family: "{{ 'windows' if os_type[0:7] == 'windows' else 'linux' }}"
my_provider: "{{ location[0:3] }}"
vars_files:
- "server-specs.yml" # shared
provisioning vars
* - "{{ my_provider }}-vars.yml" #
provider-specific vars*
tasks:
- name: building {{ vm_guest_name }} at {{ providers[my_provider] }}
* import_tasks: "{{ my_provider }}-create-vm.yml" #
provider-specific tasks*
On Friday, April 29, 2022 at 7:51:28 AM UTC-4 [email protected] wrote:
> On 2022-04-28 (Thu) 19:39, 'Walter Rowe' via Ansible Project wrote:
> > Adding to my earlier reply .. we then use a wait_for task to wait for
> > the EC2 to be ready for SSH.
>
> We use the ec2_instance module as well, but we use the build-in 'wait'
> parameter which works well:
>
>
> https://docs.ansible.com/ansible/latest/collections/amazon/aws/ec2_instance_module.html#parameter-wait
>
>
>
> --
> Dick Visser
> GÉANT
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/624e79bb-5160-43a1-8f7b-ba30117e505fn%40googlegroups.com.
