Installing OCNRF

2 Installing OCNRF

This section describes the prerequisites and installation procedure for OCNRF.

Prerequisites

Following are the prerequisites to install and configure OCNRF:

OCNRF Software

The OCNRF software includes:

OCNRF Helm charts
OCNRF docker images

The following software must be installed before installing OCNRF:

Software	Version
Kubernetes	v1.15.3
HELM	v2.14.3 and v3.2

Additional software that needs to be deployed as per the requirement of the services:

Software	Chart Version	Required For
elasticsearch	5.5.4	Logging Area
elastic-curator	5.5.4	Logging Area
elastic-exporter	1.0.2	Logging Area
logs	2.0.7	Logging Area
kibana	6.7.0	Logging Area
grafana	6.1.6	Metrics Area
prometheus	9.1.2	Metrics Area
prometheus-node-exporter	0.17.0	Metrics Area
metallb	0.7.3	External IP
metrics-server	0.3.1	Metric Server
tracer	0.8.3	Tracing Area

Note:

Install the specified software items before proceeding, if any of the above services are needed and the respective software is not already installed in CNE.

To check the installed software items, execute:

helm ls

Some of the systems may need to use helm command with admin.conf file, such as:

helm --kubeconfig admin.conf

Network access

The Kubernetes cluster hosts must have network access to:

Local docker image repository where the OCNRF images are available.
To check if the Kubernetes cluster hosts has network access to the local docker image repository, try to pull any image with tag name to check connectivity by executing:
```
docker pull <docker-repo>/<image-name>:<image-tag>
```
Note:

Some of the systems may need to use helm command with admin.conf file, such as:

helm --kubeconfig admin.conf
Local helm repository where the OCNRF helm charts are available.
To check if the Kubernetes cluster hosts has network access to the local helm repository, execute:
```
helm repo update
```
Note:

Some of the systems may need to use helm command with admin.conf file, such as:

helm --kubeconfig admin.conf

Note:

All the kubectl and helm related commands that are used in this document must be executed on a system depending on the infrastructure of the deployment. It could be a client machine such as a VM, server, local desktop, and so on.

Client machine requirement

Client machine needs to have the following minimum requirements:

Network access to the helm repository and docker image repository.
Helm repository must be configured on the client.
Network access to the Kubernetes cluster.
Necessary environment settings to run the kubectl commands. The environment should have privileges to create a namespace in the Kubernetes cluster.
Helm client must be installed. The environment should be configured so that the helm install command deploys the software in the Kubernetes cluster.

Server or Space Requirements

For information on the server or space requirements, see the Oracle Communications Cloud Native Environment (OCCNE) Installation Guide.

Secret file requirement

For HTTPs and Access token, the following certs and pem files has to be created before creating secret files for Keys and MySql.

Note: The following files must be created before creating secret files.

ECDSA private Key and CA signed ECDSA Certificate (if initialAlgorithm: ES256)
RSA private key and CA signed RSA Certificate (if initialAlgorithm: RS256)
TrustStore password file
KeyStore password file
CA signed ECDSA certificate

ServiceAccount requirement

Operator must create a service account, bind it with a Role for resource with permissions for atleast get, watch and list.

serviceAccountName is a mandatory parameter. Kubernetes Secret resource is used for providing the following:

MYSQL DB Details to micro-services.
NRF's Private Key, NRF's Certificate and CA Certificate Details to Ingress/Egress Gateway for TLS.
NRF's Private and NRF's Public Keys to nfAccessToken micro-service for Digitally Signing AccessTokenClaims.
Producer/Consumer NF's Service/Endpoint details for routing messages from/to Egress/Ingress Gateway.

The Secret(s) can be under same namespace where OCNRF is getting deployed (recommended) or # Operator can choose to use different namespaces for different secret(s). If all the Secret(s) are under same namespace as OCNRF, then Kubernetes Role can be binded with the given ServiceAccount. Otherwise ClusterRole needs to be binded with the given ServiceAccount. The Role/ClusterRole needs to be created with resources: (services, configmaps, pods, secrets, endpoints) and (verbs: get, watch, list). Refer to Creating Service Account, Role and Role bindings for more details.

DB Tier Requirement

DB Tier must be up and running. In case of geo-redundant deployments, replication between geo-redundant DB Tier must be configured. Refer to DB Tier section in OCCNE installation guide.

