Otherwise if you ever need to do a rollback or post mortem or similar you have to figure out what commit out of the 20 different projects was actually being used at the time.
Of course that comes at a cost and there are other ways to get the same benefit, but my experience is that this is an easy way to keep things consistent.
- much less admin, don’t need to maintain/update so many repos
- easier to coordinate changes between systems at the same time
- everything is on a single version of each library - you don’t have some services on one version, some on another, etc
Benefits of having a single Docker image:
- much faster (overall) build times - doing everything in one go is way faster than doing each one individually
- much faster deployment - only have to download the image once per host, rather than many variations
- most services have a similar set of the same base dependencies, so reduces duplication
- overall the difference in image size between including one service and including all of them is probably only 5-10MB anyway
Those are just the things which immediately come to mind. There are probably many others.
Image layers are immutable and get deduplicated/cached individually when stored or sent over the network. For example if you pull 10 images with a common base to the same host, the first image might be slow to download but after that docker only fetches the deltas between it and the rest.
Has been particularly interesting to balance the different languages in the same repo. Few painful bits, but overall has worked out really well.
We also build the entire thing into a single Docker container containing every service. You just start the particular one you want via the command (the entrypoint is a little shell script to invoke the correct executable).