Automatically Clone Your Config with PAPI

by John Councilman
2588

There are times when you want to automatically clone and edit a configuration, rather than doing it manually through Luna. By using the Property Manager API (PAPI), you can do exactly that. This is particularly beneficial in the case where you have a “Master Config” with all the required optimizations that you want to use as a template for creating many similar sites or streaming configurations.

This blog post will show you how to clone your config with PAPI for the above use cases.

For this blog post, I’ve chosen to use Python, as many of my clients are using this for automation in place of Perl or Java. The Akamai developer portal has libraries for several different languages, so if you want to use something else, see Open Source API Clients.

In the rest of this post I’ll run through an example workflow utilizing Python, and explain each step.

Prerequisites

An admin with Luna access must obtain the authentication information needed to interact with an account using Akamai APIs. Specifically, you’ll need the following information:

  • Base URL
  • Client TokenC
  • Client Secret
  • Access Token

You’ll see these values in the Luna interface. Details on obtaining this information may be found here: https://developer.akamai.com/introduction/Prov_Creds.html

Obtain Libraries and Initialize

Begin by initializing Python as you would any other script and importing libraries:

Next, obtain the Akamai library from https://github.com/akamai-open/AkamaiOPEN-edgegrid-python.

Now Initialize Requests (HTTP) object and Akamai Auth:

Next import URLJoin (available via pip) to easily create full URLs from the Akamai base URL.

Next, you utilize the JSON module. This is mainly used for generating JSON requests outside of HTTP Requests. HTTP Requests contains its own built-in JSON Parser. Available via Pip as well.

Because we must parse some strings returned by the API which do not utilize JSON, I’ve decided to utilize the regular expression module (available via Pip) to easily parse strings returned.

This script is interactive. We would like for a user to be able to utilize command-line arguments to interact with the script instead of hard-coding everything. The argparse module (Available via Pip) allow this to be easily implemented.

Initialize Authentication and Variables

Use the authentication credentials from the Prerequisites section to enter the Base URL.

Now enter the client secret information is entered here. For this example, we are statically assigning it within the code, but you could keep it in an external file with some sort of encryption algorithm to secure the information.

Adding Interactive Command-line Arguments

The following bit of code will contain all interactive command line arguments to be utilized later within the script. Note that you could hard code all the values and not make it interactive. In this case the argparse module would not be needed.

Notice that we also implement a “list info” option to display all current configurations. This will be explained later.

We’ve added a couple of options below to allow for overwrite of specific property manager variables which will change for each newly cloned configuration; specifically Segment Duration, Live/On-Demand, and Authentication Information.

Typically, we would only clone configurations residing within a single contract. It’s safe to statically declare a contract ID within the code. Your contract ID may be contained from your account contact or within Luna.

Initialize the command line argument parser:

List Group and Property Information (Alternate Flow)

We’ve created a specific use case within the script lying outside of the configuration flow utilized to list all property and group IDs within a contract. This is useful for determining your environment, source Group IDs, destination Group IDs, and Source Property IDs to populate the script with for actual configuration.

The following will pull all groups within a contract, then loop through available properties within each respective group. Notice that the built-in JSON parser with “requests” is used.

The output will look similar to the following:

Continuation of Variable Assignment if Cloning Property

Below, we assign variables from the command line arguments or exit if required arguments are not given.

Initialize Authentication and Variables

The first thing we must do when cloning a configuration is to obtain the latest version of the Source configuration, referred to as the Master Config.

Obtain Master Config Version, ProductID, and eTag

Two examples are given below, one obtains the absolute latest version; the other obtains the latest Production version. Utilize one or the other – choosing the one best for your use case.

Latest PRODUCTION version:

Absolute latest version:

In either case, use:

Expect a 200 status code for success, otherwise, error out:

Utilize the built-in JSON parser to extract the needed variables:

Finally, here’s an example to delete a property prior to cloning. This is not normally used, but documented for example only:

Create a New Property Based on Master Config

First off, we should create a new cloned configuration based on the original Master Configuration. This configuration will require modification once created.

Notice how we are creating a JSON structure as a variable. We will do this several more times.

Below, notice newGroupId in the request URL. This is where we are creating new property (outside of Master Config group and in another one).

Note that the status code from the Clone command is 201; not 200.

You need to use a regular expression match to pull out only the property ID from propertyLink output:

Once the property has been created, we must create a new hostname to attach to the property.

Again, the status code of a successful operation will be 201 after the Create Hostname command. If we receive something other than a 201, we might have created this hostname before, so let’s try to re-use it first before erroring.

In the case of 201, we have successfully created a new hostname:

Once a new configuration and hostname have been created, we should pull the newest version of the newly cloned configuration. This is similar transaction as the one to pull the version of the Master configuration. Notice that we do not ask for the Production version since we’ve never activated this one. We also must pull the eTag from this particular configuration for later use.

Using the version number obtained before along with the hostname link, we will attach the newly-created Hostname to the newly-created property. Note that this particular request results in a 200 status code on success.

Edit Cloned Configuration Prior to Publication

Now that you have your cloned configuration, have attached a new hostname to it, and have generated a new CP Code, you must customize the configuration prior to activation on the network.

Notice that we’re modifying a previously obtained JSON structure within memory.

Activate the Property on the Akamai Network

You’ll want to notify people about the new property, use the following code to generate an email list for single or multiple email addresses.

I broke up the code here, because after the email structure the actual activation begins.

Categories: DevOps How To, Technology

Suggested Article

LEAVE A REPLY