As part of the October release, Akamai’s new and improved Property Manager CLI package is now generally available. This unlocks a foundationally new approach for working with Akamai configurations, and leveraging configurations as code.

This package exposes two primary commands.

• akamai property-manager – for people who want to make configuration changes locally in their existing environments. This also empowers different app teams within an organization to own different parts of a configuration and deploy changes specific to them on their own schedule.

• akamai pipeline – for doing the same as above, as well as deploying configuration changes via an automated Akamai Pipeline that plugs into existing CI/CD workflows.

I’ll explain these commands in more detail, and some of the interesting ways our group of beta testers used them for federated development and faster deployment.

Federated Development Using the property-manager Command

An akamai property-manager new-property call lets users create a local instance of their property to work on.

This local instance also breaks down a configuration into a collection of snippets that can be found inside a config-snippets directory. You can add, edit, remove, and reference configuration snippets locally. This has proven to be especially powerful for organizations who are looking to leverage a microservices oriented model where different teams control different parts of a configuration.

Some of the cool things we noticed our beta users do with configurations snippets are:

• Distribution of ownership

• Local source control

• Independent, parallel development

• Assign local permissions

Distribution of Ownership

Different parts of the configuration can now be owned by different app owners. Typically a site admin controls a generated main.json file that has a set of includes within it. These #includes correspond to snippets that are differentiated by certain criteria such as path matches or hostnames.  

For example, the ‘Shoes’ team within a retail website wants to cache more content and hence have a higher TTL compared to other departments. They will be included inside the generated main.json and own the Shoes snippet below:

Sample main.json code:
"rules": {

       "name": "default",

       "children": [

           "#include:Compressible_Objects.json",

           "#include:Cache_extensions.json",

           "#include:Shoes.json",

           "#include:Jewelery.json",

           "#include:Watches.json",

           "#include:Shirts.json",

           "#include:Handbags.json",

           "#include:Outerwear.json",

           "#include:Furniture.json"

       ]

…

}

Sample Shoes.json:
{

   "name": "Shoes",

   "children": [],

   "behaviors": [

       {

           "name": "caching",

           "options": {

               "behavior": "MAX_AGE",

               "mustRevalidate": false,

               "ttl": "30d"

           }

       }

   ],

   "criteria": [

       {

           "name": "path",

           "options": {

               "matchOperator": "MATCHES_ONE_OF",

               "values": [

                   "/shoes/*"

               ],

               "matchCaseSensitive": false

           }

       }

   ],

   "criteriaMustSatisfy": "all"

}

Local Source Control

The configuration snippets can be source controlled in existing local repositories. For example, users leveraging GIT can simply use commands such as git init, git remote add, and git push to work with configuration snippets just as with any other piece of code

Independent, Parallel Development

The collection of snippets that make up a configuration file are stored on a central build server. Individual teams can then copy these snippets to their local environments and work on them in parallel. When ready to deploy changes, they simply overwrite the existing snippet in the build repository and have a rule to activate on a GIT commit.

Assign Local Permissions

A subset of our beta users baked in local permissions for different snippets. This ensured that they could leverage existing groups and user permissions within their organization and extend it to working with Akamai changes.

Deploy Changes Faster Using the akamai pipeline Command

The Akamai Pipeline functionality goes a step beyond the property-manager command and integrates configuration snippets within the context of an automated build pipeline. An akamai pipeline new-pipeline allows you to build a pipeline of environments based off an existing configuration template, or from scratch.

Any attribute in the generated pipeline configuration can then be tokenized - our beta users have defined environments such as dev, qa, integration, production all with the same set of rules, but differing in attributes such as origin hostnames, billing codes, cloudlet policies, behaviors that can be turned on or off, etc.

Once a configuration change is made, that change can simply be propagated within the pipeline using a single akamai pipeline promote command. This command can also be integrated in build automation tools such as Jenkins, CircleCI, or TravisCI to enable a continuous integration workflow.

The akamai property-manager CLI is free to use with any Akamai delivery product today. If you’re already a CLI user, you can simply run akamai install property-manager and get started.

Additional Information

• You can get started with Akamai Property Manager on GitHub here.

• James Chin, one of the brains behind the Akamai Pipeline project, wrote an excellent how-to entitled "Using Jenkins and Akamai Pipeline Together".