Supported Since: 17.01
Deploying a cluster in IPS gives you a set of running ESB instances within the underlying Kubernetes/OpenShift platform, hosting a chosen set of configurations.
In IPS, each cluster has multiple associated cluster versions, and an active cluster (i.e. one that has running ESB instances) always has an active cluster version. Deploying a cluster effectively sets an active cluster version for the cluster, hence starting set of ESB instances hosting the projects and other configurations associated with the chosen cluster version.
You can access the cluster deployment page via multiple paths:
via Deployments tab on cluster details page
via the projects page where you can select a set of project versions and choose to deploy them on a preferred cluster
via the project version details page where you can attempt to deploy the currently viewing cluster version on a selected cluster
via the cluster versions page where you can select an existing cluster version to be directly deployed on the parent cluster
The cluster deployment page is a "workbench" that allows you to put together a set of projects, their port mapping configurations, and additional configuration artifacts, into a single cluster version that can be deployed on the selected cluster. It consists of the following main components:
Add Projects button allows adding a new project version to the deployment.
Projects tab displays the projects associated with the deployment:
Deployed Projects section displays already deployed projects (if any), and will not be changed during the deployment.
Pending Updates section displays projects that would be changed (added/removed) during the deployment, with the
Status column displaying the corresponding status (
To be Deployed or
To be Deleted).
Deployed and to-be-deployed projects display a Configure button where you can configure the port mappings for projects that would be deployed during the next deployment cycle.
Port mappings are assignments of external port numbers (visible outside the container network) to ports exposed by
(connectors inside) a project, so that they can accept messages from the external network. For example, if your project
has a HTTP ingress connector configured for port
Configuration Artifacts tab displays additional configuration files, such as custom libraries, XSDs or
configurations, that should be directly added to the deployed ESB instances (
$X_HOME/lib folders or
child paths under them) rather than being embedded in a project archive.
Add Uploaded Artifact button allows you to search for and pick an artifact that has been uploaded previously
(e.g. a standard
log4j2 configuration being used by several clusters).
Add New Artifact button exposes a file uploader that can be used to add a new artifact, including
artifact type (Type):
Configuration File (e.g. XSD,
actual file (File)
artifact upload path on the UltraESB-X instance (Path): relative to
$X_HOME/conf in case of a
$X_HOME/lib in case of a
Remarks section contains a text field for including any comments regarding the deployment. This will be visible only when there are pending changes on top of the loaded cluster version (meaning that a new cluster version would be generated during deployment).
Cluster Status Indicator to the left of the Add Projects button displays the real-time status of the cluster while a deployment is ongoing.
Deployment Progress Bar provides a detailed view of the status of the cluster, and is continuously refreshed showing you real-time status of the pods that are or have been deployed in it.
The page allows you to directly deploy an existing cluster version on a cluster, or to make modifications to an existing cluster version (in which case a new cluster version would be generated at deployment time).
When accessed via the Versions or Deployments tab under cluster details, the deployment page will load a 'pure' cluster version (i.e. one that has no pending changes and can be deployed straightaway). In other cases, the page will contain pending changes (e.g. newly added project versions) which would eventually get deployed as a new cluster version.
Regardless of the access path, the deployment page will keep track of the changes you make on the currently loaded cluster version, and will create a new cluster version if and only if there are pending changes (added/removed projects, changed port mappings or added/removed configuration artifacts) at the time of clicking the Deploy button.
|If you move away from a deployment page with pending changes without clicking Deploy, the changes will be lost!|
Assume you have a cluster that has already been reconfigured and deployed 5 times (meaning it has 5 old cluster versions):
If you want to deploy a new project on top of the currently deployed configuration, along with a customized
Go to clusters perspective → Details → Deployments (which will load the currently deployed cluster version configuration by default).
Click Add Project button and select the desired project version
If the project has exposed ports, click Configure against the new project (now under Pending Changes) and enter a port number for the Endpoint input field
Under Configuration Artifacts tab, click Add New Artifact.
Configuration File as the artifact Type.
log4j2.xml file via the File section (either by dragging-and-dropping the file into it, or by clicking
the section and using the file picker to pick the file on your local filesystem).
/ for Path (which resolves to
$X_HOME/conf/ when the file is being added to the actual ESB instance)
If, instead, you want to deploy the project and the logging configuration, on top of cluster version #3,
Go to clusters perspective → Details → Versions.
The 5 versions of the cluster would be listed in the versions page.
Click the Deploy button against the desired version (#3).