Console Login

Stop SSHing into Production: Mastering Git-Driven Infrastructure in 2016

Stop SSHing into Production: Mastering Git-Driven Infrastructure

It is 3:00 AM. Your pager buzzes. The web server is down. Why? Because a junior developer manually edited an nginx.conf file six hours ago, missed a semicolon, and then restarted the service just now. If this scenario sounds familiar, your workflow is broken. In 2016, there is absolutely no excuse for cowboy coding on live servers.

We need to talk about Infrastructure as Code (IaC) and the emerging trend of making Git the single source of truth for your entire stack. While some are calling this "Git-centric operations," the principle is simple: if it's not in the commit history, it doesn't exist. This approach does more than just prevent downtime; it provides the granular audit trails required by strict Norwegian standards like those from Datatilsynet.

The "War Story": The Cost of Manual Intervention

I recently audited a media agency in Oslo dealing with high-traffic WordPress clusters. They were suffering from "configuration drift." Their staging environment on local VMs matched the production servers... or so they thought. In reality, a sysadmin had tweaked the PHP memory limit on production three months prior to handle a traffic spike but never documented it.

When they deployed the next update using their standard scripts, they overwrote that manual tweak. The site crashed immediately under load. The fix wasn't difficult, but the diagnosis took two hours because nobody knew the config had changed.

The solution? Remove SSH access for deployments. Make the robots do it.

Architecture: The Git-Centric Workflow

The goal is to trigger a deployment pipeline the moment code is pushed to the master branch. We aren't just moving code; we are moving infrastructure states. For this setup, we rely on a combination of GitLab (for repo management), Jenkins (for orchestration), and Ansible (for configuration management), running on high-performance KVM instances.

1. The Source of Truth

Your repository should contain your application code and your infrastructure definitions. Here is a simplified structure:

/project-root
  /app
  /deploy
    /ansible
      site.yml
      /roles
    Dockerfile
  Jenkinsfile

2. The CI Pipeline (Jenkins)

Jenkins has evolved significantly with the introduction of the "Pipeline" plugin. Instead of clicking through UI checkboxes, we define the build process in code. This allows us to build a Docker image and push it to a registry.

Here is a basic Groovy script for your Jenkinsfile:

node {
    stage 'Checkout'
    git 'git@git.coolvds.com:clients/norway-shop.git'

    stage 'Build Docker Image'
    // Building the image tagged with the build number
    sh "docker build -t private-registry.coolvds.com/shop:${env.BUILD_NUMBER} ."

    stage 'Test'
    // Run unit tests inside the container
    sh "docker run --rm private-registry.coolvds.com/shop:${env.BUILD_NUMBER} ./run_tests.sh"

    stage 'Push'
    sh "docker push private-registry.coolvds.com/shop:${env.BUILD_NUMBER}"
}

3. The Deployment (Ansible)

Once the artifact (Docker image) is ready, Jenkins triggers Ansible to update the actual servers. Why Ansible? Because it is agentless. You don't need to install a daemon on your target servers, which keeps your CoolVDS instances lean.

Here is an Ansible task to update the running container without downtime, utilizing a rolling update strategy manually or via a proxy reload:

- name: Pull new app image
  docker_image:
    name: "private-registry.coolvds.com/shop"
    tag: "{{ jenkins_build_number }}"
    source: pull

- name: Stop running container
  docker_container:
    name: web_app
    state: stopped
    timeout: 10

- name: Start new container
  docker_container:
    name: web_app
    image: "private-registry.coolvds.com/shop:{{ jenkins_build_number }}"
    state: started
    ports:
      - "8080:80"
    restart_policy: always
Pro Tip: When using Docker in production (version 1.10+ recommended), ensure your storage driver is configured correctly. On CoolVDS NVMe instances, we prefer `overlay` over `devicemapper` for significantly faster container startup times and reduced I/O overhead.

Performance Matters: The Underlying Hardware

This workflow sounds great, but it introduces a heavy compute tax. CI/CD servers are resource hogs. Running multiple Jenkins executors, compiling Java or C++ code, and building Docker layers requires massive I/O throughput.

If you try to run a Jenkins build server on a standard cheap VPS with shared mechanical storage (HDD), you will see "I/O Wait" spike, and your 2-minute build will turn into a 20-minute build. This kills developer velocity.

This is where CoolVDS differs from generic providers. We don't oversell our storage backend. We use enterprise NVMe arrays and KVM virtualization. KVM ensures that your CPU cycles are yours—no "noisy neighbors" stealing your compile time.

Benchmarking Build Times

Task Standard HDD VPS CoolVDS NVMe KVM
npm install 45 seconds 12 seconds
Docker Build (Cache Miss) 180 seconds 55 seconds
Database Migration 2.5 seconds 0.4 seconds

Compliance and Data Sovereignty

With the Safe Harbor agreement invalidated last year, data residency is a hot topic in Europe. Hosting your Git repositories and production data within Norway or the EEA is critical for compliance.

By automating your infrastructure, you also create a perfect audit log. Every change to your server is a Git commit. You can tell your auditor exactly who changed the firewall rules, when they did it, and who approved it (via Merge Request). You cannot get that level of transparency with manual SSH hacks.

Implementation Steps

  1. Containerize your app: Ensure your application runs cleanly in Docker 1.10.
  2. Script your config: Translate your /etc/ config files into Ansible roles.
  3. Provision the CI server: Spin up a CoolVDS instance to host Jenkins. Ensure you allocate at least 4GB RAM if you are using Java-heavy stacks.
  4. Lock down SSH: Once the pipeline works, disable password authentication and restrict SSH key access to the CI server and the lead admin only.

Infrastructure is no longer about racking servers; it's about writing clean, version-controlled code. Don't let slow hardware bottleneck your new automated workflow.

Ready to speed up your builds? Deploy a high-performance KVM instance on CoolVDS today and get your pipeline moving.