The FileNet Content Manager operator
The FileNet Content Manager operator is built from the Red Hat and Kubernetes Operator Framework, which is an open source toolkit that is designed to automate features such as updates, backups, and scaling. The operator handles upgrades and reacts to failures automatically.
The operator helps you to take care of repeatable tasks by using the Kubernetes APIs and
kubectl
tools. Operators watch
over a Kubernetes environment and use its
actual state versus the defined state to decide what actions to take. The following diagram shows
the control loop that occurs as a result of constantly watching the state of the Kubernetes
resources.

The following concepts are key to managing the operator:
- Namespace deployment
-
At the beginning of a project, an administrator might encourage developers to use a short-lived namespace that is in their own name. These namespaces do not need to be metered. In the long term and for tracking purposes, it makes sense to divide up workloads into dedicated namespaces for your application lifecycle stages, such as development, preproduction, and production.
If you deploy all of your components at the same lifecycle stage into a targeted namespace, you can meter your deployments by the namespace and the platform label or swidtag. Metering uses a system of metadata annotation and aggregation, and is critical to help you understand your deployments against entitlements.
- Roles, role binding, and service accounts
-
The default for role-based access control (RBAC) is to deny all access unless you grant access.
A role scopes a set of operations that can be carried out on a group of resources. A service account provides an identity for processes that run in a pod, so it is necessary to grant a role to a service account for intra-cluster processes. A role binding associates a service account to a role, which in effect determines the operations that the account can run inside a namespace. An administrator can configure the role and role binding resources for each application before any operator is deployed. Each application must specify a
serviceAccountName
in its pod spec, and the service account must be created.The following diagram shows the relationship between the objects that are used to grant users access to Kubernetes API resources.
The operator uses a custom resource definition (CRD), which describes what the operator is meant to watch. The crd.yaml file contains the description of the custom resources for the container images, and the role.yaml and role_binding.yaml files define the access to the resources. The service_account.yaml file creates a service account with a role that has the permissions to manage the resources. The CRD specifies a configuration, but the cluster also needs controllers to monitor its state and reconcile the resource to match with the configuration. When the CRD is deployed it can then be used to control the automation containers by using Kubernetes primitives such as Services, ReplicaSets, DaemonSets, and Secrets. To control access, registry secrets and security context constraints (SCC) are needed to set the range of allowed IDs.
The operator lifecycle manager (OLM) acts as the management system for the operators on that cluster. Cluster administrators control which operators are available and who can interact with the running operators.
The following diagram shows the concepts that are involved and highlights the key components in controlling a deployed operator. To install the components, you use the custom resource (CR) templates that are available in a CASE package download. You then create and customize your CR file, which you then apply to the operator to watch.

If changes applied by the operator or other modifications that are made in the environment do not provide the expected result, restart the pods by scaling the impacted deployments down to 0 then up to the desired number to have Kubernetes (OpenShift) terminate the existing pods and create new ones.