jetify-com
Feature Request: Allow alternative OCI image creation
It would be great to have pluggable container construction abilities so those on macOS using nerdctl/lima or buildah/krunvm could construct images transparently.
Thanks for a nice tool!
Reposting the podman request from #14:
Podman can be used as a (rootless and rootfull) drop-in replacement for Docker. Some users would like to take advantage of this, mainly on systems where the root filesystem is immutable and/or it is not beneficial to have both Docker and Podman installed.
All that would be required to support Podman afaik would be checking for a podman command and then using that if available (and possibly configurable in a configuration file and/or the CLI.)
Users can additionally work around this limitation of devbox by making either 1. an alias for Docker to pass to Podman, or 2. make a file in /usr/bin/ named docker that redirects to Podman. However, this isn't ideal, and it would most likely be trivial to implement support for Podman in the program itself.
I would love to help to implement this myself, however, I am inexperienced in Go, so I don't want to go tinkering where I shouldn't.
I'm not familiar with nerdctl/lima or buildah/krunvm, but Podman can be run rootless and is known to have some security advantages compared to Docker, so that's another good reason to support it! Can't wait for this.
Podman support should be fairly trivial, just make it check for that and use it if it's the only method available.
As for how devbox should handle multiple container managers, it might be best to have it set as a CLI flag and/or inside of a configuration file ($XDG_CONFIG_DIR/devbox/config.yml or something along those lines), like I suggested in #14.
I'm not knowledgeable on how other container managers work, but having it use a default if available and be configurable might be best.
Adding a note that another "engine" we might want to support is nix's own dockerTools.buildLayeredImage.
As an update for everyone on this issue, I'm thinking this is implemented via a flag called --engine:
devbox build --engine=podmanbuilds using podmandevbox build --engine=dockerbuilds using dockerdevbox build --engine=nixbuilds using nixdevbox buildbuilds using the default. We could make it smart so if you only have one of the tools installed it defaults to the one you have installed.
I'm also thinking this feature would be marked as experimental for a few versions of devbox, to gain confidence that it's working well before marking it as a fully supported.
devbox build --engine=nixbuilds using nixdevbox buildbuilds using the default. We could make it smart so if you only have one of the tools installed it defaults to the one you have installed.
From Optimising Docker Layers for Better Caching with Nix:
The automatic splitting and prioritization has improved image push and fetch times by an order of magnitude. Having multiple images allows Docker to request more than one at a time.
Ideally devbox could transparently use the nix engine to build docker containers by default so it can claim these thriftier docker images that are faster to download in it's marketing.
Note some questions of "why devbox over docker in" this reddit post about devbox.
@ParetoOptimalDev Agreed. I'll look more into using dockerTools transparently. One of my goals is for devbox to build optimized containers out of the box: think layers setup for optimal caching, automatic caching of dependencies for the language you're using, secure by default, minimal container size using multi-stage builds, etc.
The type of thing that people don't get right the first time they write a Dockerfile ... but with devbox they could get it for free without having to write one.
@orowith2os Just sent out a quick PR that adds support for podman via an --engine flag. I'll try to get it merged before the next release. If that works well, then we can figure out how to make that configurable without having to add the flag.
Version 0.0.4 is out and supports --engine=podman. If anyone that actively uses podman can try it out and give us feedback, that would be greatly appreciated!
Closing this issue since Devbox no longer builds containers directly. Dockerfiles + Devcontainers can now be generated using devbox generate dockerfile or devbox generate devcontainer.
