Parallel builds with provisioner only uses one build entity

[JKetelaar]

Overview of the Issue

Whenever I am creating a parallel build, the Ansible provisioner uses only one build entity, in each of the tasks.

Reproduction Steps

Run Packer with an Ansible provisioner and two builders. It will run the provisioner on only one builder.

Packer version

Packer v1.6.6

Simplified Packer Buildfile

Build file

{
  "variables": {
    "hcloud_key": "{{ env `HCLOUD_KEY` }}"
  },
  "builders": [
    {
      "name": "common",
      "type": "hcloud",
      "token": "{{ user `hcloud_key` }}",
      "image": "ubuntu-20.04",
      "location": "nbg1",
      "server_type": "cpx11",
      "ssh_username": "root",
      "snapshot_name": "test-1"
    },
    {
      "name": "gocd",
      "type": "hcloud",
      "token": "{{ user `hcloud_key` }}",
      "image": "ubuntu-20.04",
      "location": "nbg1",
      "server_type": "cpx11",
      "ssh_username": "root",
      "snapshot_name": "test-2"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "/usr/bin/cloud-init status --wait"
      ]
    },
    {
      "type": "ansible",
      "playbook_file": "./playbooks/packer-debug.yml",
      "keep_inventory_file": true
    }
  ]
}

Ansible playbook (./playbooks/packer-debug.yml)

---
- hosts: all
  remote_user: root
  become: true
  tasks:
    - debug: var=ansible_all_ipv4_addresses
    - debug: var=ansible_default_ipv4.address

As you can see in the log output on line 5 and line 7 it shows two different IPs (116.203.213.239 and 116.203.51.13). If you then look on line 28, it shows that the gocd builder indeed has the right IP (116.203.213.239), though looking at line 67 it shows that also the common builder uses the gocd builder IP address.

Operating system and Environment details

Both on Ubuntu 20 and MacOS.

Log Fragments and crash.log files

https://gist.github.com/JKetelaar/6cfab554d0f24f0b4f1b653c82aadf84

[JKetelaar]

Just tried the same thing with a shell provisioner, and that seems to work fine:

  "provisioners": [
    {
      "type": "shell",
      "inline": [
          "curl ifconfig.co -4 -sS"
      ]
    }
  ]

results into

==> gocd: Connected to SSH!
==> gocd: Provisioning with shell script: /var/folders/3w/39m15bx92gv32355pj5p2p7m0000gn/T/packer-shell289500689
    gocd: 116.203.51.13
...
==> common: Connected to SSH!
==> common: Provisioning with shell script: /var/folders/3w/39m15bx92gv32355pj5p2p7m0000gn/T/packer-shell942882521
    common: 116.203.213.239

So it looks like something Ansible related

[JKetelaar]

I also tried creating a custom inventory_file_template:

      "inventory_file_template": "{{ .HostAlias }}-{{ build_name }} ansible_host={{ .Host }} ansible_user={{ .User }} ansible_port={{ .Port }}\n"

No luck with that either...

[SwampDragons]

I can't reproduce this. The confusion may be that since the ansible provisioner uses a proxy adapter, it looks like it's going to the same place. But I did a practical test by actually creating a fake configuration file at /etc/foo file using the "file" ansible module for parallel amazon builds, and both instances ended up with the file created on them.

If you are still unable to get this working, we can reopen -- but I think this is just a confusing log issue.

[JKetelaar]

Hi @SwampDragons - thanks for the response!

It indeed uses a proxy adapter, which is also where I think it fails. How I figured it out it fails, is because when using apt to install packages, one of the builders succeeds but the other fails, which seems because the other is locked (as it is the same VM/server).

The first example of this issue explains the issue clearly and happens every single time, on multiple (Packer) host machines (even using GitHub actions).

Please do re-open, because this issue is still existing. If needed, we can chat through any communication platform that fits you, if you have any questions left. 😄

[SwampDragons]

If you think it's the proxy adapter, you can disable it using "use_proxy": false in your ansible provisioner config. How about you try that and see if the issue persists.

[SwampDragons]

Rereading...

How I figured it out it fails, is because when using apt to install packages, one of the builders succeeds but the other fails, which seems because the other is locked (as it is the same VM/server).

Your parallel builds are each targeting the same instance? I missed that in the original comment. That's not really how Packer is intended to be used so now I'm thinking this is some kind of race condition.

[JKetelaar]

That was poorly worded from my end, sorry. What I mean is that there are two seperate builders (two VM's) created through Hetzner. When Ansible connects with the server, it only connects to one of the builders, instead of the two separate instances.

I will try the use_proxy

[JKetelaar]

use_proxy works 🎉 - so there's something wrong with the proxy in combination with Ansible

[ghost]

This issue has been automatically migrated to hashicorp/packer-plugin-ansible#10 because it looks like an issue with that plugin. If you believe this is not an issue with the plugin, please reply to hashicorp/packer-plugin-ansible#10.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.