Lab: Create and Host a Static Website

Abstract

It’s commonly recommended for those starting tech careers to put a portfolio online, and have an active in order to set themselves apart. In my case I’m documenting my initiation in devops and cloud stacks through personal projects and labs. This kind of lab work perfectly lends itself to lab reports. Also, hosting the lab notebook on AWS demonstrates an entrance into using those cloud services. Thusly motivated, the first Lab will be to Create the Static Site using Jekyll and Serve it using AWS.

Method:

1. Environment - Install Git, Jekyll, VSCode etc. And on local machine initiate projects and repositories to manage changes. As well, integrate online with GitHub and Travis CI to automate site build and change management through git pushes. This activity follows the LinkedIn Learning module for setting up a Jekyll Static Site, by Nate Babettini Learning Static Site Building with Jekyll
2. Deployment - Deploying the site will be done using the AWS suite. Domain purchase, route 53 dns records, certificate management, s3 hosting, and cloud front distribution all have to be done correctly. The steps observed in the in the LinkedIn Learning linked above did not quite suffice. Refer instead to the documentation done by amazon itself.

Observations:

• Editing in markdown and reviewing on localhost was satisfying
• Travis CI integration had multiple breakdowns due to versioning bundle and ruby. Review of support docs and 15 test builds later solutions were to add to _travis.yml the lines before install:, -gem install bundler, rvm: and -3.1.3
• Distribution through cloudfront wasn’t possible with Google Domains. The site had to be set up through Route 53 in order to get certificates and distribution working. The course referenced in Method.1 underspecified this stage.
• Long roadblock with earlier attempt due to how CloudFront deals with “index.html”. For example /projects/ in the browser bar which should have rendered the file located at /projects/index.html was instead returning 403 forbidden page generated by AWS not contained in the S3 bucket.
• The problem with how AWS CloudFront interprets index.html was documented by Nelson Figueroa “Resolving AWS CloudFront Access Denied Errors”.
• Confirming that due to my theme my subdomains all expected index.html I opted to reinit the project for the domain gordonmakes.com using the theme jekyll-swiss authored by git user broccolini.
• I was able to confirm that posts were now in a feed and named theirtitle.html as the document not index.html and that jekyll-swiss was rendering beautiful posts. That confirmation gave me confidence to procede with my original method outlined above.
• removing the line “permalink: /about/” from about.markdown was essential in changing the site generation towards causing jekyll to generate an about.html in root directory as opposed to generating /about/index.html

Conclusions:

This is the section were scientists conclude more funding is needed to continue their valuable careers work.

I loved the results of renderring my pages with the Jekyll-Swiss theme.

I found that getting security certificates was so much faster and easier when I changed my domain management over from Google Domains to Route 53, the integrations in AWS were key to success, reducing wait times for DNS updating and frustrations.

While trouble shooting I found myself more and more wary of the blogs of many people who published content about hosting a static sight on AWS, and more and more found myself turning to the AWS documentation itself.

I was not very happy using Travis CI to build my sites when my local device was perfectly capable of this task. I would prefer to integrate my pushes to github and Amazon S3 using an alternative build method.

I would also like to put both the project I abandoned and it’s associated domain that I purchased to work in the future. Possibly by gaining experience hosting with Microsoft Azure or Google Cloud.