我正在使用 ansible 在 azure 中部署一个 VM,并使用在下一个任务中创建的公共 IP。但是创建公共 ip 所花费的时间太长,因此在执行后续任务时会失败。创建 ip 的时间也各不相同,不是固定的。我想介绍一些逻辑,其中下一个任务仅在创建 ip 时运行。
- name: Deploy Master Node
azure_rm_virtualmachine:
resource_group: myResourceGroup
name: testvm10
admin_username: chouseknecht
admin_password: <your password here>
image:
offer: CentOS-CI
publisher: OpenLogic
sku: '7-CI'
version: latest
有人可以在这里帮助我..!非常感谢。
我认为wait_for
模块是一个糟糕的选择,因为虽然它可以测试端口可用性,但它通常会给你误报,因为端口在服务实际准备好接受连接之前就打开了。
幸运的是,wait_for_connection模块正是针对您所描述的情况而设计的:它将等到 Ansible 能够成功连接到您的目标。
这通常需要将 Azure VM 注册到 Ansible 清单(例如,使用add_host
模块(。我不使用Azure,但是如果我使用OpenStack,我可能会写这样的东西:
- hosts: localhost
gather_facts: false
tasks:
# This is the task that creates the vm, much like your existing task
- os_server:
name: larstest
cloud: kaizen-lars
image: 669142a3-fbda-4a83-bce8-e09371660e2c
key_name: default
flavor: m1.small
security_groups: allow_ssh
nics:
- net-name: test_net0
auto_ip: true
register: myserver
# Now we take the public ip from the previous task and use it
# to create a new inventory entry for a host named "myserver".
- add_host:
name: myserver
ansible_host: "{{ myserver.openstack.accessIPv4 }}"
ansible_user: centos
# Now we wait for the host to finished booting. We need gather_facts: false here
# because otherwise Ansible will attempt to run the `setup` module on the target,
# which will fail if the host isn't ready yet.
- hosts: myserver
gather_facts: false
tasks:
- wait_for_connection:
delay: 10
# We could add additional tasks to the previous play, but we can also start
# new play with implicit fact gathering.
- hosts: myserver
tasks:
- ...other tasks here...