Search for a command to run...
A DevOps/Cloud Architect experienced with building and automating DevOps processes and tools for engineering teams encompassing cloud-native applications. Extensive background experience working with AWS and Microsoft Azure cloud services building hands-on robust and scalable solutions and services.
No comments yet. Be the first to comment.
In this series, I will be talking about broader topics encompassing AWS and its services. There will be technical discussions, deep dives, comparisons, and many more.
The Evolution of DevOps - The Golden Age Let's wind the clock back a couple of decades to the late 90s and early 2000s, a time when most organisations had a single gatekeeper: the system or IT administrator. If engineering teams needed to run their a...
This guide presents a comprehensive set of rules for software engineering inspired by the movie Zombieland. The rules are not simply a list of arbitrary guidelines, but rather a carefully crafted set of principles that are designed to promote efficie...
Organisations today are increasingly adopting cloud services from different providers to meet their business needs. However, managing multi-cloud infrastructure can be challenging, especially when it comes to infrastructure management, which is where...
What is AWS CloudFront? AWS CloudFront is a content delivery network (CDN). It securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. It offers a simple and cost-effective way to distri...
DevOps is more than just a software development methodology – it's a culture. The DevOps culture emphasizes 3 main pillars: collaboration, communication, and shared responsibility between development and operations teams. In this post, we will discus...
In this guide, we will show you how to set up a GitHub Actions workflow to deploy your web application to S3 and invalidate your cache on CloudFront for your end users. The guide includes prerequisites, creating an IAM user, creating a custom policy for the IAM user, fetching your CloudFront distribution ID, saving secrets in GitHub Secrets, and a YAML pipeline workflow. Please note that this post assumes that your source code is hosted on GitHub and is running on a Node.js framework.
An AWS account with admin privileges
An S3 bucket
A CloudFront distribution
A GitHub account
Basic understanding of GitHub Actions workflows
The steps involved are straightforward and shouldn't take too long to complete.
Create an IAM user in AWS
Attach a custom policy tailored to your pipeline needs
Create or retrieve your CloudFront distribution ID
Save the Access Key ID, Secret Access Key from IAM, and CloudFront distribution ID in GitHub Secrets
Create the pipeline using a GitHub workflow
Visit the IAM page on AWS.
Create a new user. Give it a meaningful and distinct name.
Don’t tick the box that says “Provide user access to the AWS Management Console - optional”. This user does not need access to the console to function.
For permissions, choose the option, “Attach policies directly” and click “Create Policy”. Copy the JSON policy mentioned below in the next section.
Review the new user and create.
Next, visit the Users page on IAM and click on the newly created user.
Navigate to the Security credentials tab.
Scroll down to Access keys and click Create access key.
Take note of the Access key ID and Secret access key. You will need it later for saving it to GitHub Secrets.
To set up the pipeline, you will need an IAM user that would authenticate with your AWS account and perform the updates automatically. It is best to follow security principles and provide this user with the least privileged access to safeguard your AWS account from accidental or unwanted malicious activities.
As we basically need to allow the pipeline to be able to communicate with AWS S3 and CloudFront respectively, we need to supply the following permission scope and create a policy for the IAM user.
S3 permissions
List the buckets
Get the objects in the buckets
Create objects in the buckets
Delete objects in the buckets
CloudFront permissions
Create invalidation
Get invalidation
List the invalidation
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::example.com"
]
},
{
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::example.com/*"
]
},
{
"Action": [
"cloudfront:CreateInvalidation",
"cloudfront:GetInvalidation",
"cloudfront:ListInvalidations"
],
"Effect": "Allow",
"Resource": [
"arn:aws:cloudfront::<aws_account_id>:distribution/*"
]
}
]
}
With the custom policy above, you can attach it to the IAM user you have created. Ensure the following is updated:
S3 bucket name - example.com
AWS account ID - for the CloudFront ARN
Visit your CloudFront page.
Click on Distributions.
Select your Distribution that points to your S3 bucket.
Take note of the Distribution ID in the first column. You will need this ID when you save it in your GitHub Secrets
You need to save the following secrets in your GitHub repository secrets:
IAM credentials that you created earlier - Access Key ID (AWS_ACCESS_KEY_ID) and Secret Access Key (AWS_SECRET_ACCESS_KEY)
CloudFront Distribution ID that you retrieved earlier (AWS_DISTRIBUTION_PRODUCTION)
A workflow is a configurable, automated process that can run one or more jobs. Workflows are defined by a YAML file that is checked into your repository. They run when triggered by an event in your repository, or they can be triggered manually or on a defined schedule. Below is a template of an S3 Sync workflow.
name: S3 Sync - Production
on:
push:
branches:
- 'master'
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2.5.1
with:
node-version: '15'
- 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: ap-southeast-1
- name: Install packages
run: npm install
- name: Run build
run: npm run build
- name: Generate
run: npm run generate
- name: Upload artifact
uses: actions/upload-artifact@master
with:
name: web-app-dist
path: './dist'
deploy_to_production:
name: Deploy to S3 Production
runs-on: ubuntu-latest
needs: build
environment:
name: production
url: https://example.com
steps:
- name: Download landing page artifact
uses: actions/download-artifact@v2
with:
name: web-app-dist
path: dist
- name: Display structure of downloaded files
run: ls -R
working-directory: dist
# S3 sync
- name: S3 Sync
uses: jakejarvis/s3-sync-action@v0.5.1
with:
args: --acl public-read --follow-symlinks --delete
env:
AWS_S3_BUCKET: 'example.com'
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_REGION: 'ap-southeast-1' # optional: defaults to us-east-1
SOURCE_DIR: 'dist' # optional: defaults to entire repository
# Invalidate Cloudfront
- name: Cloudfront Invalidation
uses: chetan/invalidate-cloudfront-action@master
env:
DISTRIBUTION: ${{ secrets.AWS_DISTRIBUTION_PRODUCTION }}
PATHS: '/*'
AWS_REGION: 'ap-southeast-1'
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
Using this workflow, you can easily deploy your applications to S3 by syncing the files and invalidating your cache on your CloudFront distribution. This ensures that your end users receive the latest content from your release.
The workflow is divided into two sections:
CI section, which builds your application, generates the static files and compresses them to be uploaded as artifacts.
CD section, which downloads the compressed artifact, configures the AWS credentials, syncs the static files to S3, and invalidates your CloudFront distribution.
The reason for this approach is to enable the reuse of our artifacts, if necessary, for other GitHub workflows. It also provides a clear separation between continuous integration builds and continuous deployments.
Setting up a GitHub Actions workflow is fairly simple once you get the hang of it. This workflow allows you to deploy your S3 applications with confidence to various environments.