deis/jenkins-node

Tooling for bringing up a Jenkins Worker Node for Deis CI.

Jenkins Node

This component comprises of a Docker image used to run a worker node for CI jobs specifically for the Deis Workflow project on https://ci.deis.io.

Essentially, it bundles all the dependencies specific to running CI for Deis Workflow with the stock Jenkins JNLP connection logic as used by the jenkinsci/docker-jnlp-slave image.

This component does not support building Deis v1 end-to-end jobs due to lack of virtualization support in containers.

Usage

The agent needs three values at minimum to run. They can be passed as arguments or exposed via environment variables. Here we illustrate usage via the latter approach:

• JENKINS_URL pointed to the Jenkins master host, e.g. https://ci.deis.io
• JENKINS_NAME representing the name of the agent itself
• JENKINS_SECRET representing the secret associated with JENKINS_NAME for connecting via the Jenkins Remoting module.

Optionally, JENKINS_TUNNEL (of host:port format) can be specified if the JNLP service port is not handled by the host represented in JENKINS_URL

As Static Agent

If a static agent is desired, an administrator will need to create a new node at https://ci.deis.io/computer/new. Once it has been created with the agent's launch method set to "Launch agent via Java Web Start", the resulting name and secret can be passed to the container, either via docker run or via the helm chart install.

To run directly:

$ make build
$ docker run \
  -e JENKINS_URL=https://my.jenkins.master \
  -e JENKINS_NAME=my-node-name \
  -e JENKINS_SECRET=mynodesecret \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /home/jenkins/workspace:/home/jenkins/workspace quay.io/deis/jenkins-node:canary

To run via the helm chart:

helm install charts/jenkins-node --name my-node-name --namespace jenkins \
  --set jenkins.url=https://my.jenkins.master \
  --set agent.name=my-node-name \
  --set agent.secret=mynodesecret

As Dynamic Agent

The container may also be run via the Kubernetes Plugin, which provisions agents on-demand.

First, configure the plugin itself, i.e., set Jenkins URL and other values as needed. This can be done at https://${JENKINS_URL}/configure

Next, the only configuration necessary for this agent to run is to add the volume mounts, as seen in the docker command above and in the helm chart, to the pod template configuration under the general settings set above.

The plugin will handle passing the provisioned name and secret to the container each time it spins up a new node.

jenkins-node's Issues

migrate existing nodes to k8s

This ticket is to help track progress on migrating the existing CI nodes over from an Ansible-style deployment to k8s containers.

So far the following jobs are being used for testing:

• jenkins-node-1 is deployed to champagne.deis.com
• test-job-for-node-test-k8s is set up to run on the k8s worker

At this point, the job is succeeding. Further testing is required to ensure e2e works on this node as well, but once that's completed then we can start slowly migrating the nodes to k8s.

slim down docker image

sittin' at 1.634 GB at time of writing...

make this app scalable

Because we require a single NODE_NAME and NODE_SECRET envvar in the container which relates to a single worker node in jenkins, this application is unable to scale higher than 1. Instead of creating single applications for each jenkins node, it'd be more "12 factorish" to allow this app to scale proportionately to the number of nodes we want in Jenkins.

Refactor: Reduce custom logic

#9 updates the jenkins-node image to act more like a default Jenkins jnlp-slave. However, due to how e2e is setup to run (see deis/e2e-runner), we still have some custom logic in the Dockerfile and jenkins-slave script.

Therefore, this ticket is to make updates (most likely necessary both in this and the aforementioned e2e-runner repo) to switch up the Dockerfile to pull from jenkinsci/jnlp-slave as well as removing our version of the script (delete the rootfs dir).