Fig 1.0: Boot2docker compatibility and more

I didn't know about Crane. Time to go play with that!

Crane looks so perfectly simple and sweet

fig generally gets used for development environments since it's relatively easy to install docker, install fig, clone a repo and run `fig up` and get that application running correctly with all of its dependencies including database, background workers, etc. No more of the old "ok, install postgres, install the right gems, etc. just to make some small change in this project" song and dance!

However, it's perfectly suited to run in production for small to medium sized applications. You can even see a sample "Deploy on git push using fig" that I put together here:

https://github.com/nathanleclaire/laraveldocker

It's fun!

How many production environments deploy all containers on a single host?

Glad someone agrees with me :) For what it's worth, I resisted adding .dockerignore as long as I could, basically for the same reason (why not add .gitignore support instead?) but the demand for it was simply too overwhelming to ignore, so I gave up and let it in.

See https://github.com/docker/docker/pull/3452 and follow -up mailing list thread.

In the end it kind of grows on you :)

Usually I just have a very tiny .dockerignore with .git in it (since .git usually grows so huge), although some applications store logs and stuff that you should probably not send to the docker daemon every time.

I've found Github's auto-generated-by-language .gitignore files very useful.

Agree, I think ignore files are leaky abstractions. The problem is specificity.

It links docker containers for local dev environments. You can launch a project with say a webapp, a cache like redis, and a db like mysql with the comamnd 'fig up'. The 3 docker containers in this case are linked via a fig.yml that defines the setup. It also attaches your local development code so realtime changes propgate through the cotainer (e.g live server reloads)

Getting a new dev onboarded with your whole dockerized stack involves:

- pip install fig

- cd into directory with fig.yml

-'fig up'

Really a great tool. Definitely recommend it. Good intro here: http://www.fig.sh/

I keep thinking of it as kinda like foreman/Procfile but for Docker containers instead of bare processes. And with a much richer config format.

I haven't seen how it has evolved, but historically it has been basically the same as our Docker provider: http://docs.vagrantup.com/v2/docker/index.html

The other comments at this level saying Vagrant spins up a full VM are incorrect. Vagrant will spin up boot2docker if it isn't running (which Fig requires as well), and then just execute Docker to run containers. On Linux, Vagrant doesn't spin up a VM at all; it just executes Docker directly.

I'm not here to talk about Fig vs. Vagrant, since I think this thread should be about congratulating Fig to 1.0, but I did want to make sure that some facts aren't incorrect.

They are different tools for different use cases.

Fig is a tool written in Python specifically designed to orchestrate groups of docker containers. It does not require virtualization by default, it talks directly to the Docker API (so you can use it directly on Linux without boot2docker/VirtualBox). It is useful because previously people were writing their own custom little Bash scripts etc. to bootstrap containers for e.g. a PHP app to run app code, a MySQL database, a redis instance and an instance of nginx to serve static files which are all meant to be tied together and work together in a specific way. One of the goals of docker is "one concern per container" so this helps people to use it in the right way and you don't have to, say, restart your database to restart your app (like you would if you crammed them all into one container).

Vagrant is a general purpose tool for automation and management of virtual machines written in Ruby. You specify configuration in Ruby. One of its goals is choice, so it has swappable "drivers" (so that you can use different hypervisors such as VirtualBox, Fusion, and HyperV) and "provisioners" (for installing software etc. when you bootstrap a new VM). I'm afraid I have to plead ignorance on the Docker provisioner, but mitchellh is the creator so I'm sure his input is sound.

the concept is the same as Vagrant. but it's substantially faster. when you `fig up` your app, it spins up almost instantaneously because it's backed by Docker.

Similar ends, but different means. Vagrant would launch a full-blown VM (likely on the order of several minutes), whereas fig'ing will start a container (on the order of a few seconds).