Installation Sequence

This section explains the tasks to be performed for installing OCNRF.

OCNRF pre-deployment configuration

Following are the pre-deployment configuration procedures:

Creating OCNRF namespace

Note:
This is a mandatory procedure, execute this before proceeding any further. The namespace created/verified in this procedure is an input for next procedures.
Creating Service Account, Role and Role bindings

Note:
Following are sample steps, in case of already configured service account with role and role-bindings or the user has previously prepared procedure to create service account, skip this procedure.
Configuring MySql database and user
Configuring Kubernetes Secret for Accessing OCNRF Database
Configuring secrets for enabling HTTPS
Configuring Secret for Enabling AccessToken Service

Creating OCNRF namespace

This section explains how the user can verify if the required namespace is available in the system or not.

Procedure

Verify required namespace already exists in system:
```
$ kubectl get namespaces
```
In the output of the above command, check if required namespace is available. If not available, create the namespace using following command:

Note:
This is an optional step. In case required namespace already exists, skip this procedure.
```
$ kubectl create namespace <required namespace>
```
For example:-
```
$ kubectl create namespace ocnrf
```

Creating Service Account, Role and Role bindings

This section explains how user can create service account, required role and role bindings resources. The Secret(s) can be under same namespace where OCNRF is getting deployed (recommended) or operator can choose to use different namespaces for different secret(s). If all the Secret(s) are under same namespace as OCNRF, then Kubernetes Role can be binded with the given ServiceAccount. Otherwise ClusterRole needs to be binded with the given ServiceAccount.

Sample template for the resources is as follows and add sample template content to resource input yaml file.

Example file name: ocnrf-resource-template.yaml

Example command for creating the resources

kubectl -n <ocnrf-namespace> create -f ocnrf-resource-template.yaml

Sample template to create the resources

Note:

Update <helm-release> and <namespace> with respective OCNRF namespace and planned OCNRF helm release name in the place holders.

## Sample template start#
apiVersion: v1
kind: ServiceAccount
metadata:
  name: <helm-release>-ocnrf-serviceaccount
  namespace: <namespace>
---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: <helm-release>-ocnrf-role
  namespace: <namespace>
rules:
- apiGroups:
  - "" # "" indicates the core API group
  resources:
  - services
  - configmaps
  - pods
  - secrets
  - endpoints
  verbs:
  - get
  - watch
  - list
---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: <helm-release>-ocnrf-rolebinding
  namespace: <namespace>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: <helm-release>-ocnrf-role
subjects:
- kind: ServiceAccount                                   
  name:  <helm-release>-ocnrf-serviceaccount
  namespace: <namespace>
## Sample template end#

Configuring MySql database and user

Procedure for Geo-Redundant OCNRF sites

This section explains how database administrator can create the databases and users for OCNRF network function.

Note:

Procedure can be different for geo-redundant OCNRF sites and standalone OCNRF site.
Before executing the below procedure for Geo-Redundant sites, ensure that the DB-Tier for Geo-Redundant sites are already up and replication channels are enabled.
While performing Fresh Installation, in case OCNRF release is already deployed, purge the deployment, remove databases, users used for previous deployment. Refer to Uninstalling OCNRF for uninstallation procedure.

Login to the machine where ssh keys are stored and which has permission to access the SQL nodes of NDB cluster.
Connect to the SQL nodes.
Login to the MySQL prompt using root permission or user, which has permission to create users with conditions as mentioned below. For example: mysql -h 127.0.0.1 -uroot -p

Note:
This command may vary from system to system, path for MySQL binary, root user and root password. After executing this command, user need to enter the password specific to the user mentioned in the command.
Check OCNRF network function database user already exists. If the user does not exists, create an OCNRF network function database user.
Below steps covers the creation of two type of OCNRF database users. Different users has different set of permissions.
1. OCNRF privileged user: This user has complete set of permissions. This user can perform create, alter, drop operations on tables to perform install/upgrade/rollback or delete operations.
2. OCNRF application user: This user has less set of permissions and will be used by OCNRF application during service operations handling. This user can insert, update, get, remove the records. This user can't create, alter and drop the database as wells as tables
```
$ SELECT User FROM mysql.user;
```
In case, user already exists, move to next step. Else, create new following ocnrf user:
- Create new ocnrf privileged user:
  $ CREATE USER '<OCNRF Privileged-User Name>'@'%' IDENTIFIED BY '<OCNRF Privileged-User Password>';
  
  Example:
```
$ CREATE USER 'nrfPrivilegedUsr'@'%' IDENTIFIED BY 'nrfPrivilegedPasswd'
```
- Create new ocnrf application user:
```
$ CREATE USER '<OCNRF APPLICATION User Name>'@'%' IDENTIFIED BY '<OCNRF APPLICATION User Password>';
```
  Example:
```
$ CREATE USER 'nrfApplicationUsr'@'%' IDENTIFIED BY 'nrfApplicationPasswd'
```
Note:
Both users must be created on all the SQL Nodes on all the sites.
Check OCNRF network function database already exists. If the database does not exists, create databases for OCNRF network function:
Execute the following command to check if database exists:
```
$ show databases;
```
In case database already exists, then move to next step. Else, perform the following steps.
For OCNRF application, two type of databases are required:
1. OCNRF application database: This database consists of tables used by application to perform functionality of NRF network function.
2. OCNRF network database: This database consists of tables used by OCNRF to store per the network details like system details and database backups.
1. Create database for OCNRF application:
```
$ CREATE DATABASE IF NOT EXISTS <OCNRF Application Database> CHARACTER SET utf8;
```
  Example:
```
$ CREATE DATABASE IF NOT EXISTS nrfApplicationDB CHARACTER SET utf8;
```
2. Create database for OCNRF network database:
```
$ CREATE DATABASE IF NOT EXISTS <OCNRF network database> CHARACTER SET utf8;
```
  Example:
```
$ CREATE DATABASE IF NOT EXISTS nrfNetworkDB CHARACTER SET utf8;
```
  Note:
  OCNRF application and network database must be created on any one of SQL node on any one of the OCNRF site.
3. Grant permission to users on the OCNRF database created:
  
  Note:
  This step must be executed on all the SQL nodes on all the OCNRF Geo-Redundant sites.
```
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF Application Database>.* TO '<OCNRF Privileged-User Name>'@'%';
```
  Example:
```
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON nrfApplicationDB.* TO 'nrfPrivilegedUsr'@'%';
```
4. Grant permission to OCNRF privileged user on OCNRF network database:
```
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF network database>.* TO '<OCNRF Privileged-User Name>'@'%';
```
  Example:
```
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON nrfNetworkDB.* TO 'nrfPrivilegedUsr'@'%';
```
5. Grant permission to OCNRF application user on OCNRF application database:
```
$ GRANT SELECT, INSERT, LOCK TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF Application Database>.* TO '<OCNRF APPLICATION User Name>'@'%';
```
  Example:
```
$ GRANT SELECT, INSERT, LOCK TABLES, DELETE, UPDATE, EXECUTE ON nrfApplicationDB.* TO 'nrfApplicationUsr'@'%';
```
6. Grant read permission to OCNRF application user for replication_info:
```
$ GRANT SELECT ON replication_info.* TO '<OCNRF APPLICATION User Name>'@'%';
```
  Example:
```
$ GRANT SELECT ON replication_info.* TO 'nrfApplicationusr'@'%';
```
7. Apply the grants using following command:
```
FLUSH PRIVILEGES;
```
Execute the command, show grants for <username>, to confirm that users has all of the required permissions
Exit from database and logout from MYSQL nodes.

Procedure for standalone OCNRF site

Login to the machine where ssh keys are stored and which has permission to access the SQL nodes of NDB cluster.
Connect to the SQL nodes.
Login to the MySQL prompt using root permission or user, which has permission to create users with conditions as mentioned below. For example: mysql -h 127.0.0.1 -uroot -p

Note:
This command may vary from system to system, path for mysql binary, root user and root password. After executing this command, user need to enter the password specific to the user mentioned in the command.
Check OCNRF network function user already exists. If the NF does not exists, create an OCNRF network function user.
Below steps covers the creation of two type of OCNRF users. Different users has different set of permissions.
1. OCNRF privileged user: This user has complete set of permissions. This user can perform create, alter, drop operations on tables to perform install/upgrade/rollback or delete operations.
2. OCNRF application user: This user has less set of permissions and will be used by OCNRF application during service operations handling. This user can insert, update, get, remove the records. This user can't create, alter and drop the database as wells as tables.
```
$ SELECT User FROM mysql.user;
```
In case, user already exists, move to next step. Else, create new following OCNRF user:
- Create new OCNRF application user:
```
$ CREATE USER '<OCNRF APPLICATION User Name>'@'%' IDENTIFIED BY '<OCNRF APPLICATION Password>';
```
  Example:
