Skip to content
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

docker-compose.yml should support every docker run option #754

Closed
5 tasks done
bfirsh opened this issue Dec 23, 2014 · 29 comments
Closed
5 tasks done

docker-compose.yml should support every docker run option #754

bfirsh opened this issue Dec 23, 2014 · 29 comments

Comments

@bfirsh
Copy link

bfirsh commented Dec 23, 2014

Notable things missing:

The following run options aren't in docker-py; cpuset-mems, cpu-period, cpu-quota, oom-kill-disable, sig-proxy

Related: #363

Examples: #293 #830

@aanand aanand added this to the 1.1.0 milestone Dec 23, 2014
@bfirsh bfirsh removed this from the 1.1.0 milestone Jan 8, 2015
@mishak87
Copy link

Any progress with add-host #597? In docker-py support is already present docker/docker-py#400 from 0.7.0.

Ideally if configuration would look like this

hosts:
   hostname: ip

@dommmel
Copy link

dommmel commented Jan 29, 2015

AFAICT support for "device" is also present in docker-py (see docker/docker-py#373)

@gpolyn
Copy link

gpolyn commented Feb 3, 2015

+1 for #597

@zhucegep
Copy link

zhucegep commented Feb 5, 2015

I really need this feature: #597

@mishak87
Copy link

mishak87 commented Feb 5, 2015

@zhucegep you can try crane which supports it

@razic
Copy link

razic commented Feb 8, 2015

@bfirsh are memswap_limit and cpuset not integrated into docker-compose yet?

@razic
Copy link

razic commented Feb 8, 2015

also i'm trying to use cpu_shares which looks to be defined here, but doesn't seem to actually be working... https://github.com/docker/fig/blob/master/compose/service.py#L21

@zhucegep
Copy link

@mishak87 thank you, I had implement this feature on environment variable.

usage:

environment:
    HOSTS:  "zookeeper zookeeper.example.com\n172.17.42.1 my.own.com"

impl:

#! /bin/bash
echo  "# host config by docker" >> /etc/hosts
echo  "$HOSTS" | while read line 
do
  link_service_name=`echo $line | cut -d" " -f1`
  ip=$link_service_name
  # if does not contain "." then change it to ip from env
  [[ $ip =~ "." ]] || ip=`env | grep TCP=tcp:// | grep -i $link_service_name | cut -d"/" -f3 | cut -d":" -f1 | sort | uniq`
  # replace service name to ip, and echo to /etc/hosts
  echo $line | sed s/$link_service_name/$ip/g >> /etc/hosts
done

@nexus49
Copy link

nexus49 commented Feb 21, 2015

+1 for #597

@cancan101
Copy link

Any updates on docker-compose supporting the device option?:

--device=[] Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)

@gastonmorixe
Copy link

cpuset?

@bfirsh
Copy link
Author

bfirsh commented Mar 30, 2015

I've added some examples of pull requests adding docker-compose.yml options in case anybody needs an example to help them implement these.

@gastonmorixe
Copy link

@bfirsh cool, may I know why can't we add a fallback way to send whatever run param we want? so we are not always behind docker. Soon docker will have logs driver/limits, I'd love to use that even under a RC, but I can't without patching compose too.

Thanks

@mishak87
Copy link

@imton IMO it is necessary to synchronize feature releases of docker with compose so it does not lag behind. Maybe using it for regression/integration tests so it is always necessary to keep it up-to-date.

But since receiving new name, lets hope it will be also receiving the attention it deserves!

@gastonmorixe
Copy link

@mishak87 while I understand what you say, I don't agree. I think docker changes so fast we have to have fallback and for docker's betas/RC we won't be updating compose.

@mishak87
Copy link

TL;DR Current state leads to tools/forks like crane which implement more features and react faster. Maybe it would be faster to make decision on format/behaviour and let community to help out with implementation.

@imton That does not make sense to me from product perspective. We are talking about tool that orchestrates docker containers by reading single configuration.

I really do appreciate the pace with which docker keeps on significantly improving with each version, but leaving this tool in dust behind is bad. It would be like publishing golang 1.4 but only with tools supporting 1.3 features.

For a docker newcomer, composer is already part of official documentation. I would implicitly assume it is in lock with at least last stable version of docker. It is not useful to me for development and playing with, if I can't use new features.

From technical point of view it is confusing at least for me personally. I would expect compose to contain 90% of generated code from some hashmap of possible config values crossed with docker-py feature set.
Maybe it would make sense to leave it with open-source community so you can focus on docker alone.
Maybe you could decide how configuration should look like and ask for pull requests? I could promise you to make at least one each month for at least a year.

@pahud
Copy link

pahud commented Apr 7, 2015

+1 for #597

1 similar comment
@blankenhaus
Copy link

+1 for #597

@tj
Copy link

tj commented Apr 13, 2015

I want to help but there's no in-source docs :( – need add-hosts as well. How do you run the tests?

@bfirsh
Copy link
Author

bfirsh commented Apr 14, 2015

@tj Instructions on how to run the tests is in the contributing docs. Here's an example of adding an option if that's helpful: #830

Give us a shout in #docker-compose on Freenode if you need a hand with anything. :)

@tj
Copy link

tj commented Apr 14, 2015

Would you be against a hosts map? I know it doesn't fit the same model as #820 but something similar to environment like @mishak87 mentioned makes the most sense to me. The naming conventions get a little weird though since it wouldn't be 1:1 with the flags, that feels a little awkward, but let me know what you think!

@gomex
Copy link

gomex commented May 20, 2015

cpuset was added in which version? I am using 1.2.0 and don't have this option here:

Unsupported config option for sisaudev service: 'cpuset'

@zutherb
Copy link

zutherb commented May 27, 2015

+1

@brianclements
Copy link

+1. Especially regarding the --log-driver, but for everything really. Volume containers don't need logging, some temporary containers can use default, and app containers can be specified accordingly.

@Claudweb
Copy link

Claudweb commented Jul 1, 2015

+1 for mac_address

@bfirsh bfirsh changed the title fig.yml should support every docker run option docker-compose.yml should support every docker run option Jul 6, 2015
@mnowster mnowster self-assigned this Jul 6, 2015
@mnowster
Copy link

mnowster commented Jul 7, 2015

mac_address and memswap_limit will be in 1.4.

I'm closing this issue as those run options are now covered.

If there are further ones, please open a new issue. Thank you.

@migueleliasweb
Copy link

Hey everyone, I just got a problem with --cpu-quota support. After reading some comments here I saw some options were merged, any news about --cpu-quota ?

@Shinoby92
Copy link

still nothing about the oom-kill disabling in stack deploy?

@fullbl
Copy link

fullbl commented Dec 5, 2022

what about sig-proxy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests