Deploying the API Manager subsystem on Linux® x86_64 (CLI)

Deploy the individual API Manager subsystem. This procedure uses the CLI.

API Connect subsystems can be installed by creating individual subsystem custom resources (CRs), instead of using an API Connect cluster.

There are four subsystems that can be installed:

API Manager (discussed in this procedure)
API Analytics. For more information, see Deploying the API Analytics subsystem on Linux x86_64 (CLI)
API Portal. For more information, see Deploying the API Portal subsystem on Linux x86_64 (CLI)
API Gateway. For more information, see Deploying the API Gateway subsystem on Linux x86_64 (CLI)

Deploying the API Manager involves three main tasks:

Installing the certificate manager in the subsystem namespace
Setting up the certificates
Deploying API Manager

Installing the certificate manager in the subsystem namespace

Log in to your cluster with your OpenShift user credentials:
```
oc login
```
If you installed the operators in All namespaces on the cluster mode, you need to use a project other than openshift-operators in which to deploy the instances.
- If needed, create a new project in which to create the Operand Request object:
```
oc new-project <project_name>
```
  For example:
```
oc new-project integration
```

Create a file called operand-request.yaml and add the following content:

apiVersion: operator.ibm.com/v1alpha1
kind: OperandRequest
metadata:
  name: ibm-apiconnect-cert-manager
spec:
  requests:
  - operands:
    - name: ibm-cert-manager-operator
    registry: common-service
    registryNamespace: ibm-common-services

Create the resource:
```
oc apply -f operand-request.yaml
```

Setting up the certificates

Change to the namespace where you want to install the subsystem:
```
oc project <namespace>
```

Create a file that is called api-manager-certs.yaml and paste in the following contents:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigning-issuer
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "selfsigning-issuer"
  }
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ingress-issuer
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "ingress-issuer"
  }
spec:
  ca:
    secretName: ingress-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ingress-ca
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "ingress-ca"
  }
spec:
  duration: 87600h # 10 years
  renewBefore: 720h # 30 days
  secretName: ingress-ca
  commonName: "ingress-ca"
  usages:
  - digital signature
  - key encipherment
  - cert sign
  isCA: true
  issuerRef:
    name: selfsigning-issuer
    kind: Issuer
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "api-manager"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "ingress-ca"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: portal-admin-client
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "portal-admin-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: portal-admin-client
  secretName: portal-admin-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "api-manager"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "portal-admin-client"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gateway-client-client
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "gateway-client-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: gateway-client-client
  secretName: gateway-client-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "api-manager"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "gateway-client-client"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: analytics-ingestion-client
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "analytics-ingestion-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: analytics-ingestion-client
  secretName: analytics-ingestion-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "api-manager"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "analytics-ingestion-client"

Apply the file to your namespace:
```
oc apply -f api-manager-certs.yaml
```

Verify that the command installation succeeded:

oc get certificates

All certificates created successfully:

NAME                         READY   SECRET                       AGE
analytics-ingestion-client   True    analytics-ingestion-client   70s
gateway-client-client        True    gateway-client-client        70s
ingress-ca                   True    ingress-ca                   71s
portal-admin-client          True    portal-admin-client          71s

Deploying API Manager

