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!