but on github GitHub - jenkinsci/blueocean-plugin: Blue Ocean is a reboot of the Jenkins CI/CD User Experience it is maintained since two months ago
The Blue Ocean plugin is different than the obsolete jenkinsci/blueocean container image. The obsolete container image provides enough files to run a Jenkins controller as a container. A plugin is a single file that must be loaded into a Jenkins controller in order to run.
Switch to a container image that is not obsolete.
1 Like
thank you sir , is there any recent release of jenkinsci on docker hub
You asked:
I had previously said:
âActively maintainedâ means that new container image tags are pushed to Dockerhub each time there is a release of Jenkins core. The Dockerhub tags for the jenkins/jenkins container image include tags published less than a month ago for Jenkins 2.452.1 (LTS) and tags published last week for Jenkins 2.460 (weekly).
A new LTS will be released Wednesday 12 Jun 2024. A new weekly will be released Tuesday 2 Jun 2024 and Tuesday 11 Jun 2024. New Dockerhub tags to match those releases will created shortly after the release becomes available.
1 Like
but jenkins/jenkins need a lot of additions to work well on CD/CI , ex : you need to mount docker binary when launching container -v /var/run/docker.sock:/var/run/docker.sock and the more you use container to build image as the container become very slow , and there is no caching when rebuilding an image, âŚetc
Mounting the Docker socket into the controller image is a mistake for two reasons.
- Running Jenkins jobs on the controller is a mistake. Use agents to run Jenkins jobs. The controller isolation section in the âSecuring Jenkinsâ chapter of the documentation describes the security risks of running jobs on the controller
- Mounting the Docker socket in the container image is a mistake. A stackoverflow article describes the security risks of mounting the Docker socket in a container
When I build images, the layers that do not change are cached. I donât know what configuration you use to build container images, but if the layers are not cached in your configuration, then you need to fix that configuration. Layer caching is a standard part of the docker build process.
1 Like
Hi sir , I use the following to launch jenkins/jenkins :
jenkins:
container_name: jenkins
environment:
- JAVA_OPTS=-Dhudson.model.DirectoryBrowserSupport.CSP="sandbox allow-scripts; script-src 'unsafe-inline'; style-src 'unsafe-inline';"
- PLUGINS_FORCE_UPGRADE=true
image: jenkins/jenkins
ports:
- "8080:8080"
restart: unless-stopped
volumes:
- /var/jenkins_home:/var/jenkins_home:rw # Workspace home
- /var/run/docker.sock:/var/run/docker.sock:ro # Allows Jenkins to stop/start containers
- /usr/bin/docker:/usr/bin/docker
What are you trying to achieve exactly?
I want to use jenkins container for CI/CD
when I use /usr/bin/docker:/usr/bin/docker to accessing docker binary , jenkins become very heavy.
and there is another problem that is no caching when rebuild image
as long as we shoud not use /var/run/docker.sock:/var/run/docker.sock ,
how do we access docker binary
Mounting the docker socket inside the controller image is a mistake. See my earlier answer
If you really must run Docker from the Jenkins controller, even with the knowledge that it is a mistake, then refer to the Docker installation instructions for Jenkins. Those instructions (for the moment) describe how to configure Docker in Docker for a Jenkins controller.
We plan to replace those instructions soon, because they are a poor choice for Jenkins users. They are complicated, prone to failure, and bring all the security risks of running Docker in Docker.
The most secure approach is to configure agents that are allowed to run Docker, label those agents (something like docker) and define the jobs that need Docker to require the label docker)
thank you so much sir