```
$ CREATE USER 'nrfApplicationUsr'@'%' IDENTIFIED BY 'nrfApplicationPasswd'
```
- Create new OCNRF privileged user:
```
$ CREATE USER '<OCNRF Privileged-User Name>'@'%' IDENTIFIED BY '<OCNRF Privileged-User Password>';
```
  Example:
```
$ CREATE USER 'nrfPrivilegedUsr'@'%' IDENTIFIED BY 'nrfPrivilegedPasswd'
```
Note:
Both users must be created on all the SQL Nodes for all the sites.
Check OCNRF network function databases already exists. If not exists, create databases for OCNRF network function:
Execute the following command to check if database exists:
```
$ show databases;
```
Check if required database is already in list. In case the database already exists, then move to next step. Else, perform the following steps.
For OCNRF application, two type of databases are required:
1. OCNRF application database: This database consists of tables used by application to perform functionality of NRF network function.
2. OCNRF network database: This database consists of tables used by OCNRF to store per OCNRF network details like system details and database backups.
1. Create database for OCNRF application:
```
$ CREATE DATABASE IF NOT EXISTS <OCNRF Application Database> CHARACTER SET utf8;
```
  Example:
```
$ CREATE DATABASE IF NOT EXISTS nrfApplicationDB CHARACTER SET utf8;
```
2. Create database for OCNRF network:
```
$ CREATE DATABASE IF NOT EXISTS <OCNRF network database> CHARACTER SET utf8;
```
  Example:
```
$ CREATE DATABASE IF NOT EXISTS nrfNetworkDB CHARACTER SET utf8;
```

Grant permissions to users on the databases:

Note:

This step must be executed on all the SQL nodes on each OCNRF standalone site.

Grant permission to OCNRF privileged user on OCNRF application database:

$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF Application Database>.* TO '<OCNRF Privileged-User Name>'@'%';

Example:

$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON nrfApplicationDB.* TO 'nrfPrivilegedUsr'@'%';

Grant permission to OCNRF privileged user on OCNRF network database:

$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF network database>.* TO '<OCNRF Privileged-User Name>'@'%';

Example:

$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, EXECUTE ON nrfNetworkDB.* TO 'nrfPrivilegedUsr'@'%';

Grant permission to OCNRF application user on OCNRF application database:

$ GRANT SELECT, INSERT, LOCK TABLES, DELETE, UPDATE, EXECUTE ON <OCNRF Application Database>.* TO '<OCNRF APPLICATION User Name>'@'%';

Example:

$ GRANT SELECT, INSERT, LOCK TABLES, DELETE, UPDATE, EXECUTE ON nrfApplicationDB.* TO 'nrfApplicationUsr'@'%';

Grant read permission to OCNRF application user for replication_info:

$ GRANT SELECT ON replication_info.* TO '<OCNRF APPLICATION User Name>'@'%';

Example:

$ GRANT SELECT ON replication_info.* TO 'nrfApplicationusr'@'%';

Apply the grants using following command:
```
FLUSH PRIVILEGES;
```
Exit from MySQL prompt and SQL nodes.

Configuring Kubernetes Secret for Accessing OCNRF Database

This section explains the steps to configure kubernetes secrets for accessing the OCNRF database created in the above section. This procedure must be executed before deploying OCNRF.

Kubernetes Secret Creation for OCNRF Privileged Database User

This section explains the steps to create kubernetes secrets for accessing OCNRF database and privileged user details created by database administrator in above section. This section must be execute before deploying OCNRF.

Create kubernetes secret for privileged user as follows:

Create kubernetes secret for MySQL:

$ kubectl create secret generic <privileged user secret name> --from-literal=dbUsername=<OCNRF Privileged Mysql database username> --from-literal=dbPassword=<OCNRF Privileged Mysql User database passsword> --from-literal=appDbName=<OCNRF Mysql database name> --from-literal=networkScopedDbName=<OCNRF Mysql Network database name> -n <Namespace of OCNRF deployment>

