Welcome to my new site! In this inaugural article, I’m going to describe how I set up the Jekyll static site generator on Mac OS X and how I configured Amazon S3 to host the website. Specifically, I’ll cover the following topics:
- Installing RVM and Ruby on Mac OS X (and configuring RVM for
- Installing Jekyll on Mac OS X
- Configuring Amazon S3 to serve a website
- Using jekyll-s3 to link Jekyll to Amazon S3
- Creating a DNS record to point a domain name to an Amazon S3 site
There were a number of quirks and unexpected behaviors I ran into when I went through this process, so my hope in writing this article is that you’ll be able to avoid those annoyances.
- First things first: Git
- RVM and
- Finally, Jekyll
- Setting up S3
- Getting your stuff into S3
- Setting up your domain
- Obligatory “conclusion” section
A couple of months ago I wanted a place to host my PGP key signing policy, so I set up a very basic GitHub Pages–powered site that consisted of nothing but that and a list of my GitHub projects. GitHub Pages has built-in support for Jekyll, a static site generator written in Ruby, so I adapted the site to use Jekyll — more out of academic interest than any real need, with only two pages on my site!
Eventually I capitulated and decided to create a full-fledged website for myself, mostly to be a repository for physics things I’d like to publish and as a “focal point for my online identity” (read: list of links to social-networking sites). Ironically, as I used Jekyll more and more heavily I decided that Amazon S3 would be a better choice as a hosting service.
First things first: Git
Each website hosted on GitHub Pages is (naturally) stored in a Git repository. Although this is obviously not necessary if you’re not using GitHub Pages, I’d strongly recommend keeping any website you develop in a Git (or other SCM) repository. It’ll allow you to view previous versions of your site, split tentative new features or designs into independent branches, and generally keep better track of what you have and what you’ve been doing with it.
Installing and using Git is outside the scope of this article, but briefly: on Mac OS X you can install it easily with Fink or Homebrew, and you can find good tutorials at Git Immersion, Git Magic, and GitHub itself.
I didn’t (and don’t) have much familiarity with Ruby, but it seems like the Ruby community has a really well-polished and universally-used package manager called RubyGems. It also seems like Apple has made this tool kind of worthless by botching the default Ruby configuration in Mac OS X. The Apple-supplied version of RubyGems is too old to install Jekyll, and after I updated RubyGems and installed Jekyll the resulting setup was weird: running Jekyll (or any other Gem, like SASS) required
sudo, and consequently the generated website was owned by
root. These were not huge issues, but eventually I found a way to avoid them altogether.
RVM, the Ruby Version Manager, was originally intended to help developers test their Ruby code against different versions of Ruby and different combinations of Gems.1 It seems to have since become the preferred way to install Ruby no matter what you’re doing, and it’s the way I managed to get Ruby installed on my machine.
Following the instructions on the RVM site, run the following command in your shell:
\curl -sSL https://get.rvm.io | bash -s stable
(The backslash ensures that
curl will be called in a vanilla configuration, even if “curl” is normally aliased to something else.) Next, copy the contents of this Gist into a file named “rvm.rb” that lives somewhere in your
PATH. I have a “bin” directory right in my home folder so I put it there; you could also use
/usr/local/bin or even
/usr/bin. Make the file executable using
chmod u+x rvm.rb.
Finally, put this line in your
Change the path to “rvm.rb” to reflect where you put the file. Once you restart your shell, the “rvm” command will work exactly the way it’s supposed to.
Now that RVM is installed, we can install and select the latest version of Ruby (as of this writing) with
rvm install 2.1
Now you can type
rvm use 2.1
to enter the “RVM environment” — any Ruby commands you run (
gem, etc.) will take place within the context of this environment. That means they’ll use the version of Ruby you just installed. It also means that any Gems you install within this environment will not be visible to the system-provided Ruby. (Those Gems will still be there, however, when you leave and reenter the RVM environment.)
Note that you’ll need to run “rvm use 2.1” every time you open a new shell if you want to take advantage of the Ruby and Gems you’ve installed. You might want to put that command in your
tcshrc so you don’t have to type it every time.
Phew! We’re finally set up to install Jekyll. Fortunately it’s now as simple as
gem install jekyll
at the command line. With that done, I won’t belabor the care and feeding of Jekyll itself, but its documentation is excellent, and in particular I found it helpful to look at the source code of sites that use Jekyll already.
Setting up S3
Disclaimer: Amazon S3 costs money. There is a free usage tier, but please don’t blindly follow these instructions without knowing what you’re signing up for.
So now you’ve got a website, courtesy of Jekyll, and you need to host it somewhere. As I said, I started at GitHub Pages, but after a while I became accustomed to using my own custom plugins with it. (For example, I use the SASS stylesheet language, which I highly recommend, and I use the converter from this Gist to have Jekyll run SASS automatically.) A Jekyll-generated site consists only of static files, and the cheapest and most reliable host I found for this purpose was the Amazon Simple Storage Service (S3). (Although some of Amazon’s Web Services offerings have had notable outages in the past, S3 is used by such big names as Dropbox and Tumblr as their underlying storage service.) Thanks to some changes Amazon made at the beginning of 2011, S3 is almost perfect for this purpose.
To set up S3 as your web host you’ll need to do the following:
- Create a bucket to hold your website.
- Set the bucket permissions so that your website is properly accessible.
- Tell S3 that this bucket is supposed to be a website.
To use Amazon S3 you’ll need an Amazon Web Services account, which shares credentials with your regular Amazon account but requires an extra signup procedure. Once you’ve gone through that, log in to the “AWS Management Console” at the preceding link, and then going to the “Amazon S3” tab. Click on “Create Bucket” and create a bucket whose name is your soon-to-be website’s fully-qualified domain name: mine is
www.bdesham.info, for instance; yours might be
web.xyzzy.com. For reasons we’ll get to later, if you want an “apex” or “naked” domain name like
example.com, you need to use the bucket name
www.example.com instead; later you’ll be able to get rid of the “www”.
Next you need to set the bucket permissions. By default, the contents of S3 buckets are viewable only by their owners, but obviously a public website needs to be viewable by anyone. With your bucket selected in the Buckets list, click “Properties” and then click on “Edit bucket policy” under the “Permissions” tab that appears. Enter the following text:
www.example.com is replaced with the name of your bucket. Click “Save” and “Close”.
Finally you need to tell S3 that you’d like to use this bucket as a website. Click on “Website” at the bottom of the page and click the “Enabled” checkbox. “Index Document” is the name of the page you’d like served when someone requests a directory: for example, I’d like requests for
/foobar/ on my site to return the page at
/foobar/index.html, so I entered “
index.html” in this field. If you have a page appropriate for serving when someone gets e.g. a 404 error, you can enter that page’s name in “Error Document”.
That does it for the configuration of your S3 bucket. While you’re in the “Website” tab, take note of the “Endpoint” URL; you’ll need that to configure your DNS later. I’ll also take this opportunity to mention that while you can manage your bucket using the AWS Management Console and upload stuff into it with jekyll-s3 (as we’ll see), the excellent Mac apps Transmit and Cyberduck will also let you explore and manage your S3 data.
Getting your stuff into S3
Now that your bucket is all configured, you need to upload your site into it. I spent hours unsuccessfully trying to do this with FUSE and
rsync, but then I found
jekyll-s3 (since renamed s3_website), a Gem designed expressly to push your Jekyll-generated site to S3. Follow the installation and setup instructions for that Gem. (Your S3 ID and secret can be found by going to the AWS Management Console and clicking “Account” and then “Security Credentials”.) Running
jekyll will build your site and then
s3_website push will publish it. Slick, huh?
Setting up your domain
The final step is to adjust your DNS settings so that your domain name points to your S3 website. (You’ll have to do this on your domain registrar’s website, and interfaces for these vary, so my directions here are general.) The domain you’ll be pointing to is the “Endpoint” listed in the AWS Management Console.2
First set a CNAME record for the “www” subdomain — something like
www.example.com CNAME www.example.com.s3-website-us-east-1.amazonaws.com.
Yes, that trailing period is supposed to be there.
Now we need to deal with how to handle the “apex” or “naked” domain,
example.com with no “www.” out front. Due to vagaries of DNS that I still don’t understand, you can’t just set a CNAME for this record (which is sometimes called “@”). In the case of Amazon S3, which isn’t designed to be a web host per se, we need to use an outside service to handle the domain apex. I found a service called WWWizer which is extremely easy to use: you don’t even need to sign up; just create a DNS record like
example.com A 18.104.22.168
and the site will automatically redirect requests for
www.example.com. For a small fee, you can also have that site keep your visitors on what looks like
example.com while you actually serve content from
www.example.com. This seems to be the way to go if you’re set on hosting content from [what looks like] the apex domain with S3.
Obligatory “conclusion” section
At this point I’ve given instructions for most of the things you’ll need to do in order to host a Jekyll site with Amazon S3; the steps I’ve glossed over are things for which a lot of documentation is available. I hope what I have written is straightforward. I make no guarantees that I’ll have the time or knowledge to answer questions, but if you’d like to try your luck, feel free to e-mail me from the link at the bottom of the page. Thanks for reading!