[ENHANCEMENTS] Support ARM64 in Docker

[rekonnected]

Is your feature request related to a problem? Please describe.
Currently, the specified Docker image (passivelemon/zoraxy-docker) does not support arm64, meaning it cannot run in a Docker container on a Raspberry Pi or an Oracle ARM VM for example.

Describe the solution you'd like
The Docker image uploaded to DockerHub should support arm64.

Describe alternatives you've considered
https://github.com/cyb3rdoc/zoraxy-docker is an alternative image that currently supports arm64, however it is out of date and seemingly unmaintained.

Additional context
N/A

Not sure what it would take to adapt the existing x64 image to support arm64 as well, but in most cases I've seen lately if the application and its dependencies support arm64 natively, it should be a relatively simple build command change. I've done this to a couple containers for the AMP server management panel, see MitchTalmadge/AMP-dockerized#140 and imagegenius/docker-amp#8 for what that entailed. I am happy to try and assist if desired.

[tobychui]

Hi @rekonnected, have you check out the offical docker file over here?
https://github.com/tobychui/zoraxy/tree/main/docker

PassiveLemon is one of our project maintainer now. If you have interest in contributing an ARM64 supported docker, feel free to PR here :)

[PassiveLemon]

Going to be honest, I don't know how to publish ARM containers. I'll look into that.

Upon some research, it shouldn't be very difficult. I'll try to work on that.

[PassiveLemon]

@rekonnected So you have experience with the --platform=linux/amd64,linux/arm64 flag? I'm currently trying to use this with buildx and using that will not put the created image into my store to push it. I set the --load flag which should allow me to push it from the store but it will then complain ERROR: docker exporter does not currently support exporting manifest lists. This should be fixed by using the Containerd store but I can't seem to get this working on NixOS.

Maybe you know an alternative solution that doesn't involve me using some cloud service to build them?

[PassiveLemon]

Actually, I believe I got it. @rekonnected Could you test the ARM64 2.0.0 image? It's currently on Dockerhub

[rekonnected]

Actually, I believe I got it. @rekonnected Could you test the ARM64 2.0.0 image? It's currently on Dockerhub

exec /zoraxy/entrypoint.sh: exec format error

Sadly seems like it's still trying to run an x64 app under ARM, based on this error...

[PassiveLemon]

That's weird for it to affect the entrypoint script...

Upon further review, it doesn't seem like its actually building it as arm64, just uploading it to Dockerhub as arm64.

[PassiveLemon]

I've been struggling with this for the past couple days. I believe the issue was provenance or whatever. Setting it to false appears to actually build the manifest for the container. Before, I don't think it was because I wasn't able to inspect the image manifest which was causing issues when trying to run the arm64 image.

@rekonnected Could you try the 2.1.0-Test image?
Now right now I can't get the container to run with the --platform linux/arm64 flag as it returns: exec /zoraxy/entrypoint.sh: exec format error but it could just be my system.

[rekonnected]

It runs, with this output then stops:

/zoraxy/notifier.sh: line 15: [: : integer expression expected

/zoraxy/notifier.sh: line 18: [: : integer expression expected

/zoraxy/notifier.sh: line 21: [: : integer expression expected

|| is not a valid version. Please ensure it is set correctly. ||

You'll get exec format error any time the architecture doesn't match and you aren't running something like QEMU to compensate. Your system is probably amd64 so arm64 will generate an exec format error, and vice versa.

[PassiveLemon]

Do you have the variable VERSION set to anything? Is it defined at all?

[tobychui]

@PassiveLemon the exec format error is most likely that, in your script, you tried to call a amd64 binary on arm64 platforms. I am not sure about docker, but I guess it might be either

1. You downloaded the invalid architecture / amd64 binary on arm64 docker env
2. If you are using go compiler, you downloaded the wrong architecture of such compiler
3. My release automation script is wrongly written and compiled other architecture but named it as arm64

If you figure out the reasons and it is 3, please poke me and let me know, thank!

[PassiveLemon]

1. The Docker buildx command should allow me to build on both an amd64 and arm64 (QEMU system assuming its setup properly. I use the official Github Docker action workflow for this so I believe this is functional, especially after my recent discovery.

2. The go compiler is part of one of the image layers and that should also have the correct architecture fetched because of the Docker buildx environment.

3. Based on what rekonnected just sent, it doesn't even get to build Zoraxy because of earlier issues in the entrypoint.

There are some errors in the notifier script but that's not too important, I'll try to fix that later. What the || is not a valid version... line means is that the script did not find a release that contained the version, either manually set by the user, or fetched by "latest" tag. What it looks like is that the VERSION variable was either accidentally set as a blank or was improperly fetched. I have a check for a GitHub API rate limit in place but it can't really work flawlessly because the check itself might be the one that triggers the limit, which then causes the other uses of the API to fail.

[rekonnected]

I did not have the version variable set, but even after setting it to 2.1.0, 2.1.0-Test, or 2.0.0 gives an error similar to this:

|| 2.0.0 is not a valid version. Please ensure it is set correctly. ||

[rekonnected]

It was my unique configuration causing a problem, I forgot to give the container DNS. Once i hooked it into my very stupid dnsnet, it cloned right away with VERSION=2.6.5. Testing more thoroughly now that it's up.

(long story short: don't use dns as a container on the same host as every other container, it becomes a mess fast)

Now that I think about it, this highlights an unhandled exception in the version checker. It doesn't currently verify if there is internet at all before checking version, and since the version check fails, it says it's invalid. A connectivity check would probably prevent that in the future.

[rekonnected]

Well, found a hard crash fast. (domain and IP changed)

This happened after I added one subdomain and tried to add another.

2023/07/28 04:43:33 Adding Subdomain Rule:  sub.domain.xyz to 10.0.0.1:80
panic: net/http: internal error: connCount underflow
goroutine 406 [running]:
net/http.(*Transport).decConnsPerHost(0x2bc2c20, {{0x0, 0x0}, {0x40212b28a0, 0x5}, {0x403e255f08, 0x12}, 0x0})
	/usr/local/go/src/net/http/transport.go:1493 +0x3d4
net/http.(*Transport).dialConnFor(0x401c3f72f0?, 0x4021b362c0)
	/usr/local/go/src/net/http/transport.go:1476 +0x114
created by net/http.(*Transport).queueForDial in goroutine 31
	/usr/local/go/src/net/http/transport.go:1436 +0x380

[PassiveLemon]

I did not have the version variable set, but even after setting it to 2.1.0, 2.1.0-Test, or 2.0.0 gives an error similar to this:

|| 2.0.0 is not a valid version. Please ensure it is set correctly. ||

Hmm maybe I need to make the README a little more clear. The VERSION variable is for the version of Zoraxy that you want to download so that's why the ones you tried did not work. The container and Zoraxy are updated separately (personal preference) so there are 2 versions to worry about. The one you want is just the tag name of the release in the Zoraxy GitHub.

I could definitely add some kind of network check to the container. Should be pretty easy.

That last problems looks like a problem for @tobychui

[tobychui]

Hi @PassiveLemon, thanks for poking me.
For @rekonnected issue,
Yes, this is another bug that I think it is related to concurrent accessing the http transport in your subdomain setup. Please open a new issue and describe in details how to reproduce it and provide the necessary settings you used in the proxy rule(s) so we can further investigate what might be the issue.

[rekonnected]

Understood, thank you both for all your efforts! I'll close this since it looks like the app itself is running okay on ARM now, of course feel free to reopen if needed.