I’ve heard a lot of stuff about Chef by Opscode some time ago but never actually gave it a try. Chef is a bundle of software that allows you to configure and install your servers by coding, not by entering commands. I fiddled with it one time but it was really hard to set up.

Because we’re launching our new server infrastructure on a new bigger Amazon instance in a fe days, I thought I’d give it a try.

The main reason I was looking for something like Chef was automation. In the past I would install every server manually and I didn’t have some predefined bash scripts for setting up a server, installing the base system and preconfigure Rails, PHP apps and things like backups. Chef allows me to do that now.

Our new server is going to run various apps. Our own website, some WordPress websites and mainly Ruby on Rails apps. Because we run some business-critical apps for our clients the server setup should be clean and certainly not hacked together, and we need external backups to S3 and be able to add another server to the pool when usage gets bigger – which is going to happen.

When you have Chef installed, you probably want to run a Chef Server and a Chef Client. The Chef Server keeps all the state of the server configuration for the configuration and installation scripts. The Chef Client actually reads the configuration and runs the script.

The chef clients runs multiple recipes that configure your server. For example, a recipe downloads apache or nginx via apt-get when you’re on Ubuntu, but could install an RPM if you are on an rpm-based distribution. The recipe is the actual script, but you can also store configuration attributes and download urls with the recipes. These little bundles of recipes and other configuration are called cookbooks.

We currently have the following cookbooks in our Chef repository:

Our Chef repository

Recipes can depend on other recipes from other cookbooks. For instance to install Phusion Passenger and nginx, I want to use the ruby_enterprise cookbook so it will first in stall the Phusion Ruby Enterprise Edition and then installes and configures nginx and passenger for it.

We use Scout App for monitoring the performance and usage of the instance and we use it so we receive warnings if something reaches critical numbers.

For Scout, I did not run the Scout agent as explained on their on website, but I created a recipe for it in the scout cookbook:

gem_package "scout" do
  action :install
end


gem_package "request-log-analyzer" do
  action :install
end

user "scout" do
  comment "Scout Agent User"
  home "/home/scout"
  supports :manage_home => true
end

execute "scout_first_run" do
  user "scout"
  command "scout #{node[:scout][:key]}"
  creates "/home/scout/.scout/client_history.yaml"
  cwd "/home/scout"
  returns 1
  action :run
end

cron "scout_run" do
  minute "*/5"
  command "scout #{node[:scout][:key]}"
end

What this recipe does it that it installs the gem “scout” using the gem_package Chef command. It then goes on to create a new system user for scout, run the scout agent for the first time and actually adds a cronjob to run it every 5 minutes.

You can see the code is quite clean and it doesn’t look like a hacked-together bash script and it doesn’t look as closed down as some kind of configuration database or .ini file. They are nice Ruby recipe’s for configuring stuff on your server.

You can see that I’m using the node[] variable a few times. The node variable is a Ruby hash of the current configuration the server (or node) is in that the client is being run. Using the web interface on the Chef server you can actually configure per-server configuration values. In our case, the Scout key would be different for every server.

You can do a l it more with these recipes like defining templates for files, default attributes, generating passwords but I’ll save that for another post.

The best thing about the recipes is that I can also communicate with the AWS API. The application cookbook you see there actually creates an EBS block storage devices and attaches it to the current node if it is not already created.

Because all state is saved in the Chef Server configuration database you can easily add more block storage devices or other external stuff just by running the Chef Client. The Chef client probes the server for all the current state the client is in and goes on upgrading all the new changes the recipes requested.

The status page in the Chef Server webapp

Hi all,

I had some downtime today so I’m sorry if you could not access this blog to get help on all the topics I right about. Everything should be fixed now. There seemed to be an error with our hosting provider. I’m trying to see if it was something major or if it was just a minor glitch in the power or connectivity or something.

Anyways, back up now so enjoy!

Update: It seemed there was an administrative error with the supplier of my hosting provider. Will not happen again!

I started using Heroku three weeks ago since @_micho from teambox.com recommended it to me. He told me they had a free app tier with some basic functionality and you can upgrade if you need more power or other functionality.

I’ve been testing it for deploying several development and staging apps the last two weeks and Everyday Feed already runs on it in a production-kind-of way. I’ve come to a conclusion: always deploy your first deployment on Heroku.

So, why is this?

