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 0.0.0.0:22: 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 aarch64Docker 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 ).
This is a “pure” Docker + network concern, but the documentation on jenkins.io 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.
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).
The image for jenkins/ssh-agent is hosted at Docker Hub
As you already saw, the alpine tag for this image does not provide anything else than a JDK8 on x86_64 CPU
Rejoice! There is an arm64 declination available, though: latest (which is also latest-jdk11 ) as per Docker Hub
=> 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” - https://adoptium.net/) 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 (the build farm is able to build on arm64 linux)
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.
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.
PR done, let’s hope I’ll make myself understood.
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?