CI tools testing lab: Making it do useful work

I this post I’m going to describe how to create Zuul-compatible Jenkins jobs and Zuul pipelines to trigger them on code changes in Gerrit.

This is the sixth and final post in a series describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features. Previously I’ve described how to install Jenkins, Gerrit, add the zuul-server and zuul-merger components, link Jenkins to Zuul and show the Zuul graphical status page.

Before we can create Jenkins jobs and Zuul pipelines, we need to create a Gerrit project for everything to work against.

CI tools testing lab: Integrating Jenkins and adding Zuul UI

In this post I’m going to describe how I connected Jenkins to my experimental Zuul setup. I’m also going to describe how to build a container to expose the Zuul graphical UI over HTTP.

This post is the fifth in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features. Previously I’ve described how to install Jenkins, Gerrit and add the zuul-server and zuul-merger components.

Zuul communicates with Jenkins by means of the Gearman Plugin.

CI tools testing lab: Adding Zuul Merger

zuul-merger is a component of Zuul that merges code patches together to emulate the state code will be in once those patches are merged.  This post describes how I’ve ran it in a Docker container as part of a lab setup.

This post is the fourth in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features. Previously I’ve described how to install Jenkins, Gerrit and add zuul-server.

To have a useful zuul-merger service, we need to run two services – zuul-merger itself, and an HTTP server to make the code built by zuul-merger available to Jenkins. But first, we need to write a configuration file.

CI tools testing lab: Setting up Zuul Server

In this post I’m going to describe the various components of Zuul, and how to run zuul-server in a Docker container  in a lab setup.

This post is the third in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features. Previously I’ve written about how I’ve started Jenkins and Gerrit to have the necessary services for Zuul to work against.

In order to gain a deep understanding of Zuul and prepare fur running it in production, I came up with a rather complex container layout . If you just want to see what Zuul looks like you can get a single container with everything (including Jenkins and Gerrit) here.

A fully functional Zuul system consists of several components:

CI tools testing lab: Adding Gerrit

In this post I’m going to describe how I quickly brought up Gerrit using Docker in a lab setup, and integrated it with Jenkins.

This post is the second in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features.

Please see the previous post for an explanation of my goals, choice of tools and work done previously.

Since I’m focused on testing Zuul, I did not want to spend too much time setting up Gerrit. Instead I looked for a ready made container image that I could quickly bring up.

CI tools testing lab: Initial setup with Jenkins

 Gerrit, Jenkins and the Jenkins Gerrit Trigger Plugin make for a relatively easy way to setup an automated code review system. Using these components, you can have Jenkins run automates tests on code while it is being reviewed in Gerrit.

But as projects grow in complexity and amount of developers, some shortcomings of of this system become apparent as the reviewed code being tested in Jenkins stops reflecting the way it will actually look when merged into the main development branch. This is an issue we came across on oVirt’s CI system.

Looking for a solution, we found Zuul – a tool developed by the OpenStack community when they faced similar issues.

This post is a first in a series of posts describing how I’ve used Docker to build a lab setup on my laptop to try out Zuul and check out its various features.

Rundeck: An interesting job scheduling system

Rundeck is a system for creating, managing, and using IT automation processes. The main selling point of the system, according to its website, is the ability to provide processes in such a way that would allow SysAdmins and DevOps to delegate process execution to other people in the organization.

In order to facilitate process creation and delegation, Rundeck provides a friendly web-based UI as well as the ability to integrate it to various account management systems. Rundeck also allows to automate the registration of hosts for it to run jobs on, by integration with various configuration management and cloud infrastructure systems.

Rundeck`s approach of having a centralized server with a web-based UI provides some advantages over other automation systems such as Fabric and Ansible. The UI allows for easy discovery and use of available jobs as well as creation of new ones. The server model also allow one to fire a job and walk away instead of having to stare at the console until its done.

Automatic loading of SSH keys from scripts

When using SSH with public-key authentication, ‘ssh-agent‘ is a useful compromise between storing the SSH private key un-encrypted to disk and having to type the key`s passphrase every time you need to make an SSH connection.

When using SSH from scripts, things are further complicated, because no one is around to type in the passphrase. From this reason, SSH keys that are used by servers are, more often then not, stored with no encryption, thereby becoming a lucrative target for hackers.

With some clever manipulation, a script can be written in such a way where it can make use of the ‘ssh-agent‘ to load and use an encrypted private key.

systemd cheat sheet

The system manager’s adoption by Red Hat alone, was enough to make ‘systemd‘ a required learning for every self-respecting Linux sysadmin. Its adoption by most other Linux distributions, made it completely mandatory.

Its not hard to learn to use ‘systemd’. The developers made a conscious efforts to make it compatible, where possible, with existing procedures and commands. The developers also produced some very extensive and detailed documentation. Indeed, a rare thing in the Linux world for such a young product.

To get you started on learning, here is a quick cheet sheet mapping new ‘systemd’ command to classic ‘System-V’ commands.

Comparison of Puppet and Ansible

A configuration management system is a crucial tool in the tool box of any sysadmin. I have been using and advocating Puppet for several years now. Recently I have noticed that Ansible had emerged to be considered as an alternative to Puppet. I’ve decided to give Ansible a good look, evaluate its strengths and weaknesses, and decide if, by chance, it is time for me to put Puppet aside.