Blog

A Smarter Akamai Pipeline: Use Cases and Enhancements

A Smarter Akamai Pipeline: Use Cases and Enhancements

March 26, 2020 · by David Makofske ·

This blog is part of the Akamai Platform Release, where we’re giving you all the details about what Akamai has added and improved for developers! You can view all of our updates here.  

The Akamai Pipeline feature is part of the Property Manager (PM) command-line interface (CLI). It automates the Akamai portion of release processes when used with a GitOps-driven CI/CD process (such as AWS Code and Azure Pipelines). We released the Akamai Pipeline last year and have seen it gain significant popularity with our user base. In this blog post, we’ll outline the most popular use cases as well as some exciting new enhancements.

Pipeline allows you to define a set of JSON templates for Akamai configurations, and then define your own release environments with variables that are substituted into the templates to create separate environment-specific configurations (for example: dev.example.com, qa.example.com, staging.example.com, www.example.com). This allows users to modify a single configuration template and then promote it through the release environments, rather than having to iteratively change multiple configurations that each represent a different release environment. These Pipeline CLI operations can then be utilized by integration servers like Jenkins to automate all or part of the release process.

How Pipeline Works

Diagram 1 shows how the Akamai Pipeline works for a simple three-stage Pipeline consisting of dev.example.com, qa.example.com, and www.example.com. 

chart
Diagram 1: Akamai Pipeline architecture and core commands 

The Templates directory contains the JSON files that make up your configuration template. The Pipeline breaks your template into one default rule component and one component for each top-level match, but can be broken into any user-defined granularity. This is helpful if you need to have different portions of your configuration managed by and permissioned for different teams. Incidentally, if this capability is important to you, but you don’t need all of the Pipeline functionality, it is also available standalone in the PM CLI as the Snippets command. 

For each Pipeline environment you define, there will be a directory under the Environments directory. Inside the environment-specific directory you will find the “hostnames.json” and “variables.json” files that allow you to define the stage-specific details. While the Pipeline setup will define some common default variables for you, you can define any variables you want. Any aspect of your configuration that needs to change as your release Pipeline proceeds can be defined as a variable and automatically updated for each environment. 

Once initial template and variable files are defined, you’re ready to use the Pipeline. Three simple commands allow you to release to an environment:

  1. Merge inserts your variables and hostnames into your template and creates the single JSON file output needed to update Akamai in the Dist directory

  2. Save stores the local file to the Akamai Control Center (ACC) in the Property Manager application

  3. Promote activates the Property Manager configuration onto the Akamai network (you specify either the Akamai staging network or the production network) as well as merge and save commands if needed — use just this one command if you are ready to activate

For more information on Pipeline setup and usage, see the Resources section. 

Common Use Cases

There are several use cases for Akamai Pipeline. The simplest scenario is shown in Diagram 2, where there are three stages and changes are pushed through sequentially. In this case, the same Pipeline is used repeatedly for each new change introduced. 

Basic Pipeline
Diagram 2: Simple three-stage Pipeline with sequential promotion

A more complex, but common, scenario is that two or more releases may be in progress at once at different points in the release cycle, and they may use different environments. There are two possible configurations to deal with this. The first is shown in Diagram 3, where a separate Pipeline is spun up for each new release. This will generate warnings when the different Pipelines attempt to overwrite each other in the shared environment which can be overridden by the client if desired. 

Diagram 3: Two overlapping Pipelines
Diagram 3: Two overlapping Pipelines

 

The second approach shown in Diagram 4 is to put all of your environments into a single large Pipeline and then use only the environments you need for any given release. This environment pool approach has the advantage of not requiring a new Pipeline be created for each new release. Because it is all one logical Pipeline, there will be no overwriting warnings, so you must be sure to check that the different releases have properly merged their configuration changes.

Diagram 4: Creating a pool of all environments in a single Pipeline
Diagram 4: Creating a pool of all environments in a single Pipeline

New Developments

We will be releasing updates to the Akamai Pipeline on GitHub to improve functionality and enrich the process further. The Akamai Pipeline 0.6 release will include user-requested enhancements and fixes. Highlights include: 

  • Easing restrictions on out-of-sequence Pipeline promotions and increasing the allowed number of stages in the Pipeline for environment pool use cases
  • Enabling account switching support for our reseller customers 

A subsequent release will also add a key feature to incorporate server-side awareness of Pipeline into Property Manager to better coordinate synchronization between Pipeline and the UI. Properties used as part of the Pipeline will create a lock in the UI, which will need to be explicitly unlocked before UI changes are made. When an unlock occurs, the Akamai Pipeline recognizes this and warns the user the next time it is run. 

To stay up-to-date on the latest changes, click the “Watch” button on our GitHub repository.

Pipeline Resources