Skip to content

Add script which runs Fig inside Docker #619

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.

Sign up for GitHub

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

Merged
aanand merged 1 commit into from
Feb 23, 2015
Merged

Add script which runs Fig inside Docker #619

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .dockerignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
.git
venv
21 changes: 21 additions & 0 deletions script/dev
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
#!/bin/bash
# This is a script for running Compose inside a Docker container. It's handy for
# development.
#
# $ ln -s `pwd`/script/dev /usr/local/bin/docker-compose
# $ cd /a/compose/project
# $ docker-compose up
#

set -e

# Follow symbolic links
if [ -h "$0" ]; then
DIR=$(readlink "$0")
else
DIR=$0
fi
DIR="$(dirname "$DIR")"/..

docker build -t docker-compose $DIR
Copy link

@dnephin dnephin Feb 12, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@aanand aanand Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@bfirsh bfirsh Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

exec docker run -i -t -v /var/run/docker.sock:/var/run/docker.sock -v `pwd`:`pwd` -w `pwd` docker-compose $@
Copy link

@dnephin dnephin Feb 12, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't support alternative paths for DOCKER_HOST.

Copy link

@aanand aanand Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean? docker run will pick up DOCKER_HOST; the only assumption this line makes is that, wherever docker is running (i.e. on this machine, in a VM or in the cloud), it's also listening at /var/run/docker.sock so that can be mounted into the Compose container.

For Linux users and Mac folks using boot2docker, that's always going to be true. Arguably less certain in the case of remote servers and Swarm clusters, though.

Copy link
Author

@bfirsh bfirsh Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this makes the assumption that /var/run/docker.sock is available on the Docker host, but that's pretty much universally the case.

Copy link
Member

@thaJeztah thaJeztah Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, actually, there's a PR to change that, apparently, /var/run is deprecated and /run/ is the new location; moby/moby#10567

Copy link

@dnephin dnephin Feb 13, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is going to be correct most of the time. We actually use a different socket path in development environments by setting DOCKER_HOST. This alternative path is so that we can put a proxy in front of dockerd. But I guess that is pretty rare.