Category Archives: Jenkins

Kubernetes Pipeline

Let’s explain an easy way to build an integration pipeline (CI) on Minikube.

Launch Minikube

If you don’t have Minikube running on your system,

$ minikube start --memory 4000 --cpus 2

Wait for a few minutes, you’ll see something like.

Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.

Installing Helm

Helm is The Kubernetes Package Manager, it helps you to deploy services into Kubernetes.

$ wget https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz -O helm.tar.gz
$ tar zxf helm.tar.gz
$ sudo cp linux-amd64/helm /usr/local/bin/helm
$ sudo chmod +x /usr/local/bin/helm

Applying the RBAC policy

$ kubectl create -f https://raw.githubusercontent.com/nordri/kubernetes-experiments/master/Pipeline/ServiceAccount.yaml

and then launch helm.

helm init --service-account tiller

Checking

$ helm version
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}

Deploying Jenkins

I’m using a custom values file for this chart. What I’m adjusting is:

AdminPassword: set to admin1234
ServiceType: set to NodePort (because is Minikube)
In plugins:
– kubernetes:1.2
– workflow-aggregator:2.5
– workflow-job:2.17
– credentials-binding:1.15
– git:3.7.0

And then the deployment:

$ helm install --name jenkins -f jenkins-helm-values.yaml stable/jenkins

After a few minutes we could be able to access Jenkins with:

$ minikube service jenkins

Configuring Jenkins

First, set the credentials to access Docker Hub where we’ll push the Docker images. The only field you must keep is ID because is needed by the pipeline in a next step. Fill it with your information:

Back to Jenkins main screen, add a new item type Pipeline

And finally, configure the pipeline in the Pipeline section:

Save the changes and click on Build now

And that’s it!

The pipeline

Let’s deep into the pipeline

The head

The pipeline starts setting the worker id so the pod has different label on each execution.

Follow the pod definition where we can define the containers who will run inside the pod. For this example we’ll need:

  1. maven
  2. docker
  3. mysql, this one with environment variables
  4. java, also with environment variables

Then the volumes, we need the docker sock in order to run docker in docker and a folder to save the artefacts downloaded from the Internet (it’s a Maven project!) between the executions. Saving time and bandwidth.

Cloning the repo…

What we do here is clean the workspace and clone the repository. It a SpringBoot application with MySQL.

Building…

We build the package using maven container.

Testing…

In this stage we launch our app inside Java container and after 30 seconds we check if it online, a simple smoky test. We save the return value in RES to decide if it’s ok or not. If not, finish with fail. As we defined all the containers at the beginning there’s a MySQL running inside the pod.

Building & Uploading Docker images…

If the testing stage went OK, we can push it to Docker Hub. To set the tag we use the commit ID cut to eight characters. To login into Docker Hub we use the withCredentials who takes a credential by id and fill the environment variables.

References

Set Up a Jenkins CI/CD Pipeline with Kubernetes

Repository

GitHub

Lanzar Workers de Jenkins en AWS

En esta entrada veremos lo sencillo que resulta configurar Jenkins para levantar instancias en AWS EC2 para el entorno de CI.

1. Crear la AMI con packer.

Tenemos ya algunos nodos en el entorno de CI que se provisionan con Ansible. Utilizamos packer y la receta de ansible para crear una imagen con todo lo necesario para los jobs de Jenkins.

El fichero Json para packer

{
  "variables": {
    "aws_access_key": "",
    "aws_secret_key": ""
  },
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "eu-west-1",
    "source_ami": "ami-a8d2d7ce",
    "instance_type": "t2.small",
    "ssh_username": "ubuntu",
    "ami_name": "codeurjc-jenkins-worker {{ timestamp }}"
  }],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "sudo apt-get update",
        "sudo apt-get install -y python"
      ]
    },
    {
      "type": "ansible",
      "playbook_file": "./playbook.yml",
      "user": "ubuntu"
    }]
}
$ packer build -var 'aws_access_key=ACCESS_KEY' -var 'aws_secret_key=SECRET_KEY' packer-jenkins-worker.json

2. Configuración de seguridad

