Docker Compose: Separation & Glue
I want to share recent insights I gained when working with docker compose more.
I will go through how docker compose is more than just a “codified” version of docker run.
You will see one reason why docker is so popular in the backend server space.
This article will take you about two minutes to read.
Introduction
Last article, I
wrote about using docker compose to codify commands into a
docker-compose.yml file.
Taking complex setup commands and putting them into a file is always a good thing. Your future self under pressure will love you.
What if you have different systems that you have to glue together to run? Say:
- database server
- web server
- all the other micro-services
Well, one solution would be to: write the Dockerfile in a way that
would build everything required into a single image and work with
that. That would be the approach I would take in vagrant.
One can take this approach and to a degree, it will work well for a local development environment.
In production, would the database server (and it’s contents!) be within a single image? If the server goes down, the application starts from scratch?
Separation & Glue
This is where docker compose comes into play in a way that is more than just “codifying docker run” commands.
docker compose lets you separate all the independent parts of your application and glue them back together, even for local development.
Examples
There are great examples of docker separating independent services, or even creating whole applications at their list of sample Docker applications page.
One I would highlight is the Ruby on Rails and Postgres DB sample.
Never Out of Date
One thing I realized when working through these examples - because of the exactness of Docker, these examples never go out of date. Docker fixes the version of Ruby on Rails and Postgres DB used in the examples. The result you create with the docker commands are the exact things the author creates, even whatever security holes pop up!
The Ruby on Rails 5 release was in 2016 and Ruby on Rails 6 release was in 2019. So, the Ruby on Rails and Postgres DB article could be two to five years old (as of this writing.)
Yet, everything works - probably just like at that time.
How often had you struggled to find the current version of an article when the software the article referenced is out of date?
Magical
There’s docker magic going on behind the scenes that I haven’t figured out yet. Such as:
- how does one image, the web server, know that
dbis the IP address of the postgres image?? - what’s the routing going on??
When building a system on vagrant, it was simple because the whole system represented a single computer. There was no separation, definitely a lot of glue.
Conclusion
I’m keeping this article short with a quick introduction to docker compose and how it can be the separation of different applications for a service and the glue for the applications of a service.
Working with others’ docker compose files has been nice because it’s the exact thing they create when they wrote the article.
There’s magic going on under the covers when connecting systems. Part of me appreciates it, another feels uneasy not knowing the mechanics of the pieces.
Even with all this magic, one can still build out their docker image just as if the system lived in a single computer, like on vagrant.
I plan on exploring docker compose more.