Open tclasen opened 1 year ago
I was just going to open this exact ticket myself. mongo:5.0 arm64 image runs fine on m1/m2 for example.
@javsalgar is there any way I can help? I was looking at the existing workflows thinking about opening a pr, but doesn't seem like the build/release part of the automation is on github.
Having this fixed would be quite valuable for us at @RocketChat
Hi!
I'm afraid we currently don't have support for Debian 11 ARM. As soon as we add support for this, we will notify the community
We have been using this unofficial mirror of bitnami/mongodb
image that supports arm64 https://hub.docker.com/r/zcube/bitnami-compat-mongodb. In case someone else finds it useful.
We have been using this unofficial mirror of
bitnami/mongodb
image that supports arm64 https://hub.docker.com/r/zcube/bitnami-compat-mongodb. In case someone else finds it useful.
Cheers for this! exactly what I needed today!
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
// not stale.
We're using Apple Silicon as well and rather not rely on a workaround but stay with the Bitnami implementation (as we're using RocketChat and RocketChat suggests to use the Bitnami MongoDB image).
Therefor I wonder; does anyone have an update or estimation on this issue? Apple Silicon is out for a rather long time and here to stay I think. Is this issue deemed fixable and on a road map, or would it be best for us to plan under the assumption it won't be fixed in any foreseeable future?
At this moment there is not a bitnami/mongodb multiarch image available. Having said that, we have an internal task still on our backlog to revisit the unsupported apps. We'll update this thread once done the mentioned task
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
// not stale
Seconding // not stale
too
We are experiencing the same issues in our company. Our engineers have all migrated to m1s or m2s and since we upgraded to mongo 6.0.10 we are unable to run the bitnami images on our local machines. We would very much appreciate a fix being put in for this
Also interested in the solution here
any updates on this topic?
+1
Hi every one, today I was finally able to install mongo v. 6.0.11 in a k3d Kubernetes cluster on my MacBook with M1 chip. Mongo is installed via the operator, which on arm machines does a problem as the mongo-agent it installs doesn't have an arm64 image yet. See here https://github.com/mongodb/mongodb-kubernetes-operator/issues/1420#issuecomment-1790885017.
Cheers
tryed today the mongodb-14.0.14 and v13.18.5 chart both with now luck...
Still actual for Mac M1
Teammate just ran into the same problem on his Mac M1
At this moment there is not a bitnami/mongodb multiarch image available. Having said that, we have an internal task still on our backlog to revisit the unsupported apps. We'll update this thread once done the mentioned task
@carrodher Any update or ETA on that task?
The latest version of MongoDB does not yet support ARM: https://www.mongodb.com/try/download/community. ARM is only supported on Ubuntu and MacOS while our catalog is based on Debian.
Same problem 🥲
Working on an M1 after upgrading to Docker Desktop 4.27.1 (Docker Engine 25.0.2) and enabling the EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU environment variable.
Example: docker run -e EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 --rm -it docker.io/bitnami/mongodb:7.0
@borodiliz hey, I am new to this, could you tell me how can I enable the variable in a docker compose based project?
@borodiliz hey, I am new to this, could you tell me how can I enable the variable in a docker compose based project?
@DarhkVoyd Sure. Same as other environment variables. Here is a complete example:
version: "3.8"
services:
mongo:
image: bitnami/mongodb:5.0
environment:
- MONGODB_ADVERTISED_HOSTNAME=127.0.0.1
- MONGODB_REPLICA_SET_MODE=primary
- MONGODB_ROOT_USER=elon
- MONGODB_ROOT_PASSWORD=supersecret
- MONGODB_REPLICA_SET_KEY=foobar123
- EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 # This is required on Apple Silicon https://github.com/docker/for-mac/issues/6620
ports:
- "27017:27017"
volumes:
- "mongo-db:/bitnami/mongodb"
volumes:
mongo-db:
@borodiliz
Finally!! It worked, thank you so much you are life saver. I wasted my entire week on this error.
Should I also explicity set platform: linux/amd64
.
Thanks @borodiliz!
EDIT: Please use this for local development ONLY!!!
For those using Helm, you can include this in the values file:
extraEnvVars:
- name: EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU
value: 1
Guys, quemu emulation workaround is not suitable for Kubernetes use and not suitable for Production environments at all. Its only workaround for some dev envs, not a solution yet.
The workaround for local development works 🎉 . However I had to turnoff rosetta acceleration in Docker Desktop settings (Apple virtualization and virtIO can be enabled).
Name and Version
bitnami/mongodb:5.0.10-debian-11-r3
What architecture are you using?
arm64
What steps will reproduce the bug?
I'm actually trying to run the Bitnami helm chart for Mongodb running in minikube on a M1 Mac. But I can replicate the problem with:
docker run --rm -it docker.io/bitnami/mongodb:5.0.10-debian-11-r3
What is the expected behavior?
I would like to see aarch64 (arm64) images published to dockerhub for 5.0.10 and newer versions of Mongo.
What do you see instead?
It hangs on this step forever. In the k8s template, the pod is restarted due to being detected as stuck and timed out.
I've tried to build these myself using the bitnami/containers repo, but I get the following error:
Additional information
According to the mongo forums the x86 binary requires the AVX CPU flag which isn't provided by the Rosetta x86 emulator, meaning it is expected that the x86 version of mongo would never be able to run on the aarch64 (arm64) architecture of a M1 Mac. https://www.mongodb.com/community/forums/t/mongodb-docker-container-not-starting-properly/160540