Past Method When deploying a Jekyll blog, is was quite involved: Deploying Jekyll. Precious gems were used and a full development environment was required. If I’ve learned nothing else since then, it has been to simplify deployments as much as possible. The less coode the better. Cardinal Rule of Deployments: They Always Go Wrong. While CI is great when you have a multitude of projects and developers - having one for pet projects is just overkill.

AWS API Gateway Amazon Web Service’s scalable API offering: API Gateway is an execellent way to create simple APIs that charge by-the-request. One pain point though is that by default, your API is available via an ugly auto-generated URL such as: https://4ittmt4ei7.execute-api.us-east-1.amazonaws.com/dev/ There is an option to manually upload an SSL certificate to enable a custom domain but its tedious and well, manual. Well that just won’t do. Unfortunantly, as of this writing, API Gateway can’t be connected to Cloudfront - this is how one would apply a custom domain name to an S3 bucket, for example.

Why? One would imagine that we could compile our Python, Node, or Java projects into a ZIP file and upload them to AWSm Lambda without issue. Unfortunantly AWS Lambda’s execution environment stipulates everything should be compiled in the runtime environment. Makes sense - compile under the same criteria you’re running under. When I did this manually my workflow was: Create an Amazon Linux instance Install git Commit code SSH into EC2 instance and do a git pull master Run a shell script to package my Python code and deploy it to AWS Lambda Pretty manual process - and I totally forgot to turn off my ‘build’ EC2 instance - accruing some charges for idling.

Configure EC2 I opted for an t2.small Ubuntu 14.04 EC2 instance. This gives us two gigs of RAM and a single core for about .02 cents an hour. This should serve our purposes for a personal CI server. Elastic IP Address I elected to not assign a public IP address / Amazon DNS as this will change everytime the server reboots. Instead I allocated an Elastic IP address (under Network & Security).

Amazon Certificate Manager Since we’re hosting our site on Amazon’s S3 - we can take advantage of some other AWS products to secure or website, namely: Amazon Cloudfront Amazon Certificate Manager These services give us a few useful features for our simple blog: Free SSL/TLS certificates managed by Amazon (Using Let’s Encrypt with S3 is awkward since there is no traditional web server to secure) Global CDN - Cloudfront gives us global availablility for our S3 assets - people around the world get a fast user experiance.

Going Live After Building a Blog Part 3 - Continuous Integration with Gitlab CI - its time to automate deploying our blog to a host. Amazon’s Simple Storage Service (S3) is a good choice for serving static assets on the cheap. S3 is a bit different from a traditional VPC like DigitalOcean or Amazon’s Elastic Compute Cloud (EC2). Pros Very cheap - With AWS you pay as you go. Rather then paying $5-10 a month running a server for our static site, we can store our site for fractions of a penny: