# Was thinking, "if hosting was a library, what might it look like..."
require 'ProviderX'
# We'll pretend we already have an account with fictitious ProviderX
host = ProviderX.new(:user => 'foo', :password => 'secret')
# Let's see what ProviderX will allow us to deploy to
host.provides
> ['Amazon', 'Google']
# Let's create a new environment to deploy to
production = host.cloud.new(:vendor => 'Amazon', :name => 'production', :min_cpu => 2, :min_mem => 1024)
# We also would need to define the application that we wish to deploy
application = host.application.new(:repository => 'http://foo.com/foo.git', :type => 'Rails', :name => 'foo', :domain => 'foo.com', :ssl_enabled => true)
# All set! Let's deploy.
application.deploy_to production
application.deployed?
> true
application.deployed_to
> ['production']
production.applications
> ['foo']
# Maybe we forgot that we want to redirect www.foo.com to foo.com
application.redirects.add :from => 'www.foo.com', :to => 'foo.com'
# We don't want to deploy the code again, we just want to sync configuration changes (the redirect).
application.sync_configs production
# Perhaps we could control our resources from within our application
if production.swapping?
production.ram.add 128
end
# That's it for my day-dreaming.
Saturday, November 28, 2009
What If Hosting Was a Library?
Posted by
Justin Pease
at
9:37 AM
1 comments
Links to this post
Monday, November 2, 2009
HAProxy: Routing by domain name
Without too much effort I was able to find multiple search results that said HAProxy could direct traffic according to domain name. Unfortunately I was hard pressed to find any example configurations demonstrating that functionality. Turns out it is in section 7.7 of the documentation.
If we wanted to direct traffic for foo.com and bar.com to different servers we could do so as follows:
frontend http_proxy
bind 192.168.0.1:80
acl is_foo hdr_dom(host) -i foo
acl is_bar hdr_dom(host) -i bar
use_backend cluster1 if is_foo
use backend cluster2 if is_bar
backend cluster1
server server1 192.168.0.2:80
server server2 192.168.0.3:80
backend cluster2
server server3 192.168.0.4:80
So first we create a frontend called http_proxy that will listen on port 80 of 192.168.0.1. The next lines are the key parts.
We create an acl called is_foo which checks the Host portion of the HTTP header for the provided value, in this case 'foo' in one and 'bar' in the second acl. The '-i' flag in both examples sets the match to be case insensitive.
The last part of the frontend configuration is to tell it to use a backend named cluster1 or cluster2 depending on if the is_foo or is_bar acl matches.
Finally we define the backends cluster1 and cluster2. The backend cluster1 has 2 servers, backend cluster2 only has 1.
So in this case if we sent a request for http://foo.com to 192.168.0.1:80 the acl that checks for the value 'foo' in the host should pass, and our request should be proxied to port 80 of either 192.168.0.2 or 192.168.0.3.
The practical example shown in the HAProxy documention is that you could use this to direct traffic for assets.foo.com to a server for static content, and www.foo.com over to your application server. However, if you found this article through a search, I'm sure you already have in mind how you want to use this.
In addition to the hdr_dom shown in this example, there are many other hdr_* matchers, as well as many other configuration options with HAProxy. For full details and options see the official HAProxy documentation.
Posted by
Justin Pease
at
5:58 PM
0
comments
Links to this post
Labels: haproxy
Monday, October 26, 2009
Tiny email sending service with Amazon SQS
I found the "Dynamo Paper" by Amazon to be interesting. In particular I liked the idea of small services. Nothing new, but I liked the concept and wanted to play with it.
The result was the 71 line SQS Mailer, available on Github.
For this experiment the code polls an Amazon SQS queue. If there are messages in that queue, it retrieves them, parses them, and sends them out as emails via SMTP. If there are no messages waiting, it just sleeps for 5 seconds and tries again. So if you ran multiple applications that all needed to send email, they could send it out through this single service by sending a message to the queue. Which SMTP server account the message would go out through is controlled by a combination of a potentially application-specific identifier in the message you send to the queue, and a service-side lookup in accounts.yml.
Will this be useful? Not sure. But it was fun to put together!
Basically I sketched this out onto some notepaper one night, and then later filled in the functionality for each method when I had time:
At the current Amazon SQS pricing of $0.01 per 10,000 requests, leaving this idling would incur a cost of about $6.50 per year from AWS.
As the disclaimer in the README file states, this doesn't handle failure scenarios with any grace. If I decide it is useful for anything, I will give that some attention. Or you can fork the project and let me know what you come up with.
Posted by
Justin Pease
at
7:50 PM
0
comments
Links to this post
Sunday, September 6, 2009
Abort: couldn't find mercurial libraries
Posted by
Justin Pease
at
6:58 PM
1 comments
Links to this post
Labels: hg, mercurial, mercurial libraries, snow leopard
Thursday, November 27, 2008
Typing? I'm a programmer not a secretary.
This last week has seen a few posts on the necessity, or lack thereof, for good touch typing skills.
Posted by
Justin Pease
at
6:00 AM
0
comments
Links to this post
Labels: code, continued education, knowledge investment, programming, typing
Saturday, November 8, 2008
Knowing Your Languages
Posted by
Justin Pease
at
5:03 PM
0
comments
Links to this post
Saturday, September 27, 2008
Remove Gems By Prefix
If you are working with Merb or DM you know that approximately a gazillion gems are involved. When, for whatever reason, I want to remove them it is a pain to do by hand.
#!/bin/bashprefix=$1gem list --local | grep $prefix | awk '{ print $1 }' | xargs sudo gem uninstall$ remove_gem_by_prefix merb$ remove_gem_by_prefix dm
Posted by
Justin Pease
at
7:49 AM
0
comments
Links to this post