I need to run a docker-container inside my pipeline.
My problem is, there is no docker.sock available inside the Jenkins-container. And actual no chance to get it.
But I found some jobs using docker with this Option:
"Inject environment variables to the build process" -> "Properties
Content"
And following configured:
DOCKER_HOST=tcp://<ip>:<port>
DOCKER_CERT_PATH=/var/jenkins_home/certs
In my understanding, this is equivalent to the docker.sock and useable as plugin, isnt it?
But how can i use it inside a (multi-)pipeline project?
I've tried using this Block inside my Note:
environment {
DOCKER_HOST = 'tcp://<ip>:<port>'
DOCKER_CERT_PATH = '/var/jenkins_home/certs'
}
But got same issue: "docker: not found"
I might have a logical fallacy. Hope someone could help.
Otherwise is it possible to create a jenkins-slave including a docker.sock?
But got same issue: "docker: not found"
This indicates that your Jenkins slave, the one running the pipeline script, does not have the docker command line tools. This depends on your distribution, but in my case I fixed it by changing my build-slave/pipeline-runner creation steps to include:
yum install -y docker-client
Note that you'll still need that for the Cloudbees docker plugin (the thing which provides stuff like docker.build() and docker.image()) because it translates those nice pipeline directives down into shell commands.
Related
I see that there is some documentation on using Docker through Jenkins Pipelines here:
https://www.jenkins.io/doc/book/pipeline/docker/
They have an example for building a Docker image:
node {
checkout scm
def customImage = docker.build("my-image:${env.BUILD_ID}")
customImage.inside {
sh 'make test'
}
}
But I was unable to find the complete list (with examples) of Docker commands supported.
Here's some places I've looked:
https://plugins.jenkins.io/docker-workflow/
https://github.com/jenkinsci/docker-workflow-plugin/
https://docs.cloudbees.com/docs/admin-resources/latest/plugins/docker-workflow
What I was looking to do is docker save. Does anyone know if something like this is supported, or where it might be documented:
// Tar ball or filename+path
def imageTar = docker.save("${ImageFileName}.tar", "${ProjectImage}:${ProjectRelease}")
The commands under the docker keyword are made available by the Docker Pipeline Plugin which is usually installed by default with Jenkins. The full documentation of the plugin is available Here.
In addition because this plugin adds methods as global variables (which are available in Pipeline directly, not as steps) you can see the available options, which are based on the version of the plugin you have installed, in the Global Variable Reference documentation within your Jenkins instance. There are two ways to reach it:
Navigate to: [JENKINS_URL]/pipeline-syntax/globals
Go to one of your pipeline jobs, on the left menu click on the Pipeline Syntax link, then on the left menu select Global Variable Reference
Search for the docker section and you will see all available options.
Back to your original question - it seems that this plugin currently does not support the save command. it only supports tag, push, pull and run (of all kinds).
If you find it useful you can open a feature request in the plugin's Report an issue (Jira) page asking that they add this new capability.
We are using the code below to spin up a kubernetes cloud docker agent in Jenkins:
agent {
docker { image 'golang:1.14' }
}
We get the error below:
14:55
I get;
WorkflowScript: 158: Invalid agent type "call" specified. Must be one of [any, docker, dockerfile, kubernetes, label, none] # line 158, column 17.
docker { image 'golang:1.14' }
^
Any ideas how to fix this, please?
We have a jenkins.gdsl file which could be in the mix. Any ideas whether this is the right direction to follow? (We are not even sure what a gdsl file is!)
Probably you have to install both plugins:
Docker Pipeline
Docker plugin + deps(Auto)
Not very well explained on the doc and it seems the main plugin Docker plugin does not install Docker Pipeline by default.
See here Using Docker with Pipeline
You should install docker plugins to be able to use Docker in Jenkins.
Go to manage Jenkins.
Manage Plugins.
Install:
Docker pipeline
Docker
You should see the following plugins installed:
Optionally restart Jenkins.
I am getting errors from the durable task plugin when I run my pipeline dsl jenkins job.
The error message suggests that I should use:
-Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=300
This is the error I get:
\workspace\ne-sw-manifest_master-5ZF5EWBP7EVBXEBF6AS3C6UQLIXLCS3HRKYND6TPQAPIKZPFBDLQ#tmp\durable-252b3bfd
(JENKINS-48300: if on a laggy filesystem, consider -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=300)
I am not sure where to set this property.
I tried on Jenkins master -> Configure system -> Global properties -> Environment variables:
Name:org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL
Value:300
But, I am not sure if this is the right place to add this property OR if it has come into effect.
Also, I haven't restarted the master or slave.
My jenkins set-up is Linux master (Jenkins ver. 2.107.1) and Linux and Windows Slaves.
My build is on a Windows slave (physical machine)
option 1:
Add in your pipeline
script {
System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");
}
after Running the approve the script in security settings at Manage Jenkins – In-process Script approval.
Option 2:
go to Manage Jenkins -> Script Console
and run
System.setProperty("org.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL", "3800");
This CloudBees article explains how to set Jenkins Java arguments.
Note: you'll need to restart your Jenkins instance.
Edit: As per sirch's comment, I'm copying here the instructions for RedHat and Debian distro's.
Debian / Ubuntu based Linux distributions
If your configuration file is under /etc/default/ look for the argument JAVA_ARGS. It should look something like this:
JAVA_ARGS="-Djava.awt.headless=true"
Then, add the arguments:
JAVA_ARGS="-Xmx2048m -XX:MaxPermSize=512m -Djava.awt.headless=true"
RedHat Linux based distributions
If your configuration file is under /etc/sysconfig/ look for the argument JENKINS_JAVA_OPTIONS. It should look something like this:
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
Then, add the arguments:
JENKINS_JAVA_OPTIONS="-Xmx2048m -XX:MaxPermSize=512m -Djava.awt.headless=true"
set it either
JAVA_OPTS
or
JNLP_PROTOCOL_OPTS
which will be included in jenkins slave Startup Options
I'm trying to execute the sample of code found in Jenkins Pipeline here : https://jenkins.io/doc/book/pipeline/docker/
node {
/* Requires the Docker Pipeline plugin to be installed */
docker.image('maven:3-alpine').inside('-v $HOME/.m2:/root/.m2') {
stage('Build') {
sh 'mvn -B'
}
}
}
And give me this error:
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
[Pipeline] // withDockerContainer
I don't know why is it stopping like that without doing anything.
I have already install docker, docker plugin/docker pipeline on the latest version.
In configuration tool, i add the installation root path.
Did I miss something ?
Thanks in advance
This message is a normal debug message, maybe a little confusing, but not an error. As the Jenkins Pipeline code is written, during initialization it checks whether the step is already running in a container. I think the message could be written better.
If you have more problems than this message, please provide the entire log. Sounds like maybe a node cannot be assigned, or the docker client is not installed, or the docker image cannot be pulled.
The issue is a bit old but I faced a similar situation and I want to share.
I noticed that Jenkins mentions the the cause of the issue at the end of the pipeline logs.
For example in my case, the issue states:
java.io.IOException: Failed to run top '0458e2cc8b4e09c53bb89f680026fc8d035d7e608ed0b60912d9a61ebb4fea4d'. Error: Error response from daemon: Container 0458e2cc8b4e09c53bb89f680026fc8d035d7e608ed0b60912d9a61ebb4fea4d is not running
When checking the stage where this happened it's similar to the above you mentioned when using dockerImage.inside(), the reason in my case is that my Dockefile already defines an entrypoint and when using the inside feature jenkins gets confused, so to avoid this try overriding the entrypoint by passing it as a parameter to the inside function as follows:
dockerImage.inside("--entrypoint=''") {
echo "Tests passed"
}
Another good way to find the issue is to access your jenkins server ans list the docker containers with docker ps -a you may find the build container failed, check the logs then you will get a hint, in my case the logs says cat: 1: ./entrypoint.sh: not found.
To clarify, this is not a question about running Jenkins in Kubernetes, this is about deploying to Kubernetess from Jenkins.
I have recently settled on using Jenkins (and the workflow/pipeline plugin) to orchestrate our delivery process. Currently, I'm using the imperative style to deploy as per below:
stage 'Deploy to Integ'
// Clean up old releases
sh "kubectl delete svc,deployment ${serviceName} || true"
def cmd = """kubectl run ${serviceName} --image=${dockerRegistry}/${serviceName}:${env.BUILD_NUMBER} --replicas=2 --port=${containerPort} --expose --service-overrides='{ "spec": { "type": "LoadBalancer" }}' """
// execute shell for the command above
sh cmd
This works well because the ${env.BUILD_NUMBER} persists through the pipeline, making it easy for me to ensure the version I deploy is the same all the way through. The problem I have is that I would like to use the declarative approach as this isn't scalable, and I would like the definition in VCS.
Unfortunately, the declarative approach comes with the adverse effect of needing to explicitly state the version of the image (to be deployed) in the yaml. One way around this might be to use the latest tag, however this comes with its own risks. For example, lets take the scenario where I'm about to deploy latest to production and a new version gets tagged latest. The new latest may not have gone through testing.
I could get into changing the file programmatically, but that feels rather clunky, and doesn't help developers who have the file checked out to understand what is latest.
What have you done to solve this issue? Am I missing something obvious? What workflow are you using?
In my yaml file (server.origin.yml), I set my image as image-name:$BUILD_NUMBER
Then I run: envsubst < ./server.origin.yml > ./server.yml
This command will replace the string $BUILD_NUMBER by the value of the environment variable