DataPower

Hello!

We are starting to look into how we will integrate deployment of container-based Datapower and physical appliances.  We were planning to use the container-based deployment using the .cfg files for both the container and physical appliances.   We use deployment policies in our current Datapower deployments so we can use the same base code and make necessary environmental changes via deployment policies.

We are assuming that a deployment using a domain.cfg file would not trigger the deployment policy, so how to we mimic this functionaly?  

I was thinking in Openshift in the gatewayCluster CR I was given a tip to use the additionalInitCmds and additionalExe sections to create a script that can modify the config before it is applied to the pod.  Essentially should we replicate our current appliance deployment policies in scripts (using sed in linux to edit) and put them into config maps?

I was thinking we would have 1 bash script in a config map per environment:

dev-gw-{domain}-deployment-policy - make dev specific updates to {domain}.cfg
asm-gw-{domain}-deployment-policy - make asm specific updates to {domain}.cfg
tst-gw-{domain}-deployment-policy - make tst specific updates to {domain}.cfg

and so on up to prd.  Is this the best way?

------------------------------
Jennifer Stipe
------------------------------

Hi, 

there is a couple of different options, few of which you already mentioned. It kind of depends which is the best fit for your DevOps pipeline. We have used the Docker form-factor for the past three years and our approach, that relies on a set of start scripts, dates back to the first samples provided by IBM. The key idea is that instead of ENTRYPOINT drouter we run the container using CMD ["start.sh"] that executes bunch of shell scripts before starting the DataPower. This approach has worked well for us as the scripts are version controlled with the DataPower config files in one Git repository that is used as a source for the DataPower container "build" job.

--Hermanni

------------------------------
Hermanni Pernaa
------------------------------

Original Message:
Sent: Mon October 18, 2021 02:59 PM
From: Jennifer Stipe
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hello!

We are starting to look into how we will integrate deployment of container-based Datapower and physical appliances.  We were planning to use the container-based deployment using the .cfg files for both the container and physical appliances.   We use deployment policies in our current Datapower deployments so we can use the same base code and make necessary environmental changes via deployment policies.

We are assuming that a deployment using a domain.cfg file would not trigger the deployment policy, so how to we mimic this functionaly?  

I was thinking in Openshift in the gatewayCluster CR I was given a tip to use the additionalInitCmds and additionalExe sections to create a script that can modify the config before it is applied to the pod.  Essentially should we replicate our current appliance deployment policies in scripts (using sed in linux to edit) and put them into config maps?

I was thinking we would have 1 bash script in a config map per environment:

dev-gw-{domain}-deployment-policy - make dev specific updates to {domain}.cfg
asm-gw-{domain}-deployment-policy - make asm specific updates to {domain}.cfg
tst-gw-{domain}-deployment-policy - make tst specific updates to {domain}.cfg

and so on up to prd.  Is this the best way?

------------------------------
Jennifer Stipe
------------------------------

Hi Hermanni,

Do you have any links to the IBM examples for the shell script that functions as a deployment policy?  We started looking into some sed command but it seemed to get very complex fast due to the nature of the structure of the {domain}.cfg file.  We were thinking it might be easier to use Python instead of shell for this.  Let me know if you have any additional resources and thank you!

------------------------------
Jennifer Stipe
------------------------------

Original Message:
Sent: Tue October 19, 2021 12:56 PM
From: Hermanni Pernaa
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hi, 

there is a couple of different options, few of which you already mentioned. It kind of depends which is the best fit for your DevOps pipeline. We have used the Docker form-factor for the past three years and our approach, that relies on a set of start scripts, dates back to the first samples provided by IBM. The key idea is that instead of ENTRYPOINT drouter we run the container using CMD ["start.sh"] that executes bunch of shell scripts before starting the DataPower. This approach has worked well for us as the scripts are version controlled with the DataPower config files in one Git repository that is used as a source for the DataPower container "build" job.

--Hermanni

------------------------------
Hermanni Pernaa

Original Message:
Sent: Mon October 18, 2021 02:59 PM
From: Jennifer Stipe
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hello!

