Pre-deployment configuration

After you verify that the prerequisites are met, create an OpenShift project or a Kubernetes namespace, and create the necessary secrets.

About this task

I. Create a project or namespace

II. Create secrets for z/OS facing components of Z APM Connect DG

III. Create secrets for connectivity to your APM tool

IV. Verify the secrets

Procedure:

I. Create a project or namespace

OpenShift® projects or Kubernetes namespaces are used to logically group pods for the application. It is recommended to use a separate Kubernetes namespace or a separate OpenShift project for Z APM Connect Distributed Gateway for higher security and better organization. You can name the project or namespace anything, but for examples below, the project or namespace name ibm-zapm is used.

Create a project or namespace by using the following command for your environment.

OpenShift project:
```
oc new-project ibm-zapm
```
Kubernetes namespace:
```
kubectl create namespace ibm-zapm
```

Important: After running this command, all the documented examples will be written using OpenShift, but are written such that the same Kubernetes command can be executed by replacing the OpenShift executable oc with kubectl -n <namespace name>.

II. Create secrets for z/OS facing components of Z APM Connect DG

OpenShift or Kubernetes secrets are used to store passwords, tokens, and certificates securely. Before installation, add the correct secrets to the project or namespace.

Create secrets for the z/OS® facing components of the Z APM Connect Distributed Gateway.

If TLS will not be used or if custom TLS termination will be used, skip to Step 3 to create secrets for connectivity to your APM tool.

After the necessary truststore and keystore files are generated and transferred to the installation machines, run the following command to create the Secrets:

oc create secret generic <secret name> \
 --from-file=keystore.jks \
 --from-file=truststore.jks \
 --from-literal=truststore-pass=<pass> \
 --from-literal=keystore-pass=<pass> \
 --from-literal=key-pass=<pass>

Note: The truststore and keystore must be named truststore.jks and keystore.jks for the Connection Manager, and kafka.truststore.jks and kafka.keystore.jks for Kafka.

For example, for Kafka:

  oc create secret generic kafka-auth \
   --from-file=kafka.keystore.jks \
   --from-file=kafka.truststore.jks \
   --from-literal=truststore-pass=tpass1 \
   --from-literal=keystore-pass=kpass1 \
   --from-literal=key-pass=kpass1

For the Connection Manager:

  oc create secret generic ingress-auth \
   --from-file=keystore.jks \
   --from-file=truststore.jks \
   --from-literal=truststore-pass=tpass1 \
   --from-literal=keystore-pass=kpass1 \
   --from-literal=key-pass=kpass1

III. Create secrets for connectivity to your APM tool

Instana secrets

An Instana secret is only required if the TLS configuration that the Instana server is using uses a certificate that is signed by an internal CA. If so, a secret is needed that contains the pem file which contains the CA as well as any intermediate signing certificates.

(Optional) Run the following command to create the Instana secret:

oc create secret generic <secret name> --from-file=<cert name>

For example:

oc create secret generic instana-auth --from-file=cert.pem

Note: Ensure that the certName (Helm) or input25 (Manual) parameter is set to match the name of the certificate provided.

IV. Verify the secrets

To double check that all the secrets are in your OpenShift project or Kubernetes namespaces, run the following command:

Using OpenShift:
```
  oc get secrets
```

Output should resemble the following:

    NAME                         TYPE                                  DATA   AGE
    ingress-auth                 Opaque                                5      3m50s
    kafka-auth                   Opaque                                5      2m14s
    instana-auth                 Opaque                                1      112s

Using Kubernetes:
```
  kubectl get secrets
```