Compose: How to specify Memory & CPU limit in version 3

[viveky4d4v]

I am unable to specify CPU & memory for services specified in version 3 .

With version 2 it works fine with "mem_limit" & "cpu_shares" parameters under the services . But it fails while using version 3 , putting them under deploy section doesn't seem worthy unless i am using swarm mode .

Can somebody help ?

version: "3"
services:
  node:
    build:
      context: .
      dockerfile: ./docker-build/Dockerfile.node
    restart: always
    environment:
      - VIRTUAL_HOST=localhost
    volumes:
      - logs:/app/out/
    expose:
      - 8083
    command: ["npm","start"]
    cap_drop:
      - NET_ADMIN
      - SYS_ADMIN

[jacobmischka]

I've been wondering this too. Are we just expected to stay on v2.1 if we want to use docker-compose and not swarm mode?

[shin-]

Are we just expected to stay on v2.1 if we want to use docker-compose and not swarm mode?

Yes.

[bnowakow]

Would it make sesne to make feature request to incorporate it somehow into v3.0?
My case is running WordPress in non-swarm mode. But maybe in some future I would need to scale it up using swarm. Wouldn't it make sense to have memory limiting for non-swarm mode in 3.0 is such case (and possibly others)?

[Erwyn]

I come with the same question/suggestion. Why dropping this possibility in non-swarm mode?

[shin-]

The v3 format is specifically designed to run with Swarm mode and the docker stack features. It wouldn't make sense for us to re-add options to that format when they have been replaced and would be ignored in Swarm mode. It would bloat the format and create confusion for most users.

[zoni]

@shin- you state people are expected to stay on v2 of the format if they don't want to use swarm mode. Does this mean v2 will continue to be supported and see future additions when docker engine gains new (non-swarm/stack related) options?

I'm orchestrating a large development stack using docker-compose. Memory limits keep runaway containers from crippling the system so I really don't want to lose the ability to set them. As this is just for development, I don't care about swarm and don't want to burden developers with setting up a dummy swarm cluster just to be able to set some memory limits on containers. That would be insane and counterproductive.

[shin-]

@zoni - Yes, we will continue to maintain and add to the v2 format for the foreseeable future. The hope is that in time, the v3 format + docker stack will be an equivalent or even better solution for most use-cases and that everyone will want to use it, but we know we have a long way to go until we get there.

[jeanpralo]

@shin- Thanks for that info, I think most of the passion come from that misunderstanding. Would be interesting to add a note on the documentation: https://docs.docker.com/compose/compose-file/ to state what you just noted here.

[ranomier]

Sorry. This sounds like a biiig mistake to me. I hope do not offend people here.

So why not make a key called swarm and all points under it will only considered when swarm is used.

Even cooler when someone uses something else you can do a point for that. (e.G.: kubernets)

I hope this will considered. Greetings and happy coding :)

[shin-]

That is what deploy does, literally.

[ranomier]

So only stuff under deploy is relevant to swarm?

Maybe then a "local" key or some other name for configuration without swarm.
I personally think it is a bad idea to support two version with different feature set ;)

But this is not my decision to make :)

Thank you for your quick Answer!

[shin-]

Thank you for your feedback. The evolution of the v3 format is mostly out of my hands, but feel free to contribute ideas and formal proposals on the moby/moby repo.

[chasgames]

This is crazy, why make limits on v3 a swarm-only feature? Not a good design choice.

[MarvAmBass]

would be nice to support both, I understand that everything beneath deploy is swarm configuration.

but to be able to test something in a smaller environment, e.g. a developers laptop than it would be nice to have the old parameters still available.

makes it easier than maintaining two versions of the compose file just because of a few differencies...

[andyliddle]

Shouldn't V3 be backwards compatible?

Not everyone want to use docker stack just yet

[paulkitt]

Are we just expected to stay on v2.1 if we want to use docker-compose and not swarm mode?

Yes.

Why you don't mention this in the docu wiki? Its super frustrating to read github issues to distinguish which docker-compose version is the right one for running non swarm containers!

According to the compose referende: Version 3 (most current, and recommended)
This implies for me that I should use this version for swarm and non-swarm containers...

[aldarund]

This is wrong. For example i want to use restart: unless-stopped and memory limit. But right now i cant do it, because memory-limit only in v2 and unless-stopped only in v3...

[ffelixneto]

"This is wrong. For example i want to use restart: unless-stopped and memory limit. But right now i cant do it, because memory-limit only in v2 and unless-stopped only in v3..."

[iget-esoares]

Why don't just make deploy memory limits work as v2 if not in swarm?

[lalitprasanth]

I am using swarm mode for scalability and having large number of micro services i am using compose file as well. But unable to restrict memory usage of each container and every container is taking complete memory of the server. This will lead to server down when load hits any one container. If memory limits were enabled that particular container will be killed or per container we can scale them when load reach particular threshold.

[egee-irl]

The v3 format is specifically designed to run with Swarm mode and the docker stack features.

Why on earth isn't this _specifically_ stated in the documentation? I lost an hour trying to figure out why I couldn't adjust the resource usages from my container with Docker-Compose.

Edit - I am aware it it called out in a subsection here, it it should be at the top of the documentation or somewhere easier to find, especially considering the number of negative reactions on this thread.

