Enhancement: Defaults for packages rather than building augmented images
terev opened this issue · 7 comments
The motivation behind this issue would be to eliminate the need to build docker images for repositories that require manual configuration for environment variables volumes, etc. These things likely don't change between patch, minor or even major versions. So i'm proposing a way to distribute a set of default settings based on public image repository name. And possibly a way to map an image's tag to a built tag in order to version defaults.
The whalebrew-packages repository could be transformed to a set of skeletons used as defaults that can be overridden by the actual image labels when installing the package. The skeletons would just serve as a repository for these defaults.
A skeleton for awscli might look like:
FROM scratch
LABEL io.whalebrew.name aws
LABEL io.whalebrew.config.environment '["AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY", "AWS_SESSION_TOKEN", "AWS_DEFAULT_REGION", "AWS_DEFAULT_PROFILE", "AWS_CONFIG_FILE"]'
LABEL io.whalebrew.config.volumes '["~/.aws:/.aws"]'On my system after building this image docker says it's size is 0B
Essentially using dockerhub (and possibly private repos if the image is from there) as a store for these settings.
This would allow decoupling the labels from their actual image. Allowing new images to be used but the package would still work with whalebrew because of these defaults. Labels on actual images could be treated as overrides.
@tjamet any thoughts about this idea? I haven't flushed out the details but I'm curious hear opinions about if it's even reasonable.
I am wondering how would this look like, how to know what is the "package" image to use for a given "program" image.
I fear that de-coupling both may introduces some complexity we could avoid.
It looks like being able to run whalebrew install whalebrew/gawk --use-image mor1/gawk
Also wondering about the problem to solve. Are we trying to ensure images are kept up to date so we can benefit the latest version, always?
The problem this is trying to solve is avoiding having to build encompassing images for a given base image in order for it to be supported by whalebrew. If solved this would allow tags of any given image to be used as long as there's an associated whalebrew config for it.
When installing an image like whalebrew install wget whalebrew could check the whalebrew image repository for an image with the same name (whalebrew/wget this image could just contain the labels) then pull and inspect it to use the labels as defaults. It would also be nice as you pointed out to be able to tell whalebrew an image to use as the base config. It would also be possible to make where to look for these configuration images configurable via the whalebrew config file.
For example node has images for a lot of releases of the cli tool but whalebrew only has one supported tag latest.
I am seeing there multiple points that we could handle separately.
First is the ability to use a different image for a given package.
This is a pretty nice feature IMHO, which is already supported by installing an image and then editing the installed file whalebrew edit wget in our case. This is not as user friendly as it could be and we can indeed take an action on it to improve the UX.
On top of that, there is the reasoning about package and image to be used. I know that we are currently short in supported versions of images to be used, and hence require to tweak the settings to be able to install latest versions of several tools. Though, the model that we have currently (packing the tool together with the configuration) allows us to ensure that the package works correctly with the tool, and manage easily breaking changes. This is a quite common case in the packaging world, from Debian packages to homebrew, versions are pinned in the packages. Breaking this would make us face the package/program matching problem on our side, which I am unsure we want to get in. Instead, I would prefer to invest in improving the packaging to provide a wider range of versions, and checking that the packaging actually works.
I do have some ideas on the matter, I will try to come up with them shortly.
The last point is about matching the package and the program depending on the image name. I am unsure this needs to be performed automatically at the whalebrew level. Whalebrew could provide helpers for humans to do so, allowing them to check that both packages are actually installing the same program, not injecting malware, ... so we can have eventually have insights through issues and proposals on how users actually uses the feature and propose something that fits with the common usage.
Pls disregard my previous edits of this comment. Your suggested solution for the --use-image flag seems like a great ux improvement.