...
Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Prerequisites
The DataPower Operations Dashboard Cloud Agent Operator currently supports installation via OLM, see Prerequisites for supported versions.
...
Loading Images to a Container Registry
DataPower Operations Dashboard DPOD Cloud Agent images are currently available for download from PPA ( Passport Advantage (PPA) and need to be loaded to a container registry., so they can be pulled by your Kubernetes cluster. The container registry can may be any external registry which is accessible to the cluster, or the cluster cluster’s internal registry.
This is a the list of the images image file names (as available on PPA) and the images names and tags:
Image File Name | Image Name and Tag |
---|---|
dpod-ca-operator-catalog-<DPOD-VERSION>.tgz | dpod-cloud-agent-operator-catalog:<OPERATOR-VERSION>-amd64 |
dpod-ca-operator-bundle-<DPOD-VERSION>.tgz | dpod-cloud-agent-operator-bundle:<OPERATOR-VERSION>-amd64 |
dpod-ca-operator-<DPOD-VERSION>.tgz | dpod-cloud-agent-operator:<OPERATOR-VERSION>-amd64 |
dpod-ca-api-proxy-<DPOD-VERSION>.tgz | dpod-cloud-agent-api-proxy:<DPOD-VERSION>-amd64 |
dpod-ca-http-ingester-<DPOD-VERSION>.tgz | dpod-cloud-agent-http-ingester:<DPOD-VERSION>-amd64 |
dpod-ca-manager-<DPOD-VERSION>.tgz | dpod-cloud-agent-manager:<DPOD-VERSION>-amd64 |
dpod-ca-messaging-broker-<DPOD-VERSION>.tgz | dpod-cloud-agent-messaging-broker:<DPOD-VERSION>-amd64 |
dpod-ca-syslog-ingester-<DPOD-VERSION>.tgz | dpod-cloud-agent-syslog-ingester:<DPOD-VERSION>-amd64 |
In order to preserve the images digest digests in the container registry we recommend using the skopeo
utility (available as a package for most distributions: Installing Skopeo).
...
Consider the following example for loading the images to the OpenShift (OCP) internal container registry:
...
.
The commands might be a little different, depending on the chosen container registry, namespace name, versions, etc.
Set variables with the source, destination, versions, etc.:
Code Block DPOD_CLOUD_AGENT_NAMESPACE="integrationdpod-cloud-agent" CONTAINER_REGISTRY_EXTERNAL_URL="default-route-openshift-image-registry.apps.ocp10ocp4.mycluster.com" CONTAINER_REGISTRY_INTERNAL_URL="image-registry.openshift-image-registry.apps.ocp10ocp4.mycluster.com" DPOD_CLOUD_AGENT_VERSION="1.0.19.0" DPOD_CLOUD_AGENT_OPERATOR_VERSION="0.1.0" DPOD_CLOUD_AGENT_IMAGE_TAG=${DPOD_CLOUD_AGENT_VERSION}-amd64" DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG="${DPOD_CLOUD_AGENT_OPERATOR_VERSION}-amd64" IMAGES_DIR="/tmp" USER_ID="admin"
Load the operator catalog and bundle images to
openshift-marketplace
namespace:Code Block skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-catalog-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/openshift-marketplace/dpod-cloud-agent-operator-catalog:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-bundle-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/openshift-marketplace/dpod-cloud-agent-operator-bundle:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG}
Load the operator image to DataPower Operations Dashboard the DPOD Cloud Agent namespace (for namespace scope deployment) or to the
openshift-operators
namespace (for cluster scope deployment):Code Block # if Installation Mode is "AllNamespaces" (cluster scope), use : openshift-operators # if Installation Mode is "OwnNamespace" (Namespacenamespace scope), use : ${DPOD_CLOUD_AGENT_NAMESPACE} DPOD_CLOUD_AGENT_OPERATOR_NAMESPACE=${DPOD_CLOUD_AGENT_NAMESPACE} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_OPERATOR_NAMESPACE}/dpod-cloud-agent-operator:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG}
Load application images to DataPower Operations Dashboard the DPOD Cloud Agent namespace:
Code Block skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-api-proxy-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-api-proxy:${DPOD_CLOUD_AGENT_IMAGE_TAG} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-http-ingester-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-http-ingester:${DPOD_CLOUD_AGENT_IMAGE_TAG} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-manager-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-manager:${DPOD_CLOUD_AGENT_IMAGE_TAG} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-messaging-broker-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-messaging-broker:${DPOD_CLOUD_AGENT_IMAGE_TAG} skopeo copy --all --dest-creds=${USER_ID}:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-syslog-ingester-${DPOD_CLOUD_AGENT_VERSION}.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-syslog-ingester:${DPOD_CLOUD_AGENT_IMAGE_TAG}
Creating / Updating the ImageContentSourcePolicy
The DataPower Operations Dashboard DPOD Cloud Agent operator will deploy containers with images referencing to IBM’s cp.icr.io/cp/dpod
container registry. Since the images are currently loaded locally (or to non ibm registry) a mirroring will be needed into your own container registry (and are not still available in the IBM container registry), a mirroring is required to be configured using the ImageContentSourcePolicy
resource.
...
In the following example the first entry mirror for OCP, the path of cp.icr.io/cp/dpod
` path to is mirrored both by the internal OCP registry namespace integration
. The second entry mirror dpod-cloud-agent
and by a private external registry my-external-registry.com
with path dpod.
...
/dpod
. You should adjust these values according to the container registry that the images were loaded into.
Code Block |
---|
apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: openshiftdpod-cloud-agent-registry-mirror spec: repositoryDigestMirrors: - mirrors: - image-registry.openshift-image-registry.svc:5000/integrationdpod-cloud-agent - my-external-registry.com/dpod source: cp.icr.io/cp/dpod |
...
Without a proper ImageContentSourcePolicy
the pods will fail on ImagePullBackOff
error when trying to pull the images.
Installing the CatalogSource
In order to install DataPower Operations Dashboard Cloud Agent operator using OLM a CatalogSource must be created in openshift-marketplace
namespace (the images for the catalog and bundle should have already been loaded in previous step).
The following YAML example will create CatalogSource for DataPower Operations Dashboard Cloud AgentUse the following YAML example to create a CatalogSource
for the DPOD Cloud Agent (typically CatalogSources
are created in the openshift-marketplace
namespace):
Code Block |
---|
apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: ibm-dpod-cloud-agent-catalog namespace: openshift-marketplace spec: displayName: IBM DataPower Operations Dashboard Cloud Agent image: ${CONTAINER_REGISTRY_INTERNAL_URL}/openshift-marketplace/dpod-cloud-agent-operator-catalog:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG} publisher: IBM sourceType: grpc |
Do not forget to replace the variables reference (${...}
) with the actual values before creating the CatalogSource
.
Using the OpenShift Console
To creating create the CatalogSource
resource using the OpenShift Console, use the following steps.:
Navigate to your the OpenShift Console UI.
In the top-right of the UI, on the header bar, click the Import button (+) to import YAML.
Copy and paste the above YAML example into the editor.
Click the Create button to create the resource.
Using the OCP CLI (oc
)
To create this resource using the oc
CLI, use the following steps.:
Create a YAML file containing the above YAML example.
Use the
oc apply
command to apply the YAML resource.:Code Block oc apply -f ibm-datapower-operations-dashboard-operator-catalog.yaml
Validating that the CatalogSource is
...
Installed and Ready
To validate that the CatalogSource
resource was installed correctly, use the following steps.
Validate that the
...
CatalogSource pod is ready
use the following oc
command to get the CatalogSource
pod status and verify the status is READY
:
Code Block |
---|
oc get catalogsource ibm-dpod-cloud-agent-catalog -n openshift-marketplace -o yaml | yq read - "status.connectionState.lastObservedState") |
Validate that the
...
CatalogSource was processed into OperatorHub
Navigate to the OpenShift Console UI.
On the left panel, expand the Operators section.
Select OperatorHub.
At the top of the OperatorHub section, enter
datapower operations dashboard
into the Filter search box.A tile should be shown titled
IBM DataPower Operations Dashboard Cloud Agent
.
Installing
...
the DPOD Cloud Agent Operator
To install IBM DataPower Operations Dashboard the DPOD Cloud Agent Operator use the following steps:
...
The Approval Strategy is what determines if the IBM DataPower Operations Dashboard Cloud Agent Operator will automatically update when new releases become available within the selected channel. If Automatic
is selected, over-the-air updates will occur automatically as they become available. If Manual
is selected, an administrator would need to approve each update as it becomes available through OLM.
Using the OCP CLI (oc
)
To create IBM DataPower Operations Dashboard the DPOD Cloud Agent Operator subscription using the oc
CLI, use the following steps.:
Code Block |
---|
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: ibm-dpod-cloud-agent-operator namespace: ${DPOD_CLOUD_AGENT_OPERATOR_NAMESPACE} spec: channel: stable-v0.1 installPlanApproval: Automatic name: dpod-cloud-agent-operator source: ibm-dpod-cloud-agent-catalog sourceNamespace: openshift-marketplace startingCSV: dpod-cloud-agent-operator.v0.1.0 |
Do not forget to replace the variables reference (${...}
) with the actual values before creating the subscription.
Create a YAML file containing the above YAML example.
Use the
oc apply
command to apply the YAML resource.Code Block oc apply -f ibm-datapower-operations-dashboard-cloud-agent-operator.yaml
...
DPOD Cloud Agent Network Configuration
The Cloud Agent sends and receives data to / from the DataPower Operations Dashboard instance which is installed outside OCP the Kubernetes cluster.
Currently the DataPower Operations Dashboard DPOD Cloud Agent Operator support supports the following methods for exposing the cloud agent’s Cloud Agent’s services:
NodePort - (default) the The Cloud Agent operator will create services with the type of
NodePort
to expose the services externally to OCP.Custom - Other methods that the user would like to implement in order to expose the Cloud Agent services (example : ingress controller, LoadBalancer service etc). for more information see Kubernetes documentation
The resources created by the user will not be managed (owned
) by the Cloud Agent operator, It is the user The Cloud Agent operator will not create any resources for exposing the services externally to OCP, and it is the user’s responsibility to create, update and delete these resources .
...
(e.g.: Ingress controller, LoadBalancer services, etc.). For more information, see the Kubernetes documentation.
Forroute
, configuration see OCP
...
Route documentation.
Foringress
configuration see Kubernetes
...
Cloud Agent Inbound (ingress) Communication
The Cloud Agent inbound communication include includes:
Management API invocation generated by DataPower Operations Dashboard to the
manager
component of the Cloud Agent.Kafka communication to the
messaging
component of the Cloud Agent (messaging brokers).
...
Manager
The messaging manager
component has a number of properties (in the Cloud Agent CR) for controlling the communication:
incomingTrafficMethod
- The method of exposing the messaging manager to incoming traffic from outside the cluster.
Available options are:Custom
,NodePort
,Route
(default isRoute
for OpenShift andNodePort
for Kubernetes).externalHost
- The external host for accessing the messaging manager from outside the cluster. This value will be published by the messaging brokers (Kafka).externalPortStart
externalPort
- The starting external port for accessing the messaging manager from outside the cluster . The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port( default is 30100).incomingTrafficPortStart - The starting (default is 443).incomingTrafficPort
- The port for exposing the messaging manager to incoming traffic from outside the cluster (whenincomingTrafficMethod
isNodePort
). The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port. ( default is the value ofexternalPortStart
externalPort
).
For complete Messaging more information, see Manager API documentation
For that the Cloud Agent Operator will create the following Kubernetes services:
<CR name>-msg-bse-svc -
NodePort
services for externally accessing the messaging bootstrap port.<CR name>-msg-dir-svc-<broker number starting 0> - Messaging broker 0 (zero) service for externally direct access to this broker, will use port
externalPortStart
+1 (30101, 30102 etc). Each messaging broker will have similar service.
Manager
The Manager component has .
Messaging
The messaging component has a number of properties (in the Cloud Agent CR) for controlling the communication:
incomingTrafficMethod
- The method of exposing the messaging to incoming traffic from outside the cluster.
Available options are:Custom
,NodePort
,route
(default isRoute (OpenShift only) / NodePort
).externalHost
- The external host for accessing the manager messaging from outside the cluster. This value will be published by the messaging brokers (Kafka).externalPort
externalPortStart
- The starting external port for accessing the manager messaging from outside the cluster. The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is 44330100).incomingTrafficPort
incomingTrafficPortStart
- The starting port for exposing the manager messaging to incoming traffic from outside the cluster (whenincomingTrafficMethod
isNodePort
). The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port (default is the value ofexternalPort
externalPortStart
).
For complete Manager more information, see Messaging API documentation.
For that the The Cloud Agent Operator will create the following OCP route: Kubernetes services for the messaging component:
<CR name>-msg-bse-svc
- ANodePort
service for externally accessing the messaging bootstrap port.<CR name>
-mng - Route for externally accessing the manager over HTTPS
...
-msg-dir-svc-<broker number>
- ANodePort
service for each messaging broker (starting with zero) for external direct access to this broker, which uses portexternalPortStart
+1 (e.g.: 30101, 30102, etc).
Deploying the DPOD Cloud Agent Instance
In order to deploy IBM DataPower Operations Dashboard the DPOD Cloud Agent Instance instance, a CustomResource should be created.
This is an a minimal example of the CustomResource. The complete API is documented in DpodCloudAgent.
Code Block |
---|
apiVersion: integration.ibm.com/v1beta1 kind: DpodCloudAgent metadata: namespace: integration name: dpod-cloud-agent-prod spec: discovery: namespaces: - integrationdatapower-gateways-ns license: accept: true license: L-GHED-75SD3J use: Production manager: externalHost: dpod-cloud-agent-manager.apps.ocp10.mycluster.com replicas: 3 messaging: externalHost: dpod-cloud-agent-messaging.apps.ocp10.mycluster.com replicas: 3 storage: className: app-storage syslogIngester: replicas: 3 version: 1.0.19.0 |
Validating the Cloud Agent Instance
...
Navigate to your OpenShift Console UI.
Navigate to Installed Operators and choose
IBM DataPower Operations Dashboard Cloud Agent
.Click on
DpodCloudAgent
tab and make sure the new CustomResource is inRuning
Running
Phase.
Using the OCP CLI (oc
)
To validate the CustomResource using the oc
CLI, use the following steps.
Execute the following command and make sure the new CustomResource is in PHASE
Runing
Running
:Code Block
...
# oc get DpodCloudAgent <CR name> -n <Cloud Agent namespace>
...
oc get DpodCloudAgent dpod-cloud-agent-prod -n
...
dpod-cloud-agent