multi-architecture implementation

[AbcSxyZ]

fix #17.

Beginning of an implementation for multi-architecture support using buildx. Remove security check, to rely on #6.

I'm able to build images for those for architecture : amd64, arm64, armv7 & i386.
Here for Docker hub example.

It may be possible to use dpkg or TARGETPLATFORM to find architectures. It seems to me that TARGETPLATFORM is easier to use with buildx, but won't work if used directly with docker build.
dpkg would need few more operations (install of dpkg-dev, set manually variables before a dirtier mapping), but would work with docker build. Docker official images are using dpkg.

This version is cleaner for pushing to Docker Hub, but may be interesting to let the user use the image manually using dpkg. Any opinion ?

It's using Github Action with configuration defined in #15 to publish image on Docker Hub

[patricklodder]

Noted some things I noticed when testing this inline.

[patricklodder]

Step 12/17 : COPY --chmod=500 docker-entrypoint.py /usr/local/bin/docker-entrypoint
the --chmod option requires BuildKit. Refer to https://docs.docker.com/go/buildkit/ to learn how to build images with BuildKit enabled

Are we sure we want that dependency?

[AbcSxyZ]

I didn't know chmod was specific to buildx. Depend on the previous question about buildx vs dpkg.

[patricklodder]

It requires buildkit, which is not enabled by default everywhere. I think we can use RUN chmod 500 too?

[AbcSxyZ]

Sure. I would just recommend to use chmod within COPY if the image is only deployed/buildable with buildx. Otherwise, in RUN statement of course.

[patricklodder]

Why do you recommend it? Reduction of build steps or is there more to it?

[AbcSxyZ]

Reduction of build steps

Yes

[patricklodder]

Okay. Could you please change that then? Let's keep the extra build step until buildkit is the default build process everywhere (currently it's only default on docker-desktop.)

[AbcSxyZ]

Rn, because we are using TARGETPLATFORM, someone who will build this Dockerfile will need buildx.

In any case not a big change, but don't you want to do this edit when/if we're having a solution to enable docker build command ?

If we want to go with docker build, I suppose we should use dpkg. I think it's a matter of choice between having a more concise Dockerfile using buildx solution, where people will use this image in their own Dockerfile or with the cli and won't build it manually. Or we can get something more verbose, possibly a dirtier mapping, but easily buildable with dpkg.

I like this idea of using docker build, the solution may be not that bad, but it's the "simpler" path here.
Let's continue in #17.

[patricklodder]

I can do docker build --build-arg TARGETPLATFORM=linux/amd64 . right now to build this but it will fail on this instruction if one doesn't use buildkit by default.

The reason why I am asking to make the separate RUN chmod 500 /usr/local/bin/docker-entrypoint for the time being is to retain some form of backward compatibility for now, until buildkit is the only supported method. Since this does not affect the outcome - it only costs a trivial build step - this de-optimization helps portability until a later time that the build system is based on buildkit everywhere...

I have no way to build this without buildkit for this issue, whereas for the first issue I mentioned there is a workaround.

[AbcSxyZ]

Let's supersede this design with work from #17 :)

[AbcSxyZ]

Add implementation from issue #17 for cross architecture using dpkg --print-architecture instead of TARGETPLATFORM prepopulated variable.

[patricklodder]

ACK.

Note: This (dpkg) works for all debian-based distros, so we should have no issues for now.