Akamai : Parallel Environments
In this scenario, we will build on the Akamai : Simple Property quickstart. and add a preproduction environment.
Requirements
You have completed the Akamai : Simple Property quickstart
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.
1[
2 {
3 "cnameFrom": "bossmanfromscratch-preprod.example.com",
4 "cnameTo": "your-edge-hostname.edgesuite.net",
5 "cnameType": "EDGE_HOSTNAME"
6 }
7]
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:
Deployment
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.
Prerelease
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.
1{
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 }
61}
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. )