Por un lado tenemos que crear un usuario para manejar la API. Vamos a nuestra consola de AWS y clickamos AMI, en Users le damos a Add user, le damos un nombre por ejemplo jenkins y en Access type elegimos Programmatic access. En el siguiente paso otorgamos permisos al usuario para manejar el servicio de EC2 creando un grupo especifico para ello, si no lo tenemos creado previamente. Repasamos y creamos el usuario, veremos las claves para acceder, copiar y guardarlas en lugar seguro.

Ahora vamos a crear un grupo de seguridad para las instancias que levantemos de Jenkins. Tenemos que permitir acceso por SSH a la instancia, asi que nos vamos a la consola de EC2 en el apartado de Security group y creamos uno nuevo (si no está creado previamente) y damos permisos para acceder por SSH.

Por último tenemos que importar la clave pública que permitirá a Jenkins configurar los nodos que despleguemos en AWS. Vamos a la consola de EC2, Key Pairs y hacemos click en Import Key Pair, en el cuadro de diálogo pegamos la clave pública que usamos en los nodos de nuestra infraestructura. Le ponemos un nombre por ejemplo Jenkins

3. Plugin de Jenkins

En Jenkins necesitamos este plugin.

La configuración es secilla, vamos a Manage Jenkins -> Cloud -> New cloud

Le ponemos un nombre descriptivo.

Añadimos las credenciales que hemos creado en el paso 2.

Seleccionamos la región, en mi caso eu-west-1

Para la clave, como tenemos workers en nuestra infraestructura tenemos que pegar la clave privada que tiene Jenkins.

Podemos ahora probar que la conexión a la API de AWS funciona.

Pasamos a la configuración de la AMI.

De nuevo un nombre descriptivo

La ID de la AMI que hemos creado con Packer anteriormente.

El tipo de instancia, como tenemos mucha carga usamos T2Large.

De nuevo la zona de disponiblidad, eu-west-1a

Introducimos el grupo de seguridad que hemos creado en AWS para que nos permita acceder por SSH a la instancia.

En el usuario remoto, nosotros usamos jenkins.

El tipo de AMI es obviamente una UNIX, esto es necesario porque dependiendo del tipo, la conexión se hace de una forma u otra.

Añadir el label para asignar trabajos al nodo.

En el uso ponemos que solo ejecute jobs que coincidan con el nodo.

En Idle termination time establecemos los minutos que tiene que estar la instancia ociosa antes de que se apague (stop o terminate).

En Init script podemos escribir algunas instrucciones necesarias en tiempo de arranque para la instancia, por ejemplo podríamos provisionar la instancia haciendo que se clonara el repo de Ansible y ejecutarlo con conexión local, en nuestro caso la AMI ya viene completa y no necesitamos nada.

Desplegamos más opciones haciendo click en Advance. Las opciones que más nos interesan son:

Override temporary dir location nos permite establecer un directorio temporal donde copiar el slave.jar para ejecutar Jenkins.

User data, para pasar información a la instancia.

Number of Executors, depende del Instance type que hayamos elegido, en nuestro caso 8.

Stop/Disconnect on Idle Timeout, si elegimos esta opción la instancia se parará, no se destruirá, esto con los disco EBS puede repercutir en cargos adicionales a la factura.

Subnet ID for VPC, para establecer la red a la que debe estar conectada la instancia.

Instance Cap, el limite de instancias a levantar en AWS, a más instancias más factura.

Block device mapping, elegimos un volumen EBS personalizado porque el de 8 GB que viene de serie es demasiado pequeño, la línea queda de esta manera.

/dev/sda1=:120:true:::

De forma que el disco raiz se mapea a un dispositivo que se creara en el momento de lanzar la instancia con 120GB y se borrará cuando se destruya la instancia.

Podemos conservar el volumen con false. Si ya tenemos algún disco provisionado podemos poner el nombre entre el igual y los dos puntos.

4. Configurar el Job

Ahora solo nos quedaría configurar un job con el label que hemos elegido para las AMIs, esto se entrando en la configuración de Job en cuestión y en el campo Restrict where this project can be run colocar el label.