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.
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.
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.
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.