-
Notifications
You must be signed in to change notification settings - Fork 795
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
Publish ARM64 Docker images #2119
Comments
This issue has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/ztjh-on-a-raspberry-pi-k8s-cluster/3043/18 |
https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ might make things easier.
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 943,
"digest": "sha256:c65d2b75a62135c95e2c595822af9b6f6cf0f32c11bcd4a38368d7b7c36b66f5",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 943,
"digest": "sha256:c451115c859850cde443827e764ae243ab630384ed5a93370b5086ba6616a152",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 943,
"digest": "sha256:f2141ef6a772e349f9ff08397c2a26da11074512b1f2fe6e77f7e9b2d6561a32",
"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 943,
"digest": "sha256:601aeafd9c6f28f43c0fd3f1c670de07d157ed7bd5f968e878ceed73b5c321be",
"platform": {
"architecture": "ppc64le",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 943,
"digest": "sha256:89b7353d42e788609fc51e31863af42edf6f30e1b1d655b79e72ade8c18f7385",
"platform": {
"architecture": "s390x",
"os": "linux"
}
}
]
} So we shouldn't need to mess with build-args. If we're only publishing the images but not testing them the changes to the GitHub workflow should also be minimal. |
I've tried The big difference from @consideRatio any thoughts on how we can best achieve this? I think adding the option of using |
@manics wow I love how thorough research you do ❤️ 🎉!
Thank you for your thorough work to investigate this, it was a old wish I had when I got myself a RPi but ended up not pushing through to make it happen. |
I'm glad you're keen 😄 . Here's a 3 part plan that should avoid making too many large changes in one PR:
|
So I was talking about the TLJH on ARM work on twitter, and have been offered AWS credits for CI/CD with ARM. As an ecosystem, I think the important bits are:
Getting CI for these things would be great. At least personally, I want it for TLJH so I'll work on that with GitHub self-hosted runners. |
AWS EC2 t4g instances are free to everyone until end of June (750 hours/month): https://aws.amazon.com/ec2/instance-types/t4/ The reason I suggested the 3 stage approach for Z2JH is to avoid massively refactoring the CI at the same time other changes are made. |
@yuvipanda See jupyter/docker-stacks#1019 (comment) for some progress on docker-stacks |
I say very thank you that maintainer start to consider supporting arm64/aarch64 architecture.
Sorry the docker-stacks GH Action in this comment is now experimental so need some fixes. You'd understand if you saw it, this action uses run-on-arch-action. As @manics says, it's more better way is fix chartpress and use GH official |
We are getting closer but havn't reached the goal fully yet. The CI pipeline to publish failed when updating the singleuser-image just recently.
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/runs/2331388629?check_suite_focus=true I think we are missing the following in the publish workflow. - name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1 I've opened #2144 to address this. |
I went through all images we make use of in the Helm chart, and I checked those compatible with arm64
|
Other than the
|
Closing, follow-up issues created. |
Proposed change
As described in https://discourse.jupyter.org/t/ztjh-on-a-raspberry-pi-k8s-cluster/3043/16 and sakuraiyuta@d22290b by @sakuraiyuta it's possible to run Z2JH on ARM systems with some changes. I think we should look at supporting ARM64 in Z2JH.
Work on ARM64 started in TLJH (issue: jupyterhub/the-littlest-jupyterhub#62, WIP PR from @yuvipanda jupyterhub/the-littlest-jupyterhub#674).
Alternative options
Do nothing.
Who would use this feature?
AWS EC2 ARM64 users.
Raspberry pi users.
Suggest a solution
This will require work on the Docker images and the GitHub workflows. Based on sakuraiyuta@d22290b I think we could make the following changes:
Docker images
For example, replace
FROM ubuntu:20.04
withFROM $ARCH/ubuntu:20.04
, see https://github.com/docker-library/official-images#architectures-other-than-amd64chartpress --build-arg ARCH={amd64|arm64v8}
mirroring Docker's--build-arg
jupyter/base-notebook
doesn't support other architectures.e.g. we could build our own image from
$ARCH/python
, or perhaps ignore it since it's just an example.Publish workflow
Option 1: Keep the existing build workflow, add a new workflow for building and publishing arm64v8 Docker images only (
chartpress --push
but not--publish
) since the standard amd64 workflow will publish the chart.Option 2: Split the build/push image and publish chart steps into separate jobs: an amd64 build image job, an arm64v8 build image job, and a chart publish job that only runs if both the amd64 and arm64v8 jobs succeed. This means the chart will only be published if Docker builds succeed for all supported architectures.
Test workflow
K3S supports ARM64 so we could duplicate the current test workflow for ARM64 if we wanted to.
However since all ARM64 steps have to be run in a single action this requires either maintaining two separate test workflows, or refactoring the existing one to move most steps into a script.
Alternatively we could keep things simple, ignore the tests to begin with, and just publish the images.
The text was updated successfully, but these errors were encountered: