Allow build-docker.sh to run on aarch64 macOS
Categories
(Webtools :: Searchfox, task)
Tracking
(Not tracked)
People
(Reporter: kats, Assigned: kats)
Details
Attachments
(2 files)
I'm trying to get to "instant fun with the test repo" on my M3 macbook pro and am running into difficulties. Filing this bug to track problems and to have a bug number for patches.
|
Assignee | |
Comment 1•2 years ago
|
||
|
|
Assignee | |
Comment 2•2 years ago
|
||
|
|
Assignee | |
Comment 3•2 years ago
|
||
So now I have build-docker.sh and run-docker.sh working.. sort of. There's a few hiccups which I haven't been able to nail down good workarounds for:
- When running
pip3 install yqwith Cloudflare WARP enabled (this is our VPN replacement) I get an error because WARP doesn't like the cert on files.pythonhosted.org and blocks the connection. I have to disable WARP during build-docker.sh to allow it to get past this - During indexer-provision.sh, the step to install the openjdk hangs the first time it runs, possibly something to do with the certs file as there's an error related to that.
topshows some java process spinning at 100% CPU so I have to kill that and rerun the apt install openjdk command to proceed.
|
||
Comment 4•2 years ago
|
||
I wonder if this is something where addressing our CI needs could help here. taskcluster seems to understand building docker-images. If we get that operational, then maybe one could simply download the latest "-docker" image (if not doing things that change the docker image). That is potentially something the contractor could help with and which would align with higher level organizational goals.
Obviously that doesn't address this specific problem, but potentially helps with onboarding flow in general.
|
|
Assignee | |
Comment 5•2 years ago
|
||
For my purposes I ended up ditching build-docker.sh and run-docker.sh and writing my own docker image-building flow. The existing provisioning scripts have grown quite complex and a lot of that stuff is not needed for my context (at least not yet). Currently I am building minimal indexer and webserver images, but the webserver image just indexer+nginx, so I'll probably collapse it all into one docker image. That would also fit better with the deployment flow that I will need to use. I would be deploying into a managed kubernetes cluster rather than a "raw" AWS account where I control instances and such.
|
|
Assignee | |
Comment 6•2 years ago
|
||
Anyway I'm happy to close this bug for now since I have the basic functionality working on my macOS laptop even though I'm not using build-docker.sh any more.
|
|
||
Comment 7•2 years ago
•
|
||
I think there is an (unfunded/unstaffed, searchfox is cheap so no one cares) desire to move searchfox from AWS to GCP, and according to https://docs.taskcluster.net/docs/manual/deploying#clouds taskcluster is deployed via kubernetes in GCP which suggests it probably would be an option for searchfox so if you have any desire to put kubernetes stuff in-tree (with no real need for review of stuff that can't break the build), I'm on board for that. I'm also of course completely fine with you just getting things working for you and we can revisit things being in-tree at the point that it's more of a maintenance hassle for you for things to not be in-tree.
|
|
Assignee | |
Comment 8•2 years ago
|
||
Ah, good to know. What I ended up doing was creating separate docker images that were more "minimal" than what we have in-tree. My build and deploy process is roughly:
- build an indexer image (if there were changes to the indexer Dockerfile or auxiliary scripts)
- run the indexer in our CI on a
git cloned copy of the codebase. I don't yet have git/blame tarball caching so it just rebuilds the blame every time. This produces an /index folder - Build the web-server image (again as part of the CI pipeline) using the indexer image as the base (since it already contains a lot of stuff needed for rust tools compilation) and add nginx and the index folder
- Deploy the web-server image into our kubernetes environment
This does away with the complexity of having a separate volume for the index, but it does mean the web-server docker image is larger (as it has the index baked into it). It's also trivial to horizontally scale since each pod is independent.
I'm happy to spend some time separating the proprietary bits from the generic bits and contribute the generic bits back if you think that would be useful.
|
|
Assignee | |
Comment 9•2 years ago
|
||
More pertinent to your point, there's nothing in my process that's specific to AWS or GCP, it just produces a standalone docker image that can be deployed wherever. So it would probably be a good starting point for searchfox-in-GCP.
Description
•