Stop trying to manage Docker with SSH loops
It is August 2015, and we need to have a serious talk. If I see one more deployment script that is just a glorified BASH for loop iterating through a list of IP addresses to run docker pull, I am going to revoke your sudo access. We passed the "Does Docker work?" phase last year. Now we are in the "How do I keep this alive across 20 servers without losing my mind?" phase.
Container orchestration is the only way forward. But right now, the landscape is a mess of competing standards. You have the "native" camp, the "Google" camp, and the "Twitter scale" camp. I have deployed all three on our infrastructure this month. Here is the unvarnished truth about what works, what breaks, and what you need to run them effectively in a Norwegian production environment.
The Contenders: Swarm vs. Kubernetes vs. Mesos
1. Docker Swarm (The Native Choice)
Swarm is currently the easiest entry point because it speaks the Docker API natively. If you can run commands on a single host, you can run them on a Swarm. It aggregates your pool of engines into a single virtual engine.
The Good: Zero learning curve if you know the Docker CLI. It integrates perfectly with Docker Compose.
The Bad: It is still young (beta). Scheduling logic is simplistic. It treats your cluster like one big machine, which is great until a network partition splits your brain.
2. Kubernetes (The Google Way)
Google released version 1.0 last month. Everyone is talking about it. Kubernetes (K8s) takes a different approach. It doesn't just manage containers; it manages "Pods"—groups of containers that share an IP and storage.
The Good: Self-healing is real. If a node dies, K8s reschedules the pods elsewhere automatically. The concept of Services and ReplicationControllers is powerful for maintaining state.
The Bad: Complexity. Setting up etcd clusters, the API server, the scheduler, and the kubelet on every node is a headache compared to a simple docker run. The learning curve is a vertical wall.
3. Apache Mesos + Marathon (The Enterprise Heavyweight)
If you are running a cluster with 10,000 nodes, use Mesos. It abstracts CPU, memory, storage, and other compute resources away from machines, enabling fault-tolerant and elastic distributed systems.
The Verdict: Unless you are Twitter or Airbnb, this is likely overkill. The operational overhead to maintain a Zookeeper quorum and Mesos masters for a simple web app is hard to justify for most SMEs.
The Hidden Bottleneck: Overlay Networks & Disk I/O
Here is the war story. Last week, we tried to deploy a MongoDB replica set inside containers across three nodes using Weave for the overlay network. Performance tanked. Why? Because encapsulation adds latency.
When you wrap packets inside packets, you increase CPU load and decrease throughput. If your underlying VPS is already fighting for CPU time or struggling with noisy neighbor I/O, your fancy container cluster will crawl. Orchestration layers like Kubernetes are chatty. They constantly health-check via API calls.
Pro Tip: Check your iowait. If you are seeing high wait times on your current host, do not blame Docker. Blame the spinning rust (HDD) underneath it. Databases inside containers require SSDs. Period.
Configuration Matters
Whether you use Swarm or K8s, you need to tune your Linux kernel. Most default distros like CentOS 7 or Ubuntu 14.04 aren't tuned for thousands of containers and virtual interfaces.
Add this to your /etc/sysctl.conf to handle the network load:
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
fs.file-max = 100000
Why Infrastructure Choice is Critical
Many legacy VPS providers in Norway are still selling OpenVZ containers. You cannot run Docker properly inside OpenVZ. It requires a kernel version (3.10+) that many old OpenVZ nodes don't support, and you can't load kernel modules required for overlay networks.
You need KVM (Kernel-based Virtual Machine) virtualization. This provides the isolation of a dedicated server with the flexibility of the cloud. This is where CoolVDS becomes the logical reference implementation. We don't mess around with overselling resources.
- KVM Standard: Every CoolVDS instance is KVM-based, meaning you can install your own kernel, run Docker, CoreOS, or even compile your own modules.
- Pure SSD Storage: When five containers try to write logs simultaneously, SATA drives choke. We use enterprise SSDs to keep I/O latency negligible.
- Local Latency: If your customers are in Oslo or Bergen, hosting in Frankfurt or Virginia adds 30-100ms of round-trip time. CoolVDS offers low latency right here in the Nordics, which is critical for synchronous replication in databases.
Data Sovereignty and The Personal Data Act
With the recent focus on data privacy (following the Snowden leaks), storing customer data outside of Norway is becoming a legal minefield under the Personopplysningsloven. Datatilsynet (The Norwegian Data Protection Authority) is watching closely. Running your Kubernetes cluster on US-owned infrastructure might rely on Safe Harbor frameworks, but for how long? Hosting locally on CoolVDS removes that ambiguity.
Final Thoughts
If you are just starting, grab a CoolVDS KVM slice, install Docker Compose, and keep it simple. If you are scaling up, look at Kubernetes, but ensure your underlying metal can handle the churn.
Don't let IOPS wait times kill your application. Deploy a high-performance KVM instance on CoolVDS today and build a cluster that actually stays up.