GitOps Workflows: Stop SSH-ing Into Production

It is June 2018. If you are still deploying code by copying files over FTP or running kubectl apply -f from your laptop, you are actively sabotaging your company's stability. I recently audited a mid-sized e-commerce setup in Oslo where a senior developer hot-patched a PHP file directly on the production server. The site went down for 45 minutes because of a missing semicolon. No audit trail. No rollback mechanism. Just panic.

With GDPR officially enforced as of last month, this cowboy style of administration isn't just risky—it is legally dangerous. The Data Inspectorate (Datatilsynet) does not care about your "agile velocity" if you cannot prove who changed what data processor configuration and when.

Enter GitOps. Coined by Weaveworks recently, it is the operational framework where Git becomes the single source of truth for your entire system, both infrastructure and application code. If it isn't in Git, it shouldn't exist in production.

The Architecture: Pull vs. Push

In a traditional CI/CD pipeline (Jenkins, Bamboo), the CI server pushes changes to the cluster. This is a security flaw. It means your CI server needs root access (or cluster-admin rights) to your production environment. If your Jenkins gets compromised, your entire infrastructure is gone.

GitOps inverts this. We use a Pull model.

• The Repository: Contains YAML manifests (Deployments, Services, Ingress).
• The Agent: Runs inside your cluster (e.g., Weave Flux). It watches the Git repo.
• The Action: When the agent detects a new commit, it pulls the state and applies it to the cluster.

Pro Tip: By using a Pull model, you can lock down your firewall completely. No incoming ports need to be open for deployment tools. The cluster only needs outbound access to your Git repository. This is a massive win for security audits.

Setting Up the Pipeline (The 2018 Stack)

Let's look at a practical implementation using GitLab CI (very popular here in Europe for its self-hosted capabilities) and Kubernetes running on CoolVDS KVM instances.

1. The Container Build

First, we need a deterministic build. Docker multi-stage builds are essential here to keep images light. Here is a stripped-down Dockerfile for a Go application:

FROM golang:1.10-alpine as builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .

FROM alpine:3.7
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/main .
CMD ["./main"]

2. The Manifests

You need your infrastructure defined as code. Do not use latest tags. In GitOps, the tag is the version control. Here is a standard deployment.yaml. Note we are using apps/v1 which finally became stable recently in Kubernetes 1.9, though many of you might still be on extensions/v1beta1 depending on your cluster version.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: production
  labels:
    app: payment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment
  template:
    metadata:
      labels:
        app: payment
    spec:
      containers:
      - name: payment
        image: registry.coolvds.com/payment:a1b2c3d
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "250m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 3
          periodSeconds: 3

3. The Sync Mechanism

You install Weave Flux into your cluster. Flux will poll your Git repo. When your CI pipeline passes tests, it builds a Docker image and commits a change to the deployment.yaml in your config repo, updating the image tag. Flux sees this and syncs.

Here is how you might configure Flux arguments in its deployment spec:

args:
  - --git-url=git@gitlab.com:your-org/infra-config.git
  - --git-branch=master
  - --git-path=workloads/production
  - --git-poll-interval=1m
  - --sync-garbage-collection=true

The --sync-garbage-collection=true flag is terrifying but necessary. It means if you delete a file in Git, Flux deletes the resource in the cluster. Total synchronization.

The Hardware Bottleneck: Why Cheap VPS Fails GitOps

This is where the theory meets reality. Kubernetes is noisy. The control plane—specifically etcd—requires extremely low latency write speeds. If fsync latency goes above 10ms, your cluster becomes unstable. Leader elections fail. Pods get evicted.

Many "budget" VPS providers in Norway oversell their storage using standard SSDs or even spinning rust (HDD) in RAID arrays with noisy neighbors. If you try to run a GitOps workflow where agents are constantly polling, diffing, and applying YAML manifests on top of an etcd cluster with high I/O wait times, you will experience timeouts.

At CoolVDS, we don't play games with I/O. We use enterprise NVMe storage exclusively.

Benchmarking Etcd Performance

Before you deploy your GitOps cluster, run fio to test if your underlying disk can handle the etcd requirements. Here is the command I use on every new node:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

On a standard shared hosting VPS, you might see 50-100 IOPS with high latency. On a CoolVDS NVMe instance, we consistently deliver the throughput required for production-grade Kubernetes. This speed is critical when you are doing rolling updates of 20 microservices simultaneously.

GDPR & Compliance in Norway

With the new privacy laws effectively in place since May 25th, 2018, data sovereignty is paramount. Hosting your GitOps repositories and your actual production workloads outside the EEA (European Economic Area) introduces complex legal hurdles regarding data transfer mechanisms.

By hosting your Kubernetes nodes in Norway (or within the EU) on CoolVDS, and keeping your Git repositories self-hosted or in EU-compliant regions, you simplify your Record of Processing Activities (ROPA). GitOps gives you the "Who" and "When" for the audit log; CoolVDS gives you the "Where".

Final Thoughts

GitOps is not just a trend; it is the industrialization of our craft. It moves us away from fragile scripts and manual intervention toward robust, self-healing systems. But software is only as good as the hardware it runs on.

Do not let storage latency be the reason your automated pipeline fails. Build your cluster on infrastructure designed for high concurrency.

Ready to stabilize your production environment? Spin up a high-performance NVMe KVM instance on CoolVDS today and start building your GitOps future.