-
-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build containers for multiple architectures #93
Conversation
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 |
Thank you so much for doing this. Significantly simplifies our dev workflow for M1 machines. |
Since the slim images are missing a ton of build tools it's easier to use a full image to build and then move the already built files over to the final image.
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. |
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). |
Is there anything we can do to get this merged/deployed? 🙏 |
+1 for deployment. Thanks! |
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. |
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. |
The new organization now has the following multi platform images- They're pretty stable now should anyone want to use them. |
That would close #47 . |
Thanks for the interest! 🍰 Now that Uvicorn supports managing workers with 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 Given that, I'll now close this one, but thanks for the effort! ☕ |
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.