Jenkins on Kubernetes Engine – Cloud Stack Group

Today we would be getting to know some new and collective data and that is regarding the process of Jenkins on Kubernetes Engine. The topic when understood is very easy and it indeed teaches you some of the best practices for using Jenkins with Google Kubernetes.

Now when discussing about the services, Jenkin is an open-source server that lets you flexibly orchestrate your build, test, and deployment pipelines. Kubernetes Engine is a hosted version of Kubernetes, a powerful cluster manager and orchestration system for containers

When you as a company decide to deploy Jenkins on Kubernetes Engines there is a need to have a set up of continuous delivery (CD). This entire process provides some of the basic as well as important benefits over a standard VM based deployment.

Below mentioned are some of the key points that is taken into consideration and with this process followed the entire work becomes easier and simpler.

• When your build process uses containers, one virtual host can run jobs against different operating systems.
• Kubernetes Engine provides phenomenal build executors, that allows each build to to run in a clean environment that’s identical to the builds before it.
  • As part of the ephemerality of the build executors, the Kubernetes Engine cluster is only utilized when builds are actively running, leaving resources available for other cluster tasks such as batch processing jobs.
  • Build executors launch in seconds

• To monitor the route web traffic for your instances, it is necessary that Kubernetes Engine leverages the Google global load balancer. The work of load balancer is to handle SSL termination, and along with that provides a global IP address that routes users to your web front end on one of the fastest paths from the point of presence closest to your users through the Google backbone network.

Now let us proceed further and have a look at some of  the codes and methods that are undertaken for the purpose of work getting compelled within the stipulated time and also by this we can enable and configure the data server with help of different deploying methods and controllers.

Deploying the Jenkins controller with Helm

With the help and use of Helm deployment of Jenkins from the charts repository. Helm basically is a complete managerial package that can be used to configure as well as deploy Kubernetes apps.

When saying this we would like to emphasize on deploying of Jenkins controller into separate namespace and that too in the Kubernetes cluster. The work of namespaces is to allow the process of creation of quotas for the deployment of Jenkins as well as making sure that logically they are separating Jenkins from other deployments within the cluster.

Moving further, when deploying Jenkins controller with Helm, there is a need to have the command which helps the installation process to be done with the faster pace and along with that assurity on the result.

Install Jenkins Helm Chart

• Command for Installing the Jenkins Chart and Provision a PVC dynamically

$ helm install –namespace browncompute –name jenkins –version 0.14.4 \ –set Master.ImageTag=2.117 \ –set Master.ServiceType=NodePort \ –set Master.InstallPlugins.0=kubernetes:1.5.2 \ –set Master.InstallPlugins.1=workflow-aggregator:2.5 \ –set Master.InstallPlugins.2=workflow-job:2.19 \ –set Master.InstallPlugins.3=credentials-binding:1.16 \ –set Master.InstallPlugins.4=git:3.8.0 \ –set Agent.ImageTag=3.19-1 \ –set rbac.install=true \ stable/jenkins –tls;

• Install the Jenkins Chart and Pass an Existing PVC

$ helm install –namespace browncompute –name jenkins –version 0.14.4 \ –set Master.ImageTag=2.117 \ –set Master.ServiceType=NodePort \ –set Master.InstallPlugins.0=kubernetes:1.5.2 \ –set Master.InstallPlugins.1=workflow-aggregator:2.5 \ –set Master.InstallPlugins.2=workflow-job:2.19 \ –set Master.InstallPlugins.3=credentials-binding:1.16 \ –set Master.InstallPlugins.4=git:3.8.0 \ –set Persistence.ExistingClaim=jenkins-home \ –set Agent.ImageTag=3.19-1 \ –set rbac.install=true \ stable/jenkins –tls;

• Install the Jenkins Chart without a PVC

$ helm install –namespace browncompute –name jenkins –version 0.14.4 \ –set Master.ImageTag=2.117 \ –set Master.ServiceType=NodePort \ –set Master.InstallPlugins.0=kubernetes:1.5.2 \ –set Master.InstallPlugins.1=workflow-aggregator:2.5 \ –set Master.InstallPlugins.2=workflow-job:2.19 \ –set Master.InstallPlugins.3=credentials-binding:1.16 \ –set Master.InstallPlugins.4=git:3.8.0 \ –set Persistence.Enabled=false \ –set Agent.ImageTag=3.19-1 \ –set rbac.install=true \ stable/jenkins –tls;

Creation of Jenkins Services

Let us proceed further and take a look at the method that is undertaken for the creation of Jenkins services. It is the work in which Jenkins provides two services that the cluster needs to access to. So, here the best way is to deploy these services individually and separately and that they can be managed easily and with the process of naming them.

• An externally-exposed NodePort service on port 8080 that allows pods and external users to access the Jenkins user interface. This type of service can be load balanced by an HTTP load balancer.
• An internal, private ClusterIP service on port 50000 that the Jenkins executors use to communicate with the Jenkins controller from inside the cluster.

The following sections show sample service definitions. (The controller is called master in the definitions.)

Well, below mentioned is the code that is used for creation of Jenkins Services.

jenkins/k8s/service_jenkins.yaml

—

kind: Service

apiVersion: v1

metadata:

name: jenkins-ui

namespace: jenkins

spec:

type: NodePort

selector:

app: master

ports:

– protocol: TCP

port: 8080

targetPort: 8080

name: ui

jenkins/k8s/service_jenkins.yaml

—

kind: Service

apiVersion: v1

metadata:

name: jenkins-discovery

namespace: jenkins

spec:

selector:

app: master

ports:

– protocol: TCP

port: 50000

targetPort: 50000

name: slaves

Creating the Jenkins deployment

It is that as a deployment process go ahead and deploy the Jenkins controller with a replica count of 1. This shares the details and gives assurity that there is a single Jenking controller who is always running the cluster all times. It is like if their situation arises in which the Jenkins controller pod dies or the node that it is running on shuts down, Kubernetes restarts the pod elsewhere in the cluster.

It’s important to set requests and limits as part of the Helm deployment, so that the container is guaranteed with a certain amount of CPU and memory resources which is inside the cluster before the work or the details is being scheduled. If this process is not followed then there would be the controller which can go down due to CPU or memory starvation.

The Jenkins home volume stores XML configuration files and plugin JAR files that make up your configuration. This data is stored on a Persistent Disk managed by the GKE cluster and will persist data across restarts of Jenkins. To change the size of the persistent disk edit the Persistence. Size value when installing Jenkins with Helm.

Connecting to Jenkins

Once the Jenkins pod has been created you can create a load balancer endpoint to connect to it from outside of Cloud Platform. Consider the following best practices.

• Use a Kubernetes ingress resource for an easy-to-configure L7 load balancer with SSL termination.
• Provide SSL certs to the load balancer using Kubernetes secrets. Use cert and tls.key values, and reference the values in your ingress resource configuration.

Configuring Jenkins

Securing Jenkins

One the connection of Jenkins is done for the first time, it is important to immediately secure the Jenkins. This can be done with the help of following Jenkins standards security setup with its tutorial and this is for a simple procedure that leverages an internal use of database. This setup doesn’t require additional infrastructure and provides the ability to lock out anonymous users.

Installing plugins

Below mentioned is the details of the plugins that needs to be followed for the process of installation. These plugins enhances the interactions between Jenkins and Kubernetes Engine.

• The Kubernetes plugin enables using Kubernetes service accounts for authentication, and creating labeled executor configurations with different base images. The plugin creates a pod when an executor is required and destroys the pod when a job ends.
• The Google Authenticated Source plugin enables using your service account credentials when accessing Cloud Platform services such as Cloud Source Repositories.

To add additional plugins using the Helm chart, edit the list of plugins in the values file that you pass to the Helm install or upgrade commands.

Customizing the Jenkins Agent Docker image

When there is a process set in which if creating a pod template, the details can be either you can provide an existing Docker image, or you can create a custom image that has most of your build-time dependencies installed. Using a custom image can reduce a major time to build and create more consistent build environments.

It is that the custom Docker image that is been shared must be getting installed as well as configured in the Jenkins JNLP inbound agent. The JNLP agent is software that communicates with the Jenkins controller to coordinate running your Jenkins jobs and reporting job status.

One option available here is to make sure that we add FROM jenkins/inbound-agent to your image configuration.

Below mentioned are some of the codes and artifacts that are taken into consideration for the purpose of having Jenkins installed for Kubernetes.

FROM jenkins/inbound-agent RUN apt-get update && apt-get install -y golang

Moving further, the next step is to build and upload the image to your project’s Container Registry repository by running the following commands.

docker build -t gcr.io/[PROJECT]/my-jenkins-image .

gcloud auth configure-docker

docker push gcr.io/[PROJECT]/my-jenkins-image

 

Let us proceed further and check on the details in which it is like when creating a pod template, it is now very easy to set the Docker image field to the following string, where [PROJECT] is replaced with your project name and [IMAGE_NAME] is replaced with the image name. The command for the same is as shared below.

gcr.io/[PROJECT]/[IMAGE_NAME]

 

Over to You:

We at Cloud Stack Group present to you the commands and details in which Jenkins for Kubernetes id been shared. On knowing the need and importance of the service we provide the solution to our clients regardless how complex it would be.

Not only this we and our team of highly skilled and trained engineers are versatile enough to deliver that level of work which is being expected by our esteemed and valued clients. Having experience of over years and knowing the current trend in the IT field we are very well upto date with all latest set of tools and services that can make the work completed at a very high speed.

Our expertise of the services is not only limited till Jenkins and Kubernetes. Rather we are the leading as well as one stop destination that provides migration of AWS services, detailed and accurate DevOps services, and all the latest AWS optimization services that takes the world of every business sector to a new level.

With this said, connect with us today to know how we work and in what way. Our team is always available to serve our clients in all the best possible way along with the assurance to be with them at every single step they want to have assistance of our help and support.

Well, with this said let connect with us over the call or via email to let us further discuss what is the best for taking your server and business to a new level that is highly recommended in todays’ fast and developing year of 2020.