Since Tutor is fully available to run on Kubernetes it could be a great idea to allow multiarchitecture mode, MySQL and Mongo already has ARM variant in Dockerhub.
There are some instructions we can add to the Tutor build steps to make sure all the images are built for multiple architectures, this way Tutor can be used on these platforms (including Mac M1) as smoothly as possible (Given that you’re using Docker Desktop/minikube with VM).
The following article explains further how to build it all on a single machine:
I would love to try and help, I’m just not familiar with the codebase.
I think that the official BuildKit approach is way easier and I don’t have to rebuild all the containers on my machine.
Regarding MySQL: 8.0 is officially supported, Helm chart or specific tutor configuration can probably solve that.
I’ve attached the guide, using buildkit is just a small addition to the process and it will produce several architectures as needed, you don’t need extra hardware for that, just extra settings to the same CI.
I meant that using a Helm chart for Kubernetes that knows this limitation.
I’ll try to see if I can produce a MySQL arm64 Docker image on GitHub Docker because MySQL 5.7 is available as arm64 deb file and we’ll be able to use it, if it’ll work and you would like me to transfer the repository to you I’m OK with that.
BTW I wasn’t aware that you were talking about openedX and not MySQL but once I’m done with MySQL (I managed to cross compile it with deb files downloaded from Launchpad manually since the files were compiled in Launchpad but I couldn’t find them in the Ubuntu repository for arm64).
I found some file that looks like the file you were trying to build with Docker but it has many Jinja templates in it, what am I supposed to do with it? Is there any file ready for building?
Thanks!
EDIT: This is the arm image implementation based on the original file with some modifications, it won’t cross compile as I had to download the deb files for arm manually:
@regis Like me or hate me but your changes work and after several hours of building on my 2015 MacBook Pro (Intel Core i7 2.2 GHz) it was finally built, I’m guessing it has something to do with that pyenv 2.2.2 that you’ve mentioned in the post.
I want to repeat this process for several other architectures but it’s going to be a very long time before I can show results.
In the meanwhile I’m thinking about provisioning GitHub actions to try and reproduce it to take the load off of your personal PC or wherever you are building from.
This is my repo with GitHub Actions running for several hours (72 hours is the maximum), It should build a Docker image and push it to ghcr, I can modify it to fit your favorite registry:
Sadly there’s no spoiler tag but these are the results, the total time 24407 seconds (6 hours and 46 minutes approximately):
Great news (Sorry but I can’t edit after 24hrs), I have a working GitHub Actions pipeline that creates and pushes the images to ghcr.io.
This is the resulting Docker image:
This is the working pipeline that created this:
So we now have 2 architectures supported, I tried adding some others but the Python compilation is a bit too much for this pipeline.
I can try working on the MySQL a bit further to provide the arm64 support like promised but it’s very hacky and there’s a lot to remove before it’s ready for production use.
Hey @yaron, thanks for your investigation, and sorry about the delay in replying. I need to work on a couple of other things first, but this will be the next big item on my tutor-TODO list. I will need to figure out why buildx succeeds on GitHub actions but not on my laptop.
@regis is there any way I can help? Can we have an online session to try and figure that out?
I think that we’re also missing mongo3 on ARM, if that’s the case I’ll start working on it, having an ARM version as docker images is mostly required for Kubernetes and Mac M1 AFAICT.
Correct me if I’m wrong but open edX uses mongo 3, starting mongo 4 there was a builtin arm64 support for both Dockers and binaries, it’s not the case for mongo 3, I wish you know something I don’t about this because although it’s a relatively easy migration I don’t want to create something that already exists.
OK I have made some progress on this item. The good news is that I managed to cross-build the “openedx” image with buildx. What I was missing was a proper installation of binfmt typically a case of rtfm…
The bad news is that cross-platform compilation takes a very long time. And this is not just on my computer. The GitHub action built by @yaron (thanks again!) takes 3 hours to complete the build. This means that cross-platform building should not be part of our continuous integration (CI) workflow but only of continuous deployment (CD). Also, the build should be made in a asynchronous manner such that the linux build is not blocked by the arm64 build.
This is mostly a brain dump at this point. We are still actively working to find what’s the best solution to facilitate the integration with Mac M1 users.
LOL, glad you fixed the binfmt using the good old rtfm method
Well, what I was thinking is allowing cross platform as part of tutor but building on the respective platform by default (So if you have M1 it’ll succesfully built for you with the respective parameters automatically), this way there’s not reason for me to build for an architecture I can’t use but I can do it if I have my own repository and I want to be able to push to it (ECR and an internal CI/CD process for example).
Keeping the CD option (So that the CI build server will build for both architectures and push to the docker registry) is pretty convenient because I can simply pull the tag and docker will know exactly which container to pull so I won’t have to build it myself if I don’t want to.
It looks like there’s a way to build simultanously on 2 different nodes (one for each platform) using a dedicated buildkit configuration:
BTW are you using GitHub Actions? Do you want me to try running those separated?
FYI @yaron the matter of getting Open edX to run on arm64 is getting a lot of traction by 2U, as they are keen to migrate their developers to Tutor. The matter is discussed here: Ensure Tutor works out-of-the-box on ARM64 · Issue #35 · overhangio/2u-tutor-adoption · GitHub
tl;dr: in the near future it is very likely that I will migrate my CI to a multi-platform build-cluster which will build multi-platform images for all plugins.
Well, apparently there are numerous issues and it’s not running out of the box but I finally have a working tutor on arm64.
The issues I ran into are the ones I’ve opened on GitHub here and here.
After fixing dockerize and the permissions docker it loads perfectly and since it’s not my budget I’ve had to turn this machine off but we will continue and use this machine and insights for documentation and bug fixing purposes as much as needed until we will have an out of the box working version.
Another thing worth mentioning is that the minimum instance type for tutor on AWS is c6g.large (2 vCPUs and 4 GB of RAM) and it’s better to configure some swap space otherwise every memory load spike causes the machine to hang for a couple of minutes, I restarted several times until I figured that out.
BTW are you sure about the permissions management with a distinct docker? It looks a bit overkill, maybe managing the permissions with tutor inside python internally has a better potential because if the permissions docker fail everything fails and we don’t even know why because we’re assuming that the permissions are correct without tutor knowing what’s actually going on.