How to Automate Microservice Deployment with Consul, HAProxy, and Docker

Preface

Microservice architecture advocates splitting a single application into a set of small, independently deployable services that communicate via lightweight mechanisms. Each service is built around specific business functionality and can be deployed to production or staging environments independently.

Combined with modern service discovery and infrastructure‑as‑code, we can automate load balancing, service discovery, and containerization to achieve end‑to‑end business chain automation.

Background

Previous platform architecture suffered from resource contention, complex deployment steps, and static configuration that caused high coupling and manual effort.

In non‑cloud environments, mixing workloads to save resources led to interference between services and limited isolation.

Each business required a separate set of resources, resulting in 10‑15 manual steps for service rollout or rollback.

Static configuration meant that any change in service A required notifying dependent service B, increasing maintenance cost.

These issues manifested as frequent service outages, manual recovery, and low automation.

New Ideas and Improvements

Containerized deployment: Define CPU, memory, and disk parameters programmatically and create Docker containers in bulk, improving resource utilization.

Service discovery: Use Consul’s DNS‑based service discovery to automatically register containers and resolve service-name:port instead of static ip:port, enabling rapid service recovery.

What Is Service Discovery?

In a distributed microservice system, a registry is needed to announce available services and nodes, and a discovery mechanism is required to locate them. Service discovery components store information about all services and provide features such as metadata storage, health checks, and real‑time updates.

Consul Introduction

Consul is an open‑source, multi‑datacenter, highly available tool for service discovery and configuration sharing. Its main use cases are service discovery, service segmentation, and configuration management.

Multi‑datacenter

Service discovery

Health checks

Key/Value store

Runtime templating (Consul Template)

Web UI

Consul Service Discovery

Uses HTTP and DNS to simplify cross‑infrastructure service connections.

Switches communication from ip:port to domain:port.

Service changes are reflected in real‑time DNS updates.

Provides health checks, heartbeats, and customizable features.

Consul Service Configuration

All data in a Consul cluster is shared; any node can retrieve the latest information. Templates can render configuration files from KV data, enabling real‑time updates.

# For example:
{{ range tree "service/redis" }}
{{ .Key }}:{{ .Value }}{{ end }}
# renders
minconns 2
maxconns 12
nested/config/value "value"

Service‑based rendering example:

# For example:
{{ range service "web" }}
server {{ .Name }} {{ .Address }}:{{ .Port }}
{{ end }}
# renders
server web01 10.5.2.45:2492
server web02 10.2.6.61:2904

Operational Changes Enabled by Consul

Dynamic service registration and health checks provide strong scalability and prevent interruptions during frequent service replacements.

Configuration files are managed automatically without manual CMDB updates, adapting instantly to business changes.

Transitioning from Traditional to Microservice Architecture

HAProxy serves as a unified external entry point. Backend services are referenced by Consul domain names, allowing HAProxy to forward traffic based on dynamic DNS resolution.

HAProxy Dynamic DNS Resolution

When containers are created or destroyed, Consul updates the associated domain’s IP address, and HAProxy automatically re‑resolves the DNS, ensuring traffic is always routed to the current service instance.

resolvers consuldns
    nameserver dns1 127.0.0.1:53
    resolve_retries 200
    timeout retry 1s
    hold valid 10s

Frontend configuration for traffic isolation:

# Custom service listening logic
frontend serverA
    balance leastconn
    cookie JSESSIONID prefix
    bind 0.0.0.0:1000 accept-proxy
    capture request header Host len 128
    option httplog
    log-format %si:%sp %ci %ft %hrl %r %ST %B %Tt
    acl host_hostname1 hdr_dom(host) -i a.test.com
    acl host_hostname2 hdr_dom(host) -i b.test.com
    use_backend hostname1 if host_hostname1
    use_backend hostname2 if host_hostname2

Backend definition using Consul DNS:

# Dynamic backend resolution via Consul
backend hostname1
    server hostname1 a.service.consul:1000 resolvers consuldns maxconn 50000 check inter 2000 rise 2 fall 100
backend hostname2
    server hostname2 b.service.consul:1000 resolvers consuldns maxconn 50000 check inter 2000 rise 2 fall 100

Web Configuration Auto‑Management

Consul KV watch triggers automatic configuration updates and reloads when services come online or go offline.

# Watch KV changes and execute a script
consul watch -type=key -key=your_key /path/to/script.sh
# Render config with consul‑template and reload HAProxy
consul-template -consul-addr 127.0.0.1:8500 -template "ha.conf.ctmpl:ha.conf:HA reload"

Backend Service Auto‑Registration

Cloud instances self‑initialize, register themselves with Consul, and automatically receive traffic.

# web_service.json
{
  "service": {
    "name": "web",
    "port": 80,
    "id": "web",
    "address": "10.1.1.1",
    "check": {
      "id": "web",
      "name": "tcp",
      "tcp": "10.1.1.1:80",
      "interval": "60s",
      "timeout": "30s"
    }
  }
}

DNS query example after registration:

# nslookup web.service.consul
Server: 127.0.0.1#53
Name:   web.service.consul
Address: 10.1.1.1
Name:   web.service.consul
Address: 10.1.1.2
Name:   web.service.consul
Address: 10.1.1.3

Summary

By combining Docker, Consul, and HAProxy, we achieve high scalability, stability, and near‑full automation of the deployment pipeline, including service registration, dynamic configuration, automatic releases, self‑healing, and reduced manual intervention.

Service dependency decoupling

Dynamic configuration updates

Automated product releases

Self‑healing services

Simplified workflow and reduced middle layers

Reduced reliance on HAProxy through dynamic DNS

Improved resource utilization via cloud infrastructure

Eliminated ~90% of manual processes

Overall, the approach demonstrates a cloud‑native, automated microservice ecosystem suitable for large‑scale game operations.

Source: 网易游戏运维平台 – Author: 丁易锋, Senior Operations Engineer at NetEase Games.