We are starting to look into how we will integrate deployment of container-based Datapower and physical appliances.  We were planning to use the container-based deployment using the .cfg files for both the container and physical appliances.   We use deployment policies in our current Datapower deployments so we can use the same base code and make necessary environmental changes via deployment policies.

We are assuming that a deployment using a domain.cfg file would not trigger the deployment policy, so how to we mimic this functionaly?  

I was thinking in Openshift in the gatewayCluster CR I was given a tip to use the additionalInitCmds and additionalExe sections to create a script that can modify the config before it is applied to the pod.  Essentially should we replicate our current appliance deployment policies in scripts (using sed in linux to edit) and put them into config maps?

I was thinking we would have 1 bash script in a config map per environment:

dev-gw-{domain}-deployment-policy - make dev specific updates to {domain}.cfg
asm-gw-{domain}-deployment-policy - make asm specific updates to {domain}.cfg
tst-gw-{domain}-deployment-policy - make tst specific updates to {domain}.cfg

and so on up to prd.  Is this the best way?

------------------------------
Jennifer Stipe
------------------------------

Hi Jennifer,

I didn't find any IBM examples of using sed. That is something that we have just adopted ourselves. Python probably works as we'll if you are able to make it work. For us it was about using something that can be run inside the DP container. IBM has some other shell script samples though that might give you some ideas how you can manipulate the cfg files. If the domain cfg is too big or complex to handle you can always split the configuration using include configuration definitions. We have for example divided our cfg files based on the integrations, or in other words one cfg per integration. Here is the link to IBM provided examples:

https://github.com/ibm-datapower/datapower-labs/tree/master/docker/ibmcom-datapower-example/src/start


------------------------------
Hermanni Pernaa
------------------------------

Original Message:
Sent: Thu November 11, 2021 02:11 PM
From: Jennifer Stipe
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hi Hermanni,

Do you have any links to the IBM examples for the shell script that functions as a deployment policy?  We started looking into some sed command but it seemed to get very complex fast due to the nature of the structure of the {domain}.cfg file.  We were thinking it might be easier to use Python instead of shell for this.  Let me know if you have any additional resources and thank you!

------------------------------
Jennifer Stipe

Original Message:
Sent: Tue October 19, 2021 12:56 PM
From: Hermanni Pernaa
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hi, 

there is a couple of different options, few of which you already mentioned. It kind of depends which is the best fit for your DevOps pipeline. We have used the Docker form-factor for the past three years and our approach, that relies on a set of start scripts, dates back to the first samples provided by IBM. The key idea is that instead of ENTRYPOINT drouter we run the container using CMD ["start.sh"] that executes bunch of shell scripts before starting the DataPower. This approach has worked well for us as the scripts are version controlled with the DataPower config files in one Git repository that is used as a source for the DataPower container "build" job.

--Hermanni

------------------------------
Hermanni Pernaa

Original Message:
Sent: Mon October 18, 2021 02:59 PM
From: Jennifer Stipe
Subject: Datapower in containers - what is the equivalent of Deployment policies?

Hello!

We are starting to look into how we will integrate deployment of container-based Datapower and physical appliances.  We were planning to use the container-based deployment using the .cfg files for both the container and physical appliances.   We use deployment policies in our current Datapower deployments so we can use the same base code and make necessary environmental changes via deployment policies.

We are assuming that a deployment using a domain.cfg file would not trigger the deployment policy, so how to we mimic this functionaly?  

I was thinking in Openshift in the gatewayCluster CR I was given a tip to use the additionalInitCmds and additionalExe sections to create a script that can modify the config before it is applied to the pod.  Essentially should we replicate our current appliance deployment policies in scripts (using sed in linux to edit) and put them into config maps?

I was thinking we would have 1 bash script in a config map per environment:

dev-gw-{domain}-deployment-policy - make dev specific updates to {domain}.cfg
asm-gw-{domain}-deployment-policy - make asm specific updates to {domain}.cfg
tst-gw-{domain}-deployment-policy - make tst specific updates to {domain}.cfg

and so on up to prd.  Is this the best way?

------------------------------
Jennifer Stipe
------------------------------