Note:

Note down the command used during the creation of kubernetes secret, this command is used for updates in future.

Example:

$ kubectl create secret generic privilegeduser-secret --from-literal=dbUsername=nrfPrivilegedUsr --from-literal=dbPassword=nrfPrivilegedPasswd --from-literal=appDbName=nrfApplicationDb --from-literal=networkScopedDbName=nrfNetworkDB -n ocnrf

Verify the secret created using above command:

$ kubectl describe secret <database secret name> -n <Namespace of OCNRF deployment>

Example:

$ kubectl describe secret privilegeduser-secret -n ocnrf

Kubernetes Secret Update for OCNRF Privileged Database User

This section describes the steps to update the secrets. Update Kubernetes secret for privileged user as follows:

Copy the exact command used in Kubernetes Secret Creation for OCNRF Privileged Database User section during creation of secret:

$ kubectl create secret generic <privileged user secret name> --from-literal=dbUsername=<OCNRF Privileged Mysql database username> --from-literal=dbPassword=<OCNRF Privileged Mysql database password> --from-literal=appDbName=<OCNRF Mysql database name> --from-literal=networkScopedDbName=<OCNRF Mysql Network database name> -n <Namespace of OCNRF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MYSQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <privileged user secret name> --from-literal=dbUsername=<OCNRF Privileged Mysql database username> --from-literal=dbPassword=<OCNRF Privileged Mysql database password> --from-literal=appDbName=<OCNRF Mysql database name> --from-literal=networkScopedDbName=<OCNRF Mysql Network database name> --dry-run -o yaml -n <Namespace of OCNRF deployment> | kubectl replace -f - -n <Namespace of OCNRF deployment>

Execute the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Kubernetes Secret Creation for OCNRF Application Database User

This section explains the steps to create secrets for accessing and configuring application database user created in above section. This section must be execute before deploying OCNRF.

Create kubernetes secret for OCNRF application database user for configuring records is as follows:

Create kubernetes secret for OCNRF application database user:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<OCNRF APPLICATION User Name> --from-literal=dbPassword=<Password for OCNRF APPLICATION User> --from-literal=appDbName=<OCNRF Application Database> -n <Namespace of OCNRF deployment>

Note:

Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

Example:

$ kubectl create secret generic appuser-secret --from-literal=dbUsername=nrfApplicationUsr --from-literal=dbPassword=nrfApplicationPasswd --from-literal=appDbName=nrfApplicationDB -n ocnrf

Verify the secret creation:

$ kubectl describe secret <appuser-secret name> -n <Namespace of OCNRF deployment>

Example:

$ kubectl describe secret appuser-secret -n ocnrf

Kubernetes Secret Update for OCNRF Application Database User

This section explains how to update the kubernetes secret.

Copy the exact command used in above section during creation of secret:

$ kubectl create secret generic <appuser-secret name> --from-literal=dbUsername=<OCNRF APPLICATION User Name> --from-literal=dbPassword=<Password for OCNRF APPLICATION User> --from-literal=appDbName=<OCNRF Application Database> -n <Namespace of OCNRF deployment>

Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of MYSQL secret>". After update, the command will be as follows:

$ kubectl create secret generic <database secret name> --from-literal=dbUsername=<OCNRF APPLICATION User Name> --from-literal=dbPassword=<Password for OCNRF APPLICATION User> --from-literal=appDbName=<OCNRF Application Database> --dry-run -o yaml -n <Namespace of OCNRF deployment> | kubectl replace -f - -n <Namespace of OCNRF deployment>

Execute the updated command. The following message is displayed:
```
secret/<database secret name> replaced
```

Configuring secrets for enabling HTTPS

Creation of secrets for enabling HTTPS in OCNRF Ingress gateway

This section explains the steps to configure secrets for enabling HTTPS in ingress and egress gateways. This section must be executed before enabling HTTPS in OCNRF Ingress/Egress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files mentioned below.

To create kubernetes secret for HTTPS, following files are required:

ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RS256)
TrustStore password file
KeyStore password file
CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

Execute the following command to create secret:

$ kubectl create secret generic <ocingress-secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of OCNRF deployment>

