After making infrastructure as code project Terraform the star of HashiConf on day 1, day two was all about machine image building tool Packer.

In his opening keynote, HashiCorp co-founder Armon Dadgar explained that there had been a disconnect between what his company wanted to achieve — which is to enable cloud infrastructure — and its way of implementing it: namely, offering local desktop tools. 

To break this up, the company used the last couple of years to make a move into the cloud tooling space, introducing products such as Terraform Cloud and HashiCorp’s Cloud Platform HCP, a fully managed infrastructure automation offering.

HCP Packer to arrive later this year

In the coming months, Packer will join Consul and Vault on HCP. The new service isn’t meant to be a “Packer in the cloud”, as Packer engineering lead Megan Marsh puts it, but should rather help to enhance existing workflows. Other goals for the service include centralised governance and the simplification of image lifecycle management. 

To help with the latter, the first service that will be made available is a HCP Packer registry. According to Marsh, the registry is a form of metadata tracker supporting teams to stay on top of image dependencies and builds across different clouds and template versions. Somewhere along the line it is also supposed to act as a data source for Packer and Terraform, so that these tools can pull specific image versions, and even allow users to set custom release channels.

Exact dates when this will be ready to be taken for a spin aren’t out yet, though interested teams can already sign up to join the beta program.

Meanwhile on-prem …

While HCP Packer is on its way, the team behind the “traditional” Packer is working hard on getting it ready for its next major release. Packer 2.0 will mainly bring about changes in the plugin space and focus on HCL templating, Marsh told users in another HashiConf session. 

Thanks to the multi-component plugins, which first made an appearance in Packer 1.7 and allow the serving of more than one component, the Packer team was able to sensibly extract plugins historically bundled with the project’s core into separate repositories. This is meant to help get the size of the initial Packer binaries down considerably. 

However, it also means that, starting with the 2.0 release, the recently introduced and still optional packer init command will be required to retrieve official and community plugins (though manual installing will still be an option). 

Another big change is that, moving forward, Packer will only work with HCL templates. Currently JSON is still an alternative, but since the company plans to go all in on its own format, JSON templates will be deprecated with the 2.0 release.  

Other things on the official roadmap include image pipelining and provenance tools that are created in cooperation with the HCP team. Unofficially, Marsh is also keen on getting capabilities to facilitate multiple communicators per build and reusable provisioner configurations into the tool.

Times are changing — Vagrant tries keeping up

With Packer taken care of, the last session of the event went back to the roots with a look at what’s in store for HashiCorp’s “first revenue-producing product”: Vagrant. The Ruby project was introduced in 2010 as a tool for building and managing VM environments. While most other HashiCorp tools are shipped as binaries, Vagrant is shipped as a package along with its dependencies. Though a bit complicated to maintain, this setup makes installation comparatively easy and also helps with reproducibility.

However, in the last couple of years it turned out that the architecture chosen for Vagrant prevents the tool from addressing current challenges, and makes it hard to implement some often requested features as well as use some libraries from other HashiCorp tools.

To make sure Vagrant stays an option for at least ten more years, the product team has come up with some steps to make it easier to maintain and enhance. Much like Packer’s developers, Vagrant devs have decided to drag their 70 plugins out of the core and into their own projects. This is meant to make it easier to look after and enable users to contribute.

To better tie Vagrant in with other HashiCorp tools, the project also decided to switch from Ruby to Go. The porting process will go hand in hand with the reworking of the Vagrant architecture. Amongst other things, this will help the team maintain a stricter component interface and implement highly-requested features for permission and privilege escalation management or remote execution. It will also pave the way to using HCL in Vagrant.

This is surely a major step, so maintaining backward compatibility is high on the agenda and it all boils down to the promise that old Ruby plugins and Vagrant files can still be used “for a long time”. Vagrant is currently on v2.2 and porting activities are in full swing. Software engineer Sophia Castellarin explained the timeline, saying the project will stop shipping Ruby with their packages by the time they get to the 3.0 series. Existing Ruby plugins will still be supported then, but it will be more of a “bring your own Ruby situation”.