[natesire]

Got to be frank. This is breaking backwards compatibility. A big no no when dealing with DevOps and Systems Admins. I love Docker. Now I have to go learn what swarm mode is since I'm being forced to use it.

[ffelixneto]

I using now all engines with swarm initializated and v3 compose to deploy limits when I need. In other cases just leave the tags be ignored. ;)

[shin-]

@nathantech2005 The whole point of major versions is that they're allowed to break compatibility. And nobody is forcing you to use Swarm mode?

[stevenklar]

For the sake of testing and similiarity it is necessary to limit/reserve memory and cpu when developing localy with docker-compose and deploy to a swarm cluster with docker stack deploy.

I guess the problem is that docker-compose run container and does not make use of docker services. Otherwise this might has been implemented earlier. Am I wrong?

Is there any plan on implementing it? Because this is a clear no go for docker-compose v3 in our development and swarm configuration.

[ylavoie]

v3 allows running in swarm mode or not, so it was obviously intended to provide an upgrade path for v2. Denying memory control because of swarm doesn't make sense.

Either allow it or remove the non-swarm mode in v3 but be coherent.

[billnbell]

And I vote for adding memory options in v3 without swarm. Why not? Everyone wants it.

[kurankat]

I also wasted plenty of time trying to work out why this broke when upgrading my compose scripts from Version 2 to Version 3. I doubt this affects only a tiny proportion of users: there are many use-cases in which using compose makes more sense, like single-server deployments.
It makes no sense to not support CPU and memory limits in Version 3, given that this is the officially recommended version for general use.

[Elzor]

I think for development environments mem_limit option is really necessary.

[dfedorov-ciena]

Guys, all your thumb ups and opinions clearly don't matter to Docker, you forget that the golden rule of open source projects is "my way or you fork and do it yourself", don't be naive and don't waste your thumbs.

[alexandruionica]

Official documentation at https://docs.docker.com/compose/compose-file/compose-versioning/says:

Version 3 (most current, and recommended)

and

Version 3.x, the latest and recommended version, designed to be cross-compatible between Compose and the Docker Engine’s swarm mode.

I've set to bold relevant sections.

Anyway further down the same page we do get to:

Designed to be cross-compatible between Compose and the Docker Engine’s swarm mode, version 3 removes several options and adds several more.

• Removed: volume_driver, volumes_from, cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit, extends, group_add . See the upgrading guide for how to migrate away from these.

Oh awesome, I can upgrade to v3 and still benefit from the same mem_limit and other features while probably using new keywords . This makes sense given cross-compatible was part of the design.

https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

• cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit: These have been replaced by the resources key under deploy. deploy configuration only takes effect when using docker stack deploy, and is ignored by docker-compose

Now I expected that under https://docs.docker.com/compose/compose-file/#resources I will be informed how to keep the functionality but use new keywords

Looking for options to set resources on non swarm mode containers?
The options described here are specific to the deploy key and swarm mode. If you want to set resource constraints on non swarm deployments, use Compose file format version 2 CPU, memory, and other resource options.

So much for cross compatibility. It's cross compatible as long as you're willing to give up key functionality.

I think you should remove from the documentation of version 3 the mentions of cross-compatible given that it's clearly not cross-compatible and there is no upgrade path if you don't want to use swarm mode.

[shin-]

Everyone,

I appreciate the impassioned feedback ; please note that we're addressing this in #5684

[chasgames]

The --compatibility CLI flag, like you say, should not be relied on for production and a "best effort".

Does this mean we still can't use v3 with mem_limits for production unless we use swarm?

Would it not be easier to restore v2 functionality? it would definitely make me happier!

[shin-]

@chasgames v3 is designed to work with Swarm mode ; if you are using v3 in production, it should be with Swarm mode (and in the future, Kubernetes). The point of --compatibility is to give things like mem_limit to developers without requiring them to create a Swarm/k8 cluster on their local machine, while using the same Compose file that'll be used to deploy the app in production.

If your entire workflow currently uses docker-compose, then version 2.3 is a much better format to work with.

[edward2a]

I honestly don't understand what is the point of not supporting swarm configs in standard execution.
Using and older and non recommended version makes no sense.

Having two config schemata that provide the same functionality for different use cases via different mappings makes even less sense as it breaks the upgrade path.

A __consolidated v3__ that will use the swarm style configs in standard compose mode would make much more sense, and would provide an upgrade path which also allows easy use and testing of the config itself. Swarm options that are not utilised in compose should be easily ignored.

Using a compatibility mode as described in #5684 will only increase complexity, extend the agony of supporting two (or more) schemata that ultimately do the same, add (more) confusion and continue to annoy __my__ existence as well as anyone else's as this and multiple other issues demonstrate.

Either way, compose is a very handy tool despite the setbacks.

[shin-]

1. deploy options don't map 1-to-1 to container configurations
2. v2 is not technically older (v2.3 was introduced around the same time as v3.4)
3. The two versions serve different purposes. We recommend v3 in our documentation because it is better suited to deploying distributed applications.

This is just circling back to the same points again, so I'll lock this thread. If you want to keep discussing v2/v3 disparity and Compose format design, please use the forums.