README
¶
ContainerPilot
An init system for cloud-native distributed applications that automates the process of service discovery, configuration, and lifecycle management inside the container, so you can focus on your apps.
What is ContainerPilot?
Orchestration is the automation of the operations of an application. Most application require operational tasks like connecting them to related components (WordPress needs to know where it's MySQL and Memcached servers are, for example), and some applications require special attention as they start up or shut down to be sure they bootstrap correctly or persist their data. We can do all that by hand, but modern applications automate those tasks in code. That's called "orchestration."
To make this work, every application needs to do the following (at a minimum):
- Register itself in a service catalog (like Consul or Etcd) for use by other apps
- Look to the service catalog to find the apps it depends on
- Configure itself when the container starts, and reconfigure itself over time
We can write our new applications to do that, but existing apps will need some help. We can wrap each application in a shell script that registers itself with the discovery service easily enough, but watching for changes to that service and ensuring that health checks are being made is more complicated. We can put a second process in the container, but as soon as we do that we need an init system running inside the container as well.
ContainerPilot to the rescue!
ContainerPilot is an init system designed to live inside the container. It acts as a process supervisor, reaps zombies, run health checks, registers the app in the service catalog, watches the service catalog for changes, and runs your user-specified code at events in the lifecycle of the container to make it all work right. ContainerPilot uses Consul to coordinate global state among the application containers.
Quick Start Guide
Check out our "Hello, World" application on GitHub. Assuming you have Docker and Docker Compose available, it's as easy as:
git clone git@github.com:autopilotpattern/hello-world.git
cd hello-world
docker-compose up -d
open http://localhost
This application blueprint demonstrates using ContainerPilot to update Nginx upstream configuration at runtime. Try scaling up via docker-compose scale hello=2 world=3 to see the Nginx configuration updated.
You can also download the latest release of ContainerPilot from GitHub.
Documentation
Documentation for ContainerPilot and where it fits with the rest of the Triton ecosystem can be found at www.joyent.com/containerpilot. The index below links to the documentation in this repo for convenience.
- What is a job?
- What is an event?
- What is a watch?
- How do events trigger jobs?
- How can jobs be ordered?
Design: the Why of ContainerPilot
- Why active service discovery?
- Why isn't there a "post-start" or "started" event?
- Why Consul and not etcd or Zookeeper?
- Why are jobs not the same as services?
- Why don't watches or metrics have an exec field?
- Why use something other than ContainerPilot?
Configuration
- Installation
- Configuration file
- Consul
- Jobs
- Watches
- Telemetry
- Control plane
- Logging
- Example configurations
You might also read our guide building self-operating applications with ContainerPilot and look at the examples below.
Examples
We've published a number of example applications demonstrating how ContainerPilot works.
- Applications on autopilot: a guide to how to build self-operating applications with ContainerPilot
- MySQL (Percona Server) with auto scaling and fail-over
- Autopilot Pattern WordPress
- ELK stack
- Node.js + Nginx + Couchbase
- CloudFlare DNS and CDN with dynamic origins
- Consul, running as an HA raft
- Couchbase
- Mesos on Joyent Triton
- Nginx with dynamic upstreams
Documentation
¶
Overview ¶
ContainerPilot is an init system for cloud-native distributed applications that automates the process of service discovery, configuration, and lifecycle management inside the container, so you can focus on your apps.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
Package client provides a HTTP client used to send commands to the ContainerPilot control socket
|
Package client provides a HTTP client used to send commands to the ContainerPilot control socket |
|
Package commands provides a wrapper around os/exec to consistently manage process execution, cancellation of their child processes, timeouts, logging, arg parsing, and correct shutdown.
|
Package commands provides a wrapper around os/exec to consistently manage process execution, cancellation of their child processes, timeouts, logging, arg parsing, and correct shutdown. |
|
Package config is the top-level configuration parsing package
|
Package config is the top-level configuration parsing package |
|
decode
Package decode contains helper functions for turning mapstructure interfaces into simpler structs for configs
|
Package decode contains helper functions for turning mapstructure interfaces into simpler structs for configs |
|
logger
Package logger manages the configuration of logging
|
Package logger manages the configuration of logging |
|
services
Package services contains miscellaneous configuration validation for service names and IP addresses registered with Consul
|
Package services contains miscellaneous configuration validation for service names and IP addresses registered with Consul |
|
template
Package template provides rendering for the configuration files and the extra functions for use by the golang templating engine.
|
Package template provides rendering for the configuration files and the extra functions for use by the golang templating engine. |
|
timing
Package timing provides functions for parsing time configurations into time.Duration instances
|
Package timing provides functions for parsing time configurations into time.Duration instances |
|
Package control provides a HTTP server listening on the unix domain socket for use as a control plane, as well as all the HTTP endpoints.
|
Package control provides a HTTP server listening on the unix domain socket for use as a control plane, as well as all the HTTP endpoints. |
|
Package core contains the main control loop.
|
Package core contains the main control loop. |
|
Package discovery manages the configuration of the Consul clients and the functions used to update/query Consul with service discovery data.
|
Package discovery manages the configuration of the Consul clients and the functions used to update/query Consul with service discovery data. |
|
Package events contains the internal message bus used to broadcast events between goroutines representing jobs, watches, etc.
|
Package events contains the internal message bus used to broadcast events between goroutines representing jobs, watches, etc. |
|
Package jobs manages the configuration and execution of the jobs
|
Package jobs manages the configuration and execution of the jobs |
|
Package subcommands provides all the alternative top-level functions that run one-off commands that don't run the main event loop.
|
Package subcommands provides all the alternative top-level functions that run one-off commands that don't run the main event loop. |
|
Package sup provides the child process reaper for PID1
|
Package sup provides the child process reaper for PID1 |
|
Package telemetry provides a Prometheus client and the configuration for metrics collectors
|
Package telemetry provides a Prometheus client and the configuration for metrics collectors |
|
Package version only provides some package variables set at build time
|
Package version only provides some package variables set at build time |
|
Package watches manages the configuration and running of Consul service monitoring
|
Package watches manages the configuration and running of Consul service monitoring |