Note:

Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

Example: The names used below are same as provided in custom_values.yaml in OCNRF deployment.

$ kubectl create secret generic ocingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocnrf

Verify the secret created using the following command:

$ kubectl describe secret <ocingress-secret-name> -n <Namespace of OCNRF deployment>

Example:

$ kubectl describe secret ocingress-secret -n ocnrf

Update the secrets for enabling HTTPS in OCNRF Ingress gateway

This section explains how to update the secret with updated details.

Copy the exact command used in above section during creation of secret.
Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of OCNRF deployment>".

Create secret command will look like:

$ kubectl create secret generic <ocingress-secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<caroot.cer> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of OCNRF deployment> | kubectl replace -f - -n <Namespace of OCNRF deployment>

Example:-

The names used below are same as provided in custom_values.yaml in OCNRF deployment:

$ kubectl create secret generic ocingress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf

Execute the updated command.
After successful secret update, the following message is displayed:
```
secret/<ocingress-secret> replaced
```

Creation of secrets for enabling HTTPS in OCNRF Egress gateway

This section explains the steps to create secret for HTTPS related details. This section must be executed before enabling HTTPS in OCNRF Egress gateway.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files mentioned below.

To create kubernetes secret for HTTPS, following files are required:

ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RS256)
TrustStore password file
KeyStore password file
CA certificate

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

Execute the following command to create secret.

$ kubectl create secret generic <ocegress-secret-name> --from-file=<ssl_ecdsa_private_key.pem>  --from-file=<ssl_rsa_private_key.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<ssl_cabundle.crt> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of OCNRF deployment>

Note:

Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

Example: The names used below are same as provided in custom_values.yaml in OCNRF deployment.

$ kubectl create secret generic ocegress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=ssl_rsa_private_key.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=ssl_cabundle.crt --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt -n ocnrf

Command to verify secret created:

$ kubectl describe secret <ocegress-secret-name> -n <Namespace of OCNRF deployment>

Example:

$ kubectl describe secret ocegress-secret -n ocnrf

Update the secrets for enabling HTTPS in OCNRF Egress gateway

This section explains how to update the secret with updated details.

Copy the exact command used in above section during creation of secret:
Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of OCNRF deployment>".

Create secret command will look like:

kubectl create secret generic <ocegress-secret-name> --from-file=<ssl_ecdsa_private_key.pem> --from-file=<ssl_rsa_private_key.pem> --from-file=<ssl_truststore.txt> --from-file=<ssl_keystore.txt> --from-file=<ssl_cabundle.crt> --from-file=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of OCNRF Egress Gateway secret> | kubectl replace -f - -n <Namespace of OCNRF deployment>

Example:

The names used below are same as provided in custom_values.yaml in OCNRF deployment:

$ kubectl create secret generic egress-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=ssl_truststore.txt --from-file=ssl_keystore.txt --from-file=caroot.cer --from-file=ssl_rsa_certificate.crt --from-file=ssl_ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf

Execute the updated command.
After successful secret update, the following message is displayed:
```
secret/<ocegress-secret> replaced
```

Configuring Secret for Enabling AccessToken Service

Access Token secret creation

This section explains the steps to create secret for AccessToken service of OCNRF. This section must be executed before enabling Access Token in OCNRF.

Note:

The password for KeyStore is stored in respective password file mentioned below.

To create kubernetes secret for AccessToken, following files are required:

ECDSA private key and CA signed certificate of OCNRF (if initialAlgorithm is ES256)
RSA private key and CA signed certificate of OCNRF (if initialAlgorithm is RS256)
KeyStore password file: This file contains a password which is used to protect the PrivateKeys/Certificates that will get loaded into the application in-memory (KeyStore).
For example:echo qwerpoiu > keystore_password.txt

where qwerpoiu is the password and keystore_password.txt is the target file which is provided as input to the AccessToken secret.

Note:

Creation process for private keys, certificates and passwords is on discretion of user/operator.

Execute the following command to create secret. The names used below are same as provided in custom values.yaml in OCNRF deployment:

kubectl create secret generic <ocnrfaccesstoken-secret> --from-file=<ecdsa_private_key.pem> --from-file=<rsa_private_key.pem> --from-file=<keystore_password.txt> --from-file=<rsa_certificate.crt> --from-file=<ecdsa_certificate.crt> -n <Namespace of OCNRF deployment>

Note:

Note down the command used during the creation of kubernetes secret, this command will be used for updates in future.

Example:

$ kubectl create secret generic ocnrfaccesstoken-secret --from-file=ecdsa_private_key.pem --from-file=rsa_private_key.pem --from-file=keystore_password.txt --from-file=rsa_certificate.crt --from-file=ecdsa_certificate.crt -n ocnrf

Execute the following command to verify secret created:

$ kubectl describe secret <ocnrfaccesstoken-secret-name> -n <Namespace of OCNRF deployment>

Example:

 $ kubectl describe secret ocnrfaccesstoken-secret -n ocnrf

Access Token secret update

This section explains how to update the access token secret with updated details.

Copy the exact command used in above section during creation of secret.
Update the same command with string "--dry-run -o yaml" and "kubectl replace -f - -n <Namespace of OCNRF deployment>".

Create secret command will look like:

kubectl create secret generic <ocnrfaccesstoken-secret> --from-file=<ecdsa_private_key.pem> --from-file=<rsa_private_key.pem> --from-file=<keystore_password.txt> --from-file=<rsa_certificate.crt> --from-file=<ecdsa_certificate.crt> --dry-run -o yaml -n <Namespace of OCNRF deployment> | kubectl replace -f - -n <Namespace of OCNRF deployment>

Example:-

The names used below are same as provided in custom_values.yaml in OCNRF deployment:

$ kubectl create secret generic ocnrfaccesstoken-secret --from-file=ecdsa_private_key.pem --from-file=rsa_private_key.pem --from-file=keystore_password.txt --from-file=rsa_certificate.crt --from-file=ecdsa_certificate.crt --dry-run -o yaml -n ocnrf | kubectl replace -f - -n ocnrf

Execute the updated command.
After successful secret update, the following message is displayed:
```
secret/<ocnrfaccesstoken-secret> replaced
```

Installation Tasks

This section describes the tasks that the user must follow for installing OCNRF.

Downloading OCNRF package

Following is the procedure to download the release package from MOS:

Login to MOS using the appropriate login credentials.
Select Product & Updates tab.
In Patch Search console select Product or Family (Advanced) tab.
Enter Oracle Communications Cloud Native Core - 5G in Product field and select the product from the Product drop-down.
Select Oracle Communications Cloud Native Core Network Repository Function <release_number> in Release field.
Click Search. The Patch Advanced Search Results list appears.
Select the required patch from the list. The Patch Details window appears.
Click on Download. File Download window appears.
Click on the <p********_<release_number>_Tekelec>.zip file.
Click on the release package zip file to download the network function patch to the system where network function must be installed.

Installing OCNRF

Unzip the release package file to the system where you want to install the network function. You can find the OCNRF package as follows:
ReleaseName-pkg-Releasenumber.tgz
where:
ReleaseName is a name which is used to track this installation instance.

Releasenumber is the release number.
For example, ocnrf-pkg-1.7.2.0.0.tgz
Untar the OCNRF package file to get OCNRF docker image tar file:
```
tar -xvzf ReleaseName-pkg-Releasenumber.tgz
```
Load the ocnrf-images-<release_number>.tar file into the Docker system:
```
docker load --input /IMAGE_PATH/ocnrf-images-<release_number>.tar
```
Verify that the image is loaded correctly by entering this command:
```
docker images 
```

Execute the following commands to push the docker images to docker registry:

docker tag <image-name>:<image-tag> <docker-repo>/ <image-name>:<image-tag>

docker push <docker-repo>/<image-name>:<image-tag>

Untar the helm files:
```
tar -xvzf ocnrf-<release_number>.tgz
```
Create the customize ocnrf-custom-values-1.7.2.yaml file with the required input parameters. To customize the file, refer to Customizing OCNRF chapter.
Go to the extracted OCNRF package as explained in:
```
cd ocnrf-<release_number>
```
Install OCNRF by executing the following command:
```
helm install ocnrf/ --name <helm-release> --namespace <k8s namespace> -f <ocnrf_customized_values.yaml>
```
Example: helm install ocnrf/ --name ocnrf --namespace ocnrf -f ocnrf-custom-values-1.7.2.yaml

