Seems reasonable to me. Maybe add these comments (usage and purpose) from the PR into the script as documentation?

Running Fig inside Docker is also the only way to run fig on Windows. See #599
An official fig image should be more convenient for inclusion in boot2docker : boot2docker/boot2docker#603

I also really like the idea of an official image for this. I believe we can add that as a step to the wercker build.

@dnephin Great. I'm thinking about adding a "official-image" folder in the root of this repo with the Dockerfile of dduportal/fig image @dduportal :
https://registry.hub.docker.com/u/dduportal/fig/dockerfile/
https://github.com/dduportal/dockerfiles/tree/master/fig

Have you imagined something more minimalist ?

I can make the whole process, from writing README.md to submitting PR to docker-library/official-images.

@josephpage The official image should be the Dockerfile in the root of this repository. I think the only change that is needed is to have an entrypoint of fig and to update the test scripts that use that image to override the entrypoint. Then: docker run fig :)

Also: the official build should be stable versions, so Wercker doesn't need to do anything. Latest can point at the tag of the latest version on Git.

This kinda thing: https://github.com/docker-library/official-images/blob/master/library/crate

Then: docker run fig

Doesn't that require docker.sock to be mounted inside the container (or some other connection to the daemon)?

@thaJeztah Yep. Baby steps. ;)

@bfirsh

I think the only change that is needed is to have an entrypoint of fig

It works, but the official image will contain unnecessary build dependencies.
I believe official images should be minimal.

Hi all, there is an interesting discussion here :moby/moby#8637 .
This is the @aanand proposal for "docker groups", a.k.a. "fig in docker" as a core function of docker.

My thought is : Which energy should we spend to "perfectly Dockerize" fig in an official image, given that it should probably integrated as part of Docker in a near future ?

So on, the @josephpage proposal seems a good idea : his contribution to my image seems really lightweight and simple : from a debian:wheezy image, he just add the fig binary, re-using the description of an entrypoint to fig, making it really usefull for people coming from Windows world.

See boot2docker/boot2docker#603, boot2docker/boot2docker#603 or #599 for example => made me think that official image should be a good starting point for "now".

As addon about Dockerfile considerations, i personnaly use these guidelines :

• http://jonathan.bergknoff.com/journal/building-good-docker-images
• http://crosbymichael.com/dockerfile-best-practices.html
• http://crosbymichael.com/dockerfile-best-practices-take-2.html

It state some rules (not mandatory, but i really think its goods idea) to not embed dev. env inside production targeted container, which should be the case.
My proposal of contribution, as addon of @josephpage 's one (we'll group our works if OK) is to define to Dockerfile here :

• One for developing/compiling fig a.k.a. "fig-dev" docker image
• One for the "fig" in the Docker-spirit : make fig usage portable inside a container to not have dependency hell problem (yes we don't have to apt-get or something else when using fig, but the 32/64 bits problems of b2d, the non-compatibility of fig inside centos weeks ago, or the non compatibility today inside the busybox image are dependency-hell problems.).

Advices ?

@dduportal the links should be http not https, had to change some things around ,sry

@crosbymichael Thanks for the fix ! Links edited in the comment !

Here we go: #661

Rebased with #661.

I think it could use a short comment explaining what it's for, otherwise LGTM

This needs to be rebased/re-branded. A request for a script like this just came up in IRC :)

I put this together back in June. It does docker-in-docker, but could be modified to also support being given a socket (it might already work, but I haven't tried it)

https://github.com/ewindisch/figleaf
https://registry.hub.docker.com/u/ewindisch/figleaf/

Usage is to add a 'fig.yml' file to the current context and create a Dockerfile. One could do, for instance:

$ touch fig.yml   # You'd want to put actual content in this...
$ docker build -t my-figged-image - <<<"FROM ewindisch/figleaf"
$ docker run --privileged my-figged-image

Another option would be to run figleaf directly:

$ touch fig.yml
$ docker run --privileged -v $PWD:/opt/figapp ewindsich/figleaf

Thanks for sharing, @ewindisch, will give it a spin when I get home.

@aanand @dnephin Rebased and improved so it works as a symlink. :D

$ ln -s `pwd`/script/dev /usr/local/bin/docker-compose
$ cd /a/compose/project
$ docker-compose up

Seems to work well, except I had to remove the readlink for it to work - it was outputting an empty string. What purpose does it serve?

I'm concerned that you can't specify a docker-compose.yml path outside of the current directory. Perhaps we should mount /Users, just as boot2docker and Machine's VirtualBox driver do... or just document that if you're using a Compose file outside the current directory, you should docker run the image yourself and mount the right directory in.

Oops, that's to follow symbolic links, but it doesn't work when it's not a link. Fixed.

LGTM

Is there anything else that prevents the official docker-compose docker image set up? If not, who can do that?