Packer: Confusing provisioners: ansible vs ansible-local & shell vs shell-local

Created on 22 Nov 2017  ยท  2Comments  ยท  Source: hashicorp/packer

If my understanding for all 4 provisioners below are correct, then I think the definition of -local is confusing.
From documentation:
Type: ansible -> CMIIW Run ansible on machine running the packer (aka local machine)

The ansible Packer provisioner runs Ansible playbooks. It dynamically creates an Ansible inventory file configured to use SSH, runs an SSH server, executes ansible-playbook, and marshals Ansible plays through the SSH server to the machine being provisioned by Packer. Note, this means that any remote_user defined in tasks will be ignored. Packer will always connect with the user given in the json config

Type: ansible-local -> CMIIW Run ansible on machine created by packer (aka remote machine)

The ansible-local Packer provisioner configures Ansible to run on the machine by Packer from local Playbook and Role files. Playbooks and Roles can be uploaded from your local machine to the remote machine. Ansible is run in local mode via the ansible-playbook command.


Type: shell -> CMIIW Run shell on machine created by packer (aka remote machine)

The shell Packer provisioner provisions machines built by Packer using shell scripts. Shell provisioning is the easiest way to get software installed and configured on a machine.

Type: shell-local -> CMIIW Run shell on machine running the packer (aka local machine)

> The local shell provisioner executes a local shell script on the machine running Packer. The remote shell provisioner executes shell scripts on a remote machine.

Second question:
There is an inconsistency on how we pass extra argument on ansible vs ansible-local provisioner.
From documentation:
ansible

{
  "extra_arguments": [ "--extra-vars", "Region={{user `Region`}} Stage={{user `Stage`}}" ]
}

ansible-local:
"extra_arguments": [ "--extra-vars \"Region={{user `Region`}} Stage={{user `Stage`}}\"" ]

docs question

Most helpful comment

Hi @yokzy88, I am sorry for the lack of clarity!

The explanation could, indeed, be a little bit more concise - I will look into a potential Pull Request with a clean-up. Let this with us! :)

In an essence, ansible-local executes locally on the remote machine that Packer is in the process of creating and/or provisioning, thus in this case the locality refers more to "on the remote node itself" side of the work done by the provisioner. Which is why ansible-local requires Ansible and it's dependencies to be pre-installed on the remote machine; whereas shell-local executes on the machine from which Packer is being run to build and provision the remote machine - in other words, it would be your build server, EC2 instance or your desktop, etc., where the scripts would be executed rather than the remote machine. This is often used to execute a a number of pre and post-build actions locally so that any auxiliary steps required for the new machine to be build are executing as part of the same process, rather than from external scripts wrapping Packer around.

I hope this helps!

All 2 comments

Hi @yokzy88, I am sorry for the lack of clarity!

The explanation could, indeed, be a little bit more concise - I will look into a potential Pull Request with a clean-up. Let this with us! :)

In an essence, ansible-local executes locally on the remote machine that Packer is in the process of creating and/or provisioning, thus in this case the locality refers more to "on the remote node itself" side of the work done by the provisioner. Which is why ansible-local requires Ansible and it's dependencies to be pre-installed on the remote machine; whereas shell-local executes on the machine from which Packer is being run to build and provision the remote machine - in other words, it would be your build server, EC2 instance or your desktop, etc., where the scripts would be executed rather than the remote machine. This is often used to execute a a number of pre and post-build actions locally so that any auxiliary steps required for the new machine to be build are executing as part of the same process, rather than from external scripts wrapping Packer around.

I hope this helps!

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.

Was this page helpful?
0 / 5 - 0 ratings