20 Nov 2012
A bit ambiguous, eh?. This time around I will talk about how I was struggled with choosing the right hosting for this blog, I spent almost an entire week finding out which host can serve my way of blogging: static sites, manage-able with repository, and pushing the updates with commits / rysnc style.
As you might already know, this blog is powered by Pelican, a static blog engine written in Python, which making it possible to be hosted almost anywhere, my consideration is of course scalability and reliability. I wanted to host it in places that I don't need to think about scaling, so one obvious place in my mind would be Github User Pages where it allows you to put static HTML files in the root of
username.github.com repository and it will serve the static site for you, dead simple. But I've encountered a single big problem I was never able to solve (yet): after few days with several commits, it stopped building, I kept seeing the old version of the static site. I was able to trigger the build by removing the repository, create a new one and push the whole thing again, not a fancy solution. I checked out Twitter to see if anyone else got the same problem, and found them. I also contacted Github to see what they can say, but no words yet. I have to find another host.
Now, we're still talking about scalability and reliability, at this time, I have an Amazon AWS account, and they provide a CDN service, I was thinking that a static site would be a great match when hosted at a CDN. So I set up an S3 bucket, use boto-rsync to sync my build folder into my S3 bucket, set the bucket settings into what they called as
website-mode and set my DNS to my S3 DNS. It turned out that the domain name has to match the bucket name, I was using different bucket name, and for some personal reason, I can't change my bucket name. I had to use CloudFront.
While S3 is a simple storage service, hosting your files in a specific region, CloudFront is a CDN service to propagate your S3 contents to several edge locations around the globe. I set up a CloudFront distribution, set the default root object to index.html so when people hit kecebongsoft.com the file will be served, and updated my DNS, things worked fine, until I realize that it cannot serve a sub-site. I have some sub-sites containing my HTML5 slides, in a folder such as slide-blahblah, now if people hit kecebongsoft.com/slide-blahblah, they'll get an Access Denied message, that's because there is no such thing as default object in the subfolder, people will have to hit kecebongsoft.com/slide-blahblah/index.html in order to see the actual content, at this point, I was a bit upset, I looked around and can't find anyone who was able to work around this.
I should set my target a bit lower now, let's just start to think no one cares about my blog, well maybe just a couple of people, so for now I'll just host it in my shared-cloud account, WebFaction. It's really straight forward compared to the other two, I just need to create a site in the Control Panel and rsync my build path into the remote server, that is all, but I sacrificed the scalability, for now it only live in Singapore region, which at this time, should be just okay.
I'm really hoping that I could go back using Github User Pages. If the guy contact me back and solves the problem, it will be a home-call, I liked the User Pages mechanism in a way that you only have to push to the master branch to trigger the build, now if only it works well all the time..