The Operator Lifecycle Manager (OLM) provides a framework for installing, updating, and managing the lifecycle of operators and their services.
Prerequisites
The DataPower Operations Dashboard Cloud Agent Operator currently supports installation via OLM in OCP clusters, see Prerequisites for supported versions.
Installation Mode
When installing an operator via OLM, there are two options for the Installation Mode:
All namespaces on the cluster
AllNamespaces
(aka cluster scope)A specific namespace on the cluster
OwnNamespace
(aka namespace scope)
In AllNamespaces mode, the Operator will use a ClusterRole and ClusterRoleBinding and using that will have cluster-wide scope to manage DataPower Operations Dashboard Cloud Agent resources across all namespaces. In OwnNamespace mode, the operator will use a Role and RoleBinding as its primary access (limited to the namespace it's installed in), with a limited set of ClusterRole permissions (see Cluster-scope permissions).
Do not install the Operator in more than one mode. If AllNamespaces is chosen, do not subsequently install a second instance in OwnNamespace mode.
Loading Images
DataPower Operations Dashboard Cloud Agent images are currently available for download from PPA (Passport Advantage ) and need to be loaded to container registry.
The container registry can be any external registry accessible to the cluster or the cluster internal registry.
This is the images file name (as available on PPA) and images name :
Image file Name | Image Name |
---|---|
dpod-ca-operator-catalog-1.0.19.0.tgz | dpod-cloud-agent-operator-catalog:0.1.0-amd64 |
dpod-ca-operator-bundle-1.0.19.0.tgz | dpod-cloud-agent-operator-bundle:0.1.0-amd64 |
dpod-ca-operator-1.0.19.0.tgz | dpod-cloud-agent-operator:0.1.0-amd64 |
dpod-ca-api-proxy-1.0.19.0.tgz | dpod-cloud-agent-api-proxy:1.0.19.0-amd64 |
dpod-ca-http-ingester-1.0.19.0.tgz | dpod-cloud-agent-http-ingester:1.0.19.0-amd64 |
dpod-ca-manager-1.0.19.0.tgz | dpod-cloud-agent-manager:1.0.19.0-amd64 |
dpod-ca-messaging-broker-1.0.19.0.tgz | dpod-cloud-agent-messaging-broker:1.0.19.0-amd64 |
dpod-ca-syslog-ingester-1.0.19.0.tgz | dpod-cloud-agent-syslog-ingester:1.0.19.0-amd64 |
In order to preserve the images digest we recommend using skopeo
utility (available as package for most distributions : installing Skopeo).
skopeo copy --all --dest-creds=<destination container registry credentials if needed> docker-archive:<image file full path> \ docker://<destination container registry path>/<image name>:<image tag>
Example for loading images to OCP internal container registry :
DPOD_CLOUD_AGENT_NAMESPACE="integration" CONTAINER_REGISTRY_EXTERNAL_URL="default-route-openshift-image-registry.apps.ocp10.mycluster.com" CONTAINER_REGISTRY_INTERNAL_URL="image-registry.openshift-image-registry.apps.ocp10.mycluster.com" DPOD_CLOUD_AGENT_IMAGE_TAG="1.0.19.0-amd64" DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG="0.1.0-amd64" IMAGES_DIR="/tmp"
Load operator catalog and bundle images to openshift-marketplace
namespace
skopeo copy --all --dest-creds=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-catalog-1.0.19.0.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/openshift-marketplace/dpod-cloud-agent-operator-catalog:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG} skopeo copy --all --dest-creds=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-bundle-1.0.19.0.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/openshift-marketplace/dpod-cloud-agent-operator-bundle:${DPOD_CLOUD_AGENT_OPERATOR_IMAGE_TAG}
Load operator image to DataPower Operations Dashboard Cloud Agent namespace (for namespace scope deployment) or to openshift-operators
namespace (for cluster scope deployment)
# if Installation Mode is "AllNamespaces" (cluster scope) use : openshift-operators # if Installation Mode is "OwnNamespace" (Namespace scope) use : ${DPOD_CLOUD_AGENT_NAMESPACE} DPOD_CLOUD_AGENT_OPERATOR_NAMESPACE=${DPOD_CLOUD_AGENT_NAMESPACE} skopeo copy --all --dest-creds=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-operator-1.0.19.0.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 Cloud Agent namespace
skopeo copy --all --dest-creds=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-api-proxy-1.0.19.0.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=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-http-ingester-1.0.19.0.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=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-manager-1.0.19.0.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-manager:${DPOD_CLOUD_AGENT_IMAGE_TAG} skopeo copy --all --dest-creds=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-messaging-broker-1.0.19.0.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=admin:$(oc whoami -t) docker-archive:${IMAGES_DIR}/dpod-ca-syslog-ingester-1.0.19.0.tgz \ docker://${CONTAINER_REGISTRY_EXTERNAL_URL}/${DPOD_CLOUD_AGENT_NAMESPACE}/dpod-cloud-agent-syslog-ingester:${DPOD_CLOUD_AGENT_IMAGE_TAG}
Creating / Updating ImageContentSourcePolicy
The DataPower Operations Dashboard Cloud Agent operator will deploy containers with images referencing cp.icr.io/cp/dpod
container registry.
Since the images are currently loaded locally (or to non ibm registry) a mirroring will be needed using the ImageContentSourcePolicy
resource.
In the following example the first entry mirror cp.icr.io/cp/dpod
` path to the internal OCP registry namespace integration
. The second entry mirror private external registry my-external-registry.com
with path dpod.
apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: openshift-registry-mirror spec: repositoryDigestMirrors: - mirrors: - image-registry.openshift-image-registry.svc:5000/integration - my-external-registry.com/dpod source: cp.icr.io/cp/dpod
If the ImageContentSourcePolicy will not be defined the pods will fail on ImagePullBackOff 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 Agent
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 the CatalogSource resource using the OpenShift Console, use the following steps.
Navigate to your 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.
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
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 IBM DataPower Operations Dashboard Cloud Agent Operator
To install IBM DataPower Operations Dashboard Cloud Agent Operator use the following steps :
Using the OpenShift Console
Use the previous steps to locate the IBM DataPower Operations Dashboard Cloud Agent Operator tile in the OperatorHub UI.
Select the
IBM DataPower Operations Dashboard Cloud Agent
tile. A panel to the right should appear.Click the Install button on the right panel.
Under Installation Mode select your desired installation mode.
Select the desired Update Channel.
Select the desired Approval Strategy.
Click the Subscribe button to install the IBM DataPower Operations Dashboard Cloud Agent Operator.
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 Cloud Agent Operator subscription using the oc CLI, use the following steps.
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.
oc apply -f ibm-datapower-operations-dashboard-cloud-agent-operator.yaml
IBM DataPower Operations Dashboard Cloud Agent Network Configuration
The Cloud Agent sends and receives data to / from the DataPower Operations Dashboard installed outside OCP .
Currently the DataPower Operations Dashboard Cloud Agent Operator support the following methods for exposing the cloud agent’s services :
NodePort - (default) the Cloud Agent operator will create services with type
NodePort
to expose 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 responsibility to create, update and delete these resources.
For route
configuration see OCP route documentation
For ingress
configuration see Kubernetes ingress documentation
Cloud Agent Inbound (ingress) Communication
The Cloud Agent inbound communication include
Management API invocation generated by DataPower Operations Dashboard to the
manager
component of the Cloud AgentKafka communication to the
messaging
component of the Cloud Agent (messaging brokers).
Messaging
The messaging component has 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
(default isNodePort
)externalHost - The external host for accessing the messaging from outside the cluster. This value will be published by the messaging brokers (Kafka).
externalPortStart - The starting external port for accessing the messaging 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 port for exposing the messaging to incoming traffic from outside the cluster (when
incomingTrafficMethod
isNodePort
). The bootstrap endpoint will use this port, and each messaging broker will use a consecutive port. (default is the value ofexternalPortStart
)
For complete Messaging 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 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 from outside the cluster.
externalPort- The external port for accessing the manager from outside the cluster (default is 443).
incomingTrafficPort - The port for exposing the manager to incoming traffic from outside the cluster (when
incomingTrafficMethod
isNodePort
). (default is the value ofexternalPort
).
For complete Manager API documentation
For that the Cloud Agent Operator will create the following OCP route:
<CR name>-mng - Route for externally accessing the manager over HTTPS
Deploy IBM DataPower Operations Dashboard Cloud Agent Instance
In order to deploy IBM DataPower Operations Dashboard Cloud Agent Instance a CustomResource should be created.
This is an example of the CustomResource . The complete API is documented in DpodCloudAgent.
apiVersion: integration.ibm.com/v1beta1 kind: DpodCloudAgent metadata: namespace: integration name: dpod-cloud-agent-prod spec: discovery: namespaces: - integration 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
Using the OpenShift Console
To validate the CustomResource using the OpenShift Console, use the following steps.
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
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
oc get DpodCloudAgent dpod-cloud-agent-prod -n integration