Starting an agent with Docker on a freshly installed aarch64 machine

Hi there :wave:

After having successfully installed my first Jenkins controller on WSL2/Docker, I went ahead and tried to install an agent (following this documentation).

The first issue I’m facing with this command docker run -d --rm --name=agent1 -p 22:22 \ -e "JENKINS_AGENT_SSH_PUBKEY=[your-public-key]" \ jenkins/ssh-agent:alpine is that there seems to be a conflict on the 22 port. I already have a SSH process listening on the 22 port.
The error I get is docker: Error response from daemon: driver failed programming external connectivity on endpoint agent1 (855d9566fa3f5704f28d68bafc9a7d475488f854bc93dae75f0828237bfbb961): Error starting userland proxy: listen tcp4 bind: address already in use.
Can I change the mapping of the port? Is there anything else to do to address that?

The second issue I’m facing is that the command I used did not download the right image for my machine.
I don’t own/use many x86_64 machines. I’m an arm fanboy, so I mostly use/own armv7 and aarch64 machines. I thought the Docker image would be multiarch, but this one isn’t (others are).
I regularly build armv7 and aarch64 Docker images, so let me know if I can help adding aarch64 arch for this image (or even armv7 if that makes sense and if this is technically possible).

In the meantime, I will try another tag (aarch64 compatible) image, and see if that changes my port issue (I highly doubt it :blush:).




About your first question:

This is a “pure” Docker + network concern, but the documentation on could totally be improved to help.
You might want to publish to a different port of the WSL netork stack, while keeping the 22 port on the private network. The following snippet publish the “private 22 port of the container” to “the port 4444 of each interface available to your Docker Engine”

docker run <...> -p 4444:22 <...> 

Then you’ll have to adapt the instructions when creating the “permanent agent” (Using Jenkins agents) in Jenkins UI, to specify the port 4444 by clicking on the “Advanced” button (and also to specify the correct IP address which depends on how are you running Jenkins).

Do not hesitate to draw a network diagram to help you.

1 Like

About your 2nd question,

As I did not remember exactly which CPU arch is supported by which tag, I had to check the source (it’s not user friendly, and I believed we -the community- could update the image README for that + the tutoriel eventually).

  1. The image for jenkins/ssh-agent is hosted at Docker Hub

  2. As you already saw, the alpine tag for this image does not provide anything else than a JDK8 on x86_64 CPU :frowning:

  3. Rejoice! There is an arm64 declination available, though: latest (which is also latest-jdk11 ) as per Docker Hub

  4. You can find the exact descriptor of “which image, which tags on which arch” on the following source file: docker-ssh-agent/docker-bake.hcl at facdc2b4c4829869d6ddc4978fc93c8d6d437dca · jenkinsci/docker-ssh-agent · GitHub

=> The reason is that the Temurin JDK project (the JDK distribution that we use, which is the OpenJDK-> AdoptOpenJDK project moved to Eclipse fundation under the name “Adoptium” - did not provide Alpine ARM images when we built this.
Since this was months (e.g. an eternity) ago, this might have changed: if you are interested into helping us, do not hesitate to propose a pull requst to the bake file to add the new declinations :slight_smile: (the build farm is able to build on arm64 linux)

1 Like

Thank you Damien, I thought Jenkins would use the SSH server of the machine, not its own within the Docker container.
I got it now.
I still have problems with linking my Jenkins instance with my first runner via SSH, but I’m sure I will sort it out pretty soon.

@dduportal I rebuilt locally and published the bullseye image for JDK8, JDK11, JDK17 for arm32 and aarch64.
The builds went really fine, and getting an arm32 agent would be really cool (to me at least).
If anyone (besides me) want to give them a try, don’t hesitate.

I know bullseye is kind of bulky for a standard armv7 machine, but the alpine images for Temurin are not available yet. There are already issues about aarch64 and armv7 on the repo. I will try to find the source Dockerfile and build them by myself.

Is Jenkins building on AWS Graviton2? It is possible to build arm32 binaries with the Graviton2.


So far we are using standard AMD64 images with the help of QEMU as Docker buildx allows us to parallelize all these builds quite handily (the performance penalty is negligeable):

However the CI used for Jenkins (and the CD which is private for security reasons of course :slight_smile: ) supports ARM64 instances as per documentation/ci.adoc at 8f5c4ca57d5b44fdb98325612e81447248aa6460 · jenkins-infra/documentation · GitHub but it requires to revamp the Jenkins pipeline to build specific CPU arch on nodes with different labels: it’s easy but we never had the need so we keep using the qemu.

1 Like

Thanks a lot for playing around ith this! Can I ask you to open a pull request to add the new platforms in the docker buildx bake file linked above? The PR ci build should give us an idea how it would be handled with the actual build system.

1 Like

PR done, let’s hope I’ll make myself understood. :blush:
I have not added the arm32 yet, would you like me to do so?
By the way, how should the arm32 be referenced within the docker-bake.hcl ?
armhf, arm32, armv7l?

I haven’t been able to make another PR yet. Time will come. :wink:
In the meantime, I have my first aarch64 agent running.

Thanks for your help.