Docker Compose is a tool to manage multi-container docker applications running on a single host just by configuring a YAML file. it allows the management of multiple docker isolated environments, networks, and information volumes.
Docker Compose is a good fit for single-host deployment, development, and automated testing environments. PaaS, SaaS, and IaaS providers like; Heroku, Amazon Web Services, and Digital Ocean, among others, encourage its usage for local development.
The Architectural Journey
This chapter analyzes Docker Compose from an architectural perspective; Exploring source code, documentation, and people interaction.
Our journey will start at sea level, looking into the product vision. From there, we do a full descent, traveling to architecture, going deeper into code, and at 10.000 meters depth analyze configuration, collaboration, sustainability, and any insightful discovery during this journey.
- Andrea Nardi
- Kanya Paramita Koesoemo
- L.C Guerchi
- Manisha Sethia
Docker Compose is an orchestration tool that manages multiple docker containers in a single application, allowing the running of application components in isolated environments without unnecessary complexities. Compose automates the building, deploying and running of the docker containers allowing engineers to develop and deploy without building, dependencies, and compatibility issues. Compose achieves such isolation using container-based technology which allows a lower CPU and memory overhead compared to hypervisors and virtual machines.
We analyze the integration process, code quality, test coverage, and how this is facilitating the roadmap of Compose. Then, we delve a bit deeper into technical debt and refactoring solutions of newer features and the entire system as a whole. Overall, Compose system has an organized and aligned development process with high test coverage. However, there’s much improvement and refactoring needed on the code quality and entanglement itself.
Until now, we analyzed Docker Compose from various traditional software engineering dependencies stand points (development view, runtime view, operations view). This does not give us a full perspective of the architectural structure of the project.