1. Because Heroku is an app-based deployment service instead of an instance or server-based deployment service you can focus on the application and making it work, without having to worry about server installations, best deployment settings, software etc. You deploy your app on Heroku so you can fix your app, and not waste time on fixing your server.
2. Heroku is totally Git-based so it will force you have a good Git-workflow right away, from the start of your first deploy. One of the advantages of using Git is of course that your code is in version management and you can easily manage various feature sets and rollback to previous deployments, but it’ll also help you right away when you get more team members.
3. Heroku forces you to configure all your things that run around your app, like cronjobs, sending email, doing queuing and caching. Because Heroku forces you to work in a very automated and modular way you’ll never mess up your app’s code with external things. This make sure you configure everything nicely in external files or in the Heroku admin panel so you never hardcode things in your code.
4. Heroku is free. Well at least the first database package they have (up to 5MB). I like this from a business point-of-view because you can also scope what you spend on Heroku with your income of the app. I have a simpel rule with Everyday Feed: I will not upgrade Heroku until the application has some users or advertisers that are paying. This way I make sure people want to pay for the core functionality and add extra features from there, when I can buy more power at Heroku.

When you have your application up-and-running on Heroku, it is probably a very clean application with all configuration outside the application logic. This means you should easily be able to migrate to another server or your own EngineYard Cloud or EC2 load-balanced cloud environment because your app is not tied to a hardcoded server configuration.

When you move away, you can even keep using Heroku’s add-ons because they have a lot of partnerships with external services like New Relic and SendGrid when you move away.

Of course, you can also just stick with Heroku because from what I’ve heard they provide excellent application hosting for all your needs.

Everyday Feed started as a pet project about a week ago. I already scratched my own itch with building a service that actually let’s me read my feeds instead of skipping them. Also, this project is my way of researching and testing all the hints and tips I learned from Rework, Getting Real and Crush It.

I would really like you to test it, if the idea and functionality appeal to you. If not, you can of course also just give me feedback on design or copywriting topics if you’d like. I have some future ideas. For example I’d love to build a tablet-aware web app or an iPad app for reading the daily edition of your feed paper on mobile devices so that’s probably what I’m going to work on first. But if someone has a better idea, please let me know.

Head on over to everydayfeed.net, sign up and see if it’s useful for you. Thanks!

A little longer than two weeks ago, I talked about why the newspaper is going to rock, but that it’s not going to rock in it’s current form and that it’s not going to be owned by the big news companies.

In that post, my conclusion was that iPad/tablet-like devices are going to be the near future of consuming news. In my forecast of up to 5 years, I see a lot of  people reading their news(papers) on a tablet while commuting, traveling, on the airplane, at the office, etc. I hope this will happen even sooner with the release of the iPad in a few weeks and of course, the other tablet devices.

But, I also want to contribute to a new way of consuming news – especially online blogs, news portals, magazines and other kind of feed-like services. Because building an  iPad app is just one small step to far for me right now, today I’m announcing something else:

It is called Everyday Feed. It is a web service that allows you to read all the feeds you have like a newspaper. No, I don’t mean in a visual way but in an experience-kind of way: waking up, preparing breakfast, grabbing your newspaper along the ways and drinking some coffee. Everyday Feed will let you do that for your feeds.

Head over to the current website for more details at http://everydayfeed.net.

If you want a sneak preview, contact me directly via email, on Twitter or leave something in the comments.

This morning I got out of bed, made myself a bowl of cornflakes with milk and headed over to the kitchen table where my dad always puts down the newspaper I’m subscribed to: NRC Next. It’s a Dutch tabloid-format newspaper with daily news and in-depth articles around recent happenings in the world.

I recently resubscribed to it and I love it: I have redacted important news that fit’s to my size of wanting to read a newspaper. I just HATE folding around a large newspaper all the time. I want to have a portable newspaper that I can take with me, easily put in my bag and that falls on my doormat every day. Every night when I read the last less important articles in NRC Next, I’m already waiting for the new issue so I can enjoy another new newspaper-reading day.

So, that’s form and function. Now for the other great thing about NRC next: content.

I really HATE newspaper that just list all the news that happened the day before. They are just paper versions of the RSS feeds and news sites I refresh about 60 times a day. Those newspaper are old news in the morning and waste my time by reading the same content another time.

NRC Next provides in-depth articles and also covers topics that other newspapers do not cover like more Tech, Science and Philosophy. I like those topics in this paper because except from techcrunch.com I don’t really read about them, but they are actually the most important subjects in my life. NRC Next provides the most important “recent news” stories and than gets on to the good stuff.

Now, I think “old newspapers” are dying because of paper, because of the form and size they are printed on but also because they just provide “recent news”. All I see in most conventional newspapers is still the sum of stuff I’ve already read yesterday in my browser. They should cut that crap! Especially young internet-savvy people (25 and younger) already read those breaking news stories on the web. They get it trough sms, e-mail newsletters, blogs, RSS or refreshing newsportals 20 times a day. At least the more interested target group is interested in in-depth articles or articles about a not so well known topics: the niches. Most people tend to find content on niche blogs which are mostly amateur and the good ones are either popular and write about the same stuff from within a single standpoint or are hard to find.

