Content Delivery Network(or CDN’s) are front gate for most of the high performing websites in wild, doing lots of heavy lifting and making sure that end users receives good performance.
Today CDN’s are much more than traditional caching machine that’s sole purpose is to keep your static content near to end users. Now many of the personalization, including critical business logic runs on CDN’s. Also their are many CDN’s that provide much more than performance, for e.g. Akamai, which revolutionized the CDN in 1990’s and has pretty much ruled CDN business has mission statement: “make digital experiences fast, intelligent and secure” . There is lot of focus on security, and it is understandable because performance does not mean anything if we cannot instill trust in our customers.
So CDN that few years ago might be typical caching box is now a complex set of app which consists of rules to manage your business critical logic, personalization, edge compute(serverless computing), as well as it offers many of the security features for e.g. Web Application Firewall (WAF), Bot Management, Zero Trust Security solutions etc etc, something like below.
Many of the organizations have already considered to automate their application build process using some sort of CI/CD pipeline but unfortunately many a time they keep CDN out of their automation logic and their can be many reason, be it cultural, “oh, i know it is a caching thing that always work and it is low value thing for us”🤔 , or it is technical debt where developer don’t know if CDN’s can be automated using same tool that they use to manage rest of apps and infrastructure.
In reality CDN’s are important, (if not THE important) part of ecosystem and making it part of end to end CI/CD pipeline should be prioritized.
In this post we will see how easy it is to manage CDN as a code. For our example site we will use:
- Akamai as CDN — More about Akamai here
- Github Actions as CI/CD. — GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
- Terraform as IaaC tool — Terraform is an infrastructure as a code tool that lets you define cloud, on-premises & CDN’s in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle.
Let’s get hand’s dirty and start with conceptual diagram of what we are trying to achieve.
Our aim is to manage Akamai(CDN) changes as a code using github repo (for storing project code and artifacts), GitHub actions( as CI/CD solution) and terraform(as provisioning tool).
Step 1 —Before moving to next step, please make sure that you have:-
- Github account — For storing repo code and using github action.
- Akamai API Client access with appropriate privileges — For provisioning CDN rules and managing it. Click Here for more on getting started
- An AWS account including API credentials— we will be using it for storing terraform state file. You can use other terraform backend like Azure, consul or others. More about terraform backends here
Step 2 — Setup Github Repository
- Create a new blank repo and name it as needed. My repo is here https://github.com/deepakjd2004/github-action-terraform
- Define some repository secrets that would be needed while working with Akamai API’s and AWS S3( i.e. backend for storing terraform files). For adding secrets, go to Settings → Secrets → Actions → Repository Secrets. See below screenshot. Also click here to know more about secrets
- AWS_ACCESS_KEY_ID /AWS_SECRET_ACCESS_KEY— Your AWS access key with privilege to do CRUD operation on S3 🪣 ( basically used to store state file) . More about creating and managing aws access key here.
- EDGERC — Basically a flat file containing your api credential details. Please make sure that API has access to do CRUD operation on Property Manager API i.e. PAPI. Click here for more on access requirement. If you are new to akamai then this link will be helpful.
Step 3 — Provision AWS S3 bucket for storing terraform statefile. You can provision S3 bucket both programmatically or via. GUI.
Step 4 — Clone the blank github repo on your local/developer machine
git clone ssh://john@example.com/path/to/my-project.git
cd my-project
Step 5 — Build Terraform code for managing Akamai configuration.
Their are multiple ways in which you can easily build akamai terraform code but one of the easiest and popular way is to use ‘akamai terraform’ CLI. This CLI very conveniently export the terraform file for any existing property or delivery configuration(in akamai terminology it is json file containing caching and other business rules). You can learn more about akamai terraform CLI here.
If you are new to akamai and has no base property to clone from then you can build your own code using well documented terraform provider and examples. I used Akamai Terraform CLI to export the code.
akamai terraform create-property <property_name>
only thing that you need to make change is <property_name>
After running above you would see the below files created in your working directory/<property_name>.
Property.tf would have terraform code to provision the resource.
For our use case we are going to use cloned property to create new property. At bare minimum to create new property we need to change below resources in property.tf.
akamai_property.<resource_name>.name — put unique name for your property
akamai_property.<resource_name>.hostnames.cname_from — This is going to be your website hostname
For this example i used all other existing details for e.g. akamai_edge_hostname cp_code etc.
Also define backend information in terraform files to store statefile. Below is the code
terraform {
required_providers {
aws = {
source = “hashicorp/aws”
version = “~> 3.0”
}
akamai = {
source = “akamai/akamai”
version = “1.9.0”
}
}
backend “s3” {
bucket = “<s3_bkt_name>”
key = “<location_within_bkt>/terraform.tfstate”
region = “<region>”
}
}
On my repo this definition is in versions.tf but nothing stops you from adding it in property.tf.
Step 6 — Let’s upload our code and start managing it with git
git add
git commit -m “<commit_message>
git push
For more on git commands, click here.
Go back to explorer and check that your github repo has code copied from your local directory and it is now being tracked by git.
Step 7 — Let’s start managing our code using CI/CD pipeline i.e. github actions. If you are not familiar with github actions then please have a look at official documentation. https://github.com/features/actions
Github actions is one of the popular CI/CD solution and if you worked with any other CI/CD solution like jenkins than you would find working with github actions quite easy.
Github actions uses basic concept called Workflow, is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
Workflows are defined in the .github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.
Github actions uses runners to execute the workflows(or tasks mentioned in workflows), think of it as a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. Github free tier gives you 2000 CI/CD minutes per month and that is quite generous for experimentation.
An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.
You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace. There are so many github actions on marketplace that it is high probability that you won’t have to write custom action.
Step 8 — Let’s write our github actions workflow
Go back to your dev machine and create directory called .github/workflows
Within workflows directory, create a file called main.yaml
My code for main.yaml is here.
Let me explain the code.
In above screenshot :
- Block numbered 1 refers to conditions for ci/cd pipeline to be executed. For our example we would like our workflow code to be executed
— if their is push on main branch
— when their is a pull request — we have not defined any branch but it can be done
— if we would like to manually run the workflow manually using actions tab.
- Block numbered 2 — Remember previously we defined some secrets, now is the time to call them as an environment variable and use it as needed.
- Block numbered 3 — It defines where, how and what action jobs are going to run. In our case we are using ubuntu-latest runner and below github actions:
— actions/checkout@v3 — to checkout my repo into runner environment
— hashicorp/setup-terraform@v2 — a container having terraform CLI installed
Next, lets see other blocks
In above screenshot
— block number 1 — Used to build edgerc file, basically for interacting/authenticating with Akamai Terraform Provider.
— block number 2 — consists of various steps, first one is to check if files are formatted well, we are using continue-on-error as true and it means even if formatting fails than also go ahead with next step. ‘terraform init’ is about initializing terraform and ‘terraform validate’ will validate the terraform code.
— block number 3 — This block is about generating terraform plan command on only Pull Request(PR). The PR generates a plan. When the PR is merged, that plan will be applied.This step will continue even when it errors. This allows the next step to display the plan error message even if this step fails.
Update Pull Request adds a comment to the pull request with the results of the format, init and plan steps. In addition, it displays the plan output (steps.plan.outputs.stdout). This allows to review the results of the plan directly in the PR
Terraform Plan Status returns whether a plan was successfully generated or not. This step highlights whenever a plan fails because the “Terraform Plan” step continues on error.
Terraform Apply applies the configuration. This step will only run when a commit is pushed to main.
Step 8 — Let’s push our main.yaml file to github repo. Similar to step 6 run below commands.
git add
git commit -m “<commit_message>
git push
Step 9 — After this make some change in any of the file being managed in repo (for testing just add some comment in property.tf file) and push it to repo similar to step 8. Make sure you are on main branch.
Step 10 — If all good you will see your code commit(basically step 9) triggered a github action to provision resources on akamai.
Click on actions tab on your repo to see the workflow results.
Step 11 — In case your workflow fails than you can find the exact error by going into workflow logs. In below screenshot workflow failed because i did not pass the right version of action.
Step 12 — For successful run you can cross verify what all has been done.
Step 13 — Next, you can go into Akamai Control Centre(ACC) or using api/cli verify if your property has been indeed created or not.
Step 14 — Now, let’s see how Pull Request(PR) is going to work.
- Go back to your dev machine or laptop where you created code.
- Create a new git branch
git checkout -b ‘feature-branch’
- Make some changes in any file tracked by git on the repo and push it upward.
Pushing changes is basically opening a pull request.
Step 15 — Review the PR and merge it.
Go back to your repo, Navigate to your pull request. Your PR will trigger the Terraform Actions workflow. When the workflow completes, it will add a comment with the outcome of each step and a speculative plan.
Step 16 — Verify changes in ACC or you can also automate testing as part of github actions.
That’s it for this post. Thanks for reading!!!
Credits —
