4 ms·
Because we want to make sure that in the Docker registry we have _all_ services tagged with the latest commit. For example you might have a Git history like th
by dhinus 9y ago
Because we want to make sure that in the Docker registry we have _all_ services tagged with the latest commit.
For example you might have a Git history like this:
* 89abcde Fix bug in service_b
* 1234567 Initial commit including service_a and service_b
When 89abcde is pushed, the CI rebuilds both service_a and service_b so we can simply "deploy 89abcde" and you always have only one hash for all services, that is also nicely the same hash of the corresponding Git commit.
The trick to avoid rebuilding perfectly working services is to use Docker layer caching so that when you build service_a (that hasn't changed) Docker skips all steps and simply adds the new tag to the _existing_ Docker image. The second build for service_a should take about 1 second.
In our Docker registry we end up with:
service_a:1234567
service_a:89abcde
service_b:1234567
service_b:89abcde
But the two service_a Docker images are _the same image_, with two different tags.
- segmondy 9y agoWhy? Microservices are suppose to be truly independent.
- dhinus 9y agoFor ease of deployment and to solve the problem of "what version of service_b is compatible with version x of service_a"? IMHO this makes sense if the microservices are developed by the same team. If we're talking about services developed and managed by different teams... maybe it's not a good idea.