I refresh techcrunch.com about 15 times a day because I won’t find that stuff in any newspaper.

So what would be the (or at least my) ideal newspaper?

My ideal newspaper is a newspaper where both journalists create but also just redact content. Professional journalists should have a moderation role over news and should add their own commentary about what they find. They should put together a newspaper with content from various sources and add their own content to it. Journalists are educated in filtering the crap articles and picking the right ones or the special ones. They can add some “recent news/breaking stories” articles, especially on bigger developing ones but they should but the crap with those small “a cat fell out of the tree and hit a car which caused a major accident”-kind of stuff. I already read that yesterday!

Also, I want to cut the paper out of newspaper. I have too many papers laying around all the time and I want to be able to view movies and stuff and listen to documentaries or audio clips while reading the articles. A device like the iPad would be ideal for this. I want to be able to drag, drop, click, view, interact, bookmark, sync and share the content the editors wrote and moderated for me. And I want to take my newspaper with me all the time and I want to be able to read it anywhere. And no, that doesn’t mean on a smartphone.

Have you seen the sizes of those screens? When reading a paper I scan, I look at the pictures beside it, I switch between articles etc. That’s just nog possible on the screen size of smart phone. A laptop? No. I don’t need a keyboard when reading the newspaper, I don’t want to open/close my lid every time I switch trains when commuting, talk to somebody at the office, go out lunch or just switch channels on my TV. I want it to “feel” like a traditional paper tabloid-size version so I can carry it around everywhere without fuzz.

So the last thing I would like to add that relates to content and realtime and carrying the device. Carrying the device with you DOES NOT mean that I want to update it all the time! When I get a lot of great articles in the morning I don’t want them to be lost in the stream all the news stories in the world. The professionals behind the paper can select and moderate them for me until I get my new newspaper release the next morning and leave out all the unimportant or boring stuff. The state should be maintained in every release. I want to be sure that when I wake up there is a great new digital and interactive release of that days paper and I want to be sure that it’s still there when I get home in the evening or go to lunch so I can read on where I left off.

I want a newspaper where content is moderated and written by professional journalists so I won’t have to do the moderation myself and check 2000 feeds every day. I want it to be interactive, be able to share and bookmark stuff. I want it to portable on a comfortable size. Not a phone size and not something sluggish like a laptop.

Finally I want the content to stay all day. I want to have that traditional newspaper feeling. In the evening, I want to have the traditional newspaper feeling that tomorrow there will be a great new newspaper release waiting for me to be consumed. I want to be sure that I’m never leaving any important piece behind and that the professional journalists will tell me the next day, if I do.

No, mainstream consumers are not ready for this yet, but I think they’re going to become very close in the next 2 – 4 years. I believe that in 6 years, everyone will be reading the news on an iPad-like device while commuting. And I believe this is currently the only way that non-internet-tech-journalist-savvy people can consume news in a better way.

I just wanted to share with you this presentation I created yesterday to communicate to other people and ourselves on how we use Scrum in Firmhouse. This is a first set of tools I’m creating for ourselves to get going with Scrum to create our products. But it can be a good piece of information for you too. The slides are great to keep as a reference on what kind of meetings you are going to have and what you need to discuss in them.

Expect more detailed Scrum and Agile Development stuff in the near future. We’re getting to an awesome workflow here. In the mean time, read 37signals excellent post about how they are going to approach development of new features in their products.

Here are the slides via SlideShare embed:

So I thought I’d give you an update on Qloudwatch. Qloudwatch is going to be the easy-to-use web service that allows you to get insights on your Amazon Web Services cloud usage, group your instances into project and set budgets and warnings for AWS instance costs.

We’ve been working really hard the past few weeks to get ready for a first public release. Bob is busy thinking about an honest and functional business model and researching our terms of service and I’m crunching feature development, tweaking, adding even better security.

What we’re currently looking at releasing in our first launch is the following:

• Create projects and give other people access so you can collaborate on a cloud project. Multiple users with different AWS accounts can be added to a project so you can share costs and get a good overview what your application or cloud team is using, spanning possibly multiple AWS account.
• Adding instances to project by accessing the AWS API with your AWS credentials. Yes, we do ask you to enter them into your account for now. Because of this, we’ve implemented SSL security and encryption into our database. Even in our demo period you can test right now at http://qloudwatch.com
• Give you total and monthly cost estimates based on the running hours of the instances in a project.
• A personal dashboard where you can get insights in the instances your personal AWS account is running.

