KeyDB
KeyDB copied to clipboard
Snapchat
[NEW] Arch-less docker version tags
The problem/use-case that the feature addresses
I'd like to pin the docker image to a specifc version but without specifying the architecture. The current tags x86_64_vx.x.x and arm64_vx.x.x only provide arch-specific images, so it's not possible to pin a specific version while remaining portable across archs.
Description of the feature
Introduce arch-less vx.x.x tags which provides multi-arch images.
Same request here, there is docker manifest for creating multiarch manifests AFAIK
Now that more and more devs are moving to M* Macs, this is becoming even more welcome.
And heterogeneous k8s clusters can't use images that were generated with the current schema
Please just steal the code https://github.com/codemowers/keydb/blob/24cac279950d5acbadd54f7e659300c0adb3c474/.github/workflows/docker.yml
We already use manifests for the "latest" docker tag, for clarity you also want this functionality for each specific version? ie. docker pull eqalpha/keydb:v6.3.3
Yes please include multiarch builds for versioned tags
Also please include the Dockerfile in the Git repo for reproducible builds. How are these images produced? Locally on someone's laptop? If that's the case I'd highly recommend switching to GH actions or similar to prevent supply chain attacks
I am also confused why the images are under eqalpha org? Why not use org keydb?
Dockerfiles are located here: https://github.com/Snapchat/KeyDB/tree/main/pkg/docker. Regarding it being under eqalpha, this was a legacy name and we are looking at moving it under the 'snapchat' org namespace or registering it as an official Docker image.
I think most people are looking for Dockerfile on top level, so I'd place it there but I guess that's matter of how the source is organized
In any case how about using proper multistage Dockerfile etc? The current Dockerfiles look pretty messy. This whole gosu thing looks like total mess. How about just issuing USER 1000 and be done with it? Docker should drop the privileges and for Kubernetes we use security context anyway. I don't see why the entrypoint is generated in such a messy way as well...
Any updated on this? It's been a while and I can't see any changes yet :confused:
