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

Proposal: Docker Compose #9694

Closed
aanand opened this Issue Dec 16, 2014 · 79 comments

Comments

Projects
None yet
@aanand
Contributor

aanand commented Dec 16, 2014

This proposal, deprecating #9459, is for a command-line tool for orchestration of multi-container apps, suitable for development environments, automated CI setups and staging and production deployments, and working fluidly with Docker Machine and Docker Swarm.

Based in large part on feedback to #9459 from the Docker community, we propose the following:

  • Compose is a standalone command-line tool, rather than built into the Docker client binary.
  • The initial release of Compose is directly based on the Fig codebase, rather than written from scratch, and focused around cleanup and any backwards-incompatible changes from Fig.
  • A roadmap of features for Compose and (if deemed appropriate) the Docker engine, so as to achieve production-suitability and seamless integration with Swarm, is planned.

Separate tool

The arguments in favour of building Compose directly into the Docker client are based on usability issues we’ve observed with Fig:

  • Newcomers to Docker find Fig more immediately easy to understand and relevant to their needs, so it makes sense for them to have that benefit out-of-the-box.
  • People are often confused about the distinction between Fig and Docker, so it would be beneficial from a UX perspective if there were no distinction.
  • Fig is “one more thing to install” that prevents users from getting up and running.
  • Problems arise when versions of Fig and Docker are incompatible.

However, there are also usability arguments against building it in:

  • The various Docker commands become context-sensitive (i.e. they behave differently based on the contents of the current directory) and overloaded with meaning (arguments can either designate literal container names or names in the configuration file).
  • Docker users who aren’t interested in Compose’s features will nonetheless have to live with a tool that’s both physically and conceptually larger.

Furthermore, technical and social arguments strongly favour separation: the responsibilities of Compose and those of the current Docker client don’t overlap, and it’s better to avoid conflating non-coupled concerns in one codebase, because:

  • It’ll make the codebase even larger.
  • It’ll force both projects to share a release cycle, making it harder to experiment on Compose and to make changes to either one.
  • It’ll put extra burden on the core maintainers.
  • It’ll be harder to find issues and PRs if they all live in the same GitHub repository.

Furthermore, a separate tool will help guide the definition and maintenance of the Docker API(s), keeping the door open for a healthy ecosystem of alternatives.

Finally, it’s still possible to go carefully from a separate tool to an integrated one in the future; extracting a separate tool back out again, however, is much harder.

Based on Fig

Fig in its current state is a great orchestration tool for development/CI, and a usable one for simple production deployments. Its codebase is mature and well-understood, and doesn’t carry a lot of technical debt (though there are improvements which can and should be made!)

It would make an excellent starting point - and, given Compose is a new tool, we’d be free to make breaking changes from Fig’s logic for the first release.

Features roadmap

As well as a number of smaller features that have been requested for Fig (which will still be triaged and implemented where appropriate), several high-level features are needed to get Compose to a state where it’s suitable for multi-host production deploys. Compose’s priorities after the initial release will be identifying, designing and implementing these in collaboration with the community and users. Discussion for many of these is already ongoing on the Fig GitHub project.

@jokeyrhyme

This comment has been minimized.

Show comment
Hide comment
@jokeyrhyme

jokeyrhyme Dec 16, 2014

As mentioned in #9459:

  • I'd like the option of using a less ambiguous definition format: TOML or JSON are less "magical" than YAML
  • it'd be terrific if every docker CLI option was able to be handled in the definition: there are loads of things I end up needing external scripts for with fig, where crane covers everything I can think of

As mentioned in #9459:

  • I'd like the option of using a less ambiguous definition format: TOML or JSON are less "magical" than YAML
  • it'd be terrific if every docker CLI option was able to be handled in the definition: there are loads of things I end up needing external scripts for with fig, where crane covers everything I can think of
@pkieltyka

This comment has been minimized.

Show comment
Hide comment
@pkieltyka

pkieltyka Dec 16, 2014

I like the idea of a Stackfile in TOML. Anyone else?

I like the idea of a Stackfile in TOML. Anyone else?

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Dec 16, 2014

Member

I personally really prefer YAML, but I don't see a need to restrict it to just one format. All of these formats should be able to map to a common representation internally.

Member

dnephin commented Dec 16, 2014

I personally really prefer YAML, but I don't see a need to restrict it to just one format. All of these formats should be able to map to a common representation internally.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Dec 16, 2014

Contributor

I like the reduced ambiguity/size of TOML. My main complaint is that nesting is more verbose. Translating the group.yml example from #9459:

name = "rails_example"

[containers]

  [containers.db]
  image = "postgres:latest"

  [containers.web]
  build = "."
  command = "bundle exec rackup -p 3000"
  volumes = [".:/myapp"]
  ports = ["3000:3000"]
  links = ["db"]

I'm not a huge fan of how the containers key is repeated for every sub-dictionary. If another level of nesting were introduced for some reason, the whole file would get yet more verbose.

This might not end up being an issue, but it warrants consideration.

Contributor

aanand commented Dec 16, 2014

I like the reduced ambiguity/size of TOML. My main complaint is that nesting is more verbose. Translating the group.yml example from #9459:

name = "rails_example"

[containers]

  [containers.db]
  image = "postgres:latest"

  [containers.web]
  build = "."
  command = "bundle exec rackup -p 3000"
  volumes = [".:/myapp"]
  ports = ["3000:3000"]
  links = ["db"]

I'm not a huge fan of how the containers key is repeated for every sub-dictionary. If another level of nesting were introduced for some reason, the whole file would get yet more verbose.

This might not end up being an issue, but it warrants consideration.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Dec 16, 2014

Contributor

@jokeyrhyme: yes, Compose should aim to cover every Docker CLI option.

Contributor

aanand commented Dec 16, 2014

@jokeyrhyme: yes, Compose should aim to cover every Docker CLI option.

@pkieltyka

This comment has been minimized.

Show comment
Hide comment
@pkieltyka

pkieltyka Dec 16, 2014

@aanand you can make this work too:

name = "rails_example"

[containers.db]
image = "postgres:latest"

[containers.web]
build = "."
command = "bundle exec rackup -p 3000"
volumes = [".:/myapp"]
ports = ["3000:3000"]
links = ["db"]

I do something similar in a project conf.

I think YAML is also fine though, I just would really prefer not to see the .yml extension on the filename.. even .conf would make me happier. Just my 2cents.

@aanand you can make this work too:

name = "rails_example"

[containers.db]
image = "postgres:latest"

[containers.web]
build = "."
command = "bundle exec rackup -p 3000"
volumes = [".:/myapp"]
ports = ["3000:3000"]
links = ["db"]

I do something similar in a project conf.

I think YAML is also fine though, I just would really prefer not to see the .yml extension on the filename.. even .conf would make me happier. Just my 2cents.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Dec 16, 2014

Member

One issue I've seen with YAML in the wild (specifically in fig.yml) is that things like an environment: value of true have to be quoted or they become True (thanks to true -> True -> True.to_s).

Member

tianon commented Dec 16, 2014

One issue I've seen with YAML in the wild (specifically in fig.yml) is that things like an environment: value of true have to be quoted or they become True (thanks to true -> True -> True.to_s).

@ewindisch

This comment has been minimized.

Show comment
Hide comment
@ewindisch

ewindisch Dec 16, 2014

Contributor

Not suggesting we solve every use case, but one major limitation of most of the proposals I've seen is the lack of piping. I want a compose framework which pipes containers together. Currently, I've been using shell scripts wrapping the client...

Contributor

ewindisch commented Dec 16, 2014

Not suggesting we solve every use case, but one major limitation of most of the proposals I've seen is the lack of piping. I want a compose framework which pipes containers together. Currently, I've been using shell scripts wrapping the client...

@softprops

This comment has been minimized.

Show comment
Hide comment
@softprops

softprops Dec 17, 2014

Contributor

One + for json is that it's extremely easy to consume due to ubiquity in json parsers for every flavor of programming language. It's designed for both humans and machines to read. Yaml is easy for humans to read ( sometimes... if you can eye up your whitespace ) but deceptively hard for machines. Compare it's spec with json's if you disagree :).

I would prefer a format that makes it easy to build new tooling on top of rather than encouraging a single project to have different descriptions of the same information for different tools.

Contributor

softprops commented Dec 17, 2014

One + for json is that it's extremely easy to consume due to ubiquity in json parsers for every flavor of programming language. It's designed for both humans and machines to read. Yaml is easy for humans to read ( sometimes... if you can eye up your whitespace ) but deceptively hard for machines. Compare it's spec with json's if you disagree :).

I would prefer a format that makes it easy to build new tooling on top of rather than encouraging a single project to have different descriptions of the same information for different tools.

@xiaods

This comment has been minimized.

Show comment
Hide comment
@xiaods

xiaods Dec 17, 2014

Contributor

just like boot2docker, docker is already the owner of fig, why not enhance the fig to implement the docker compose feature?

Contributor

xiaods commented Dec 17, 2014

just like boot2docker, docker is already the owner of fig, why not enhance the fig to implement the docker compose feature?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 17, 2014

Member

+1 on supporting multiple formats. Depending on your case, JSON, TOML or YAML could be prefered. Since all formats should be easy to map to the same "internal" format, I don't see a reason to not support them.

Should there be a "default" format? (Thinking of what format to use for examples in the documentation)

Member

thaJeztah commented Dec 17, 2014

+1 on supporting multiple formats. Depending on your case, JSON, TOML or YAML could be prefered. Since all formats should be easy to map to the same "internal" format, I don't see a reason to not support them.

Should there be a "default" format? (Thinking of what format to use for examples in the documentation)

@xiaods

This comment has been minimized.

Show comment
Hide comment
@xiaods

xiaods Dec 17, 2014

Contributor

share the fig multi host patch
Enable services to use different Docker Hosts
docker/compose#607

Contributor

xiaods commented Dec 17, 2014

share the fig multi host patch
Enable services to use different Docker Hosts
docker/compose#607

@mkawalec

This comment has been minimized.

Show comment
Hide comment
@mkawalec

mkawalec Dec 17, 2014

If we are requesting features, docker exec is immensly important to me for debugging (sometimes you just want to tinker with a raw source file), I would love to see it in an exposed place.

If we are requesting features, docker exec is immensly important to me for debugging (sometimes you just want to tinker with a raw source file), I would love to see it in an exposed place.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 17, 2014

Member

share the fig multi host patch
Enable services to use different Docker Hosts

I don't think that is nescessary to implement in Compose; Compose should be able to talk to Swarm and have Swarm take care of which host a service will be deployed to.

The only thing that compose has to take care of, is passing the constraints (ie, ports, memory etc) to Swarm to act on.

Member

thaJeztah commented Dec 17, 2014

share the fig multi host patch
Enable services to use different Docker Hosts

I don't think that is nescessary to implement in Compose; Compose should be able to talk to Swarm and have Swarm take care of which host a service will be deployed to.

The only thing that compose has to take care of, is passing the constraints (ie, ports, memory etc) to Swarm to act on.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Dec 17, 2014

Contributor

@xiaods, @thaJeztah: Correct. Multi-host deployment should be Swarm's responsibility, not Compose's - although if Swarm makes changes to the Docker API to allow for e.g. scheduling hints, Compose should support them.

The multi-host patch is a good solution for simple cases, but we need to solve this issue more comprehensively, taking into account difficult stuff like volumes and links.

Contributor

aanand commented Dec 17, 2014

@xiaods, @thaJeztah: Correct. Multi-host deployment should be Swarm's responsibility, not Compose's - although if Swarm makes changes to the Docker API to allow for e.g. scheduling hints, Compose should support them.

The multi-host patch is a good solution for simple cases, but we need to solve this issue more comprehensively, taking into account difficult stuff like volumes and links.

@nathanleclaire

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Dec 18, 2014

Contributor

+1 external tool

IMO, the overarching goal for compose should be : Fig with better concurrency, some of the known issues sanded off, and multi-host support. "Don't get too smart", and provide useful building blocks for others to play with in next-order tools. I think this proposal heads in a direction which can meet those goals quite well.

On the matter of various serialization formats: In an ideal world we'd have plugins that allow users to use whichever they want (YAML, JSON, TOML, XML) that gets serialized down to a common format (perhaps JSON due to its ubiquity and ease of demarshalling into a Go struct).

In reality, JSON is very close to a subset of YAML for many of the cases which are covered by a fig-like tool (see https://github.com/nathanleclaire/jsonfig/blob/master/fig.yml for an example of writing JSON for fig, no mods needed). So I think that starting with a YAML parser which has some implicit JSON support is pretty reasonable. I used to really hate YAML but once I saw a 100+ line fig.yml I really appreciated its terseness a lot more. A huge variety of easily available conversion tools exist too.

One thing I'd really like to see is something like this (maybe it'd be built into up etc.):

$ compose validate Dockergroup.yml
err: line 15: value for key "links" is not an array.  Perhaps it should look more like
links:
 - redis
$ vi Dockergroup.yml
$ compose validate Dockergroup.yml
Everything looks good!
$

I think it'd go a long way towards cutting down on YAML confusion. Some such error messages in fig today exist but they can be a little esoteric.

Contributor

nathanleclaire commented Dec 18, 2014

+1 external tool

IMO, the overarching goal for compose should be : Fig with better concurrency, some of the known issues sanded off, and multi-host support. "Don't get too smart", and provide useful building blocks for others to play with in next-order tools. I think this proposal heads in a direction which can meet those goals quite well.

On the matter of various serialization formats: In an ideal world we'd have plugins that allow users to use whichever they want (YAML, JSON, TOML, XML) that gets serialized down to a common format (perhaps JSON due to its ubiquity and ease of demarshalling into a Go struct).

In reality, JSON is very close to a subset of YAML for many of the cases which are covered by a fig-like tool (see https://github.com/nathanleclaire/jsonfig/blob/master/fig.yml for an example of writing JSON for fig, no mods needed). So I think that starting with a YAML parser which has some implicit JSON support is pretty reasonable. I used to really hate YAML but once I saw a 100+ line fig.yml I really appreciated its terseness a lot more. A huge variety of easily available conversion tools exist too.

One thing I'd really like to see is something like this (maybe it'd be built into up etc.):

$ compose validate Dockergroup.yml
err: line 15: value for key "links" is not an array.  Perhaps it should look more like
links:
 - redis
$ vi Dockergroup.yml
$ compose validate Dockergroup.yml
Everything looks good!
$

I think it'd go a long way towards cutting down on YAML confusion. Some such error messages in fig today exist but they can be a little esoteric.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Dec 18, 2014

Contributor

@nathanleclaire Agreed on validation, it's been needed for ages (docker/compose#129). It should always run when reading fig.yml, and there should also be a way to just validate a file and exit, as in your example.

Contributor

aanand commented Dec 18, 2014

@nathanleclaire Agreed on validation, it's been needed for ages (docker/compose#129). It should always run when reading fig.yml, and there should also be a way to just validate a file and exit, as in your example.

@pkieltyka

This comment has been minimized.

Show comment
Hide comment
@pkieltyka

pkieltyka Dec 18, 2014

I think supporting so many file formats for the compose configuration is over board and you guys should pick just one. I hope that'll be TOML, but whatever the authors decide is cool.

On Dec 17, 2014, at 9:08 PM, Nathan LeClaire notifications@github.com wrote:

+1 external tool

IMO, the overarching goal for compose should be : Fig with better concurrency, some of the known issues sanded off, and multi-host support. "Don't get too smart", and provide useful building blocks for others to play with in next-order tools. I think this proposal heads in a direction which can meet those goals quite well.

On the matter of various serialization formats: In an ideal world we'd have plugins that allow users to use whichever they want (YAML, JSON, TOML, XML) that gets serialized down to a common format (perhaps JSON due to its ubiquity and ease of demarshalling into a Go struct).

In reality, JSON is very close to a subset of YAML for many cases are covered by a fig-like tool (see https://github.com/nathanleclaire/jsonfig/blob/master/fig.yml for an example of writing JSON for fig, no mods needed), so I think starting with a YAML parser that has some implicit JSON support is pretty reasonable. I used to really hate YAML but once I saw a 100+ line fig.yml I really appreciated its terseness a lot more. A huge variety of easily available conversion tools exist too.

One thing I'd really like to see is something like this (maybe it'd be built into up etc.):

$ compose validate Dockergroup.yml
err: line 15: value for key "links" is not an array. Perhaps is should look more like
links:

  • redis
    $ vi Dockergroup.yml
    $ compose validate Dockergroup.yml
    Everything looks good!
    $
    I think it'd go a long way towards cutting down on YAML confusion.


Reply to this email directly or view it on GitHub.

I think supporting so many file formats for the compose configuration is over board and you guys should pick just one. I hope that'll be TOML, but whatever the authors decide is cool.

On Dec 17, 2014, at 9:08 PM, Nathan LeClaire notifications@github.com wrote:

+1 external tool

IMO, the overarching goal for compose should be : Fig with better concurrency, some of the known issues sanded off, and multi-host support. "Don't get too smart", and provide useful building blocks for others to play with in next-order tools. I think this proposal heads in a direction which can meet those goals quite well.

On the matter of various serialization formats: In an ideal world we'd have plugins that allow users to use whichever they want (YAML, JSON, TOML, XML) that gets serialized down to a common format (perhaps JSON due to its ubiquity and ease of demarshalling into a Go struct).

In reality, JSON is very close to a subset of YAML for many cases are covered by a fig-like tool (see https://github.com/nathanleclaire/jsonfig/blob/master/fig.yml for an example of writing JSON for fig, no mods needed), so I think starting with a YAML parser that has some implicit JSON support is pretty reasonable. I used to really hate YAML but once I saw a 100+ line fig.yml I really appreciated its terseness a lot more. A huge variety of easily available conversion tools exist too.

One thing I'd really like to see is something like this (maybe it'd be built into up etc.):

$ compose validate Dockergroup.yml
err: line 15: value for key "links" is not an array. Perhaps is should look more like
links:

  • redis
    $ vi Dockergroup.yml
    $ compose validate Dockergroup.yml
    Everything looks good!
    $
    I think it'd go a long way towards cutting down on YAML confusion.


Reply to this email directly or view it on GitHub.

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Dec 18, 2014

+1 for multiple file formats... As long as they are all fully supported... Coming from Node.js and Java, I would be just easily generating JSON/YAML files...

+1 for multiple file formats... As long as they are all fully supported... Coming from Node.js and Java, I would be just easily generating JSON/YAML files...

@burnzoire

This comment has been minimized.

Show comment
Hide comment
@burnzoire

burnzoire Dec 18, 2014

Pick a single format to keep things simple for new users. We don't need projects and examples fragmented across different syntaxes. Happy with yaml as per fig, although I miss the flexibility of ruby ala Vagrantfile.

Pick a single format to keep things simple for new users. We don't need projects and examples fragmented across different syntaxes. Happy with yaml as per fig, although I miss the flexibility of ruby ala Vagrantfile.

