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:
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 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 123.45.67.8
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 123.45.67.8
$ curl 123.45.67.8
...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
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.