Add 'platform' option in docker_container

[andrey-yantsen]

SUMMARY

It would've been great to have a platform option in docker_container. E.g. in some strange cases, you could want to run the linux/386 container on linux/amd64.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

docker_container

[felixfontein]

I'm not sure what that flag should do. Do you mean it should be used when the image needs to be pulled?

You could use the docker_image module instead to pull the image with platform specified.

[andrey-yantsen]

To be honest — I'm not sure :) All in all, I was thinking about the platform argument in docker run, which is available since Docker 17.09.

Currently, if I use docker_image with specified platform I'll receive the following warning in the output:

[WARNING]: Docker warning: The requested image's platform (linux/386) does not match the detected host platform (linux/amd64) and no specific platform was requested

[felixfontein]

I looked at the source code of the of the docker CLI client, and found out that container creation accepts a query parameter platform: https://github.com/docker/cli/blob/master/vendor/github.com/docker/docker/client/container_create.go#L42

Unfortunately, this is not documented in the API docs: https://docs.docker.com/engine/api/v1.41/#operation/ContainerCreate (it only documents the query parameter name). Consequently, the Docker SDK for Python (which we use to talk to the Docker daemon) also does not support platform for container creation.

Until the Docker SDK for Python supports this, we can't implement it, unfortunately. I raised an issue for that in its repository: docker/docker-py#2822

[andrey-yantsen]

Thanks for looking into this!

Just in case I took a look at the docker-py documentation — I'm not sure which method are you exactly talking about, but I can see that there's a platform argument for client.containers.run() and client.containers.create(): https://docker-py.readthedocs.io/en/stable/containers.html.

[andrey-yantsen]

Ah, I see, it's not supported in the low-level API you're using. Strange enough.

[felixfontein]

Yes, I was looking at the low-level API (https://docker-py.readthedocs.io/en/stable/api.html#module-docker.api.container), since that's the one we are using.

[felixfontein]

I checked the sources for client.containers.create(), it only uses platform for self.client.images.pull(image, platform=platform). That's different from what docker CLI uses that parameter for.

[ju2wheels]

Adding as a side note that this is a useful feature for cross-arch testing if you have already setup Docker to use qemu with buildx and setup a custom builder, then having this option on docker_container is useful. It prevents the need to have to use Docker image to pre-pull each platform image before using it (since the local image store can only have one platform per image tag even if the tag in the upstream repository references a multi-arch/platform image manifest). Kind of weird that the low level API's didnt implement that, so pre-pulling the images seems to be the only viable workaround currently.

[felixfontein]

I agree. Actually I created a PR for Docker SDK for Python to implement this more than a month ago (docker/docker-py#2927), but the repo maintainers apparently haven't taken a look so far...

[pinko-fowle]

Searching for "m1" doesn't show anything in the issue tracker, so commenting here just to be explicit: this would be ultra ultra helpful for Apple M1 users.

Specifying platform "linux/amd64" would let us run x86 containers in Docker, which is needed if there are no ARM builds of the container available.

[ju2wheels]

Ive managed to move my platform over to ansible-core 2.11 and work around all the issues here without too much of a fuss.

The only real issue is with the image downloads... if you already have an image for one architecture locally, you have to use the docker_image task with some of the force options to force overwrite the tag with another architecture and you have to explicitly disable pull on the docker_container task or it will always want to overwrite that image tag with a native architecture one (no idea if thats a bug or not since the default should be its NOT supposed to pull but thats not what I experienced).

So if you dont mind pre-pulling your image for the architecture you want, it still works ok. Im using Linux primarily, but a few of my teammates have got this going on Macs as well (not sure if they were M1s specifically).

This pre-pull with docker_image and no pull on docker_container worked for us on both platforms when combined with buildkit/buildx qemu emulation (for non native architecture support) using https://github.com/tonistiigi/binfmt for multi-arch image build/run.

[pinko-fowle]

Blocked on docker-py being unmaintained. New ansible issue on that: #364

[felixfontein]

I created a first implementation of this in #426 (based on the rewrite #422 of docker_container to use the API directly).

[pinko-fowle]

Hero-grade work @felixfontein; thank you so very much for taking care of these critical roles.