1. Home
  2. WordPress
  3. Hosting
  4. AWS | Static Website Pipeline and Hosting

AWS | Static Website Pipeline and Hosting

Print

Automated AWS Static Website Deployment (CI/CD Pipeline w/ Github) 
I’ve had the opportunity arise twice within a single month to deploy a static website. 
1) for my work (Site Tour) 2) for my personal website to test and track my skills. (www.garyinnerarity.com)   
TLDR; 

  • I used VS Code (#Code) to edit my code hosted in my Github Repository (Private). 
  • Github actions (‘workflows’) were then configured to push commits to my S3 bucket in AWS. 
  • All S3 changes are pushed to CloudFront for Edge based caching (super speed!) 
  • Route53 was used to create an A record alias to CloudFront to make it easier to find. 

The Details    

irony: I will keep my details section brief for efficiency purposes. I have more things to build and solve! build: stack: – vs code – github desktop – github repository – AWS S3 – AWS Certificate Manager (SSL) – AWS CloudFront – AWS Route53 zone: – us-east-1


VS Code    

 At the least, you need an index.html file for your static website. Using our ‘hello world’ example, this is what it would look like: <html><head> <script> script for nav bar, Google Analytics, and so much more…</script> <title>Page Title information</title> <meta> Responsive viewport, author information, keywords for SEO, and description of web page for SEO </meta> </head>
<body> <div> <h1>hello world</h1> <div></body></html>    Save this file as index.html to your GitHub root repository. 


Github Desktop   

After your index.html file is created, you want to save it to your repository on GitHub. Launch Github from your desktop. If your Github Repo is already created and connected to your Github Desktop, then you’re ready to ‘commit to master’ and ‘push’ to the online repository. The reason why you have to ‘push’ it up is because you’re initially pulling the repo down to your computer, editing locally and committing locally before ‘pushing’ it back up (online). There’s a highly technical explanation for this – my explanation is not the highly technical version. 


Github Repo (Workflow details)    

Now that your repo is updated with your index.html file, you’re ready to configure the connection to AWS. Log into Github online (GitHub.com) and navigate to your repo. Select the ‘actions’ tab and select ’setup new workflow’ and then ’set up a workflow yourself —>’.

 
You’ll want to use their template, or mine below, which I ‘borrowed’ from others online 🙂  (https://www.kylegalbraith.com/ @kylegalbraith – seriously, an awesome dude.) 
name: S3 Syncon: [push]jobs: build: runs-on: ubuntu-latest steps: – uses: actions/checkout@v1 – name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: us-east-1 – name: Deploy Static Site to S3 Bucket run: aws s3 sync . s3://<bucketname> –delete


It’s highly important to use the – – delete flag, this will delete the contents in the S3 bucket and then re-push all of the contents from the GitHub repo to S3 again. If you don’t stale code/files could get trapped in S3 and cause bugs down the road. Trust me, I’ve made this mistake with CodePipeline – which is why I don’t use it. 


Github automatically creates a directory in your repo to store this file (main.yml, unless you change it). Notice that there’s a reference tag (environment variables?) on the secret section, you’ll need to create credentials from within AWS Console with full S3 access (and nothing else!) and enter that under Github > Settings > Secrets: AWS_ACCESS_KEY_ID&AWS_SECRET_ACCESS_KEY
Make sure you complete the next phase (S3 bucket creation) before you attempt to execute the above code. 


AWS S3    

Before you can complete the previous step, you will need an S3 bucket. Login to AWS and navigate to S3. Create a new bucket with an easy DNS name and select your region. I chose US-EAST-1. No need to enable anything else at this time under ‘configure options. Turn off ‘block all public access’, we are in fact opening this up to public access. 
After your bucket is created, you’ll go back to Github to make the connection run: aws s3 sync . s3://<bucketname> –delete


Next, open your bucket from S3, select ‘properties’ and enable ’Static website hosting’. Go ahead and enter your index.html file name as your Index document. Save. You should now see your web address for your S3 Index.html endpoint. Going to that link before you set the permissions below, will throw an error. 


Then, navigate to ‘permissions’ > ‘bucket policy’ and enter the below code, but change your bucket name. Save. { “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “PublicRead”, “Effect”: “Allow”, “Principal”: “*”, “Action”: [ “s3:GetObject”, “s3:GetObjectVersion” ], “Resource”: “arn:aws:s3:::<bucketname>/*” } ]}

That’s it! If you want to enable SSL (HTTPS) for a more secure browsing experience then keep reading! 


(Optional) AWS Certificate Manager   

Okay, you’ve made it pretty far, your static site is live, but you have no security (https) and you want a custom domain instead of some arbitrary bucket dns name. 
Now that CloudFront is created, request a certificate to your domain by following the steps available (email/dns verification for your domain). Navigate back to CloudFront, edit your distribution, add the domain alias’s and select ‘Custom SSL Certificate’, from which you will chose your verified certificate. 

(Optional) AWS CloudFront   

Time to separate yourself from the competition! Enable caching with CloudFront for edge based distribution. i.e, super fast delivery! 


Navigate to CloudFront > Create Distribution > Web (‘get started’) > enter the origin name (s3 bucket created above). Save. 


Once your distribution is created, jump back up to Certificate Manager and create an SSL cert for your distribution. 


Now that CloudFront is created, request a certificate to your domain by following the steps available (email/dns verification for your domain). Navigate back to CloudFront, edit your distribution, add the domain alias’s and select ‘Custom SSL Certificate’, from which you will chose your verified certificate. 

(Optional) AWS Route53    

You’ll be required to add CNAME records to route 53, if it’s hosted with r53, to verify your certificate (domain ownership). Once created, verified, you’ll now want to create an A record alias to point at your CloudFront distribution. I chose www.garyinnerarity.com since my index.html file is my entire website. Some people will use static sites for ‘error’ pages or ‘outage’ messages. It’s up to you! 



How can we help?