Packer plugin for Incus

Incus
1

I’ve forked the LXD plugin and spent a couple of hours fixing it up.

There is no published, signed release yet, but if you build from source and copy packer-plugin-incus into the directory where you invoke packer, you can start fooling around.

The LXD plugin shelled out to lxc, and a find/replace in the codebase was enough to get simple re-packaging of an ubuntu container image working. However, I think long-term it’s better to use the Go SDK directly.

Packer + LXD historically has yielded fairly large images, and I’m interested in ways to mitigate that, at least a little, with post-processing, or clever build techniques. There is also the notion of supporting multiple build techniques (“builder types”), which is something the Azure packer plugin does. See the docs here: Azure | Integrations | Packer | HashiCorp Developer

The Azure plugin has a standard launch->run scripts->snapshot whole disk builder, but it also supports a rather interesting “chroot” builder, which relies on a pre-existing VM in your infrastructure, mounts a new disk on it, and provisions a rootfs in a chroot. The chroot builder can be radically faster, since there is no boot stage.

So perhaps there is an approach that we could explore for Incus builder types that are a middle ground between the current snapshot approach and distrobuilder. And if it could share code with distrobuilder, that would be even more awesome.

1 Like
2

I think there might already be one.

3

I have this one: packer plugin incus
Always happy to have help if something is missing.

4

How did I miss that? I even follow Brian on GitHub

2 Likes
5

Brian, maybe add topic tags to the GitHub repo? I feel like literally searching “incus packer” should return your repo. Repository search results · GitHub

It didn’t for me yesterday.

In the meantime, I’ll rename this to packer-plugin-incuschroot or something, and if I get a builder with an alternative strategy working, I’ll submit it to your repo as a feature.

2 Likes
6

good call, done.

7

@bketelsen : would it be possible to add support for incus projects?

So something like this:

“builders”: [
  {
    “type”: “incus”,
    “project” : “myproject”
    …
  }

This is useful for me because the user that runs packer may have called incus switch to use a different default project and the temporary container created by packer cannot be run in that project.

8

@bketelsen ^

9

Hi @bketelsen , thanks a lot for your plugin, I think it will help me a lot creating all my custom images.

I have the same need as @cquike so I created a PR on your project here Add --project support by bgaillard · Pull Request #6 · bketelsen/packer-plugin-incus · GitHub

@cquike , waiting for the review I think you can build it from my fork and test it using the instructions I mentioned in the PR.

cd ~/workspace
git clone https://github.com/bgaillard/packer-plugin-incus.git
go build
packer plugins install --path ./packer-plugin-incus "github.com/bgaillard/incus"

Can you give it a try an indicate if it works as expected ?

Thanks

10

Dear @bgaillard ,

thanks a lot for that work. I am afraid I don’t have right now a test system where I can test this, and I don’t won’t to disrupt the production one. I cannot promise, but maybe by the end of this week I can give it a try, otherwise it would need to happen next year.

Thanks!

11

Hi @cquike , no problem you’ll test it when you’ll have time to do it.

Since my last message @bketelsen merged my first MR, thanks a lot for this! Just after that I realized I missed an other update so I created an other MR Fix UploadDir with --project and fix CI. by bgaillard · Pull Request #7 · bketelsen/packer-plugin-incus · GitHub (sorry for the confusion @bketelsen ).

So @cquike I think you can still continue to use my branch waiting for the MR7 to be merged.

I used this branch since several days now to create images for my homelab and it works as expected for now.

Have a nice day!