Intel Docker performance on M1?

[Internaut]

So here’s the situation. I have a base, 2015 Thinkpad X1 Carbon, aka the old banger, on which I’ve done a surprisingly successful experiment. On this, rather than local Java I have Docker Desktop for Windows, and a container I originally custom made in Google Cloud which is running my test automation framework. So, Java, Firefox, WebDriver, Cucumber and so on. I use VS Code for Windows and develop right inside the container.

It works like a charm. In fact, I think it might be more efficient than running Java under windows.

Now, I’m thinking of repeating this experiment on my base M1 Air. So same Intel based container, exported from the old banger/imported onto the Air.

Is this worthwhile or am I going to find the Rosetta translation hit (effectively on a VM) way too much, even when compared with eight year old Intel?

 

[vanc]

I use Docker based build environment for development. Last year when I got my MBP 16 with M1 Pro, I tried the same x86_64 image with Docker desktop, and it was too slow to use. Internally, Docker used QEMU to emulate the x86_64 Linux binaries.

Recently, Docker started to support x86_64 emulation with Rosetta2. That should improve the performance. The option is inside the "Features in development" section.

But for me, I managed to build a native arm64 image and it was way faster than the x86_64 image.

 

[Xiao_Xi]

I’m thinking of repeating this experiment on my base M1 Air. So same Intel based container, exported from the old banger/imported onto the Air.

What prevents you from recreating the Docker image using an Arm-based base image?

 

[Internaut]

What prevents you from recreating the Docker image using an Arm-based base image?

Point of a Docker Container, for me, would be something I could quickly hand to an employee without them having to set up their environment accommodate my software. Working 100% Intel is, in this respect, a convenience rather than a strict necessity. It‘s a nice convenience.

 

[Homy]

Maybe this would be of some help?

https://www.youtube.com/playlist?list=PLPwbI_iIX3aTT4ssN61Y4E5f1EXE-GCQs

 

[ondioline]

A branch where you change the base image to arm64 in your Dockerfile and using that instead of trying to shoehorn Rosetta or whatever else is going to be easier and better long term.

It frankly shouldn’t even require any changes if you’re using something like Ubuntu or Alpine? All the things you described build on arm64 for years now.

 

[Xiao_Xi]

Point of a Docker Container, for me, would be something I could quickly hand to an employee without them having to set up their environment accommodate my software. Working 100% Intel is, in this respect, a convenience rather than a strict necessity. It‘s a nice convenience.

Why don't you have two images: an Arm-based image for you and an X86-based image for your employee? You can develop your project using the Arm-based image with devcontainers and ship it on your x86-based image.

Although the main purpose of containers is to use the same image for development and production, you should be fine if you use two different images that have the same dependencies.

 

[VitoBotta]

I strongly recommend OrbStack instead of Docker for Desktop as the performance is much better

OrbStack · Fast, light, simple Docker & Linux

Say goodbye to slow, clunky containers and VMs. The fast, light, and easy way to run containers and Linux. Develop at lightspeed with our Docker Desktop alternative.

orbstack.dev

 

[Xiao_Xi]

I strongly recommend OrbStack instead of Docker for Desktop as the performance is much better

Does it work with VSCode as Docker? I had some problems when I tried Podman.

 

[VitoBotta]

Does it work with VSCode as Docker? I had some problems when I tried Podman.

It's a drop in replacement for Docker

 

[wyrdness]

Rosetta in a Linux VM seems to be a bit hit & miss at the moment. I have a build process that works perfectly on x86 in Docker, but wouldn't work with Rosetta on M2. Some processes wouldn't exit cleanly and became 'zombies' which caused the build to hang, as it was waiting for those processes to complete. So it's still an experimental feature and you may find issues. Or it may work perfectly for your use-case.

But why not just build arm and x86 images from your Dockerfile?

 

[Xiao_Xi]

But why not just build arm and x86 images from your Dockerfile?

Wouldn't an Arm-incompatible dependency be the only good reason not to use an Arm-based image?

 

[Internaut]

Wouldn't an Arm-incompatible dependency be the only good reason not to use an Arm-based image?

I would think certain developers using C, or libraries problematic on ARM, might run into problems. We ran into a bunch of Endian issues when migrating from Solaris/Spark to Linux/Intel (best move we've made). Your average Python/Java/PHP etc. developer wouldn’t have a problem.

Although my software runs perfectly well on macOS, ARM Linux, Intel Linux and Windows, I’ve decided it’s not worth the effort for me to have parallel ARM and Intel containers. Not yet, anyway (some training on our corporate Udemy, first, I think).