Define service config hash

[ndeloof]

Description
Compose "convergence" (actual vs expected state reconciliation) is based on comparing container label com.docker.compose.config-hash with current compose.yaml service definition.

This one includes some service configuration that should be ignored, like Scale and some of the deploy attributes.
Also, we need to ensure interoperability with docker-compose, so this config-hash should be define in a consistent way by both tools

[ndeloof]

docker-compose way: https://github.com/docker/compose/blob/854c003359bd07d0d3ca137d7a08509cfeab0436/compose/service.py#L705-L722

[ndeloof]

docker-compose creates hash from compact, ordered-by-key json for service config

{"image_id":"sha256:xxx","links":[],"net":"xxx","networks":{"xxx":{}},"options":{"image":"xx","mem_limit":"xx","platform":null,"ports":[[80,null,null,null,null]],"volumes":[]},"secrets":[],"volumes_from":[]}

options here is not the raw service definition from docker-compose.yaml file, but the result of cherry-picking the few supported attributes into the service_dict object. Following this would lock compose-cli to the docker-compose service_dict model.

[lukasmrtvy]

Seems its possible to calculate diff between docker-compose file and actual container created on dockerd.

docker-compose config --hash="<servicename>"

and

docker inspect <containername> -f '{{index .Config.Labels "com.docker.compose.config-hash"}}'

, but its not implemented in compose-cli yet. Is "something" similar on the roadmap ?

Related: https://github.com/docker/compose-cli/issues/1090

Thanks

[ndeloof]

@lukasmrtvy this --hash pseudo subcommand has just been introduced: #1444

Remaining issue I'm investigating is that the hash computed by docker-compose is not the same, which will trigger containers being re-created for users who use both tools together (probably because they miss some command we didn't yet implemented).

By the way, I'd be happy to hear your use-case for this command. Hash seems to me to be just internal "implementation detail". Is it just for you to guess if running app is in sync with your compose file, or compose up is required?

[lukasmrtvy]

Oh, sweet !

Comparing hashes or having some dry mode ( #1090 ) will give You a chance to decide what to do ( without actually touching containers ).

For example:

• notification webhooks ( application is not synchronized )
• execute another steps in CI for example
• etc

[novirium]

While the --hash subcommand for config/convert does now exist, and the hash scheme used is the same, the result it produces never matches the hash stored in the com.docker.compose.config-hash container label any more.

With docker-compose, it used to be possible to compare the result of docker-compose config --hash=<service name> to the config hash stored in the container label to determine if the config had been changed since the container had started, and needed recreating (to show as a status or warning).

As best as I can tell, this is due to docker compose changing the Service object in various ways before hashing it for the container label, which are not replicated before hashing it for the docker compose config --hash subcommand. For example, in some testing I found that just before the Service object is hashed either for storing in the container label (here) or comparing against that label (here), the digest of the available image has been added as a label in the Service config (here) and any relative paths have been expanded. These changes have not been made when config --hash generates it's hash, and so the two never actually match any more.

The path expansion probably makes sense, and could be added in as a step in config --hash, but I'm not sure why adding the current image digest into the Service object is necessary for detecting convergence - this digest is already stored in the com.docker.compose.image container label, and can be directly compared.

Whether it is by allowing these hashes to match, or by implementing a completely new dry run system like #8551 (though I suspect matching the hash mechanisms will be easier), providing a mechanism for external tools to determine if a container is running from an outdated config would be very useful.