We’re going to rapidly develop more statistics and are going to build in ways to collect better usage data from your instances if you choose to. If you want to influence our priorities, please give us some feedback of what statistics and overviews you would like to see first.

Here are some more sneak preview screenshots:

Amazon Web Services (AWS) is great and we use it as our #1 hosting infrastructure at Firmhouse. We still have some “old” traditional virtual servers laying around on some (also great) servers but we are slowly moving away from them to be totally scalable in a cloud environment.

There are however, one few problems with AWS if you’re hosting multiple websites or web applications on multiple instances for a variation of different clients and internal projects: you can’t keep track of costs and usage statistics in a categorized or budgetized manner.

Because we want to bill our clients what they are using from us (we do their managed hosting) and not give them some lame server package that is overpriced because of the overhead (100G they won’t be using) anyways, we want to give them an honest picture of what they are using and what virtual instances we have installed for them.

Amazon just gives you a credit card bill at the end of the month, which makes it  very hard to split all costs and usage into projects or budgets.

Also, Amazon bills you on one credit card but if you have multiple people working on one project with several AWS accounts, there is currently no way of getting some insights in what instances the members of a tream are launching and how much they cost all combined. All you get is $-signs on the credit card bills and the i-instance id’s in your management console(s).

And, budgets would really come in handy when you have a web application or piece of software that automatically scales itself on EC2 and launches instances by itself. Budgets shouldn’t mean terminating or stopping instances if the costs rise above a certain treshold but it would certainly come in handy if you would get a warning e-mail telling you the costs for this weeks where really of the charts so you could act accordingly and maybe re-thing your pricing strategy or make another business-wise decision.

BTW,  I should use another word for “budget”. I hate that word because usually involves guessing and the only thing you can guess is that your app shoud be scalable. But my usage of “budget” it should clarify my point. If you have another word, let me know

So, having that said:  *drumroll*

We’re Introducting Qloudwatch

We at Firmhouse have the need for solutions to these problems and we see these problems pop up in forums and mailing lists about AWS on other places we decided to get sweating and create a web app for this: Qloudwatch. We have a basic version up and running, so if you would like to try it please contact me at michiel@firmhouse.nl. The basic app currently has the following functionality:

• Create projects in which you can add instances recognized by the API in your AWS account.
• See the total cost of the project until “now” or view a history of the costs by month.
• Add billable and non-billable instances so you can for example bill all production instances to your clients and not bill your test instances.
• Invite other Qloudwatch users to a project so they can also add instances that can be set billable or non-billable so you can “share” statistics and costs on your instances.
• Get an automatic e-mail notification if you have running instances in your AWS account that you haven’t added to a project yet so you will never forget to categorize that one test hour you ran at 4 AM in the morning when your caffeine withdrawal started to kick in.

We would LOVE to know what you think: wether you disagree, wether you agree, what features you would like to see, if you would like to use the app for free, if you would like to swipe your card for it or if you have any other questions about our work on AWS. Let us know!

Here are some sneak preview screenshots:

At Firmhouse, we are working on a new web service and we’re releasing an in-development demo to everyone who is interested. Normally, in demo apps security is less the case and there is always some disclaimer that says you shouldn’t use real production data like passwords and API keys. In my opinion, this sucks because you allways want to use your real-life data to test a demo and see if it’s useful for you specifically. That’s why, the best way to have some security in your demo app is by using a self-signed SSL certificate to secure passwords and other sensitive account information your demo users will be adding.

For our web app, we use Ruby on Rails running on Phusion Passenger, served by Nginx.

This blog post will guide you trough the process of adding a self-signed SSL certificate to your Rails app, running on Phusion Passenger and Nginx by following these steps:

1. Generating the required SSL key and certificate files for use with nginx.
2. Recompiling the nginx server through the passenger-install-nginx-module command.
3. Configuring your web app in nginx to redirect non-secure connections to the secure address of the app with https:// and make sure www. will get redirected on both versions as well.

I use a few other blog posts in this article, so I would like to thank the authors for providing the information publicly and freely.

Ok, now let’s start:

1. Generating the required SSL key and certificate files

This step is largely taken from the Slicehost Articles: http://articles.slicehost.com/2007/12/19/ubuntu-gutsy-self-signed-ssl-certificates-and-nginx.

First of all, generate an SSL private key to sign your certificate with:

openssl genrsa -des3 -out myssl.key 1024

And enter a passphrase for the key which we will remove later on.

