Akamai : Parallel Environments

In this scenario, we will build on the Akamai : Simple Property quickstart. and add a preproduction environment.


Where we are

You should have the following in your repository:

$ tree
└── akamai
    └── property
        └── bossman_from_scratch
            ├── hostnames.json
            └── rules.json

3 directories, 2 files

Adding preproduction

cp -R akamai/property/bossman_from_scratch{,_preprod}

Important: We must now update the hostnames.json file so that it serves a different hostname.

2  {
3      "cnameFrom": "bossmanfromscratch-preprod.example.com",
4      "cnameTo": "your-edge-hostname.edgesuite.net",
5      "cnameType": "EDGE_HOSTNAME"
6  }

Let’s make a quick detour now and run bossman status:


Our new environment is not shown! This is because bossman only concerns itself with commits, by design.

git add akamai/property/bossman_from_scratch_preprod
git commit -m "add preproduction"

Now the new environment is tracked by bossman:



Just as we did previously, it is now time to deploy our change:


There was no change to deploy to the bossman_from_scratch property, and v1 of bossman_from_scratch_preprod was created as expected.


Now let us prerelease our new configuration to the staging network.


Note that because the commit did not touch bosssman_from_scratch, it was not deployed, so bossman does not attempt to activate it.

We can check that all is in order in Akamai Control Center:


Making a change on both environments

By default, only HTTP GET requests are allowed on the Akamai platform. Allowing the use of more methods is quite easy, though. Let’s support POST!

Simply add lines 44-51 highlighted below to both files:

  • akamai/property/bossman_from_scratch/rules.jsonn

  • akamai/property/bossman_from_scratch_preprod/rules.jsonn

Do NOT copy paste the entire JSON here, since it contains placeholders that you already filled in with different values previously.

 2  "contractId": "YOUR_CONTRACT_ID",
 3  "groupId": "YOUR_GROUP_ID",
 4  "productId": "YOUR_PRODUCT_ID",
 5  "ruleFormat": "v2020-03-04",
 6  "rules": {
 7      "name": "default",
 8      "comments": "The behaviors in the Default Rule apply to all requests.",
 9      "options": {
10        "is_secure": false
11      },
12      "behaviors": [
13        {
14            "name": "origin",
15            "options": {
16              "cacheKeyHostname": "ORIGIN_HOSTNAME",
17              "compress": true,
18              "customValidCnValues": [
19                  "{{Origin Hostname}}",
20                  "{{Forward Host Header}}"
21              ],
22              "enableTrueClientIp": false,
23              "forwardHostHeader": "REQUEST_HOST_HEADER",
24              "hostname": "httpbin.org",
25              "httpPort": 80,
26              "httpsPort": 443,
27              "originCertsToHonor": "STANDARD_CERTIFICATE_AUTHORITIES",
28              "originSni": true,
29              "originType": "CUSTOMER",
30              "standardCertificateAuthorities": [
31                  "akamai-permissive"
32              ],
33              "verificationMode": "PLATFORM_SETTINGS"
34            }
35        },
36        {
37            "name": "cpCode",
38            "options": {
39              "value": {
40                  "id": YOUR_CPCODE_ID
41              }
42            }
43        },
44        {
45            "name": "caching",
46            "options": {
47              "behavior": "MAX_AGE",
48              "mustRevalidate": false,
49              "ttl": "31d"
50            }
51        },
52        {
53          "name": "allowPost",
54          "options": {
55             "allowWithoutContentLength": false,
56             "enabled": true
57          }
58       }
59    ]
60  }

Now use bossman validate to run superficial syntax checks on your working copy…


If you get thumbs up, great! If not, double-check the JSON.

We can now commit the change:

git commit -am "allow POST"

…and deploy the change - you’re getting used to this by now :)

Note that the commit message displayed in the screenshot is from an older version of this
tutorial where we were effecting a different change, please bear with this.

Now, we can activate on the Akamai staging network:


Closing Remarks

Bossman made it very easy to deploy and activate the configurations. But a few things could be improved:

  • You repeated yourself when setting up the allowPost behaviour, this is (sometimes) an engineering anti-pattern and there would be value in avoiding it!

Because bossman does not concern itself with how you build the configuration JSON and only cares about how it is changed over time, you can use a template tool as a valuable complement. This will allow you to manage your core configuration template in one place and automatically specialize it for the different environments you maintain.

  • It would have been nice to test the caching behaviour on preprod first if this is your usual workflow…

In this tutorial we showed how all configurations could be kept in lockstep, but bossman supports the “preprod then prod” workflow with equal ease.

We will cover these in later tutorials. )