@vaceletm

This comment has been minimized.

Show comment
Hide comment
@vaceletm

vaceletm Dec 18, 2014

+1 fort single end user format. Like Nathan said, with a bit of syntax
check, it's very readable as of today (despite I'm not a huge fan of yaml)

The argument for doc fragmentation is very relevant. Ppl will copy/paste
things from various sources (tuto, blog, doc, stack overflow, gist). This
is the way we work nowadays so it should be easy and straightforward.

More formats, more code, more bugs less features.
Le 18 déc. 2014 06:53, "Nathan Burns" notifications@github.com a écrit :

Pick a single format to keep things simple for new users. We don't need
projects and examples fragmented across different syntaxes. Happy with yaml
as per fig, although I miss the flexibility of ruby ala Vagrantfile.


Reply to this email directly or view it on GitHub
#9694 (comment).

+1 fort single end user format. Like Nathan said, with a bit of syntax
check, it's very readable as of today (despite I'm not a huge fan of yaml)

The argument for doc fragmentation is very relevant. Ppl will copy/paste
things from various sources (tuto, blog, doc, stack overflow, gist). This
is the way we work nowadays so it should be easy and straightforward.

More formats, more code, more bugs less features.
Le 18 déc. 2014 06:53, "Nathan Burns" notifications@github.com a écrit :

Pick a single format to keep things simple for new users. We don't need
projects and examples fragmented across different syntaxes. Happy with yaml
as per fig, although I miss the flexibility of ruby ala Vagrantfile.


Reply to this email directly or view it on GitHub
#9694 (comment).

@Ragsboss

This comment has been minimized.

Show comment
Hide comment
@Ragsboss

Ragsboss Dec 18, 2014

Has anyone looked at existing state-of-art around composition? For example, TOSCA (Topology and Orchestration Specification for Cloud Applications) is a standard that defines a generic meta-model for composition. They use YAML too and refer to Open Stack HEAT as the reference implementation. https://www.oasis-open.org/committees/download.php/52571/TOSCA-Simple-Profile-YAML-v1.0-wd01-Rev-38.pdf. This gives a portable way (backed by standards body) to build composition manifests and users don't need to learn multiple languages/frameworks.

I haven't analyzed use of TOSCA or HEAT to model multi-container apps but given the domain agnosticity behind these tools, that (in theory) shouldn't be an issue. http://getcloudify.org/guide/3.0/understanding-blueprints.html is an open-source implementation of TOSCA standard.

Has anyone looked at existing state-of-art around composition? For example, TOSCA (Topology and Orchestration Specification for Cloud Applications) is a standard that defines a generic meta-model for composition. They use YAML too and refer to Open Stack HEAT as the reference implementation. https://www.oasis-open.org/committees/download.php/52571/TOSCA-Simple-Profile-YAML-v1.0-wd01-Rev-38.pdf. This gives a portable way (backed by standards body) to build composition manifests and users don't need to learn multiple languages/frameworks.

I haven't analyzed use of TOSCA or HEAT to model multi-container apps but given the domain agnosticity behind these tools, that (in theory) shouldn't be an issue. http://getcloudify.org/guide/3.0/understanding-blueprints.html is an open-source implementation of TOSCA standard.

@gabrielgrant

This comment has been minimized.

Show comment
Hide comment
@gabrielgrant

gabrielgrant Dec 19, 2014

Echoing @craftgear in #9459 : If this is simply a proposal to improve fig, why create a new tool, rather than just ... improve fig?

Echoing @craftgear in #9459 : If this is simply a proposal to improve fig, why create a new tool, rather than just ... improve fig?

@marcellodesales

This comment has been minimized.

Show comment
Hide comment
@marcellodesales

marcellodesales Dec 19, 2014

+1 to improve Fig! and integrate it into Docker.

+1 to improve Fig! and integrate it into Docker.

@scottstamp

This comment has been minimized.

Show comment
Hide comment
@scottstamp

scottstamp Dec 23, 2014

Contributor

If the idea in question is really whether or not to merge Fig into the standard CLI, why not just give it a command namespace? docker compose ... for composition-specific tasks and docker ... for everything else? Also, I'm not sure how feasible this would actually be, but if keeping the codebase clean is of a paramount concern, maybe it could be added as an optional "plugin" for the client.

Think:

  • Install Docker (just docker)
  • Implement a docker plugins ... namespace
  • Global plugin registry (or git integration) to allow for something like docker install compose
  • Compose becomes available through the docker compose ... namespace.

Not sure if this might be too heavy of a solution but I could see it being beneficial to new users. Personally I'm fine with installing fig through pip and calling it a day.

Contributor

scottstamp commented Dec 23, 2014

If the idea in question is really whether or not to merge Fig into the standard CLI, why not just give it a command namespace? docker compose ... for composition-specific tasks and docker ... for everything else? Also, I'm not sure how feasible this would actually be, but if keeping the codebase clean is of a paramount concern, maybe it could be added as an optional "plugin" for the client.

Think:

  • Install Docker (just docker)
  • Implement a docker plugins ... namespace
  • Global plugin registry (or git integration) to allow for something like docker install compose
  • Compose becomes available through the docker compose ... namespace.

Not sure if this might be too heavy of a solution but I could see it being beneficial to new users. Personally I'm fine with installing fig through pip and calling it a day.

@huslage

This comment has been minimized.

Show comment
Hide comment
@huslage

huslage Dec 23, 2014

Contributor

IMO, TOSCA is a standard in search of a reason to exist. It is overly complex for a Docker multi-container environment and adds a ridiculous amount of XML-like overhead. The fig.yml + broader support for Docker options is the right way to go, I think.

Contributor

huslage commented Dec 23, 2014

IMO, TOSCA is a standard in search of a reason to exist. It is overly complex for a Docker multi-container environment and adds a ridiculous amount of XML-like overhead. The fig.yml + broader support for Docker options is the right way to go, I think.

@pkieltyka

This comment has been minimized.

Show comment
Hide comment
@pkieltyka

pkieltyka Dec 24, 2014

Agreed

On Dec 23, 2014, at 6:28 PM, Aaron Huslage notifications@github.com wrote:

IMO, TOSCA is a standard in search of a reason to exist. It is overly complex for a Docker multi-container environment and adds a ridiculous amount of XML-like overhead. The fig.yml + broader support for Docker options is the right way to go, I think.


