Develop and deploy an app with Fig and Orchard

Fig makes development environments easy and repeatable. In this post we’re going to demonstrate how, with minimal changes to your configuration, you can deploy the same environment to Orchard.

First of all, get your app running on your local machine with Fig. If you don’t have an app to hand, try the Django example.

You’ll also need to sign up for Orchard and install the command-line-client.

Configuring for deployment

A few things need to change when using Fig with a remote Docker daemon. Create a separate copy of your fig.yml called something like fig-production.yml. Here’s what it should look like for the Django example:

  image: orchardup/postgresql
  build: .
  command: gunicorn -b figexample.wsgi:application
    - "80:8000"
    - db

You’ll also need to add gunicorn to requirements.txt.

If you’re deploying your own app, here are the important changes:

  • You can’t mount directories on your local machine inside containers—for example, if you’re mounting your code into a volume so you can change it without rebuilding the image. Remove any volumes entries like .:/code.
  • You shouldn’t be opening up sensitive services like your database to the world. Use expose instead of ports for services that only need to be visible to linked containers—or, if the image for the service has already exposed the port, you can remove the ports entry entirely.
  • If you’re deploying a web app, remember to map port 80 to the appropriate container.

Start a host

With Orchard, getting a remote host is ridiculously simple:

$ orchard hosts create
Default host running at

The Docker daemon running on that host isn’t accessible to just anyone. You can communicate it with it via orchard docker, or by opening up a persistent tunnel with orchard proxy, which we’ll start in the background:

$ orchard proxy &; sleep 2
[1] 15344
Started proxy. Use it by setting your Docker host:
export DOCKER_HOST=unix:///tmp/orchard-358146677/orchard.sock

Point Fig at Orchard

Now we just need to tell Fig to use your Orchard host and production fig file:

$ export FIG_FILE=fig-production.yml
$ export DOCKER_HOST=unix:///tmp/orchard-358146677/orchard.sock

And we’re ready to go.

$ fig up -d

Fig will use the Orchard host to build and start each of your services. When it’s all done, you should be able to access your app at the host’s IP address.

$ orchard hosts
NAME                SIZE                IP
default             512M      

$ curl
...HTTP response...

If it worked, your services will be running:

$ fig ps
     Name                    Command               State      Ports
figdjango_db_1    /usr/local/bin/run               Up
figdjango_web_1   python runserver ...   Up      80->8000/tcp

If anything goes wrong, you can tail the logs of your containers:

$ fig logs

Deploying changes

When you make changes to your app, you can redeploy thus:

$ fig build
$ fig up -d

To save time, you can specify the service(s) that have changed:

$ fig build web
$ fig up -d web

If a service you redeploy has dependent services linked to it, you’ll need to restart them too:

$ fig build db
$ fig up -d db web

When you’re done, shut down the proxy:

$ kill %1

Going further

As we’ve seen, Fig gives you enough to get a simple app running remotely. Taking it a step beyond, CenturyLink Labs have written some great posts on running and orchestrating more complex applications with Fig.

Auto-Loadbalancing Docker with Fig, HAProxy and Serf: Uses a Fig file and a container running Serf to load-balance multiple web containers behind an HAProxy container.

Building Complex Apps for Docker on CoreOS and Fig: Here, they use a tool called fig2coreos to convert a fig.yml into systemd config files, suitable for deployment to a CoreOS cluster.

Exciting stuff, and there’s lots more to explore.