[ZEPPELIN-6068] Support ARM64 (multi-arch) Docker images

[HwangRock]

What is this PR for?

Adds ARM64 (multi-arch) support for the Zeppelin Docker images so they can run natively on arm64 hosts such as Apple Silicon.

The Dockerfiles previously hardcoded x86 (amd64) specific values, so an arm64 build failed:

• JAVA_HOME was pinned to java-11-openjdk-amd64
• Miniconda was downloaded as the x86_64 installer
• micromamba was pulled from the linux-64 channel

Each of these is now selected from the TARGETARCH build argument (injected automatically by docker buildx), so the same Dockerfile builds for both linux/amd64 and linux/arm64.

While fixing the interpreter image I also found the micromamba source (micromamba.snakepit.net) is dead and currently breaks the amd64 build too; it is replaced with the current endpoint (micro.mamba.pm). The all-in-one image's conda environment creation is changed from mamba env update --prune to mamba env create, which is required for mamba 2.x (the former is rejected when the environment does not exist yet).

A manually-triggered docker-publish GitHub Actions workflow is added to build and push the multi-arch apache/zeppelin image to Docker Hub. Docker Hub credentials are referenced from repository secrets (DOCKERHUB_USER / DOCKERHUB_TOKEN); the login step is skipped on a dry run.

What type of PR is it?

Improvement

What is the Jira issue?

ZEPPELIN-6068

How should this be tested?

Built the all-in-one image locally for linux/arm64 via QEMU buildx against the released 0.12.0 artifact; the build ran end to end and produced a linux/arm64 image. (Published versions are built by the new workflow.)

Local arm64 build log (QEMU, Z_VERSION=0.12.0)

$ docker buildx build --platform linux/arm64 --build-arg Z_VERSION=0.12.0 \
    -t zeppelin-arm64-test:0.12.0 --load scripts/docker/zeppelin/bin

#8 [ 4/10] RUN ... conda install mamba ... && mamba env create -f /env_python_3.yml
#8   Prefix: /opt/conda/envs/python_3   (python=3.7, numpy=1.19.5, ... resolved as linux-aarch64)
#8 DONE
#9 [ 5/10] RUN ... Download Zeppelin binary (zeppelin-0.12.0-bin-all.tgz) ... DONE
#14 [10/10] WORKDIR /opt/zeppelin  DONE
#15 exporting to image
#15 naming to docker.io/library/zeppelin-arm64-test:0.12.0
#15 DONE 275.4s

$ docker image inspect zeppelin-arm64-test:0.12.0 --format '{{.Os}}/{{.Architecture}}'
linux/arm64

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? Yes, docs/setup/deployment/docker.md is updated.

[jongyoul]

@HwangRock Hello, as you talked with another channel, can we try to build a nightly-version of Apache Zeppelin everyday if there's any new commit in the master branch? It uses the release version to build a docker image, but we'd better build by actions with the latest master. It could be triggered daily basis and manually. WDYT? I got a confirmation from INFRA team being set by the proper secrets.

[HwangRock]

@jongyoul Sure, I'll add nightly in this PR. Glad to start here!

One thing before I jump in. The all-in-one apache/zeppelin image builds from the release tgz,
so a master-based nightly needs a different build path.

I see two ways to go. One is building apache/zeppelin-server and apache/zeppelin-interpreter for nightly, since those already build FROM the distribution image and work with the latest master as-is. If we go this way, could you check whether push access and tokens are set for those two repos?
The other is the all-in-one apache/zeppelin:nightly, which is the most familiar for users, but I'd need to rework the all-in-one Dockerfile for a master build.

Also, since nightly runs a full build with Spark and Hadoop every day, doing arm64 through QEMU daily would be pretty heavy on the shared runners.
I was thinking nightly could be amd64 only, with arm64 still covered by the release image. Does that work for you?