Develop and deploy an app with Fig and 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.
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:
db: image: orchardup/postgresql web: build: . command: gunicorn -b 0.0.0.0:8000 figexample.wsgi:application ports: - "80:8000" links: - db
You’ll also need to add
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
- 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 126.96.36.199
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  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 188.8.131.52 $ curl 184.108.40.206 ...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 manage.py runserver ... Up 80->8000/tcp
If anything goes wrong, you can tail the logs of your containers:
$ fig logs
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
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.