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)
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`}}\"" ]
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.
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 whyansible-local
requires Ansible and it's dependencies to be pre-installed on the remote machine; whereasshell-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!