One of the assumptions of octohost is that the code that you git push over, turn into a Docker container and run are ‘immutable’ - they don’t change at all. No file uploads. No databases inside the container.
If you’re used to working with Heroku, then this is no surprise at all - but you still may need to connect to a database, or NoSQL data-store.
octohost has some basic support for data stores but it’s still not apparent to me that running MySQL, Postgresql or other data store is a good idea inside of a Docker container.
I was working on a problem this weekend - not a super hard problem - but an annoying one:
When you've got a system that is supposed to trigger at certain times, how can you verify that it's actually happening? The system I was working with is web based - hit a specific URL at a specific time. It’s called keepalive and it runs on Heroku. It hits a few URLs daily - but I wanted to make sure:
100 days ago, I made a goal for myself to commit something to Github every day.
I was feeling a little stagnant and wanted to challenge myself and make sure that I was learning every day.
100 days later, I feel like I’ve kept my momentum.
I’ve written Chef cookbooks, created a Chef skeleton framework for myself, built a few websites, started an entire project - octohost, posted to my blog, learned about a whole bunch of new technologies: Serf, Docker, Laravel, built a whole bunch of AMIs, Droplets and Rackspace Images with Packer and Vagrant, wrote an article for Sysadvent, learned about Ansible, built some packages, updated some Heroku buildpacks, released a Capistrano 3 example repo and lots of other things.
A few days ago, I found out about Dweet.io which is billed as “Ridiculously simple data sharing for the Internet of Things.”
The entire concept was pretty interesting to me. I liked the simplicity of it, and how it was so transient - made for machines to talk to machines. I also liked that if a message wasn’t picked up in 24 hours, then it clearly wasn’t important and that message disappeared.
On our main octohost.io test server, we are running all sorts of different web applications.
When we deployed this octohost, we pointed a wildcard dns record to: 54.244.116.169
Every time we push a new container, the octohost knows the name of the git repository and tells Hipache to direct all requests for “name-of-git-repo.octohost.io” to that container.
You can also add additional domain name records into a CNAME file inside the repository.
We’ve been working on speeding up our Docker deploys over the last little while. We took deploys of a simple Harp site from 40 seconds to approximately 3 using this method - but we were still running the Harp server.
The Harp server took approximately 20-30MB of RAM at version 0.8 - but had balooned to approximately 60-80MB at version 0.11. We wanted to use the newer Harp, but tripling the memory usage was a bit of a problem.
Friday evening I needed to replace a SSH key for one of my developers. I was trying to get out of the office and start the weekend, but since I was heading out of town, I wanted it done right now.
My chef-client runs were failing mysteriously and I had no idea what was going on - that seems to be a bigger problem - but I needed this done right now.
I wanted to build an octohost using Packer and a Rackspace OpenStack Image, but I needed a few environment variables to be setup correctly.
Googling for what should be in the ENV variables gave all sorts of contradictory results - here’s what works:
# Rackspace export SDK_USERNAME="username" # Same as here: https://mycloud.rackspace.com/ export SDK_PASSWORD="password-to-login" # Not the API key. export SDK_PROVIDER="rackspace-us" # Or rackspace-uk Just posting this here for Google - hopefully you find this and it helps you - I was frustrated for quite a while.
Saw this link here that talks about installing a Ruby gem to help create a good Chef cookbook.
It’s a great idea, and if you haven’t built any already, it’s a great start. But as time goes on - you may find that you don’t really like how that particular system does it - or you want to change things. Somtimes those changes aren’t a great fit for the main repo (which you don’t control).
I have been working on setting up a new Linux system at home and have been using LVM on it.
I have been wanting to use LVM while I build this box so that I can reset:
In case things go wrong and I break things. (Like I have been doing for a couple of days already.) During the build so I can recreate the entire process using Chef Cookbooks at each step.