New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to specify Memory & CPU limit in version 3 #4513

Closed
viveky4d4v opened this Issue Feb 20, 2017 · 36 comments

Comments

Projects
None yet
@viveky4d4v

viveky4d4v commented Feb 20, 2017

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

This comment has been minimized.

jacobmischka commented Feb 20, 2017

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-

This comment has been minimized.

Member

shin- commented Feb 21, 2017

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

Yes.

@shin- shin- added the kind/question label Feb 21, 2017

@bnowakow

This comment has been minimized.

bnowakow commented Feb 25, 2017

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

This comment has been minimized.

Erwyn commented Mar 8, 2017

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

@shin-

This comment has been minimized.

Member

shin- commented Mar 8, 2017

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

This comment has been minimized.

zoni commented Mar 18, 2017

@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-

This comment has been minimized.

Member

shin- commented Mar 27, 2017

@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

This comment has been minimized.

jeanpralo commented Mar 28, 2017

@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

This comment has been minimized.

ranomier commented Jun 7, 2017

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-

This comment has been minimized.

Member

shin- commented Jun 7, 2017

That is what deploy does, literally.

@ranomier

This comment has been minimized.

ranomier commented Jun 7, 2017

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-

This comment has been minimized.

Member

shin- commented Jun 7, 2017

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.

EnTeQuAk added a commit to mozilla/addons-server that referenced this issue Aug 10, 2017

@chasgames

This comment has been minimized.

chasgames commented Sep 5, 2017

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

@MarvAmBass

This comment has been minimized.

MarvAmBass commented Sep 21, 2017

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

This comment has been minimized.

andyliddle commented Sep 25, 2017

Shouldn't V3 be backwards compatible?

Not everyone want to use docker stack just yet

@pr0totyp

This comment has been minimized.

pr0totyp commented Oct 26, 2017

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 comment has been minimized.

aldarund commented Nov 5, 2017

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 comment has been minimized.

ffelixneto commented Nov 6, 2017

"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

This comment has been minimized.

iget-esoares commented Nov 7, 2017

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

@lalitprasanth

This comment has been minimized.

lalitprasanth commented Nov 14, 2017

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

This comment has been minimized.

egee-irl commented Dec 8, 2017

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.

@nathandrew01

This comment has been minimized.

nathandrew01 commented Dec 29, 2017

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

This comment has been minimized.

ffelixneto commented Dec 29, 2017

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-

This comment has been minimized.

Member

shin- commented Jan 3, 2018

@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

This comment has been minimized.

stevenklar commented Jan 9, 2018

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

This comment has been minimized.

ylavoie commented Jan 16, 2018

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

This comment has been minimized.

billnbell commented Jan 22, 2018

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

@kurankat

This comment has been minimized.

kurankat commented Jan 25, 2018

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

This comment has been minimized.

Elzor commented Jan 27, 2018

I think for development environments mem_limit option is really necessary.

@dfedorov-ciena

This comment has been minimized.

dfedorov-ciena commented Feb 12, 2018

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

This comment has been minimized.

alexandruionica commented Feb 23, 2018

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-

This comment has been minimized.

Member

shin- commented Feb 23, 2018

Everyone,

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

@chasgames

This comment has been minimized.

chasgames commented Feb 23, 2018

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-

This comment has been minimized.

Member

shin- commented Feb 23, 2018

@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

This comment has been minimized.

edward2a commented Mar 29, 2018

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-

This comment has been minimized.

Member

shin- commented Mar 29, 2018

  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.

@docker docker locked as resolved and limited conversation to collaborators Mar 29, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.