To work around https://github.com/hashicorp/packer/issues/2648 I am considering simply opening up some shared folders (SMB) on the machine being built and uploading files using the local shell provisioner. Alternatively, using PowerShell remoting file transfers. However, I do not seem to find any variables documented that would enable me to obtain the relevant IP address to actually connect to.
I would like to know how I can provide this information to my local shell provisioner and to request that this information be added to the documentation.
The IP is not directly available to the provisioner. Which builder do you use?
I currently use Azure and Hyper-V and will likely also use VirtualBox and QEMU in the future.
I wrote a shell script that allows me to easily connect up with all my running packer builds, but it's targeting *nix systems, and only looks for qemu, vmware, or virtualbox builds at the moment. See this gist, and feel free to send me any Windows improvements via PR.
That said the theory should work on WIndows. Just use netstat to find the console and connect up. Once your logged in you can look at the machine IP and then ssh in. I've done it many times to troubleshoot installer issues.
You can also set the PACKER_LOG environment variable to any non-zero value. That will write out debug information, which will include a record of the ip/port packer attempts to connect up with using ssh during the provisioning process. Once you have that info, you should be able to ssh into the machine as well. Just make sure your done working on the system before the packer build process completes, because when that happens the box (usually) gets shutdown automatically.
Run a shell provisioner that saves the IP in a file. Use a file provisioner to download it and read it in the shell-local script.
@rickard-von-essen that's a good idea but this workaround does not necessarily work if the machine under build does not know its own reachable IP address (e.g. it is running in a cloud).
The you probably have a cli that can find the external address.
Right. The reason I filed this issue was because I was under the impression that Packer was a product designed to make such things easy and if such a feature was missing, its authors might want to add it. Perhaps I am mistaken in the purpose of Packer or the intended use of this issue tracker, as I cannot understand why you would close an issue that points out a missing feature.
Oh sorry I taught I linked to another issue. I closed it since we decided explicitly to not include this feature.
See #3331. (I was mixing this up with the similar request in #4701)
One year later, using the ansible provisionner is discouraged in favor of shell-local, so we need the IP address to call ansible by ourselves. #6179 has been implemented to get the WinRM password. I understand people don't want to break the communicator abstraction, but:
...looks kind of hackish for a piece of information packer knows.
Could this be reopen?
Have you tried running:
PACKER_LOG=1 packer build template.json
That will force packer to output additional information, including (I believe) the guest IP address (assuming it is able to discover the guest address). You can, of course, write the output to a file, for easier parsing, with:
set PACKER_LOG=1
set PACKER_LOG_FILE=log.txt
packer build template.json
Note, it's been awhile since I looked for this info, and different builders output different information. Not all of them output the guest IP address, but _I think_ the HyperV provider does.
@ladar : Thanks for your proposal, but this won't work in the case you want packer to call ansible so that the final image is generated and provisionned in one step. Doing it in a separate step is doable, and must be possible, but kind of defeats the purpose of packer.
I could really use the IP of the guest to run server spec against the build. I don't want to install ruby and all the bits inside the build it's already on the host running the build ,all I need to make this work from a shell_local is the guest IP! Which packer knows! Could it not be exposed for the communicators / builders that it makes sense for and just be empty otherwise.
This is so basic for a tool like packer, cant believe there is no way to do it without using workarounds.
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
I could really use the IP of the guest to run server spec against the build. I don't want to install ruby and all the bits inside the build it's already on the host running the build ,all I need to make this work from a shell_local is the guest IP! Which packer knows! Could it not be exposed for the communicators / builders that it makes sense for and just be empty otherwise.