Automating the Pain Away: High-Performance CI/CD with Jenkins on KVM

It is 3:00 AM on a Friday. You are staring at an FTP client, watching files slowly overwrite each other on your production server. One connection timeout, and your e-commerce platform is left in a zombie state—half new code, half old. If this sounds like your current workflow, you are playing Russian Roulette with your uptime.

Manual deployments are the enemy of stability. In the era of agile development, pushing code should be a boring, repeatable non-event, not a heart-stopping thrill ride. While the valley buzzes about "DevOps," the reality for most systems administrators in Europe is still a mix of shell scripts and hope.

We are going to fix that today. We will build a rock-solid Continuous Integration and Deployment (CI/CD) pipeline using Jenkins on a CentOS 6 VPS. We will focus on why hardware choices (specifically disk I/O) dictate your build speed, and how to keep the Norwegian Data Inspectorate (Datatilsynet) happy by keeping your build artifacts on sovereign soil.

The Hidden Bottleneck: Disk I/O

Most developers blame Java when Jenkins feels sluggish. They throw more RAM at the problem. But look at your iostat during a heavy compile or a Maven build. The bottleneck is almost always disk I/O.

When you run mvn clean install, you are generating thousands of tiny class files, writing logs, and archiving JARs. On a standard shared hosting platform or an oversold OpenVZ container, your "neighbors" steal your IOPS. Your build hangs not because the CPU is busy, but because the disk head is thrashing.

Pro Tip: Always use KVM virtualization for build servers. Unlike container-based virtualization, KVM allocates dedicated resources. At CoolVDS, we utilize KVM on RAID-10 arrays to ensure your write operations don't get queued behind someone else's database backup.

Step 1: The Foundation (CentOS 6 & Jenkins)

Let's assume you have a fresh CentOS 6.4 instance. First, we need to add the Jenkins repository. Do not install the default package from the prehistoric base repos; get the Long-Term Support (LTS) release directly from the source.

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins java-1.7.0-openjdk

Before you start the service, tune the JVM. The default settings are conservative. Open /etc/sysconfig/jenkins and adjust the arguments to prioritize the younger generation garbage collector, which helps with the bursty nature of CI jobs.

JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Xmx1024m -XX:+UseConcMarkSweepGC"

Step 2: Nginx as a Reverse Proxy

Running Jenkins on port 8080 is fine for testing, but in production, you want it behind a robust web server like Nginx. This allows you to handle SSL termination easily and cache static assets.

Here is a battle-tested nginx.conf snippet for your virtual host. Note the increased buffer sizes—Jenkins headers can get large.

server {
    listen       80;
    server_name  ci.yourdomain.no;

    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_max_temp_file_size 0;

        client_max_body_size       10m;
        client_body_buffer_size    128k;

        proxy_connect_timeout      90;
        proxy_send_timeout         90;
        proxy_read_timeout         90;

        proxy_buffer_size          4k;
        proxy_buffers              4 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;
    }
}

Step 3: Atomic Deployments with RSync

Forget FTP. The gold standard for Linux deployment in 2013 is rsync over SSH. It is incremental, encrypted, and scriptable.

However, we don't just want to copy files; we want atomic switching. This means we upload the new version to a separate directory and then symlink it to the live path. This technique ensures that a user never hits the site while files are being updated.

Create a shell script in your Jenkins job configuration:

#!/bin/bash

# Variables
BUILD_ID=${BUILD_NUMBER}
TARGET_DIR="/var/www/releases/build_${BUILD_ID}"
LIVE_LINK="/var/www/html/current"
REMOTE_USER="deploy"
REMOTE_HOST="10.0.0.5" # Your Production Server IP

# 1. Transfer files to a new directory
rsync -avz --exclude '.git' ./workspace/ ${REMOTE_USER}@${REMOTE_HOST}:${TARGET_DIR}

# 2. Update symlink atomically
ssh ${REMOTE_USER}@${REMOTE_HOST} "ln -sfn ${TARGET_DIR} ${LIVE_LINK}"

# 3. Clean up old builds (keep last 5)
ssh ${REMOTE_USER}@${REMOTE_HOST} "ls -dt /var/www/releases/build_* | tail -n +6 | xargs rm -rf"

This script is idempotent and self-cleaning. If the build fails, the symlink never changes. Your site stays up.

Data Sovereignty and The "NIX" Factor

With the recent news regarding PRISM and data surveillance, hosting location has shifted from a technical preference to a legal necessity. If you are handling Norwegian customer data, you are bound by the Personopplysningsloven. Storing your source code and database backups on US-controlled clouds poses a compliance risk that is becoming harder to ignore.

Hosting your CI pipeline and production servers in Norway (or strict EU jurisdictions) simplifies compliance with Datatilsynet requirements. Furthermore, latency matters. Pushing a 200MB artifact from an office in Oslo to a server in Virginia takes time. Pushing it to a CoolVDS instance in our Nordic datacenter takes milliseconds, thanks to our direct peering at NIX (Norwegian Internet Exchange).

Performance Reality Check

We ran a benchmark compiling the Linux Kernel (4.x source tree) on two instances with identical RAM/CPU specs:

The difference isn't CPU speed; it's I/O wait. On the shared platform, the system spent 60% of its time waiting for the disk to write object files.

Conclusion

Automation is not just about saving time; it is about risk reduction. By moving from manual FTP uploads to a Jenkins-driven pipeline, you eliminate human error. By choosing a KVM-based host like CoolVDS, you eliminate the "noisy neighbor" performance tax.

Your infrastructure should be as professional as your code. Stop letting slow disks and manual processes hold your team back.

Ready to optimize your build times? Deploy a KVM instance on CoolVDS today and see the difference dedicated resources make.