Now, we need to generate a Certificate Signing Request:

openssl req -new -key myssl.key -out myssl.csr

This command will ask you various questions. Fill them as you see fit. You can skip the extra attributes by just pressing enter when asked.

Now, we are going to remove the passphrase from your key by making a copy and then generating it back to the original file without entering a passphrase. You can do this with the following commands:

cp myssl.key myssl.key.org
openssl rsa -in myssl.key.org -out myssl.key
rm myssl.key.org

We now have a key file, and a csr file. We can use these to generate the actual SSL certificate with the following command:

openssl x509 -req -days 365 -in myssl.csr -signkey myssl.key -out myssl.crt

We should now move these files to the SSL configuration directory on your host. On Ubuntu, this is /etc/ssl/certs and /etc/ssl/private. Do this with the following commands (assuming you use sudo):

sudo cp myssl.crt /etc/ssl/certs/
sudo cp myssl.key /etc/ssl/private/

All required SSL key and certificate files are in place so we can continue with the next section: preparing nginx to be SSL-enabled with the passenger-install-nginx-module command.

2. Recompiling the nginx server with the passenger-install-nginx-module command

By default, the passenger-install-nginx-module command does not enable the SSL compile option in the default installation steps. Here’s how to use the custom build step to configure nginx with SSL.

First of all, be sure you already have nginx installed with the passenger-install-nginx-module command because this will have downloaded the nginx source code in /tmp, which you will need to enter in the custom build steps. If you haven’t already done this, run:

sudo passenger-install-nginx-module

Press enter after you’ve read the introduction message and choose step one “Yes: download, compile and install Nginx for me” by pressing `1′. (recommended) when the installer asks for the install options.

After nginx has been compiled and installed you can now run the

sudo passenger-install-nginx-module

command again. Press enter after you’ve read the introduction message and choose step two “No: I want to customize my Nginx installation. (for advanced users)” by pressing `2′.

You are now asked for the directory of the Nginx source code. The recommended installer step should have downloaded and extracted the source code in /tmp/nginx-x.x.xx. At the time of writing, this was /tmp/nginx-0.7.64. So enter:

Where is your Nginx source code located?

Please specify the directory: /tmp/nginx-0.7.64

And press `Enter’.

The next question will ask you where you want to install Nginx to. The default is /opt/nginx. To leave it this way (I recommend this), just press `Enter’ again.

Now the installer will ask your for extra Nginx configure options as shown in the following screenshot.

Here you should add the --with-http_ssl_module argument which will make sure the configure script will enable the Nginx HTTP SSL module for compilation.

Extra arguments to pass to configure script: --with-http_ssl_module

The script will ask you for a confirmation if you really would like to modify the configure arguments. And yes, you would like to so press `Enter’ to confirm.

The script will now start to configure, compile and install Nginx in /opt/nginx.

Wait a few seconds or minutes for it to finish and continue to the next section: configuring Nginx to use the SSL certificate and create a secure connection for your Rails application.

3. Configure your Nginx to use the SSL certificate to secure the connection to your application

First of all, we will need to add a server block to the Nginx configuration so your application will listen on port 443 and use Phusion Passenger for serving your app. Open /opt/nginx/conf/nginx.conf and add the following block below everything else:

server {
    listen 443;
    ssl on;
    ssl_certificate /etc/ssl/certs/myssl.crt;
    ssl_certificate_key /etc/ssl/private/myssl.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv2 SSLv3 TLSv1;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

    server_name yourdomain.com;
    root /srv/apps/qloudwatch/current/public;

    passenger_enabled on;
    passenger_use_global_queue on;
}

Make sure you use yourdomain.com or www.yourdomain.com here (not both) for nice HTTP redirection to the correct domain name.

Now we need to configure that all non-secure request are redirected to the secure address of the web app. For example: all requests to http://yourdomain.com/ and http://www.yourdomain.com/ should be redirected to https://yourdomain.com.

To do this, add the following before the server section we just added:

server {
    listen 80;
    server_name www.yourdomain.com yourdomain.com;
    rewrite ^(.*) https://yourdomain.com$ permanent;
}

Now, restart your Nginx server by calling `sudo killall nginx -HUP’. Wait a few moments for Nginx to launch and try http://yourdomain.com/ to see if everything works.

And that’s all! You have just generated a self-signed SSL certificate, installed Nginx with the SSL-module enabled and configured the domain with your web application to be reached trough SSL.

I understand this can be quite something to take in if you’re new to SSL and Nginx so if you have any questions, any questions at all about this or other web app deployment strategies please post a comment, contact me on Twitter (@michiels is my account) or send me an e-mail.