Create a ManagementCluster YAML file. For example, you can create a file that is called api-manager.yaml with the following example configuration. All fields in the example are required. Update the values as applicable for your configuration:
```
apiVersion: management.apiconnect.ibm.com/v1beta1
kind: ManagementCluster
metadata:
  name: api-manager
  labels: {
    app.kubernetes.io/instance: "api-manager",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "api-manager"
  }
  annotations: {
    apiconnect-operator/cp4i: "false"
  }
spec:
  version: 10.0.6.0
  profile: n1xc2.m16
  portal:
    admin:
      secretName: portal-admin-client
  analytics:
    ingestion:
      secretName: analytics-ingestion-client
  gateway:
    client:
      secretName: gateway-client-client
  cloudManagerEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
    - name: admin.$STACK_HOST
      secretName: cm-endpoint
  apiManagerEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
    - name: manager.$STACK_HOST
      secretName: apim-endpoint
  platformAPIEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
    - name: api.$STACK_HOST
      secretName: api-endpoint
  consumerAPIEndpoint:
    annotations:
      cert-manager.io/issuer: ingress-issuer
    hosts:
    - name: consumer.$STACK_HOST
      secretName: consumer-endpoint
  databaseVolumeClaimTemplate:
    storageClassName: <storage-class>
  microServiceSecurity: certManager
  certManagerIssuer:
    name: selfsigning-issuer
    kind: Issuer
  license:
    accept: false
    use: production
    license: L-KZXM-S7SNCU
```
- Change the value of spec.license.accept to true if you accept the license agreement. For more information, see Licensing.
- In metadata.annotations, do not remove apiconnect-operator/cp4i: "false". This annotation guarantees that the API Manager does not attempt to integration with the Platform UI. This integration is not supported.
- For spec.license.use enter production or nonproduction to match the type of license that you purchased.
- For spec.license.license enter the license ID for the API Connect program that you purchased. To get the available license IDs, see API Connect licenses in the API Connect documentation.
- For spec.profile enter the type of installation profile that you want. For more information, see API Connect deployment profiles for OpenShift and Cloud Pak for Integration.
- For spec.version enter the API Connect product version or channel to be installed.
- For spec.databaseVolumeClaimTemplate.storageClassName, specify the RWO block storage class to use for persistence storage. For more information about selecting storage classes for Cloud Pak for Integration, see Storage considerations. To review API Connect storage support, see the "Supported storage types" section in Deployment requirements, in the API Connect documentation.
- Replace $STACK_HOST with the desired ingress subdomain for the API Connect stack. This variable is used when specifying endpoints. Domain names that are used for endpoints cannot contain the underscore "_" character. The host on OpenShift is typically prefixed by apps. Such as apps.subnet.example.com. Do one of the following:
  - For subdomain customization only: For the ingress hostnames (hosts.name), retain the prefixes that are predefined for the ingress hostnames and replace all instances of STACK_HOST with the desired ingress subdomain for the API Connect stack. For example, if your host is apps.subnet.example.com:
```
cloudManagerEndpoint:
    < ... >
  hosts: 
  - name: admin.apps.subnet.example.com
    secret: cm-endpoint
apiManagerEndpoint:
    < ... >
  hosts: 
  - name: manager.apps.subnet.example.com
platformAPIEndpoint:
    < ... >
  hosts: 
  - name: api.apps.subnet.example.com
    secret: api-endpoint
consumerAPIEndpoint:
    < ... >
  hosts: 
  - name: consumer.apps.subnet.example.com
    secret: consumer-endpoint
```
  - For complete hostname customization: Change both the predefined prefixes and the STACK_HOST subdomain to match your desired hostnames.
    
    For example, forcloudManagerEndpoint, you can replace admin.$STACK_HOST with my.cloudmgr.myhost.subnet.example.com, where my.cloudmgr replaces admin, and apps.subnet.example.com replaces STACK_HOST:
```
cloudManagerEndpoint:
      < ... >
    hosts: 
    - name: my.cloudmgr.apps.subnet.example.com
      secret: cm-endpoint
```
    You can do this for some or all of the hostnames, depending on your customization requirements.
Configure database backups for the API Manager. To successfully restore API Connect in the event of a disaster, where you need to redeploy a new cluster, you must configure the database backup settings before the initial installation of the Management subsystem. For more information on configuring backup settings, see Configuring backup settings for a fresh install of the Management subsystem on OpenShift or Cloud Pak for Integration.
Apply the YAML file to the cluster:
```
oc apply -f api-manager.yaml
```
Check the status of the API manager by running the following command in the project (namespace) where it was deployed:
```
oc get ManagementCluster
```
The installation is complete when the READY status changes to True, and the SUMMARY reports that all services are online:
```
NAME         READY   SUMMARY   VERSION    RECONCILED VERSION       AGE
api-manager   True   17/17       <version>   <version-build>       7m17s
```
Verify that you can log in to the Cloud Manager UI.
1. Run the following command to get the API Connect endpoints, so you can determine the URL for the Cloud Manager UI:
```
oc get routes
```
2. Locate the management-admin endpoint, and note it down.
3. Get the Cloud Manager admin user password:
```
oc get secret api-manager-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo ""
```
4. Open a browser and go to the api-manager-admin endpoint.
5. Log in to the Cloud Manager as an administrator by using the administrator password.

What's next?

Prepare your deployment for disaster recovery, so that your data can be restored if there is an emergency. For more information, see Preparing for disaster recovery.
Install other subsystems as needed.