Add script which runs Fig inside Docker

[bfirsh]

Handy for development. Works something like this:

$ cd ../afigproject
$ ../fig/script/dev up

Maybe needs a better name? Should we update CONTRIBUTING.md?

[dnephin]

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

[josephpage]

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

[dnephin]

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.

[josephpage]

@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.

[bfirsh]

@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 :)

[bfirsh]

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

[thaJeztah]

Then: docker run fig

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

[bfirsh]

@thaJeztah Yep. Baby steps. ;)

[josephpage]

@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.

[dduportal]

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 ?

[crosbymichael]

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

[dduportal]

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

[bfirsh]

Here we go: #661

[bfirsh]

Rebased with #661.

[dnephin]

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

[thaJeztah]

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

[ewindisch]

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

[thaJeztah]

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

[bfirsh]

@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

[dnephin]

So I guess the tradeoff here (vs using an official image that gets pulled on the first run) is that it's probably a bit faster the first run, but a bit slower on subsequent runs. Even with the cache, it's still going to take a second or two to run each time, right?

That seems ok for a first pass, but we should really consider moving to just pulling an image from the docker registry.

[aanand]

Perhaps we should follow the same logic as docker run: attempt to run, check for the "No such image" error, build the image and try again.

For actual distribution, I agree - we should be pulling a tagged image from the registry.

[bfirsh]

👍 and the image should just have the built binary in it. See: https://github.com/docker/swarm-library-image

This is just for development, however.

[aanand]

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.

[bfirsh]

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

[aanand]

LGTM

[lmakarov]

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