-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Comments
As mentioned in #9459:
|
I like the idea of a |
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. |
I like the reduced ambiguity/size of TOML. My main complaint is that nesting is more verbose. Translating the
I'm not a huge fan of how the This might not end up being an issue, but it warrants consideration. |
@jokeyrhyme: yes, Compose should aim to cover every Docker CLI option. |
@aanand you can make this work too:
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. |
One issue I've seen with YAML in the wild (specifically in |
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... |
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. |
just like boot2docker, docker is already the owner of fig, why not enhance the fig to implement the docker compose feature? |
+1 on supporting multiple formats. Depending on your case, Should there be a "default" format? (Thinking of what format to use for examples in the documentation) |
share the fig multi host patch |
If we are requesting features, |
I don't think that is nescessary to implement in Compose; Compose should be able to talk to The only thing that compose has to take care of, is passing the constraints (ie, ports, memory etc) to Swarm to act on. |
@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. |
+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 One thing I'd really like to see is something like this (maybe it'd be built into
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. |
@nathanleclaire Agreed on validation, it's been needed for ages (docker/compose#129). It should always run when reading |
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.
|
+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... |
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. |
+1 fort single end user format. Like Nathan said, with a bit of syntax The argument for doc fragmentation is very relevant. Ppl will copy/paste More formats, more code, more bugs less features.
|
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. |
Echoing @craftgear in #9459 : If this is simply a proposal to improve fig, why create a new tool, rather than just ... improve fig? |
+1 to improve Fig! and integrate it into Docker. |
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? Think:
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. |
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 |
Agreed
|
it should be |
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. |
Some name inspiration:
|
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 |
@thaJeztah |
When I look at crane and fig and (RIP) gaudi, I really want to see this kind of orchestration minimally standardized. |
@thaJeztah no I didn't :) Personally, |
"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 thats what this proposal is about, also fig is docker compose as its undergoing a name change. |
+1 on Crane! |
As in
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 *Where |
In terms of the arguments to keep compose separate from docker cli. Can we not do the following:
This type of rig makes more sense to me. |
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 |
I found docker-compose requires Docker 1.4+. This wasn't for Fig. Should On Mon Feb 16 2015 at 5:33:59 PM Aanand Prasad notifications@github.com
|
@wernight Compose should work with Docker 1.3 - if it doesn't, please open an issue! |
Another idea for a name:
or for short
Rationale: A fig.yml comprises of a "shipment" of services. |
@aanand I use Compose 1.1.0-rc2 with 1.3.3. It works |
Compose has now been released and is available here: http://docs.docker.com/compose/ |
Thanks all for your feedback! |
@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. |
I'm posting my bit of knowledge here. Don't worry about the tcp ports. Just locate your
|
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:
Separate tool
The arguments in favour of building Compose directly into the Docker client are based on usability issues we’ve observed with Fig:
However, there are also usability arguments against building it in:
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:
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.
The text was updated successfully, but these errors were encountered: