Packer: [azure-rm] Cannot build image when 'communicator' set to 'none'

[said026]

Hello,

I am experiencing errors when trying to build an image with azure-rm builder when communicator is set to none :

==> azure-arm: ERROR: -> DeploymentFailed : At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.
==> azure-arm: ERROR:   -> BadRequest
==> azure-arm: ERROR:   -> InvalidParameter : The value of parameter linuxConfiguration.ssh.publicKeys.keyData is invalid.

The goal I want to achieve is to disable the SSH login part to the VM.

• Packer 1.2.3
• Host platform : Debian 8 Jessie x64
• Debug log output: https://gist.github.com/said026/4d7c3ff1fad0b5c7fc0c865f26ef76b7
• Used template file : https://gist.github.com/said026/d723f694215f734556271b9e140ea97d

[SwampDragons]

Hey, sorry you're having issues with this. The "none" communicator exists for debugging purposes, and can't build images. I'll check to make sure that's clear in the docs.

Packer needs to be able to connect to your image via SSH or it can't do its job. You can disable SSH once you are done building the image, but you need it while the image is building.

[SwampDragons]

I misspoke. You should be able to use the "none" communicator in conjunction with a custom_data_file to do the building, as long as you don't expect to be able to use the majority of Packer's provisioners.

[cloudbooster]

@said026 please note that custom_data_file can only be used for distros that have cloud-init package. You would need to do cleanup of the user etc that got created as a part of build and set the azure agent state.

[said026]

Thank you @SwampDragons and @harijayms for your replies. It turned out that the Debian 8 image I was using didn't include cloud-init package. However, I reproduced the same error when using an Ubuntu Server 16.04-LTS which includes cloud-init (https://docs.microsoft.com/en-us/azure/virtual-machines/linux/using-cloud-init).

I guess by settting communicator to none, the builder doesn't supply a public key which is required by Azure to create a VM. For information, it perfectly works when using the amazon-ebs builder.

[SwampDragons]

Yeah, this definitely sounds like a bug. It's a fairly unique use case so I probably won't be able to get to this for the next release, but if anyone wants to take a stab at it I can point you at the relevant code files.

[boumenot]

This is not a use case that we ever considered. Packer has a wealth of provisioners, and specifying a communicator of none effectively means you don't want any of them. I am not sure if Packer provides much value at that point.

If you want to deploy a VM with custom data I recommend you use the CLI. It's a bare bones experience, but that exactly what you are doing.

[SwampDragons]

@boumenot this is a really good point. While historically we've allowed people to use Packer + other builders for this kind of very-bare provisioning, it's not really what Packer was intended for. It feels like the benefits would involve being able to use post-processors, but at that point you're really using Packer as a CI system and there may be other tools that suit your needs better.

[nywilken]

Hi folks, thanks for all the good context around this request. After further review, we've decided to close this issue because the feature request is not a typical workflow for Packer to support and believe that there are other solutions better suited for this use case.

If, however, a member of the Packer community is interested in opening up a PR that does not add complexity to the Packer code base or user experience we would be happy to review and take it into consideration. Cheers :smile:

[hashibot[bot]]

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.