Hi Everyone,

We have achived our use cases by deploying ISAM9 on openshift in single project. Now we have another requirement like, we need to create multiple project in Openshift for ISAM9 where we are planning  to run config container in one project and reverse proxy container in another project but currently I am not sure how to do this ? can someone tried this or do we have any documnetation then please guide me for the setup.

------------------------------
Mayur Wattamwar
------------------------------

Hi Mayur,

The OpenShift cookbooks and assets I have documented were created for use in a single project.  When you say you want to run the system across multiple projects, I assume there is some reason for this related to separation (for security)?

Let's assume two projects.  "config" and "production"

Within an OpenShift cluster, services can be configured to be visible across projects - in fact that is the default in the OKD system I'm using for my testing.  A service created with name "isamconfig" in "config" project can be accessed from another project using the fully qualified name "isamconfig.config.svc".

With this in mind, it should be relatively easy to set up a system where the config service is in one project but the other components are in another project.  You would just need to use fully qualified names when referring to the services you need to connect across projects.

However, perhaps you are thinking about more separation than that - where the config project and production project are isolated from each other.  I have done some investigations looking at the use of OpenShift "ImageStreams" to build an ISAM system where the configuration is built in a configuration container and then baked into an image which is published to an image stream.  The "worker" containers are subscribed to this image stream and perform a rolling update to this new image/config.

This method looks promising for isolated configuration.  The configuration snapshot created by the configuration container would be published to an image stream in the production project.

However, there is one area I'm not sure about.  When doing configuration, there are times when the config container needs to talk to the isam runtime service.  In a truly separated environment you wouldn't want this to be the runtime service in the production project.  I think you could work around this by having a runtime deployment in both the config project and the production project - and use the unqualified service name to invoke.  I haven't tried it though.

In my ISAM docker assets on GitHub, there is an "alt-deployment-configs" directory.  This contains alternative core and rp templates which are based around the use of an image stream to load configuration into the worker containers.  I don't have documentation for this but it might be worth taking a look at it.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Thank you Jon, I will check and get back to you on this if anything require.

------------------------------
Mayur Wattamwar
------------------------------

Original Message:
Sent: Wed June 24, 2020 10:24 AM
From: Jon Harry
Subject: ISAM9 with multiple project in OpenShift

Hi Mayur,

The OpenShift cookbooks and assets I have documented were created for use in a single project.  When you say you want to run the system across multiple projects, I assume there is some reason for this related to separation (for security)?

Let's assume two projects.  "config" and "production"

Within an OpenShift cluster, services can be configured to be visible across projects - in fact that is the default in the OKD system I'm using for my testing.  A service created with name "isamconfig" in "config" project can be accessed from another project using the fully qualified name "isamconfig.config.svc".

With this in mind, it should be relatively easy to set up a system where the config service is in one project but the other components are in another project.  You would just need to use fully qualified names when referring to the services you need to connect across projects.

However, perhaps you are thinking about more separation than that - where the config project and production project are isolated from each other.  I have done some investigations looking at the use of OpenShift "ImageStreams" to build an ISAM system where the configuration is built in a configuration container and then baked into an image which is published to an image stream.  The "worker" containers are subscribed to this image stream and perform a rolling update to this new image/config.

This method looks promising for isolated configuration.  The configuration snapshot created by the configuration container would be published to an image stream in the production project.

However, there is one area I'm not sure about.  When doing configuration, there are times when the config container needs to talk to the isam runtime service.  In a truly separated environment you wouldn't want this to be the runtime service in the production project.  I think you could work around this by having a runtime deployment in both the config project and the production project - and use the unqualified service name to invoke.  I haven't tried it though.

In my ISAM docker assets on GitHub, there is an "alt-deployment-configs" directory.  This contains alternative core and rp templates which are based around the use of an image stream to load configuration into the worker containers.  I don't have documentation for this but it might be worth taking a look at it.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Hi Jon,
thanks for your help, your suggestion help us lot to implement in our organisation.

------------------------------
Mayur Wattamwar
------------------------------

Original Message:
Sent: Wed June 24, 2020 10:24 AM
From: Jon Harry
Subject: ISAM9 with multiple project in OpenShift

Hi Mayur,

The OpenShift cookbooks and assets I have documented were created for use in a single project.  When you say you want to run the system across multiple projects, I assume there is some reason for this related to separation (for security)?

Let's assume two projects.  "config" and "production"

Within an OpenShift cluster, services can be configured to be visible across projects - in fact that is the default in the OKD system I'm using for my testing.  A service created with name "isamconfig" in "config" project can be accessed from another project using the fully qualified name "isamconfig.config.svc".

With this in mind, it should be relatively easy to set up a system where the config service is in one project but the other components are in another project.  You would just need to use fully qualified names when referring to the services you need to connect across projects.

However, perhaps you are thinking about more separation than that - where the config project and production project are isolated from each other.  I have done some investigations looking at the use of OpenShift "ImageStreams" to build an ISAM system where the configuration is built in a configuration container and then baked into an image which is published to an image stream.  The "worker" containers are subscribed to this image stream and perform a rolling update to this new image/config.

This method looks promising for isolated configuration.  The configuration snapshot created by the configuration container would be published to an image stream in the production project.

However, there is one area I'm not sure about.  When doing configuration, there are times when the config container needs to talk to the isam runtime service.  In a truly separated environment you wouldn't want this to be the runtime service in the production project.  I think you could work around this by having a runtime deployment in both the config project and the production project - and use the unqualified service name to invoke.  I haven't tried it though.

In my ISAM docker assets on GitHub, there is an "alt-deployment-configs" directory.  This contains alternative core and rp templates which are based around the use of an image stream to load configuration into the worker containers.  I don't have documentation for this but it might be worth taking a look at it.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------