Build containers for multiple architectures

[tedivm]

This switches the build+push to using buildx, which in turn is building for amd64, arm64, and arm v7. This shouldn't change the amd64 containers in any way, but will allow users running on OSX M1 chips or AWS Graviton to use native containers instead of the qemu bridge (which segfaults a lot on the new m1 chips).

Once merged I'll make a PR to the FastAPI containers as well, but that requires these containers already be published.

[tedivm]

You can see how it looks on docker hub here (my local test is still running so tags will keep popping up until it's done)- https://hub.docker.com/repository/docker/tedivm/uvicorn-gunicorn

[mayteio]

Thank you so much for doing this. Significantly simplifies our dev workflow for M1 machines.

[tedivm]

Update: the slim containers are building for all architectures now, using a multistage approach that builds the dependencies in one container (the python full container) and then copies them into the new container.

[tedivm]

All of the images (slim, alpine, etc) are now up in my docker hub account for testing (I don't have anything running to keep them up to date, as they only exist for this PR, so please don't use them in any prod environment).

[vincentsarago]

Is there anything we can do to get this merged/deployed? 🙏

[Matthieu-Tinycoaching]

+1 for deployment. Thanks!

[tedivm]

Okay for anyone interested I have a repo and set of containers up for a straight uvicorn multiarch build.

It does not use gunicorn, making it a better candidate for tossing into nomad/ecs/kubernetes. It does install uvicorn, including building uvloop for the architectures that don't have a wheel. It uses the same prestart script setup, as well as the same envvars and locations for setting your python modules.

I'll get a readme up later today.

[tedivm]

Another update- I kind of went a bit wild, created a new organization with a variety of github actions to make managing containers easier.

As a result I have a new uvicorn container. This container has a much more in depth tagging structure that allows you to select a Python Version, Variant (full, slim, alpine), and now a package version (instead of just having the most recent version). This ends up building 150 containers each run now (like I said, I went wild) each of which supports three architectures (for a total of 450 builds). The github actions make it so when new versions are released the workflow automatically updates, with the repository supporting the last 10 versions of each package. Even the readme files get automatically updated.

I plan on adding a lot more containers now that I've got a framework for building them.

[tedivm]

The new organization now has the following multi platform images-

• uvicorn
• gunicorn
• gunicorn running uvicorn
• oso

They're pretty stable now should anyone want to use them.

[codespearhead]

That would close #47 .

[tiangolo]

Thanks for the interest! 🍰

Now that Uvicorn supports managing workers with --workers, including restarting dead ones, there's no need for Gunicorn. That also means that it's much simpler to build a Docker image from scratch now, I updated the docs to explain it.

Because of that, I deprecated this Docker image: https://github.com/tiangolo/uvicorn-gunicorn-docker#-warning-you-probably-dont-need-this-docker-image

And by using a Python base image and writing the Dockerfile from scratch you will get multi-arch by default. 😎

Given that, I'll now close this one, but thanks for the effort! ☕