Add Dockerfiles for arm32 & arm64 docker hub images. #10
Conversation
There was a problem hiding this comment.
I just realized that .aarch64 and .tmpl can look exactly the same. The only difference would be to edit line 3 in the Dockerfile.aarch64/Dockerfile.aarch32 to read:
"ARG VERSION=v1.3.0"
This would avoid the hard coding in lines 9 and 22
in Dockerfile.tmpl we'd leave VERSION without a default value.
|
Another thing I've realized. There is an alpine 32-bit image. It is under arm32v6, and not arm32v7. I will update the commit with this soon. |
|
Sorry about that guys, I got a bit confused as to the work flow. Not sure if it was required for me to revert the first few commits. Anyway, the latest commit is what should be review. :) As you can see, both 32-bit and 64-bit images are now alpine based. Only two questions on this:
Anyway, would like to see what others think. |
|
As a side note you use arm32v6/alpine but most of todays ARM32 SBC are armv7 (armhf) not v6 (except the older RPi). so you should provide arm32v7 arm64v8, IMHO arm32v6 may not be interesting. |
|
Right, I would gladly use an arm32v7 image, but the problem is, there is no alpine base for arm32v7. Only for arm32v6. Perhaps one doesn't exist for v7 because there wouldn't be anything different/special about the image? I'm not sure. |
|
Sorry I should have been clearer in my post, I know that it's not available for arm32v7 (and I've created an issue today to find out why). In theory code compiled for arm32v7 should be faster that arm32v6 on Cortex-A7 but that's just theory ;) |
|
I got an answer today and you can use the arm32v6 image so your pull request is fine ;), in fact Alpine armhf architecture is armv6 and not armv7. I hope you'll get reviewed soon ;) |
|
@jsrz thanks for this PR :)
We would obviously have preferred to do this, but as we use a |
|
Ok, I see you want to keep consistent with the FROM scratch version. |
…32 traefik images" This reverts commit 706366e.
This reverts commit c9ad488.
…-library-image into dev/add_arm_support
Added update script inside the arm directory for updating the aarch dockerfiles Added a call to the arm update script from the top level update.sh. NOTE: Top level update.sh will not complete on a non-x86 machine. The cert update script runs an x86 Docker image to update the certs.
|
Alright, made more updates.
One caveat about the above though. The top level update.sh file calls certs/update.sh. This shell script will spin up a container to update the certs. This container is based on an x86 alpine image. The consequence of this, is that the top level update.sh script will only run properly on an x86 machine (as it always has). If you run this top level script from an ARM machine, it will fail to run the certs update container (exec format error). Overall, I think this is acceptable. I don't see a point in putting energy to get the top level script to also work on ARM. This ARM situation will only be temporary. All of this can get taken care of cleanly once docker merges the manifests lists features/commands. |
|
As a side note, I think it would be easier to directly run Maybe I'm missing something (certainly) but that would simplify the process. |
|
@seblucas not possible in the |
|
With the new multi-stage build feature in Docker, it can be possible to do this on the scratch image as well. The first stage can run alpine to pull the certs in, then the second image will be from scratch, and you just copy the certs in from the alpine stage. The same approach can be used to eliminate the need to store a binary in the repo. The only issue is this would lock down the update.sh script to docker 17.05 or later. |
This PR is addressing issue #1665 (traefik/traefik#1665). A request to have Docker hub images for ARM32 (aarch32) and ARM64 (aarch64).
I don't think the initial patch should be merged, just want to get some discussion going on the best way to do this.
A few things that should be figured out before merging:
The original issue called for 32-bit and 64-bit images. The 64-bit image is based off of alpine just like the x86 image. The 32-bit image is based off of Ubuntu because there is no official 32-bit alpine image. The first question is, is this ok? Would we rather do something different?
Currently, I'm using wget to pull the particular release of traefik. The template adds a build argument so that you can use the template to pull whatever version you want. (the --build-arg switch). I like this way of doing it better to avoid binaries in the repo. I'd like to hear thoughts on this approach as well.
An alternative is to make these distroless images (FROM scratch). However, that would require pushing binaries into the repo so that we can use the COPY command to get them into the container. I'm not a fan of pushing binaries into the repo, but it looks like that's how it's done for the x86 docker hub image. If we want to do that, we can do it too.
If you notice, there are copies of entrypoint.sh where each of the Dockerfile.aarchxx reside. We could avoid these by running docker build from say the alpine directory (for the aarch64 image). Since the build context would start from there, you could reference a parent directory from the docker file. Something like "COPY ../entrypoint.sh...." Instead of "COPY entrypoint.sh..." This way a single entrypoint.sh file can be used. Not sure what we'd do about the Ubuntu directory. I guess moving entrypoint.sh up to the top level and always building from the top level would work. I guess that could potentially make the copying of the build context take a while though.
Although not addressed by this PR, I would argue that you should consider not having a traefik binary in the repo for the original x86 image. Doing a wget of the release from the Dockerfile should work just fine. That's what I did with the ARM images. Not sure what the thoughts are on this.