Docker images published should be arch agnostic

[l3mur 2]

When you publish the image it's possible to define a manifest to dynamically allow the arch of the pulling system to request the appropriate image. 

The current setup explicitly names the image by way of architecture. This is not best practice and incorrect. 

The git repo seems very inactive, Where do we go to make PRs to fix the deployment?

[Lessaj 467]

30 minutes ago, l3mur said:

The current setup explicitly names the image by way of architecture. This is not best practice and incorrect. 

Why do you feel that this is not a best practice and incorrect? I would argue that it is - if I have a 64 bit system, I would want it to install the 64 bit package, not the 32 bit one.

[l3mur 2]

I should have clarified, I"m talking about architecture in terms of arm64/x64/armv7. 

 

Docker hub allows you to publish multiple, architecture specific images under a single tag, and the docker client will appropriately pull the image it needs. 

For an example, navigate to any common tag selection and you'll see the available architectures. https://hub.docker.com/_/docker/tags for example. 

 

 

This is nice because if you're using multiple nodes running different arch cpus, you can leverage k8s/swarm to spin up new instances as needed. In my case I want to be able to leverage my desktop as a streaming server when necessary, but leverage swarm to switch to a rpi on the fly if I shut it down. 

[Lessaj 467]

Okay I think I see what you're saying, you want to have an instance that you can move between systems of different architectures - but if the docker client will get the appropriate image where is that introducing an issue of having it run on one machine vs another? The data itself shouldn't be any different between the architectures it's just the executables. I'll admit to not being particularly familiar with docker or swarm but understand the concepts, just not clear on what the setup is that is doing the composing and setting the architecture as it would move between systems. Seems like a fairly niche use case.  

[Q-Droid 989]

Isn't this how it works now, no need to specify arch when pulling? Or are you saying that when managing nodes in k8 it doesn't quite work the same way?

 

[adminExitium 355]

FWIW, the official docker images are amd64 only. So the first step would probably be to add arm64 as an available arch before compiling a multi-arch manifest.

Edited May 22, 2025 by adminExitium

[Q-Droid 989]

1 hour ago, adminExitium said:

FWIW, the official docker images are amd64 only. So the first step would probably be to add arm64 as an available arch before compiling a multi-arch manifest.

Doh! 

[l3mur 2]

6 hours ago, adminExitium said:

FWIW, the official docker images are amd64 only. So the first step would probably be to add arm64 as an available arch before compiling a multi-arch manifest.

A little confused by this statement, as on the official docker hub account from Emby there are arm64 images available: https://hub.docker.com/u/emby.

It should be possible to maintain the existing deployment process, and then just publish an additional manifest file that indicates what image to use for what arch. At least that's how it is on AWS. I'll mess around with it on docker hub and see if it offers something similar. 

[adminExitium 355]

Oh, sorry, my mistake. Generally, even without multi-arch manifests, it's only a separate tag, rather than a completely separate image so I missed that. That should make it simpler to combine the 3 images then, since the hard-work of multiple arch support is already done.

[l3mur 2]

Okay, I've rigged up a proof of concept. This will work for me, but for the project to benefit everyone else they probably just want to do this in the official registry:
 

docker pull emby/embyserver_arm64v8:latest                                                  
docker pull emby/embyserver:latest                                                          
docker tag emby/embyserver_arm64v8:latest aarobc/emby:arm64v8                               
docker tag emby/embyserver:latest aarobc/emby:amd64                                         
docker push aarobc/emby:arm64v8                                                             
docker push aarobc/emby:amd64                                                               
docker manifest create aarobc/emby:latest \                                                 
 --amend aarobc/emby:amd64\                                                                
 --amend aarobc/emby:arm64v8                                                               
 docker manifest push aarobc/emby:latest 

You can now see that the image is available with both amd64 and arm64 variants under the same tag of `latest` because of the manifest. 
https://hub.docker.com/r/aarobc/emby/tags

Edited May 22, 2025 by l3mur

[Q-Droid 989]

1 hour ago, l3mur said:

A little confused by this statement, as on the official docker hub account from Emby there are arm64 images available: https://hub.docker.com/u/emby.

It should be possible to maintain the existing deployment process, and then just publish an additional manifest file that indicates what image to use for what arch. At least that's how it is on AWS. I'll mess around with it on docker hub and see if it offers something similar. 

I wasn't aware of this either and agree they should be merged. Was under the impression Emby had already done this for the official image much like LSIO did for theirs. I only use amd64 so never really paid attention.

 

[alucryd 315]

Hi guys, finally got around implementing this, just pushed the latest beta as a multi-platform image. Please let us know how it fares. Cheers.