A Docker Compose Override File Can Help Avoid Compose File Duplication

Use the same Docker Compose file in development and production but still run different services.

Hit the subscribe button to receive more videos like this!

---

Timestamped Table of Contents:

0:00 -- What we'll cover in this video
0:41 -- Comparing a regular Docker Compose YAML file to an override file
2:10 -- Seeing how the Docker Compose override file works in practice
3:48 -- The example file lets you ignore the real override file from version control
5:58 -- The override file works great for Webpack and managed databases
7:18 -- This pattern lets you re-use a single Compose file in dev and production

Reference links:

---

Follow along?

[khalidal-awady]

Our devops guy left and I've been trying to figure out all the stuff he did. Thanks for the explanation this really helps out a lot

[iMaxos]

I earlier looked at the documentation of docker-compose for the override file and finally opted to have a prod file instead because I wasn't quite getting the gist of it. Thanks for the video. clear as water

[nnutipa]

Didn't know about it. Amazing thing! Thanks!

[JohnMitchellCalif]

that's super useful! It's really easy for Dev-mode and Production-mode systems to be completely different... which means it's harder/slower to get working code deployed into prod. Using overrides makes it easier to be production-centered. Thanks!

[dawid_dahl]

I'm going to use this for work. Thank you so much!

[ralphotowo]

Thanks for sharing. It'll be amazing if I could also have the webpack service in the docker-compose.yml file and override it from the docker-compose.override.yml file. That way I have a single docker-compose.yml file with everything needed to deploy to production, but can throw in an override file if I need to use it in a different environment. I'll try this out.

[markokraljevic]

you didnt explain how to override specific keys within a service