Docker Compose is an invaluable development tool for microservices apps. If you’re working with containers, you’ll likely use it in some capacity. Whether you’re using it for orchestration or app definition (or both), Compose abstracts away the complexity and guesswork involved in container management.
What is a Docker Compose environment?
Docker Compose has built-in container orchestration for single and multi-service environments. It’s the obvious choice for setting up a local dev environment for containerized workloads: you can use it to run your Dockerized app with limited config or overhead. For example, you might use Compose to spin up the containers, see how they interact with each other, and do some simple testing.
Docker Compose for the perfect local environment
A Docker Compose environment might be more limited and less complex from what you’d use when you have cloud resources available. However, sometimes Compose’s orchestration is all you need. Compose is especially convenient during the inner dev loop, since you can spin up environments within minutes, and run them without overwhelming your laptop.
For these reasons, teams find Compose sits at a good balance between simplicity and capability. They can use it to provide build instructions/config for in-progress services, and pull prebuilt images from a container registry.
Docker Compose also takes care of basic networking between containers, and allows users to configure external networks. With Compose, you can also create custom links (aliases) between containers.
Compose excels because it has top-notch DevEx. By virtue of being so straightforward, you can spend more time developing your app instead of tweaking orchestration config. The Docker CLI has thorough logging, so fixing/improving your Compose definition isn’t a huge task.
Should I use Docker Compose for cloud environments?
When you have cloud compute at your disposal, you may want to take advantage of that. Compose is exceptional because it is so lightweight, but with the tradeoff of limited scalability. You can get more efficient (and better optimized) orchestration with a lightweight Kubernetes distro instead, which will also be closer in parity to your production environment.
At the end of the day, Compose is the clear winner for local dev, but its benefits are lost by the time you get to remote environments. Instead, you might use your Compose file as an application definition (instead of a Kubernetes manifest) for your ephemeral, staging, and production environments. We’ll get into that shortly.
K3s: lightweight, yet capable container orchestration
Rancher’s k3s distribution (named after the abbreviation of “Kubernetes” at half-length) is a lightweight alternative. Unlike stock k8s, k3s is much easier to configure and tweak. While it has fewer features, it still is pretty powerful and can be a good approximation of production orchestration, especially for intermediate-stage environments.
Sometimes, it makes sense to use k3s at the local level, but its value really shines in cloud dev environments, staging, and ephemeral environments. With a much smaller memory footprint, it’s a stellar alternative for most use cases that don’t require massive scaling, complex networks, or multi-tenant architecture.
Docker Compose to Kubernetes for preview environments
If you want to forego Kubernetes manifests altogether, you’ll save yourself the hassle of defining, tweaking, and optimizing orchestrations. Instead, you might have a compose.dev.yml and a compose.staging.yml and/or compose.prod.yml. These will be more or less similar, with varying services (perhaps debug containers instead of final-built images). This way, when something works in one environment but not another, you can narrow down the issue to the places where the config differs (or conclude that its infrastructure-related).
With a platform like Shipyard, you can get all the perks and convenience of using Docker Compose for local dev. Once you’re done iterating, Shipyard transpiles your Compose file to Kubernetes manifests, so you get production-grade orchestration for every branch-based ephemeral environment. After you merge your code changes, you can take that same (or similar) Compose file and use it for a service like AWS Elastic Beanstalk for your production deployment.
Elastic Beanstalk for Compose in production
One major benefit of Compose is that if you set up your environment workflow right, you can use Compose as your application definition throughout different environments. This prevents configuration drift and helps keep all your service definitions constant. After all, it’s much simpler to handle a couple of Compose files instead of writing custom Kubernetes manifests for every type of environment in your SDLC.
AWS Elastic Beanstalk ingests your app and Compose file, and uses that to orchestrate your application for staging or production deployments. It’s typically lauded for its ease-of-use, especially since it can harness EC2 with relatively little setup.
If you wanted a purely-Compose environment workflow, you could use Docker Compose’s native orchestration locally, Shipyard’s ephemeral environments for test/QA and/or staging, and Elastic Beanstalk for staging and/or prod.
Tying it all together
Docker Compose plays an important role in environment workflows from development to deployment. Using Compose can remove some of the lift with regards to config and orchestration, and abstract away the trickier parts of multi-container management.
Many teams who use Shipyard love Compose for its flexibility. They use it for local development, and then pass their Compose file to Shipyard to gain production-level orchestration for every PR/MR. Once they’re done iterating and testing, some use Compose as the application definition for a service like Elastic Beanstalk. If you’re looking for dev/prod parity without the hassle, sign up for a 30-day free trial.