Caution:
This command will appear hung for a while. Because from OCNRF 1.7.2 release onwards, Kubernetes jobs will get execute by Install/Upgrade/Rollback helm hooks. Helm Deployment will be shown as DONE after all the applicable hooks are executed.
timeout duration (optional): If not specified, default value will be 300 (300 seconds) in Helm2 and 5m (5 minutes) in Helm3. Specifies the time to wait for any individual kubernetes operation (like Jobs for hooks). Default value is 5m0s. If the helm install command fails at any point to create a kubernetes object, it will internally call the purge to delete after timeout value (default: 300s). Here timeout value is not for overall install, but it is for automatic purge on installation failure.

To verify the deployment status, open a new terminal and execute the following command:

Command: $ watch kubectl get pods -n <k8s namespace>

The pod status gets updated on a regular interval. When helm install command exits with the status, you may stop watching the status of kubernetes pods.

Note:
In case helm purge do not clean the deployment and kubernetes objects completely then follow Cleaning OCNRF deployment section.
Execute the following command to check the status:
helm status <helm-release>

For example: helm status ocnrf

Execute the following command to check status of the services:

kubectl -n <k8s namespace> get services

For example:

kubectl -n ocnrf get services

Note: If external load balancer is used, EXTERNAL-IP is assigned to

<helm release
                            name>-ingressgateway.ocnrf

is the release name. ocnrf is the helm release name.

NAME                   TYPE          CLUSTER-IP     EXTERNAL-IP  PORT(S)            AGE
ocnrf-egressgateway    ClusterIP     10.233.1.61    <none>       8080/TCP,5701/TCP  30h
ocnrf-ingressgateway   LoadBalancer  10.233.52.194  <pending>    80:31776/TCP       30h
ocnrf-nfaccesstoken    ClusterIP     10.233.53.115  <none>       8080/TCP           30h
ocnrf-nfdiscovery      ClusterIP     10.233.21.28   <none>       8080/TCP           30h
ocnrf-nfregistration   ClusterIP     10.233.4.140   <none>       8080/TCP           30h
ocnrf-nfsubscription   ClusterIP     10.233.44.98   <none>       8080/TCP           30h
ocnrf-nrfauditor       ClusterIP     10.233.1.71    <none>       8080/TCP           30h
ocnrf-nrfconfiguration LoadBalancer  10.233.40.230  <pending>    8080:30076/TCP     30h
ocnrf-ocnrf-app-info   ClusterIP     10.104.113.86  <none>       5906/TCP           30h

Execute the following command to check status of the pods:

kubectl get pods -n <k8s namespace>

Status column of all the pods should be 'Running'.

Ready column of all the pods should be n/n, where n is number of containers in the pod.

For example:

kubectl get pods
                                -n ocnrf

NAME                                     READY  STATUS   RESTARTS  AGE
ocnrf-egressgateway-d6567bbdb-9jrsx      2/2    Running  0         30h
ocnrf-egressgateway-d6567bbdb-ntn2v      2/2    Running  0         30h
ocnrf-ingressgateway-754d645984-h9vzq    2/2    Running  0         30h
ocnrf-ingressgateway-754d645984-njz4w    2/2    Running  0         30h
ocnrf-nfaccesstoken-59fb96494c-k8w9p     2/2    Running  0         30h
ocnrf-nfaccesstoken-49fb96494c-k8w9q     2/2    Running  0         30h
ocnrf-nfdiscovery-84965d4fb9-rjxg2       1/1    Running  0         30h
ocnrf-nfdiscovery-94965d4fb9-rjxg3       1/1    Running  0         30h
ocnrf-nfregistration-64f4d8f5d5-6q92j    1/1    Running  0         30h
ocnrf-nfregistration-44f4d8f5d5-6q92i    1/1    Running  0         30h
ocnrf-nfsubscription-5b6db965b9-gcvpf    1/1    Running  0         30h
ocnrf-nfsubscription-4b6db965b9-gcvpe    1/1    Running  0         30h
ocnrf-nrfauditor-67b676dd87-xktbm        1/1    Running  0         30h
ocnrf-nrfconfiguration-678fddc5f5-c5htj  1/1    Running  0         30h
ocnrf-appinfo-8b7879cdb-jds4r            1/1    Running  0         30h