3 ms·

> On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are i

> On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are in. What on Earth are you talking about? arm64 Docker images predate the emergence of M1, and their number has proliferated in the last two years like there was no tomorrow. Here is an excerpt from my own tiny, non-representative collection of Docker images I have had to deal with lately: $ (for i in `docker images | tail -n +2 | awk '{ printf "%s:%s\n", $1, $2 }'`; do docker inspect $i | jq '.[].Architecture'; done) | grep -c amd64 7 $ (for i in `docker images | tail -n +2 | awk '{ printf "%s:%s\n", $1, $2 }'`; do docker inspect $i | jq '.[].Architecture'; done) | grep -c arm64 23 Most of the 23 arm64 Docker images is pretty obscure stuff, with one or two manually rebuilt for the arm64 architecture. Yet, I have downloaded all of my obscure images directly from the Docker Hub – not traded them for a pinch of spice from a shady Docker image dealer at a drench inducing corner of the dark web. All of the arm64 images run at the native speed, locally and in the cloud. The only reason I store x86 (i.e. «amd64») images locally is my laptop being a transient transit point between their source and the destination. I would have rebuilt them as well but the build process is either broken for each of them or is too convoluted to justify spending a time trying to fix it.

nxrabl 4y ago
But then it's not the same container, right? Either you'd need to switch your whole cloud infrastructure to run on ARM (which I see is possible now, and I'd be curious to hear if people have done that successfully) or we're back to "works on my machine ^W architecture".
- inkyoto 4y ago
  > Either you'd need to switch your whole cloud infrastructure to run on ARM … Nope, the whole cloud infrastructure does not need to switch. Since containers are fully self-contained, self-sufficient and isolated from each other, they can coexist peacefully and run alongside each other in a mixed setup in AWS ECS/Fargate clusters. And they do. AWS Lambda also supports aarch64, and the degree of isolation for the lambdas is even higher and they can also run out of a x86 or an aarch64 Docker image (if required), and 30-40% cheaper with performance loss incurred for the workloads I am interested in.
  - inkyoto 4y ago
    > […] and 30-40% cheaper with performance loss incurred for the workloads I am interested in. Should read: «… with no performance loss incurred for the workloads I am interested in». A typo crept in.
cmeacham98 4y ago
I was exaggerating slightly - you will get some images in ARM. But it's hard to not see this as evidence for my point when you were only able to rebuild "one or two" of the 8-9 amd64 images you're running without significant time investment. By your own stats roughly one third of the images you use don't support ARM. And if you want to run one of those on ARM - you're likely screwed! Even some _official_ images don't support ARM, random example: https://hub.docker.com/_/percona https://hub.docker.com/_/percona Docker ARM support is improving, but acting like it's ready for prime time is laughable. Try doing your day job with no amd64 containers for any reason for a month and come back to me.
- inkyoto 4y ago
  You had made a response to the following statement – the one I was responding to: > On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are in. The statement is false. x86 containers do not use the translation, hence they can't run on M1. People have been successfully running aarch64 (ARM) containers, including on AWS Graviton (re:Invent 2018) and on Graviton2/3 (more recently), for a few years now. Oracle cloud have been offering Ampere cloud compute resources for… a couple of years now? But you have conveniently dodged it, for it did not suit your agenda and presented it as «exaggerating slightly». It is not slight and it is not exaggeration, it is a blantantly distorted and also a likely ignorant statement. > But it's hard to not see this as evidence for my point when you were only able to rebuild "one or two" of the 8-9 amd64 images you're running without significant time investment. > By your own stats roughly one third of the images you use don't support ARM. And if you want to run one of those on ARM - you're likely screwed! Whether one is screwed or not is a matter of perspective (I am certainly not the one), just as 23 aarch64 images are hardly «were only able to rebuild "one or two"». I have revised my 9 locally stored x86 images, thanks to you, and purged one stray one, with the remaining ones being, in fact, an images itself, and an Docker image tag slapped on it. Therefore, I only have 4x remaining x86 Docker images, but of course it is not going to convince you and you will resort to a distorted narrative again. > Docker ARM support is improving, but acting like it's ready for prime time is laughable. «Docker for ARM» means «Docker running on Linux/ARM». Docker has supported Linux, and Linux has support aarch64 for a long time now. Solutions I design for my clients have been running as/in aarch64 containers for a few years now, and my clients indeed now find it laughable how they could not switch to ARM sooner due to 30-40% lesser cloud compute bills. Most solutions do not require neither containers nor servers, though, it is only the platform related stuff. > Try doing your day job with no amd64 containers for any reason for a month and come back to me. If you don't understand the difference between the aarch64, and that the Apple instantiation of the aarch64 architecture is not the only one, then you it is unlikely that you understand what Docker is and what Docker is not. Therefore, it will be difficult for you to self-assess and quantify the magnitude of your own uproarious laughter. We are at a point now when the CPU has become a configuration setting at the infrastructure provisioning time, and is not an insurmountable barrier. All of the containers I need to run for my current needs, run, and they do it perfectly well in mix and match Fargate container clusters. Most containers are Graviton2 containers, with a few select ones (the ones that are cumbersome to rebuild), run in AWS x86 containers, and both types coexist peacefully. Last but not least, I do not even run most containers locally, I occasionally help developers with build related problems or to cobble a POC together to verify an idea, evolve it into a solution or a product, and scrap the container setup. Everything else, including production workloads, runs in the cloud, and it just works 24x7.

nxrabl 4y ago

But then it's not the same container, right? Either you'd need to switch your whole cloud infrastructure to run on ARM (which I see is possible now, and I'd be curious to hear if people have done that successfully) or we're back to "works on my machine ^W architecture".

inkyoto 4y ago
> Either you'd need to switch your whole cloud infrastructure to run on ARM … Nope, the whole cloud infrastructure does not need to switch. Since containers are fully self-contained, self-sufficient and isolated from each other, they can coexist peacefully and run alongside each other in a mixed setup in AWS ECS/Fargate clusters. And they do. AWS Lambda also supports aarch64, and the degree of isolation for the lambdas is even higher and they can also run out of a x86 or an aarch64 Docker image (if required), and 30-40% cheaper with performance loss incurred for the workloads I am interested in.
- inkyoto 4y ago
  > […] and 30-40% cheaper with performance loss incurred for the workloads I am interested in. Should read: «… with no performance loss incurred for the workloads I am interested in». A typo crept in.

cmeacham98 4y ago

I was exaggerating slightly - you will get some images in ARM. But it's hard to not see this as evidence for my point when you were only able to rebuild "one or two" of the 8-9 amd64 images you're running without significant time investment. By your own stats roughly one third of the images you use don't support ARM. And if you want to run one of those on ARM - you're likely screwed! Even some _official_ images don't support ARM, random example: https://hub.docker.com/_/percona https://hub.docker.com/_/percona Docker ARM support is improving, but acting like it's ready for prime time is laughable. Try doing your day job with no amd64 containers for any reason for a month and come back to me.

inkyoto 4y ago
You had made a response to the following statement – the one I was responding to: > On recent M1/M2 Macs you take the additional pain (and thus performance hit) of translation to x86 (because that's almost certainly what your containers are in. The statement is false. x86 containers do not use the translation, hence they can't run on M1. People have been successfully running aarch64 (ARM) containers, including on AWS Graviton (re:Invent 2018) and on Graviton2/3 (more recently), for a few years now. Oracle cloud have been offering Ampere cloud compute resources for… a couple of years now? But you have conveniently dodged it, for it did not suit your agenda and presented it as «exaggerating slightly». It is not slight and it is not exaggeration, it is a blantantly distorted and also a likely ignorant statement. > But it's hard to not see this as evidence for my point when you were only able to rebuild "one or two" of the 8-9 amd64 images you're running without significant time investment. > By your own stats roughly one third of the images you use don't support ARM. And if you want to run one of those on ARM - you're likely screwed! Whether one is screwed or not is a matter of perspective (I am certainly not the one), just as 23 aarch64 images are hardly «were only able to rebuild "one or two"». I have revised my 9 locally stored x86 images, thanks to you, and purged one stray one, with the remaining ones being, in fact, an images itself, and an Docker image tag slapped on it. Therefore, I only have 4x remaining x86 Docker images, but of course it is not going to convince you and you will resort to a distorted narrative again. > Docker ARM support is improving, but acting like it's ready for prime time is laughable. «Docker for ARM» means «Docker running on Linux/ARM». Docker has supported Linux, and Linux has support aarch64 for a long time now. Solutions I design for my clients have been running as/in aarch64 containers for a few years now, and my clients indeed now find it laughable how they could not switch to ARM sooner due to 30-40% lesser cloud compute bills. Most solutions do not require neither containers nor servers, though, it is only the platform related stuff. > Try doing your day job with no amd64 containers for any reason for a month and come back to me. If you don't understand the difference between the aarch64, and that the Apple instantiation of the aarch64 architecture is not the only one, then you it is unlikely that you understand what Docker is and what Docker is not. Therefore, it will be difficult for you to self-assess and quantify the magnitude of your own uproarious laughter. We are at a point now when the CPU has become a configuration setting at the infrastructure provisioning time, and is not an insurmountable barrier. All of the containers I need to run for my current needs, run, and they do it perfectly well in mix and match Fargate container clusters. Most containers are Graviton2 containers, with a few select ones (the ones that are cumbersome to rebuild), run in AWS x86 containers, and both types coexist peacefully. Last but not least, I do not even run most containers locally, I occasionally help developers with build related problems or to cobble a POC together to verify an idea, evolve it into a solution or a product, and scrap the container setup. Everything else, including production workloads, runs in the cloud, and it just works 24x7.