plugin: Podman plugin for Packer

[Polpetta]

Description

Hi, first of all I wanna say sorry for opening a ticket for this, but really I don't know how to get in touch with you Packer development team, so I followed the suggestion of the CONTRIBUTING.md file and opened an issue. Since I hit #8187 and I forcefully needed to use Podman instead of Docker for a software at work that is deeply integrated with Systemd I decided to give it a try and to port the already working Docker plugin developed by you guys (https://github.com/hashicorp/packer-plugin-docker) for Podman (I searched a little bit and I wasn't able to find any particular Packer plugin specific for Podman). I curbed down some features, like post-processors and ECR/Docker login, since I wanted to start with something minimal (if needed, I'll try to port the rest). I added support for Systemd with a specific flag and tried to write plugin documentation following the way Docker plugin does. You can find the source code here: https://github.com/Polpetta/packer-plugin-podman Most of the code is literally the Docker plugin, where I tweaked just some little parts here and there. I didn't fork it since I think Podman is a different program than Docker, even if the starting point is the same they have different features that could make the two plugins diverge in the codebase (for example, podman-compose). I hope this is ok (don't really wanna make any Copyright infringement), if not I'll take the necessary steps to fix it.

An example of how it works with Systemd support (HCL):

packer {
  required_plugins {
    podman = {
      version = ">= 0.1.0"
      source = "github.com/Polpetta/podman"
    }
  }
}

source "podman" "example" {
  image  = "fauust/docker-systemd:ubuntu-18.04"
  export_path = "output-example"
  changes = [
    "LABEL maintainer='polpetta'",
    "LABEL description='a podman block example'",
    "ENTRYPOINT /sbin/init"
  ]
  systemd = "always"
  run_command = [
    "-d",
    "-i",
    "-t",
    "--entrypoint=/sbin/init",
    "--",
    "{{.Image}}"]
}

build {
  source = [
    "source.podman.example"
  ]
  # ... additional providers, as usual :)
}

Currently I'm not planning of adding all the features Podman supports, but if anyone wants to contribute I'll gladly check and merge possible PRs. I hope this contribution will help Packer grow even more!

Last but not least thank you for building this amazing piece of software that helps me every day at work :tada:

[StephenWithPH]

@Polpetta ... I'm watching this with interest.

I have Packer's native packer-plugin-docker working right now using Podman by way of some shell indirection (putting a symlink somewhere on my $PATH named docker which points to my local podman binary). This seems to be working (so far!) because Packer shells out to invoke docker (see GitHub code search: https://github.com/hashicorp/packer-plugin-docker/search?q=Command%28%22docker%22)

An easy-but-naive path forward could be parameterizing the shell command used (since Podman's CLI is designed to accept all the commands Docker's CLI accepts).

I'm not sure if Hashicorp would accept a PR, but it might be a lower lift than a brand new plugin.

[StephenWithPH]

https://github.com/hashicorp/packer/issues/8187#issuecomment-575814442 shows some commentary around this

cc @theodoregoetz

[Polpetta]

@Polpetta ... I'm watching this with interest.

I have Packer's native packer-plugin-docker working right now using Podman by way of some shell indirection (putting a symlink somewhere on my $PATH named docker which points to my local podman binary). This seems to be working (so far!) because Packer shells out to invoke docker (see GitHub code search: https://github.com/hashicorp/packer-plugin-docker/search?q=Command%28%22docker%22)

An easy-but-naive path forward could be parameterizing the shell command used (since Podman's CLI is designed to accept all the commands Docker's CLI accepts).

I'm not sure if Hashicorp would accept a PR, but it might be a lower lift than a brand new plugin.

Hey! First of all thank you for checking out my plugin :blush: The problem with your approach is that you're not leveraging the full features Podman has: in my case, I had to use Podman to build my image because the stuff I was building had a mandatory Systemd dependence, so in that case just swapping Docker/Podman was not enough since I wanted to customize Systemd behavior while building (the only flag I added to the plugin I hacked up is Systemd flag).

That said, this could be a good approach for generating, as a starting point, a set of plugins for Buildah and Podman, but then I think even if they all are similar software they have their differences and those should be implemented too (I think this is the reason at the end of the day why one should use Podman instead of Docker in order to build an image, rootless aspect aside).

Finally, yes, most of the plugin is just invoking Docker under the hood and most of the plugin I made was just replacing docker with podman :grin: But that said there are different features that are worth implementing as separate plugins. Could be interesting to build a framework for Container-based builders tho :+1: