Compose: Compose v3 warning for deploy key on non-Swarm

[taiidani]

When using Docker Compose on local with a v3 docker-compose.yml file that has a deploy key set in one of its services, we get the following warning emitting on a number of commands:

`WARNING: Some services (queue_crawler) use the 'deploy' key, which will be ignored. Compose does not support deploy configuration - use `docker stack deploy` to deploy to a swarm.

Is there a way to mute this warning?

Use cases

Dev/Prod parity

We are trying to use the YML file on local to communicate changes to the DevOps team which, at the moment, maintains a separate YML file. Having deploy declared at the development level is the perfect way for specifying these attributes such as the number of replicas to run. As a poor man's workaround right now we must use comments which DevOps reads and applies manually to the production configuration.

# Queue workers for crawlers. 3 workers are run in Production

Ad-hocs in Production

We get the same warning in production any time we run a cron. Our cron setup uses a docker-compose run command off the same file which docker stack deploy used so that we have consistency between the two behaviors.

At the moment we have no workaround for this. We get the warning output at the top of all of our cron runs, and it propagates into our log aggregator.

[shin-]

It's a warning. Why is this an issue?

[taiidani]

Sorry, should I be submitting the request in another format other than a GitHub issue? The appearance of the warning every time our developers run a Docker Compose command (or every time our crons run) gets very loud, especially when we're scripting Docker Compose, and causes us issues.

I guess script wise we could just | sed the warning out of our logs and tell our developers to ignore the warning spam, but I was hoping for a cleaner suggestion from the project maintainers. Is there an alternative practice to follow, or a setting where we can indicate that we're aware there's an ineffective deploy key but still want to use that YML file?

[shin-]

Sorry for the terse response - I was trying to get a feeling of whether there was another issue that was making it seem like the warning was preventing the software from working properly. Thank you for taking the time to clarify.

There is currently no way to hide this. I'm wary of letting users selectively remove warnings from their output because it can very easily obscure problems going forward when trying to debug or troubleshoot applications.

One way to mitigate the issue would be to isolate the deploy keys in a separate docker-compose.deploy.yml file that can be combined with the base file when needed. See the docs on that subject.

[taiidani]

So you're suggesting maintaining separate docker-compose.yml and docker-compose.prod.yml files? That should work to eliminate the warning on local, and we should be able to jigger that into our cron logic as well.

For the deployment side it will require us to maintain two completely populated files. I don't think docker stack deploy supports the extending feature that Compose has ala -f file1.yml -f file2.prod.yml. That's an inconvenience we can manage, and for that matter an issue for the docker/docker repo, not the docker/compose repo.

Thanks!

[shin-]

For the deployment side it will require us to maintain two completely populated files. I don't think docker stack deploy supports the extending feature that Compose has ala -f file1.yml -f file2.prod.yml. That's an inconvenience we can manage, and for that matter an issue for the docker/docker repo, not the docker/compose repo.

You could generate that file automatically at deployment time with the ouput of docker-compose -f file1.yml -f file2.prod.yml config, if that helps.

[taiidani]

Hmm, that's a great idea! Although it might not bring over what we need?

# docker-compose.yml
version: '3.1'

services:
  test:
    image: busybox

# docker-compose.prod.yml
version: '3.1'

services:
  test:
    deploy:
      replicas: 2

Results in:

rnixon$ docker-compose -f docker-compose.yml -f docker-compose.prod.yml config
networks: {}
services:
  test:
    image: busybox
version: '3.1'
volumes: {}

It looks like the deploy key got stripped out?

[shin-]

Oh, yeah - it will be fixed in 1.12.0. #4669. Sorry about that!