Packer private registry

Packer
1

Hi everyone,

I was on the “configuring packer” page looking for information related to packer private registry…but I didn’t found anything about this topic.
The PACKER_PLUGIN_PATH environment variable seems to be pointing to the already dowloaded plugin path.

Is the topic “packer private registry” is already opened on hashicorp side ?

Let explain the context :
The client for which I’m working will run Terraform and Packer on gitlab runners completely isolated from Internet.
There’s no problem with Terraform (i’ve already found how to do that) and the registry will be hosted on a Nexus instance.
But I didn’t found anything for Packer.

2

Hi!

Is the registry you’re referring to for packer plugins or for artifacts?

Private registries for artifacts (ie images) are possible both for the build and for post-processor stanzas.

If you need to consume images in a build stanza with an air-gapped environment, then of course the registry needs to be resolvable locally (either on the same host or in the same air-gapped network). Same story for build artifacts using the post-processor stanzas. If you’re referring to a Nexus instance, I’m assuming that you’re pushing container images - you can set the login = true and login_username, login_server and login_password to authenticate to the private registry.

As for the plugins, you need to ship them in the build environment before air-gapping it, same as with Terraform.

I have the suspicion this is not quite what you’re looking for though - have I misunderstood?

3

Hi,

I’m referring to plugins.

I’ve uploaded the plugins to a private Nexus instance but when I try to use them with :

packer {
required_version = “>= 1.7.0”
required_plugins {
virtualbox = {
version = “>= 0.0.1”
source = “github.com/hashicorp/virtualbox”
}
}
}

It still tries to reach the official registry even if I set PACKER_PLUGIN_PATH as an environment variable.

With Terraform, I’ve figured out how to set a Private Registry with Nexus, Nginx as a reverse proxy and the instruction network_mirror in the terraform config file.

Is there something similar planned for Packer or not ?

4

Ah sorry, I was way off, thanks for clarifying.

Yeah, going from the documentation the only addressing scheme currently supported is github.com/...

A plugin’s source address is its global identifier. It also tells Packer where to download it.
Source addresses consist of three parts delimited by slashes (/), as follows:
<HOSTNAME>/<NAMESPACE>/<TYPE>

  • Hostname: The hostname of the location/service that distributes the plugin. Currently, the only valid “hostname” is github.com, but we plan to eventually support plugins downloaded from other domains.
  • Namespace: An organizational namespace within the specified host. This often is the organization that publishes the plugin.
  • Type: A short name for the platform or system the plugin manages. The type is usually the plugin’s preferred local name.

Checking the Packer code, indeed it doesn’t seem to use go-getter. but implements only one plugin installation method, github:

My bet is that the name of the plugin in PACKER_PLUGIN_PATH doesn’t conform to the naming convention that packer expects, which triggers the check. There is a toggle on the Packer documentation which says:

The easiest way to manually install a plugin is to name it correctly, then place it in the proper directory. To name a plugin correctly, make sure the binary is named packer-plugin-NAME. For example, packer-plugin-amazon for a “plugin” binary named “amazon”. This binary will make one or more components available to use. Valid types for plugins are down this page.
Once the plugin is named properly, Packer automatically discovers plugins in the following directories in the given order. If a conflicting plugin is found later, it will take precedence over one found earlier.

(Chose “manually multi-component plugin” option)

I think if you set the names correctly in the correct paths, you will be able to do a packer build no problem. You’ll skip the packer init step though.

5

Hi,

Thanks for the reply.
If I understand well the documentation, as long as the line with plugingetter is not modified, I will not be able to use a real private registry for Packer (something possible for Terraform).
The plugins I want to use have been already uploaded on my private Nexus…but in order to use them…I will need to download them in a sub-directory named after packer-plugin-NAME_OF_THE_PLUGIN in PACKER_HOME_DIR/plugins.

Is that right ?

6

Hi,

After many unsuccesful tries with the eyes on the official documentation, I still get errors with dial tcp: lookup api.github.com: i/o timeout

  • I’ve set the PACKER_HOME_DIR and PACKER_PLUGIN_PATH environment variables, this time I get a permission denied error.
  • New try after updated the permissions (755 for plugins and 55 for sha256 file) : new error related to the sha256 file.
  • Last try after having delete the sha256 file…and it still not running as expected (timeout error this time).

The workstation on which I run Packer i meant to not having a connection to Internet, this is why I’m tring to work with a private registry

7

Hi,

Sorry for having bothered you so much this morning…I’ve figured it out by myself.
It’s little bit tricky, but once i’ve discovered how to do it, it’s easier.
I thought I had to keep the plugin block in my config…and i’ve tested with virtualbox-iso.

Thanks for your help

1 Like