Crane reads docker-compose.yml files. Alternatively, you can use Crane's own configuration format, which maps more closely to Docker's run command to make it even easier. The CLI interface has similar commands than docker-compose, but they differ slightly in semantics. Read the compatibility notes for more information.
Instead of detaching from all containers and interleaving the logs (like docker-compose up does), Crane attaches to the target and detaches from the dependencies by default. As a result, using interactive debugging is possible, e.g. if you are using Ruby, pry or byebug work as expected.
Instead of targeting all configured containers or a single one, Crane supports targeting a group of containers. This works by clustering containers in the configuration into groups.
Pre-define commands that you run over and over again (like running a server, tests or REPLs) in the configuration. Now they are only a crane cmd away — a perfectly streamlined Docker workflow.
Scripts can be run before or after key lifecycle events of containers. They are run synchronously on the host where Crane is installed and may even interrupt the flow by returning a non-zero status. Read more.
For example, booting a vanilla Rails app on a mid-2014 2,6GHz Macbook Pro:
| Default | > 60s |
|---|---|
With Docker :cached option |
> 15s |
| Using Crane | ~ 1.5s |
Typically, the speed gains are even higher in real-world scenarios.
Crane integrates Unison, a file synchronizer. It is executed as a container, so you don't have to install and configure anything.
Every accelerated bind-mount is synced in both ways (unlike rsync!) via a Docker volume to the mounting container.
Crane does this automatically in the background and adjusts the container config on the fly - you shouldn't even notice! Except the speed of course ...