Merge pull request #576 from zealic/fix/docs-issue
fix ttl typo and whitespace in docs
|4 months ago|
|.github||2 years ago|
|client||2 years ago|
|commands||1 year ago|
|config||1 year ago|
|control||1 year ago|
|core||1 year ago|
|discovery||1 year ago|
|docs||7 months ago|
|events||1 year ago|
|integration_tests||1 year ago|
|jobs||1 year ago|
|scripts||2 years ago|
|subcommands||2 years ago|
|sup||1 year ago|
|telemetry||1 year ago|
|tests||1 year ago|
|version||2 years ago|
|watches||1 year ago|
|.gitignore||2 years ago|
|.travis.yml||2 years ago|
|CHANGELOG.md||1 year ago|
|CONTRIBUTING.md||2 years ago|
|Dockerfile||1 year ago|
|LICENSE||3 years ago|
|README.md||2 years ago|
|glide.lock||1 year ago|
|glide.yaml||1 year ago|
|main.go||2 years ago|
|makefile||1 year ago|
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.
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):
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 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.
Check out our “Hello, World” application on GitHub. Assuming you have Docker and Docker Compose available, it’s as easy as:
git clone email@example.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 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.
You might also read our guide building self-operating applications with ContainerPilot and look at the examples below.
We’ve published a number of example applications demonstrating how ContainerPilot works.