Unified Deployment Orchestration (Nomad + Consul)
Project information
- Category: DevOps
- Client: INSTAR Deutschland GmbH (Waletech) Shenzhen, China
- Project date: 01 Feb, 2020
- Project URL: www.nomadproject.io
The problem: deployments across a growing bare-metal + VPS fleet were manual, inconsistent, and untracked.
What I did: First the honest evaluation — Ansible/Tower, Salt, Kubernetes, and Nomad on the table. We chose Nomad for its lean footprint (install only what a workload needs), and it made the rest easy: an existing Dockerfile re-parses into a job file and you inherit the orchestration. Today the platform spans **6+ namespaces, 6+ node pools, and 10+ datacenters**, each isolated with its own policy — and every deployment is a documented, versioned job file, not a runbook.
Security is baked in, not bolted on. A cfssl-generated CA enforces mTLS between the server and every client with encrypted Serf gossip, and a per-namespace Sentinel policy grants least-privilege: the cloud team's token can `submit-job` and `scale-job` in `cloud` but is denied in `wiki-search` or `tickets`. Containers spin up, self-heal, and roll back — canary-first deploys gated on a health check, `auto_revert` on failure, replace the old manual SSH rollouts. Consul provides service discovery and health-checking, so services find each other across data centres without hard-coded IPs: an nginx upstream reads the Consul catalog and re-renders automatically as backends come and go. Consul-template drives the remaining templating, including cross-data centre certificate renewal. Onboarding a new team to the platform went from a multi-day manual process to a single job-file PR.
The payoff: one orchestration layer every engineering team actually uses.