Allow Local Builds of Images from Containerfile

[wbrawner]

Is your feature request related to a problem? Please describe. I don't necessarily want to have to push my development images to a remote registry.

Describe the solution you'd like It would be more convenient to simply provide a Containerfile in a repository alongside the source code that contributors could use to build a local image. toolbox create could then offer functionality to use this Containerfile instead of needing an image name.

Describe alternatives you've considered One can just run podman create prior to running toolbox create, though it would be nice to have toolbox handle that automatically.

Additional context VS Code has development containers that allow for maintainers to ship Dockerfiles alongside their code, so that contributors don't need to spend time configuring their machines with the necessary dependencies in order to be able to contribute code. Dev containers configure much more than the container images though, such as VS Code extensions and forwarded ports, and they aren't as tightly integrated with the desktop environment, so they aren't a great substitute.

[wbrawner]

I've been doing a little thinking here. toolbox create can just have a -f flag added to point to a Containerfile to build the image from, but what about other commands? Also, what about the naming of the container? Should we come up with some sort of naming convention based on the directory name to distinguish containers between various projects or should the Containerfile be required to include a name label? I think if we could agree on a naming convention for containers created from a Containerfile, we could have the other commands check for the existence of a Containerfile in the current directory and use that naming convention to check for an existing container for that directory and use it. Alternatively, we could leave the other commands unaffected and require a name argument be passed when toolbox create is called with the -f flag. Thoughts?

[debarshiray]

Yes, this will be good to have.

One can just run podman create prior to running toolbox create, though it would be nice to have toolbox handle that automatically.

One quick question. Did you mean podman build, instead of podman create? I don't see a way to make podman create create a container straight from a Containerfile.

[debarshiray]

I've been doing a little thinking here. toolbox create can just have a -f flag added to point to a Containerfile to build the image from,

Umm... doesn't podman build primarily require a build context because the Containerfile could refer to other auxiliary files. The simplest invocation of podman build is podman build ..

Ultimately, toolbox create will have to call out to podman build, so it will be wise to keep the interfaces aligned. So, instead of a -f option, maybe --build-context like podman build has? Podman actually accepts additional build contexts, but we can skip that for the first version.

I do hope that we don't end up with all the options that podman build has. I think it's reasonable to expect people to build the image separately, if it's sufficiently advanced.

Also, what about the naming of the container? Should we come up with some sort of naming convention based on the directory name to distinguish containers between various projects

That's a good question. I don't know. :)

should the Containerfile be required to include a name label?

Does podman build automatically honor a name label in the Containerfile? It doesn't seem to do that with:

$ podman build images/fedora/f38
...
Writing manifest to image destination
--> a77a31216d7a
a77a31216d7ad6aba587a12789206dc4184283652b3889987c327fcaf541960e
$ toolbox list --images
IMAGE ID      IMAGE NAME                                    CREATED
a77a31216d7a  <none>                                        17 seconds ago

If there's already a way to specify the image name in the Containerfile that podman build understands, then that would be the best. Else, maybe we need an option like --tag? Possibly with a different name, because --tag sounds odd in the context of create.

I think if we could agree on a naming convention for containers created from a Containerfile, we could have the other commands check for the existence of a Containerfile in the current directory and use that naming convention to check for an existing container for that directory and use it.

I wonder if there's some well known convention for naming images that we can re-use, because we can't always expect the Containerfile to include a name. We have a convention in Toolbx of creating the container name from the image name, but nothing for the image. So, if we don't have a name for the image, we don't have one for the container either.

Docker and Podman has this convention of randomly generating names for containers based on a list of adjectives and names. That's one option.

I am a bit afraid of inventing too many conventions for the first implementation. It would be better to keep it simple and let the conventions develop over time.

Alternatively, we could leave the other commands unaffected and require a name argument be passed when toolbox create is called with the -f flag. Thoughts?

Or, this, yes.

We provide ways for the user to specify a name for the image. By default, the container's name will be derived from this name, as we currently do, unless the user overrides it with a custom name for the container.

If the user doesn't specify a name for the image, then the container will be named after the image's hash, as we currently do. It's not pretty, but it works. Then we see how it evolves.

[boolzy]

I was just working on an alias/wrapper to do this by creating a shell function to call podman build, so it's nice to see plans for native functionality.

My approach was to have toolbox build call podman build, as to more logically separate CLI args, where toolbox create is more closely associated with podman create, so having build added under create seemed to cross responsibilities per say because I don't believe it's possible to build an image with podman create.

Ideally I'd like to see something like toolbox build -t localhost/custom-toolbox:latest /path/to/Containerfile, which more closely matches the podman build workflow.

It seems like there's already been some work to add the functionality under toolbox create in #1401 and #1469 so I'd be curious on opinions on dedicating a build subcommand. One of the advantages of keeping it under toolbox create would be the ability to build and run the container in one command. This does have some appeal, as if one has to run separate commands to toolbox build then toolbox create, it's not really saving anything other than the need to jump between podman and toolbox, compared to just doing everything with toolbox.