mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-01 11:19:52 +03:00
Docker images list wrong architecture #713
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Nacknime on GitHub (May 30, 2020).
Subject of the issue
All of your docker images/tags are uploaded with the OS/Arch set to Linux/amd64. This leads to "docker pull bitwardenrs/server" or "FROM bitwardenrs/server" always pulling the tag "latest" even on other hardwares/architectures.
Steps to reproduce
Run "docker pull bitwardenrs/server" on a Raspberry Pi (ARMv7).
Expected behaviour
Docker should automatically pull the tag raspberry.
Actual behaviour
Docker pulls tag latest and running the image fails.
@mprasil commented on GitHub (May 30, 2020):
This is because we use crosscompiling on x86_64 hardware. Docker hub does not provide other architectures for trusted (built by them directly from source) builds AFAIK.
There are images for other architectures available, they are just not picked up automatically by docker and you just need to select proper tag.
@jacksondaw commented on GitHub (May 30, 2020):
I think you are misunderstanding how docker works. If no tag is specified it uses "latest". The bitwardenrs/server:raspberry works great for me on a 3 b+.
https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-from-docker-hub
@jangrewe commented on GitHub (Jun 2, 2020):
@Nacknime This would be an issue for the Docker project then. Maybe you may want to ask over there if they could default to pulling the tag
raspberryinstead oflatestif the user is too lazy to specify the correct tag for his architecture, but don't get your hopes up that they'll implement this...Maybe this provides some more background: https://vsupalov.com/docker-latest-tag/
@jjlin commented on GitHub (Jun 2, 2020):
bitwarden_rs isn't currently a multi-arch image, mostly because of various technical and logistical complications, but it could be done.
It's a recognized issue, but it'll take time to fix it. Don't bother asking Docker to pull
raspberryinstead oflatestby default; this doesn't make sense, and Docker would never consider doing that.@fopina commented on GitHub (Jun 6, 2020):
Not using multi-arch actually rendered it impossible to use in my raspberry Pi swarm, as it checks the registered arch to choose a node.
as the existing images have amd64 registered as arch, swarm complains no node was found (even if
docker rundirectly in the Pi works)So I built my own multi-arch image -> https://github.com/fopina/bitwarden_rs_builder
Tried to understand how to build it directly from this project but a bit unfamiliar with rust and the existing dockerfile family is a bit confusing.
Would it bit of interest if I make a PR to this (using github actions, not dockerhub) so it ends up like what I have at https://hub.docker.com/r/fopina/bitwarden_rs/tags (linking as well for those who bump into this issue looking for a multiarch image)?
@macmpi commented on GitHub (Jun 10, 2020):
Would indeed really help to have proper arch set for seamless use through docker hub registry.
See an illustration of this for use on an arm64 NAS for exemple: can only see @fopina builds, but not originals.
Thanks for consideration.
@fopina commented on GitHub (Jun 10, 2020):
@macmpi feel free to use those in the meantime (or fork the builder and review/rebuild if you don’t trust 3rd party images - I don’t :P)