0. General thoughts
I didn’t find the documentation easy to navigate. I spent more time looking for what I needed than I did with Heroku.
I was surprised that DotCloud didn’t offer a way to run or test your application locally. This is the company that brought us Docker so I figured I’d get to use it locally to set up my image.
As you’ll see below, it’s surprisingly not easy to run a staging and production version of your app in DotCloud.
1. Provision redis
Adding Redis to my application was super easy. I added two lines to my dotcloud.yml file and I had a redis stack.
data: type: redis
2. Deploy the daemon
- You configure what to run using a Supervisord config file. The one I used for twitter-dedupe was pretty simple.
- You deploy your code using aDotCloud’s command line tool:
DotCloud has git and hg integrations but I couldn’t tell from the documentation if I could select which branch gets pushed to DotCloud each time I invoke dotcloud push.
3. Access the logs
During development and for live troubleshooting there’s a handy command to tail the logs live:
There weren’t any built-in connections between DotCloud and Loggly.
That meant diving in and configuring syslog on my DotCloud container and wiring it up to Loggly’s syslog endpoint, or wiring Loggly into my application itself. Neither seemed appealing so I skipped it.
4. Do it all again for a staging environment
I couldn’t find any documentation or best practices for running multiple copies of the same application on DotCloud.
Each folder my computer could be tied to one, and from what I can tell, only one DotCloud application.
So to duplicate my application and having a staging environment I followed all the steps to set up my application again in a different folder.
I ended up with something like this:
dotcloud/ ├── slateliteprd │ ├── dcdaemon.py │ ├── dotcloud.yml │ ├── requirements.txt │ └── supervisord.conf └── slatelitetst ├── dcdaemon.py ├── dotcloud.yml ├── requirements.txt └── supervisord.conf