Defining and deploying a DBB server container

Configuring DBB server

For running a POC or trial, the basic configuration provides all that you need for a quick setup and start. For running a production server, you need to configure both the User Registry and an instance of Db2. The following Custom Resource (CR) defines a default configuration for a POC or trial.

apiVersion: dbb.ibm.com/v1
kind: DBBServer
metadata:
  name: <name>
  namespace: <namespace>
spec:
  license:
    accept: true
  useLocalDerby: true
  derbyPVClaimSpec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
    storageClassName: dbb-derby
  logsPVClaimSpec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
    storageClassName: dbb-logs

This CR sets the required license acceptance to true (license is found in the CASE bundle). It also indicates that it is using a Derby database and defines persistent volume claims for the Derby database and log files. These claims use a default storage class. So, the OCP administrators must have defined a default storage class.

If you are installing for the first time, continue with the configuration steps below. If you are upgrading from a previous release, review and follow the instructions in Migrating a Dependency Based Build container.

Deploying the DBB server Custom Resource

After the configuration is set in the CR, the CR can be applied to your cluster. The DBB operator will use the CR to create the necessary artifacts (such as ConfigMaps, Deployments, Route, and Service) for an operating DBB server. After the configuration is complete, the server starts automatically and can be monitored in the OCP console under Workloads > Pods and selecting the namespace used for the CR.

1. Use the oc client to log in to your cluster.

   oc login https://<your_cluster_hostname> -u <username> -p <password>
   

2. Create a namespace and set the project for your DBB OCP resources or use the --namespace <namespace> option in step 3.

   oc create namespace <namespace>
   

   Note: While a unique namespace is not required for multiple DBB server deployments, it is recommended.

3. Deploy the CR

   oc apply -f dbbserver_cr.yaml
   

Custom Resource Status

As the Customer Resource (CR) is reconciled by the operator, the state on the CR will change from initial to available. If the initial deployment attempt fails, the state will go to initialFail. After deployment, if the server fails to run, the state will go to notAvailable.

For each state, the following table shows the statuses that are displayed as part of the CR.

Additional Steps

By default, the DBB operator configures a NetworkPolicy and an EgressNetworkPolicy in the namespace, which completely shuts down ingress and egress, respectively. Ingress and egress must be opened in order for the DBB server container to work.

1. Update NetworkPolicy
   • Log in to the cluster console as administrator and navigate to Networking > NetworkPolicies.
   • Select the Project/Namespace used for the DBBServer CR.
   • Select the NetworkPolicy named <DBBServer CR name>-dbb-np.
   • Click the YAML tab to view the YAML code.
   • Add the following lines to the end of the YAML code and save. This opens ingress to all traffic. More strict rules may be added as needed.

     ingress:
       - {}
     

2. Update EgressNetworkPolicy
   • Log in to the cluster console as administrator and navigate to Administration > CustomResourceDefinitions.
   • Select EgressNetworkPolicy custom resource definition.
   • Select Instances.
   • Select the <DBBServer CR name>-dbb-enp instance with the namespace that is used to apply the DBBServer CR.
   • Click the YAML tab to view the YAML code.
   • At a minimum, you must add an egress to the cluster's API node in front of the Deny egress and save. Other egress rules may be applied as needed for the database and LDAP.

     egress:
       - to:
           cidrSelector: 9.30.235.162/32
         type: Allow
       - to:
           cidrSelector: 0.0.0.0/0
         type: Deny
     

3. Restart the DBB server pod. Once the NetworkPolicy and EgressNetworkPolicy are updated, you may need to restart the DBB server pod for the updated policies to take effect.
   • Log in to the cluster console as administrator and navigate to Workloads > Pods.
   • Select the Project/Namespace used for the DBBServer CR.
   • Find the DBB server pod named <DBBServer CR name>-dbb-deployment-<deployment id>-<unique id>.
   • Click the three dots next to the DBB server pod and select Delete Pod. A new pod automatically spins up to replace the deleted pod.

Validating DBB server setup

1. Log into your OpenShift Cluster console.

2. Expand the Workloads tab on the left-hand side menu and click Pods.

3. On the Pods page, select the project from the drop-down list.

4. The Pod, <cr_name>-dbb-deployment-1-<id> should have the Running status. Click the pod and inspect the YAML or logs if errors occur.

5. Click the Networking tab on the left-hand side menu and click Routes.

6. Note the location URL for the dbb-server route. Use the hostname in this url for later steps.

7. Navigate to https://<hostname>/dbb/rest/collection.

8. Log in with any DBBAdmins credentials you have configured.

9. You should see a heading of "DBB Collections" with no collections listed.

10. Create sample collections.

    • Navigate to https://<hostname>/dbb/rest/collection/setup. Expected result is "OK - Setup completed."
    • Navigate to https://<hostname>/dbb/rest/collection. Expect to see a list of collections ("Collection1", "Collection2", and "Collection3").
    • Navigate to each collection to see the logical files and logical dependencies.

Troubleshooting

Review the YAML or Logs tab in the pod. If the server is running, open a terminal for the pod and review the log files that are generated at /logs to identify issues with the server.