Reply to this email directly or view it on GitHub.

Agreed

On Dec 23, 2014, at 6:28 PM, Aaron Huslage notifications@github.com wrote:

IMO, TOSCA is a standard in search of a reason to exist. It is overly complex for a Docker multi-container environment and adds a ridiculous amount of XML-like overhead. The fig.yml + broader support for Docker options is the right way to go, I think.


Reply to this email directly or view it on GitHub.

@eddiejaoude

This comment has been minimized.

Show comment
Hide comment
@eddiejaoude

eddiejaoude Dec 24, 2014

Lots of great ideas. But good to start simple, get something stable, people using it & then build on it.

Fig currently supports yaml, probably best to start with that.

Just my 2 cents.

Lots of great ideas. But good to start simple, get something stable, people using it & then build on it.

Fig currently supports yaml, probably best to start with that.

Just my 2 cents.

@kriswill

This comment has been minimized.

Show comment
Hide comment
@kriswill

kriswill Dec 27, 2014

$ docker compose web-editor -p 3000
  Docker v1.5
  open your browser to http://localhost:3000 for interactive editing of .docker-compose
  ctrl-c to stop

The users can copy/paste full or partial configurations, validations... No YAML kittens are hurt in the process.

$ docker compose web-editor -p 3000
  Docker v1.5
  open your browser to http://localhost:3000 for interactive editing of .docker-compose
  ctrl-c to stop

The users can copy/paste full or partial configurations, validations... No YAML kittens are hurt in the process.

@silenceisgolden

This comment has been minimized.

Show comment
Hide comment
@silenceisgolden

silenceisgolden Dec 29, 2014

+1 on standalone. I currently use 2 different Dockerfiles for production and development. Since development is on local (NodeJS) I share the volume in from boot2docker to the container, then run a shell script to actually start the process and container. I think this makes it imperative to provide a way to run a local stack and a production stack of settings, but make it clear the best practices for both.

+1 on standalone. I currently use 2 different Dockerfiles for production and development. Since development is on local (NodeJS) I share the volume in from boot2docker to the container, then run a shell script to actually start the process and container. I think this makes it imperative to provide a way to run a local stack and a production stack of settings, but make it clear the best practices for both.

@chrisfosterelli

This comment has been minimized.

Show comment
Hide comment
@chrisfosterelli

chrisfosterelli Dec 29, 2014

While reading through the initial proposals, I thought it made sense to include Compose as a component of the main binary. However after reading about Swarm, and how it will be separate entity, as well as with the release of Docker Machine I think it makes much more sense to have Compose separate as well.

I'd like to +1 JSON support as well. I don't think it's that much more code + bug surface for JSON support, although obviously the developers would have a much better idea of whether that is true or not.

@aanand Given that this will be based off of Fig, does that mean Compose will long-term remain a Python app?

While reading through the initial proposals, I thought it made sense to include Compose as a component of the main binary. However after reading about Swarm, and how it will be separate entity, as well as with the release of Docker Machine I think it makes much more sense to have Compose separate as well.

I'd like to +1 JSON support as well. I don't think it's that much more code + bug surface for JSON support, although obviously the developers would have a much better idea of whether that is true or not.

@aanand Given that this will be based off of Fig, does that mean Compose will long-term remain a Python app?

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Dec 31, 2014

Contributor

@chrisfosterelli Yes, it will remain in Python until such time as we decide a Go rewrite is worth it.

Contributor

aanand commented Dec 31, 2014

@chrisfosterelli Yes, it will remain in Python until such time as we decide a Go rewrite is worth it.

@olalonde

This comment has been minimized.

Show comment
Hide comment
@olalonde

olalonde Jan 2, 2015

As a developer, it would be nice if "services" (distributed systems that are defined by a fig.yml file) could be composed. There could be a services registry ("composer registry"? like the Docker registry but for complete systems which in turn can be composed of other systems).

For example, I'm currently working on an app composed of:

  • 9 independent micro-services (repositories), each backed by a separate database
  • an API gateway

It would be nice if I could have a fig.yml for each micro-service repository (which would each be responsible for bringing up their HTTP container + database container).

My API gateway's fig.yml could then simply reference all the other services it depends on without having to know that, for example, micro-serviceY requires a database container. The individual services could also be responsible for how to properly load balance themselves, etc.

It would also enable the creation of a micro-service ecosystem where one can easily declare a micro-service dependencies without having to know what internal infrastructure that is required to run it.

Does that make any sense?

olalonde commented Jan 2, 2015

As a developer, it would be nice if "services" (distributed systems that are defined by a fig.yml file) could be composed. There could be a services registry ("composer registry"? like the Docker registry but for complete systems which in turn can be composed of other systems).

For example, I'm currently working on an app composed of:

  • 9 independent micro-services (repositories), each backed by a separate database
  • an API gateway

It would be nice if I could have a fig.yml for each micro-service repository (which would each be responsible for bringing up their HTTP container + database container).

My API gateway's fig.yml could then simply reference all the other services it depends on without having to know that, for example, micro-serviceY requires a database container. The individual services could also be responsible for how to properly load balance themselves, etc.

It would also enable the creation of a micro-service ecosystem where one can easily declare a micro-service dependencies without having to know what internal infrastructure that is required to run it.

Does that make any sense?

@Peeja

This comment has been minimized.

Show comment
Hide comment
@Peeja

Peeja Jan 3, 2015

Yo, dawg.

I'd like to have this too, or something that accomplishes the same thing. The issue with the current design is that neither containers nor multi-container apps are recursive abstractions.

I'd like to be able to treat an entire multi-container app as a single container, so I can compose it with yet more containers. The image for that container could then be hosted in the ordinary Docker registry.

You can actually do that now by running Docker-in-Docker, but it's kind of a hack.

Peeja commented Jan 3, 2015

Yo, dawg.

I'd like to have this too, or something that accomplishes the same thing. The issue with the current design is that neither containers nor multi-container apps are recursive abstractions.

I'd like to be able to treat an entire multi-container app as a single container, so I can compose it with yet more containers. The image for that container could then be hosted in the ordinary Docker registry.

You can actually do that now by running Docker-in-Docker, but it's kind of a hack.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 3, 2015

Member

Sounds a bit like the templates on http://panamax.io ? Could be interesting, but I'm not sure it is wise to put it on the roadmap so soon?

Member

thaJeztah commented Jan 3, 2015

Sounds a bit like the templates on http://panamax.io ? Could be interesting, but I'm not sure it is wise to put it on the roadmap so soon?

@Peeja

This comment has been minimized.

Show comment
Hide comment
@Peeja

Peeja Jan 5, 2015

It's as close to Panamax's templates as it is to a fig.yml. My point is that I'd like to take it a step further: rather than use a different abstraction to bundle containers together, why not bundle them into something which is itself a container?

Otherwise, Docker feels like a data structure that can only contain scalars.

Peeja commented Jan 5, 2015

It's as close to Panamax's templates as it is to a fig.yml. My point is that I'd like to take it a step further: rather than use a different abstraction to bundle containers together, why not bundle them into something which is itself a container?

Otherwise, Docker feels like a data structure that can only contain scalars.

@tcoats

This comment has been minimized.

Show comment
Hide comment
@tcoats

tcoats Jan 14, 2015

@aanand I propose allowing multiple .yml files in a directory and using the name of the file as the name of the group. This would keep the simple fig format and allow more freedom of configuration files and directory layouts.

I've written tugboat - a command line tool similar to fig that uses individual .yml files for each group. The .yml file format is identical to fig however the group concept is a first class citizen in the command.

e.g.

ping.yml:

google:
  image: ubuntu
  command: ping google.com
facebook:
  image: ubuntu
  command: ping facebook.com

tug up ping will create test_google and test_facebook containers.
tug up ping google will create test_google only.
tug has other commands: start, stop, rm, down, cull, diff.
tug ps shows a high level summary of which groups have running containers.
tug ps ping shows a more detailed breakdown for just the ping group.

The tug tool can be installed with npm install -g tugboat. It is written in Node.js but could easily be ported to Go.

The great thing about allowing multiple group .yml files in a single directory is that a project can ship with different groups for different purposes. Another example of this flexibility is that in our production environment we're using a single directory on our servers that contains all the groups we use. This is the authoritative location for all the configuration for our datacenter. The .yml files also bind sub folders of this directory for providing configuration to our docker containers. Host specific configuration is performed with environment variables.

I've also written a tool and docker container to sync running groups with consul. I've found it's a great way to provide an elastic architecture. The tugboat-consul daemon sits on a directory of .yml group files and exposes a directory in the consul key value store with the name of the host. From consul .yml file group names can be added to this directory - the daemon detects the change and issues a tug up [groupname] which does a diff against what is currently running. When items are deleted the daemon issues tug cull [groupname] as well.

From the consul ui we have a folder that has a list of all our docker capable hosts inside a datacenter. Inside each of these directories we can see what is currently running, and add and remove services dynamically. This is especially useful when we burst. We don't know in advance the hostname of our elastic instances. Once provisioned from our image they show up in consul where we can instruct them what to run.

This is our swarm + compose solution - tugboat + consul.

Thoughts?

tcoats commented Jan 14, 2015

@aanand I propose allowing multiple .yml files in a directory and using the name of the file as the name of the group. This would keep the simple fig format and allow more freedom of configuration files and directory layouts.

I've written tugboat - a command line tool similar to fig that uses individual .yml files for each group. The .yml file format is identical to fig however the group concept is a first class citizen in the command.

e.g.

ping.yml:

google:
  image: ubuntu
  command: ping google.com
facebook:
  image: ubuntu
  command: ping facebook.com

tug up ping will create test_google and test_facebook containers.
tug up ping google will create test_google only.
tug has other commands: start, stop, rm, down, cull, diff.
tug ps shows a high level summary of which groups have running containers.
tug ps ping shows a more detailed breakdown for just the ping group.

The tug tool can be installed with npm install -g tugboat. It is written in Node.js but could easily be ported to Go.

The great thing about allowing multiple group .yml files in a single directory is that a project can ship with different groups for different purposes. Another example of this flexibility is that in our production environment we're using a single directory on our servers that contains all the groups we use. This is the authoritative location for all the configuration for our datacenter. The .yml files also bind sub folders of this directory for providing configuration to our docker containers. Host specific configuration is performed with environment variables.

I've also written a tool and docker container to sync running groups with consul. I've found it's a great way to provide an elastic architecture. The tugboat-consul daemon sits on a directory of .yml group files and exposes a directory in the consul key value store with the name of the host. From consul .yml file group names can be added to this directory - the daemon detects the change and issues a tug up [groupname] which does a diff against what is currently running. When items are deleted the daemon issues tug cull [groupname] as well.

From the consul ui we have a folder that has a list of all our docker capable hosts inside a datacenter. Inside each of these directories we can see what is currently running, and add and remove services dynamically. This is especially useful when we burst. We don't know in advance the hostname of our elastic instances. Once provisioned from our image they show up in consul where we can instruct them what to run.

This is our swarm + compose solution - tugboat + consul.

Thoughts?

@richardolsson

This comment has been minimized.

Show comment
Hide comment
@richardolsson

richardolsson Jan 23, 2015

I definitely think having a single file format is preferable over having many. Fragmentation (of documentation, mainly, but also other aspects) can be devastating for any project.

I also like the "Stackfile" name, without the suffix. The "stack" analogy is nicer than the "group" analogy IMO, even though it's less ambiguous and might, strictly speaking, be semantically incorrect for some set-ups (which are not actually stacks).

I definitely think having a single file format is preferable over having many. Fragmentation (of documentation, mainly, but also other aspects) can be devastating for any project.

I also like the "Stackfile" name, without the suffix. The "stack" analogy is nicer than the "group" analogy IMO, even though it's less ambiguous and might, strictly speaking, be semantically incorrect for some set-ups (which are not actually stacks).

@xiaods

This comment has been minimized.

Show comment
Hide comment
@xiaods

xiaods Jan 23, 2015

Contributor

Just like Dockerfile convention, Stackfile is ok for the purpose. cc @richardolsson

Contributor

xiaods commented Jan 23, 2015

Just like Dockerfile convention, Stackfile is ok for the purpose. cc @richardolsson

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jan 23, 2015

Contributor

All: Docker Compose 1.1.0 RC1 is out: https://github.com/docker/fig/releases/tag/1.1.0-rc1

Contributor

aanand commented Jan 23, 2015

All: Docker Compose 1.1.0 RC1 is out: https://github.com/docker/fig/releases/tag/1.1.0-rc1

@mainiak

This comment has been minimized.

Show comment
Hide comment

mainiak commented Jan 23, 2015

👍

@noirbizarre

This comment has been minimized.

Show comment
Hide comment
@noirbizarre

noirbizarre Jan 28, 2015

Good initiative to have chosen fig as starter for docker-compose but, if I may, I think docker-compose is a way too long name for a command line tool.
It's all about comfort and readability.
In a script it does not matter, but in an every day developper shell workflow, the difference is noticeable:

fig stop && fig rm --force && fig run -d && fig ps

became

docker-compose stop && docker-compose rm --force && docker-compose run -d && docker-compose ps

The docker prefix prevent tab completion to directly give me docker-compose as docker is in the list.

I know this is far from being a major point, but it already bothered me since I've switched from fig to docker-compose yesterday.
I thought you should be aware of it.

Why not having a shortcut like:

  • dcomp
  • compose
  • stack or dstack
  • ...
    Or, why not keep the original projet name: fig ?

Good initiative to have chosen fig as starter for docker-compose but, if I may, I think docker-compose is a way too long name for a command line tool.
It's all about comfort and readability.
In a script it does not matter, but in an every day developper shell workflow, the difference is noticeable:

fig stop && fig rm --force && fig run -d && fig ps

became

docker-compose stop && docker-compose rm --force && docker-compose run -d && docker-compose ps

The docker prefix prevent tab completion to directly give me docker-compose as docker is in the list.

I know this is far from being a major point, but it already bothered me since I've switched from fig to docker-compose yesterday.
I thought you should be aware of it.

Why not having a shortcut like:

  • dcomp
  • compose
  • stack or dstack
  • ...
    Or, why not keep the original projet name: fig ?
@madwire

This comment has been minimized.

Show comment
Hide comment
@madwire

madwire Jan 28, 2015

@noirbizarre I have to agree, its rather annoying

madwire commented Jan 28, 2015

@noirbizarre I have to agree, its rather annoying

@noirbizarre

This comment has been minimized.

Show comment
Hide comment
@noirbizarre

noirbizarre Jan 28, 2015

@madwire Thanks to support it. I was affraid nobody cares since nobody raised the point !

@madwire Thanks to support it. I was affraid nobody cares since nobody raised the point !

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Jan 28, 2015

Member
alias fig='docker-compose'
Member

dnephin commented Jan 28, 2015

alias fig='docker-compose'
@noirbizarre

This comment has been minimized.

Show comment
Hide comment
@noirbizarre

noirbizarre Jan 28, 2015

Yep, that's what I did but it's kind of hackish, no ?
And, it breaks projects still using fig (I have some)

Yep, that's what I did but it's kind of hackish, no ?
And, it breaks projects still using fig (I have some)

@Stono

This comment has been minimized.

Show comment
Hide comment
@Stono

Stono Jan 30, 2015

I have this as part of my cookbook which configures the box for dockerness

ln -s /usr/bin/docker-compose /bin/fig

Stono commented Jan 30, 2015

I have this as part of my cookbook which configures the box for dockerness

ln -s /usr/bin/docker-compose /bin/fig
@funkyfuture

This comment has been minimized.

Show comment
Hide comment
@funkyfuture

funkyfuture Jan 30, 2015

it should be ln -s … /usr/local/bin/fig

it should be ln -s … /usr/local/bin/fig

@ferdynice

This comment has been minimized.

Show comment
Hide comment
@ferdynice

ferdynice Feb 2, 2015

I think it is silly to use 'fig' as a recommended alias, because this will confuse anyone not familiar with the project's origin.

Since 'compose' and 'dc' already seem to be existing commands and 'dcom' is too Microsofty, I'm in favor of 'dcomp'.

On second thoughts 'doco' is really fast to type, beats 'dcomp' by a mile. Anyway just my 2 cents.

I think it is silly to use 'fig' as a recommended alias, because this will confuse anyone not familiar with the project's origin.

Since 'compose' and 'dc' already seem to be existing commands and 'dcom' is too Microsofty, I'm in favor of 'dcomp'.

On second thoughts 'doco' is really fast to type, beats 'dcomp' by a mile. Anyway just my 2 cents.

@olalonde

This comment has been minimized.

Show comment
Hide comment
@olalonde

olalonde Feb 3, 2015

Some name inspiration:

  • Crane: machine used to place containers on cargos

crane

olalonde commented Feb 3, 2015

Some name inspiration:

  • Crane: machine used to place containers on cargos

crane

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Feb 3, 2015

Member

I'm in favor of 'dcomp'.

That sounds like "de-comp" / "de-compose". I don't like the smell of that :)

@olalonde you realize "Crane" is an existing product? Similar to docker-compose, but (iirc) communicates with docker via the CLI in stead of the API

Member

thaJeztah commented Feb 3, 2015

I'm in favor of 'dcomp'.

That sounds like "de-comp" / "de-compose". I don't like the smell of that :)

@olalonde you realize "Crane" is an existing product? Similar to docker-compose, but (iirc) communicates with docker via the CLI in stead of the API

@ferdynice

This comment has been minimized.

Show comment
Hide comment
@ferdynice

ferdynice Feb 3, 2015

@thaJeztah
Good point. For now I am using 'doco'.

@thaJeztah
Good point. For now I am using 'doco'.

@almereyda

This comment has been minimized.

Show comment
Hide comment
@almereyda

almereyda Feb 4, 2015

When I look at crane and fig and (RIP) gaudi, I really want to see this kind of orchestration minimally standardized.

When I look at crane and fig and (RIP) gaudi, I really want to see this kind of orchestration minimally standardized.

@olalonde

This comment has been minimized.

Show comment
Hide comment
@olalonde

olalonde Feb 5, 2015

@olalonde you realize "Crane" is an existing product?

@thaJeztah no I didn't :)

Personally, dcomp also make me think of de-compose. doco is not bad but it is very similar to docco which is a widely used documentation generator for Javascript code (http://jashkenas.github.io/docco/). I think docko would be better if anything.

olalonde commented Feb 5, 2015

@olalonde you realize "Crane" is an existing product?

@thaJeztah no I didn't :)

Personally, dcomp also make me think of de-compose. doco is not bad but it is very similar to docco which is a widely used documentation generator for Javascript code (http://jashkenas.github.io/docco/). I think docko would be better if anything.

@wernight

This comment has been minimized.

Show comment
Hide comment
@wernight

wernight Feb 6, 2015

"Crane" even taken, sounds really good (and since Fig and Crane and Docker Compose seem to try going the same thing the same way, why not have a good strong official one doing that).

wernight commented Feb 6, 2015

"Crane" even taken, sounds really good (and since Fig and Crane and Docker Compose seem to try going the same thing the same way, why not have a good strong official one doing that).

@madwire

This comment has been minimized.

Show comment
Hide comment
@madwire

madwire Feb 6, 2015

@wernight thats what this proposal is about, also fig is docker compose as its undergoing a name change.

madwire commented Feb 6, 2015

@wernight thats what this proposal is about, also fig is docker compose as its undergoing a name change.

@marcellodesales

This comment has been minimized.

Show comment
Hide comment

+1 on Crane!

@almereyda

This comment has been minimized.

Show comment
Hide comment
@almereyda

almereyda Feb 12, 2015

As in

docker crane mv sdc:local sdc:almereyda@remote.host.tld --verbose

which initiates a move, for example? Does this require we're all using ZFS soon*?

Just want to keep up on the direction we're taking here. Especially also in terms of CoreOS' and btrfs plus the APIs to generalize able interfaces like Panamax, ex-Gaudi, Cockpit, dockerboard and the likes?


*Where sdc stands for a vocabulary that defines a Secure Docker Crane at the endpoint.

As in

docker crane mv sdc:local sdc:almereyda@remote.host.tld --verbose

which initiates a move, for example? Does this require we're all using ZFS soon*?

Just want to keep up on the direction we're taking here. Especially also in terms of CoreOS' and btrfs plus the APIs to generalize able interfaces like Panamax, ex-Gaudi, Cockpit, dockerboard and the likes?


*Where sdc stands for a vocabulary that defines a Secure Docker Crane at the endpoint.

@alexisvincent

This comment has been minimized.

Show comment
Hide comment
@alexisvincent

alexisvincent Feb 14, 2015

In terms of the arguments to keep compose separate from docker cli. Can we not do the following:

  • Keep them separate -> All the benefits of a separate codebase.
  • Have a 'docker compose / docker up' command which forwards to compose -> better ux
  • This could also check compose versions and prompt the user to update compose if outdated.

This type of rig makes more sense to me.

In terms of the arguments to keep compose separate from docker cli. Can we not do the following:

  • Keep them separate -> All the benefits of a separate codebase.
  • Have a 'docker compose / docker up' command which forwards to compose -> better ux
  • This could also check compose versions and prompt the user to update compose if outdated.

This type of rig makes more sense to me.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Feb 16, 2015

Contributor

Attention, all: work is progressing on Docker Compose, based on the Fig codebase. A release candidate is out.

https://github.com/docker/fig/releases/tag/1.1.0-rc2

Contributor

aanand commented Feb 16, 2015

Attention, all: work is progressing on Docker Compose, based on the Fig codebase. A release candidate is out.

https://github.com/docker/fig/releases/tag/1.1.0-rc2

@wernight

This comment has been minimized.

Show comment
Hide comment
@wernight

wernight Feb 18, 2015

I found docker-compose requires Docker 1.4+. This wasn't for Fig. Should
probably be written somewhere if that's the case, no?

On Mon Feb 16 2015 at 5:33:59 PM Aanand Prasad notifications@github.com
wrote:

Attention, all: work is progressing on Docker Compose, based on the Fig
codebase. A release candidate is out.

https://github.com/docker/fig/releases/tag/1.1.0-rc2


Reply to this email directly or view it on GitHub
#9694 (comment).

I found docker-compose requires Docker 1.4+. This wasn't for Fig. Should
probably be written somewhere if that's the case, no?

On Mon Feb 16 2015 at 5:33:59 PM Aanand Prasad notifications@github.com
wrote:

Attention, all: work is progressing on Docker Compose, based on the Fig
codebase. A release candidate is out.

https://github.com/docker/fig/releases/tag/1.1.0-rc2


Reply to this email directly or view it on GitHub
#9694 (comment).

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Feb 18, 2015

Contributor

@wernight Compose should work with Docker 1.3 - if it doesn't, please open an issue!

Contributor

aanand commented Feb 18, 2015

@wernight Compose should work with Docker 1.3 - if it doesn't, please open an issue!

@jghibiki

This comment has been minimized.

Show comment
Hide comment
@jghibiki

jghibiki Feb 19, 2015

Another idea for a name:

docker shipment

or for short

docker ship

Rationale: A fig.yml comprises of a "shipment" of services.

Another idea for a name:

docker shipment

or for short

docker ship

Rationale: A fig.yml comprises of a "shipment" of services.

@baptistedonaux

This comment has been minimized.

Show comment
Hide comment
@baptistedonaux

baptistedonaux Feb 20, 2015

@aanand I use Compose 1.1.0-rc2 with 1.3.3. It works

@aanand I use Compose 1.1.0-rc2 with 1.3.3. It works

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Feb 26, 2015

Contributor

Compose has now been released and is available here: http://docs.docker.com/compose/

Contributor

bfirsh commented Feb 26, 2015

Compose has now been released and is available here: http://docs.docker.com/compose/

@bfirsh bfirsh closed this Feb 26, 2015

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Feb 26, 2015

Contributor

Thanks all for your feedback!

Contributor

bfirsh commented Feb 26, 2015

Thanks all for your feedback!

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Mar 23, 2015

Member

@sanchitiks the GitHub issue tracker is not a support forum. If you need support using docker or docker-compose, please ask you question in the #docker-compose or #docker IRC channel, on https://forums.docker.com or the docker-user group on Google Groups.

Member

thaJeztah commented Mar 23, 2015

@sanchitiks the GitHub issue tracker is not a support forum. If you need support using docker or docker-compose, please ask you question in the #docker-compose or #docker IRC channel, on https://forums.docker.com or the docker-user group on Google Groups.

@JemiloII

This comment has been minimized.

Show comment
Hide comment
@JemiloII

JemiloII Apr 29, 2015

I'm posting my bit of knowledge here. Don't worry about the tcp ports. Just locate your docker.sock file. Mine was in /run/ others could be in /var/run and use that path for DOCKER_HOST

export DOCKER_HOST=/run/docker.sock worked for me
export DOCKER_HOST=/path/to/docker.sock should work for you.

I'm posting my bit of knowledge here. Don't worry about the tcp ports. Just locate your docker.sock file. Mine was in /run/ others could be in /var/run and use that path for DOCKER_HOST

export DOCKER_HOST=/run/docker.sock worked for me
export DOCKER_HOST=/path/to/docker.sock should work for you.

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