Orchestrates docker-compose for large, multi-pod apps

Exec options: -d Run command detached in background --privileged Run a command with elevated privileges --user User as which to run a command -T Do not allocate a TTY when running a command

General options: -h, --help Show this message --version Show the version of cage --all-versions Show the version of cage and supporting tools -p, --project-name The name of this project. Defaults to the current directory name. --override= Use overrides from the specified subdirectory of pods/overrides. Defaults to development unless running tests. --default-tags= A list of tagged image names, one per line, to be used as defaults for images

Run cage2 in a directory containing a pods subdirectory. For more information, see https://github.com/faradayio/cage2. ```

What's a pod?

A "pod" is a tightly-linked group of containers that are always deployed together. Kubernetes defines pods as:

A pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled, and run in a shared context. A pod models an application-specific “logical host” - it contains one or more application containers which are relatively tightly coupled — in a pre-container world, they would have executed on the same physical or virtual machine.

If you're using Amazon's ECS, a pod corresponds to an ECS "task" or "service". If you're using Docker Swarm, a pod corresponds to a single docker-compose.xml file full of services that you always launch as a single unit.

Pods typically talk to other pods using ordinary DNS lookups or service discovery. If a pod accepts outside network connections, it will often do so via a load balancer.

Project format

See examples/hello for a complete example.

hello └── pods ├── common.env ├── frontend.yml └── overrides ├── development │   └── common.env ├── production │   ├── common.env │   └── frontend.yml └── test └── common.env

Development notes

Pull requests are welcome! If you're not sure whether your idea would fit into the project's vision, please feel free to file an issue and ask us.

Setting up tools

When working on this code, we recommend installing the following support tools:

sh cargo install rustfmt cargo install cargo-watch

We also recommend installing nightly Rust, which produces better error messages and supports extra warnings using Clippy:

sh rustup update nightly rustup override set nightly

If nightly produces build errors, you may need to update your compiler and libraries to the latest versions:

sh rustup update nightly cargo update

If that still doesn't work, try stable:

sh rustup override set stable

If you're using nightly, run the following in a terminal as you edit:

sh cargo watch "test --no-default-features --features unstable --color=always" \ "build --no-default-features --features unstable --color=always"

If you're using stable, leave out --no-default-features --features unstable:

sh cargo watch "test --color=always" "build --color=always"

Before committing your code, run:

sh cargo fmt

This will automatically reformat your code according to the project's conventions. We use Travis CI to verify that cargo fmt has been run and that the project builds with no warnings. If it fails, no worries—just go ahead and fix your pull request, or ask us for help.

Official releases

To make an official release, you need to be a maintainer, and you need to have cargo publish permissions. If this is the case, first edit Cargo.toml to bump the version number, then regenerate Cargo.lock using:

sh cargo build

Commit the release, using a commit message of the format:

```txt v: