Architecture 2.0

Posted on December 19, 2018 by John Duhamel

Ok, so now I have some time to learn haskell again and therefore I’m maintaining this site. My blog post Building This is interesting, but I can’t help but notice a few flaws. Notably, I built some sort of custom setup that proxies static s3 content to a web server running on Elastic Beanstalk. Why add this complexity, when I can host this content from s3 directly? Thus, that was the first thing that I decided to improve. Below, I’ll outline the steps I took to do this.

Keep in mind that until last week, I’d completely abandoned this site. I thought the source code was gone; lost of a coorporate laptop I’d given up long ago. I always felt sort of proud of it though, so I happily paid $10 per month to Amazon to run the site on a singnle t2.small. Sort of randomly, I discovered I’d uploaded the source code to github by glancing at the about page. That gave me something to work with! However, I’m still missing my deployment scripts, the SSH key to access the server is gone, and most of my infrastructure back then was configured manually.

First, I wanted to understand how the s3 content is proxied through to Elastic Beanstalk. I was able to download a copy of the existing Dockerrun file from the Application Versions page. Here’s the relevant bit:

  "AWSEBDockerrunVersion": 2,
  "containerDefinitions": [{
    "name": "blog",
    "image": "hbpcb/s3fs",
    "command": [ "bash", "-c", "webfsd -d -f index.html -p 8000 -F" ],
    "memory": 256,
    "privileged": true,
    "environment": [{
      "name": "S3_BUCKET",
      "value": "jjd-blog"

Takeaway: Why is this container running in privilated mode? That’s definitely suspect from a security perspective. Good thing I’m removing this.

Ok, so I created a docker image which runs webfsd on port 8000. I don’t have the dockerfile anymore, but I’m guessing it’s this.

So! Let’s unwind this and get my domain pointing straight to my s3 bucket. To do this, I followed this guide. I encountered just a couple hangups. First, it turns out that in order to point a Route53 record to an S3 bucket, the bucket name needs to match the domain exactly. Thus, I needed to migrate all my site data over to a new bucket names When I did this, I found that the recommended bucket settings actually block you from updating the bucket policy and also block access to non-authenticated users. Since the intention is for all this content to be public, I needed to modify those in order to get things working. See the image below:

Aside from that, I followed the instructions in the official docs and everything worked fine. It’s worth noting, it took a while for the correct DNS records to propogate.

Ok, so now elastic beanstalk is out of the picture. Phew! There is one lingering issue, though, which is link to my wiki now returns a 404, since that redirect was previously handled through a reverse proxy running on elastic beanstalk. You can still view my wiki here. I’m planning to migrate to tiddlywiki, which will be affected by the same problems. I’ll look for a better solution when I tackle that project.

Thanks for reading! I’m looking forward to writing more, and hopefully covering some of the things I’ve learned over the past couple years. Until next time…