I recently wrote a post about Docker and the basics of Tutum. One of Tutum's strengths is the ability to tag nodes (docker hosts) and services/containers, a feature that gives you fine-grained control over how and where things are deployed. This blog post is dedicated to the tagging feature and demonstrates how it can be used.
Our example app
To illustrate how Tutum's tags work, let us pretend we are developing an API (my-api) in node.js and along with that we are using a database, rethinkdb. For this API, we have certain demands on the hosting environment. Any production data needs to be hosted on-premise for backup and data-retention reasons. In other words, rethinkdb needs to run on a Tutum node that is a located on one of our own servers. As for the API itself, as it only relays information without storing anything, it can be hosted in a cloud environment. This also goes for both the API and the database in the testing phase. For this, we choose Microsoft Azure.
Simply put, this setup gives us two images and three node clusters.
- my-api - the node.js API built by us
- rethinkdb - stock rethinkdb image from Docker Hub
- CI - Continuous Integration
- ProdAPI - Production API
- SafeStorage - On-premise node, only accessible by the API code
First of all, we'd like a testing environment. So let's setup a node cluster for that. Head over to the Nodes tab in the Tutum dashboard and click "Launch new node cluster".
Once this node is up and running, head over to the Stacks area and click "Create stack". Make sure you build and deploy the my-api image before doing this. Read my previous post if you are unsure how to do this.
Our stack file will look something like this:
api: image: tutum.co/ilix/my-api ports: - 3000:3000 autoredeploy: true tags: - testing links: - db db: image: rethinkdb tags: - testing
Note the "tags" sections that both mention testing, like we specified the creating the node cluster in the previous step. When this stack is created, Tutum will launch one api container and one db container on the newly created CI node. The testing tag will ensure that these services will never be deployed on other nodes created in the future (as long as any of those are not configured with the same tag of course).
ProdAPI & SafeStorage
The Production API node will also be on a cloud server - so setting this up is pretty much the same as the CI/testing node. The only difference is the Deploy tags setting, which should read production and api, like this:
The SafeStorage node is a bit different. In the Nodes area on Tutum, click "Bring your own node" and run the script the UI presents. (I assume you have a linux server ready for this purpose.)
Once the SafeStorage node is up and running, edit it and add the following tags: production and db.
Now that all nodes are in place, it is time to setup the production stack. Head over to the Stacks area in Tutum and create a new one. Our stack file will look something like this for production:
api-prod: image: tutum.co/ilix/my-api:master ports: - 3000:3000 autoredeploy: true tags: - production - api links: - db-prod deployment_strategy: every_node db-prod: image: rethinkdb tags: - production - db
Note how I renamed the services a little, they are called api-prod and db-prod now. This is something I do to make sure it is easier to distinguish them in the Services area in Tutum.
The interesting stuff here is, not surprisingly, the tags. I have now set the services in this stack to use production on both as well as api and db respectively. This setup will ensure our fictional requirements; the api is hosted on a cloud server and the database is safely stored on our own server where we have control over disk redundancy and physical backups.
Also, I have set deployment_strategy: high_availability on the api service. This is a nice Tutum feature that makes sure the API will be deployed on every node instance that matches the set tags - very useful if you want to be able to quickly scale the API up.