Enhancement suggestion of Sandbox CLI and Sandbox Client to make simple CI/CD

[elfinston]

Hi Team,

I am trying to make use case of Sandbox CLI with CI/CD workflow, especially combinate with Git like VCS supports multiple branches. Fortunately, Sandbox Client works well with plural Sandboxes in a machine at the same time.

Honestly, I guess there are not any depending points between VCS and Sandbox CLI. I guess It's why I succeeded without any issue. Anyway, I executed Sandbox Clients as background process on Linux as below.

[elfin@localhost ~]$ akamai sandbox list
Local sandboxes:

Default  Sandbox Name  Sandbox ID                            JWT Expiration Date
-------  ------------  ------------------------------------  -------------------------
YES      shki_sb_01    9b669a09-7b28-4161-9b42-738f99280373  Oct 15, 2021, 7:48 AM UTC
         shki_sb_02    0d20c9b5-8185-4763-8a81-f0f0c90d1f7a  Oct 15, 2021, 9:10 AM UTC

[elfin@localhost ~]$ akamai sandbox start &
[1] 3658 <<< PID
Starting Sandbox Client with arguments:
Config: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_01/config.json
Logging path: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_01/logs
Logging file: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_01/logs/sandbox-client.log
Logging config: /home/elfin/.akamai-cli/cache/sandbox-cli/sandbox-client-1.3.0-RELEASE/conf/logback.xml

Successfully launched Akamai Sandbox Client
Sandbox Client running on port: 9550

[elfin@localhost test01]$ akamai sandbox use 0d20c9b5-8185-4763-8a81-f0f0c90d1f7a
Sandbox: shki_sb_02 is now active

[elfin@localhost test01]$ akamai sandbox list
Local sandboxes:

Default  Sandbox Name  Sandbox ID                            JWT Expiration Date
-------  ------------  ------------------------------------  -------------------------
         shki_sb_01    9b669a09-7b28-4161-9b42-738f99280373  Oct 15, 2021, 7:48 AM UTC
YES      shki_sb_02    0d20c9b5-8185-4763-8a81-f0f0c90d1f7a  Oct 15, 2021, 9:10 AM UTC

[elfin@localhost ~]$ akamai sandbox start &
[2] 3782 <<< PID
Starting Sandbox Client with arguments:
Config: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_02/config.json
Logging path: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_02/logs
Logging file: /home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shki_sb_02/logs/sandbox-client.log
Logging config: /home/elfin/.akamai-cli/cache/sandbox-cli/sandbox-client-1.3.0-RELEASE/conf/logback.xml

Successfully launched Akamai Sandbox Client
Sandbox Client running on port: 9551

[elfin@localhost test01]$ netstat -an | grep 127.0.0.1:955
tcp        0      0 127.0.0.1:9550          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9551          0.0.0.0:*               LISTEN

And, I succeed A/B test using sandbox update API with rules.json files of each. In my test cases, each rules.json file was uploaded to repositories(Github and Bitbucket), and then webhook triggered from repositories to CI/CD tools(Jenkins). It's great as so far I expected.

However, I faced an enhancement point of Sandbox CLI at this timing. Because Sandbox CLI does not have yet a command to stop properly 'specific' Sandbox Client ID, Jenkins cannot kick restart specific a Sandbox Client.

On the other hand, I tried 'kill' command for PIDs of Akamai Sandbox CLI, but TCP port was kept opened by something. So, I could not start Sandbox Client again with the same Sandbox configuration(port number).

Maybe Node or JAVA process was related to the opened TCP port, but I did not try about that because I do not know detail about that and side effects or unexpected behavior.

[elfin@localhost test01]$ ps -an
   PID TTY      STAT   TIME COMMAND
  1116 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
  3658 pts/1    Sl+    0:00 akamai sandbox start
  3663 pts/1    Sl+    0:00 node /home/elfin/.akamai-cli/src/cli-sandbox/akamai-sandbox start
  3674 pts/1    Sl+    0:13 /usr/lib/jvm/java-11-openjdk-11.0.10.0.9-1.el7_9.x86_64/bin/java -Dlogging.file.path=/home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shk
  3782 pts/0    Sl+    0:00 akamai sandbox start
  3787 pts/0    Sl+    0:00 node /home/elfin/.akamai-cli/src/cli-sandbox/akamai-sandbox start
  3798 pts/0    Sl+    0:13 /usr/lib/jvm/java-11-openjdk-11.0.10.0.9-1.el7_9.x86_64/bin/java -Dlogging.file.path=/home/elfin/.akamai-cli/cache/sandbox-cli/sandboxes/shk
  4844 pts/2    R+     0:00 ps -an

[elfin@localhost test01]$ kill 3658 <<< We do not want to remember about this PID
[elfin@localhost test01]$ kill 3782 <<< We do not want to remember about this PID 

[elfin@localhost test01]$ netstat -an | grep 127.0.0.1:955
tcp        0      0 127.0.0.1:9550          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:9551          0.0.0.0:*               LISTEN

I think Docker would be the solution to my case at this time, but I believe fewer tools are better than more. Especially If customers consider using Docker, They have to control Containers and local files(Sandbox configurations) for each container(as permanent storage), so It makes complexity. Of course, They have to learn Docker.

If Sandbox CLI can handle(on/off) 'specific' Sandbox Client using Sandbox ID, the story becomes simple. It is my suggestion to adding a feature for stopping specific Sandbox Client by Sandbox CLI. Customers can make simple CI/CD workflow without Docker, so developers would be love Akamai's DevOps tool.

I am glad to post I am, some enhancement point about Sandbox CLI. Thank you so much read it.