Docker
I’ve enjoyed using Docker for my projects for these reasons:
- Various projects on my system have varying dependencies (such as Nokogiri), and ensuring all of my projects are always in a working state has been problematic for me in the past.
- Upgrading or moving to a new computer is always a pain. Getting a new Macbook Pro was always a double-edged sword. For one thing, getting a faster processor and more RAM would be a huge win. But having to re-install everything to get my Rails app working again so I can keep development moving was never fun. Dockerizing my projects has let me avoid this pain.
- I can run locally against multiple versions of databases like Mongo or Postgres. I can even run a cluster to make sure my configuration for these services are setup right.
- I can test out different versions of dependencies quickly within a container without worrying about messing up my development environment: just rebuild if the new version doesn’t work.
- Having explicit versions for production images lets me think about releases as discrete artifacts that can be communicated with my team about. Debugging can be done with a image that can be run in different environments.
- Getting CI running is fairly trivial with Docker Compose.
- Once an image has been stabilized, I can use it to speed up CI runs
- I’ve sped up my personal blog’s deployments from 6 minutes to 1 minute.
- A production image contains all the correct dependencies I need to run it, including system libraries.
- Rollbacks for images with changes to system dependencies becomes trivial.
- Developers can work in different platforms rather than forcing the team to only one OS. This works if the team decides to only develop within containers.
- Onboarding new developers to the team becomes much simpler. That long README of steps to provision the dev environment becomes:
- Install Docker
- Pull repo
docker-compose up
Did you find this helpful? Get updates when I post more like this by subscribing to the Nerd Tower newsletter.