Expose connection settings of communicator to template

[timurb]

It would be nice to have the variable with the IP of the host inside template.

My use case for this will be to run InSpec tests from local shell provisioner. Something like:

{
  "type": "shell-local",
  "command": "inspec exec spec/ --sudo --sudo-password=packer --target=ssh://packer:packer@{{ssh_host}}"
}

I understand that there could be issues with bastion host and other SSH connection parameters but a template developer already knows these when writing the template. The only dynamic value that I can't know in advance is the IP address of the host to connect.

I understand that I can workaround that by installing InSpec to inside the VM but I'd like to have an option to avoid that. Another use case could be described in https://github.com/mitchellh/packer/issues/4173

This is similar to https://github.com/mitchellh/packer/issues/3889 but relates to templates rather than to provisioners.

[rickard-von-essen]

I think we have argued over this enough in #3331. @mwhooker close?

[timurb]

3331 is about passing IP to provisioner.

My issue is a different one and is about passing IP to template. See {{ssh_host}} call in the example above.

[rickard-von-essen]

It's the same thing as described in the original post of #3331.

[derekmurawsky]

This was closed as "the same thing as described in... #3331." It is not. #3331 was closed because ansible was the only thing that needed this. This is a clear example of something else that needs it. I would submit that there are any number of reasons that having the IP readily available is necessary. Security scanners, serverspec tests, and any number of other tests that should happen before the AMI is bundled and published. Yes, there are other ways of doing so, but they involve tailing logs and other such things. In our instance, we have the AWS CLI app, but no way to get the instance ID without hacking logs as well. Please reconsider your position on making this available somewhere.

Perhaps it makes sense to make them available from specific builders instead of everywhere? For example the AWS builder could include an instance ID var and an internal IP var?

Bottom line is, I think this is important to cleanly extend the use of packer. Please reconsider.

[kiwivogel]

Agreed. The alternative would be an inspec provisioner (would be even better) (post processor doesn't seem to be an option as the machine is already shutdown at that stage.)

[hogarthj]

Note that that the ansible provisioner, over winrm, is extremely fragile and because it bypasses the tested and expected route that ansible takes to reach windows (ie it doesn't use the ansible winrm connection code) it steps out of the tested scenarios for ansible.

Exposing the IP so that ansible-playbook can be run directly with shell-local makes so much more sense for maintainability and to avoid weird edge cases.

[SwampDragons]

I've been persuaded that this is necessary, and I want to put some time into figuring out how to implement this properly across the various plugins. It needs to be a core change, though, so it'll take some time and architectural refactoring. I'm going to close this ticket and link it to the meta-ticket that'll handle that architectural refactor -- see #7079 above.

[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.