[SERVER-75583] Provide the official images for other architectures than x86 Created: 03/Apr/23  Updated: 09/Oct/23  Resolved: 27/Sep/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Sebastian Laskawiec Assignee: Zack Winter
Resolution: Done Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-77678 Docker images not working as expected Closed
Related
is related to SERVER-75539 Server doesn't boot up in Kubernetes ... Closed
Assigned Teams:
Server Development Platform
Participants:

 Description   

Problem statement

At the moment, the official Server container images are provided only for linux/amd64 platform. In order to provide full parity with the Docker Community-maintained images, we should provide other architectures as well.

ARM64 seems to be the most critical one as it makes the development on M1 MACs much easier.



 Comments   
Comment by Zack Winter [ 29/Aug/23 ]

Hey alex.neben@mongodb.com, for the multi arch I’m thinking of doing something pretty similar to what we originally discussed:

  • Create new set of tasks that run on an arm variant to build, test, and tag the new arm docker image
  • Create a task that depends on arm & amd build/test/tag tasks, which then uses `docker manifold` to reference the newly built images for each arch
  • In the case of a failure, short circuit the manifold combination step
  • Only allow re-running the entire process, creating new tags for each dependent arch

I thought of a few potential issues, do you have any thoughts on any of these?

  • It looks like we’re currently building with buildx, do you know if there might be any parameters that we’re passing it that we’ll also need to pass to the multi-arch image, but aren’t supported by manifest? Manifest seems to be the older command so I’m not sure if it has feature parity.
  • This solution involves arm:latest & amd:latest potentially getting out of sync and pointing to different versions of the code. This doesn’t seem like a major issue to me since I don’t know if there’s any way to actually guarantee they’re always fully in sync anyway and I don’t know if customers would have any kind of dependence on this
  • In the case of failures, retrying would retag image builds that already succeeded (ex. if arm fails but amd succeeds, retrying would create a new tag for amd). I don’t think this would be an issue either, but I’m not very familiar with the costs associated with docker image hosting

I think this approach is pretty similar to the one you started work on so I'm curious if you ran into any issues with that.

The main alternative would be to create an intermediate tag for each arch that we would still push after testing for that arch completes, but we would instead only retag it with a public-facing tag after all arch tests pass. The main drawbacks would be additional complexity and the fact that we would now be blocking all image pushes whenever we fail on a single architecture. It would also be a lot messier to define single architecture build pipeline that pushes to publicly facing tags since that step would then be tied to the multi-arch combination step. It does have the benefit of keeping the *:latest tags consistent in terms of pointing to the same code version across all archs + the multi arch image.

Do you have any preference on going in either direction?

Comment by Alex Neben [ 22/Aug/23 ]

Here is a good guide to making multi platform images.

Comment by Ciprian Tibulca [ 14/Aug/23 ]

for Local development experience for Atlas via Atlas CLI  project we also need ARM64 and Windows for the enterprise images

Comment by Alex Neben [ 08/Apr/23 ]

Here is my half baked attempt at this before: https://github.com/10gen/mongo-container/pull/29/files (merge conflicts need to be fixed). This requires some input from the build team. If we are going to prioritize this we need the build team to provide us someway to support multiarch images.

Generated at Thu Feb 08 06:30:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.