Difference between revisions of "PEC-REP/Current/GIMPEGuide/DeployGSP"
Line 5: | Line 5: | ||
|Section={{Section | |Section={{Section | ||
|alignment=Vertical | |alignment=Vertical | ||
− | |structuredtext={{NoteFormat|Make sure to review {{Link-SomewhereInThisVersion|topic=PlanningGSP}} for the full list of prerequisites required to deploy GSP, including | + | |structuredtext={{NoteFormat|Make sure to review {{Link-SomewhereInThisVersion|topic=PlanningGSP}} for the full list of prerequisites required to deploy GSP, including provisioning S3-compatible storage (see {{Link-AnywhereElse|product=PEC-REP|version=Current|manual=GIMPEGuide|topic=PlanningGSP|anchor=GSP_Plan_CreateS3Storage}}).|}} |
|Status=No | |Status=No | ||
}}{{Section | }}{{Section | ||
Line 11: | Line 11: | ||
|anchor=EnvSetup | |anchor=EnvSetup | ||
|alignment=Vertical | |alignment=Vertical | ||
− | |structuredtext=To prepare your environment for the deployment, complete the steps in this section for: | + | |structuredtext=To prepare your environment for the deployment, complete the steps in this section. Use the instructions for your environment: |
− | *[[ | + | *[[Draft:PEC-REP/Current/GIMPEGuide/DeployGSP#GSP Env OpenShift|OpenShift]] |
− | *[[ | + | *[[Draft:PEC-REP/Current/GIMPEGuide/DeployGSP#GSP Env GKE|GKE]] |
+ | *[[Draft:PEC-REP/Current/GIMPEGuide/DeployGSP#GSP Env AKS|AKS]] | ||
− | {{AnchorDiv| | + | {{AnchorDiv|GSP_Env_OpenShift}} |
− | === | + | ===OpenShift environment setup=== |
− | # | + | #Using the CLI, log in to the OpenShift cluster on the host where you will run the deployment. |
#:<source lang="text">oc login --token <token> --server <URL of the API server></source> | #:<source lang="text">oc login --token <token> --server <URL of the API server></source> | ||
− | #(Optional) Check the cluster version | + | #(Optional) Check the cluster version. |
#:<source lang="text">oc get clusterversion</source> | #:<source lang="text">oc get clusterversion</source> | ||
− | #If the cluster administrator has not already done so, create | + | #If the cluster administrator has not already done so, create the new project <code>gsp</code> for GSP: |
#:<source lang="text">oc new-project gsp</source> | #:<source lang="text">oc new-project gsp</source> | ||
− | #Set the default project to gsp: | + | #Set the default project to <code>gsp</code>: |
#:<source lang="text">oc project gsp</source> | #:<source lang="text">oc project gsp</source> | ||
− | #Create a secret | + | #Create the pull secret for the image registry. |
+ | #*This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as <code>docker-registry</code> in the system. For information about downloading artifacts from the repository, see {{Link-AnywhereElse|product=PrivateEdition|version=Current|manual=PEGuide|topic=ManageServices}}. | ||
+ | #*When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=ConfigureGSP|anchor=GSP_HelmCharts|display text=GSP Helm chart overrides}}. | ||
#:<source lang="text">oc create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp</source> | #:<source lang="text">oc create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp</source> | ||
− | + | #Create the Kafka secret. | |
− | # | + | #*Kafka requires a seperate access credential. |
− | + | #*This credential is represented as <tt>kafka-secrets</tt> in the system. | |
#:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp</source> | #:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp</source> | ||
− | #: | + | #:Note: Kafka can be deployed without authentication, using the following syntax: |
#:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp</source> | #:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp</source> | ||
− | #: | + | #:The following example reflects a Kafka deployment without authentication. |
#:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp</source> | #:<source lang="text">oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp</source> | ||
− | {{AnchorDiv| | + | {{AnchorDiv|GSP_Env_GKE}} |
− | === | + | ===GKE environment setup=== |
#Ensure that the gcloud CLI and required Helm version are installed on the host where you will run the deployment. | #Ensure that the gcloud CLI and required Helm version are installed on the host where you will run the deployment. | ||
− | # | + | #Using the CLI, log in to the GKE cluster on the host where you will run the deployment. |
#:<source lang="text">gcloud container clusters get-credentials <cluster></source> | #:<source lang="text">gcloud container clusters get-credentials <cluster></source> | ||
− | #If the cluster administrator has not already done so, create a new namespace for GSP | + | #If the cluster administrator has not already done so, create a new namespace <code>gsp</code> for GSP. |
− | # | + | #*Create a JSON file that specifies the namespace metadata. As an example, the file '''create-gsp-namespace.json.''' has the following JSON |
− | + | #:<source lang="bash">{ | |
"apiVersion": "v1", | "apiVersion": "v1", | ||
"kind": "Namespace", | "kind": "Namespace", | ||
Line 56: | Line 59: | ||
} | } | ||
}</source> | }</source> | ||
− | # | + | #*Create the namespace. The following example applies the '''create-gsp-namespace.json''' file to create the <code>gsp</code> namespace. |
− | + | #:<source lang="text">kubectl apply -f create-gsp-namespace.json</source> | |
− | # | + | #*Confirm that the namespace was successfully created. |
− | + | #:<source lang="text">kubectl describe namespace gsp</source> | |
− | #Create a secret | + | #Create the pull secret for the image registry. |
+ | #*This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as <code>docker-registry</code> in the system. For information about downloading artifacts from the repository, see {{Link-AnywhereElse|product=PrivateEdition|version=Current|manual=PEGuide|topic=ManageServices}}. | ||
+ | #*When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=ConfigureGSP|anchor=GSP_HelmCharts|display text=GSP Helm chart overrides}}. | ||
#:<source lang="text">kubectl create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp</source> | #:<source lang="text">kubectl create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp</source> | ||
− | #Create a | + | #Create the Kafka secret. |
− | #: | + | #*Kafka requires a separate access credential. |
+ | #*This credential is represented as <code>kafka-secrets</code> in the system, as in the following syntax. | ||
+ | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp</source> | ||
+ | #:For example: | ||
+ | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp</source> | ||
+ | #:Note: Kafka can be deployed without authentication, as in the following example. | ||
#:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp</source> | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp</source> | ||
− | #:When Kafka is | + | |
+ | {{AnchorDiv|GSP_Env_AKS}} | ||
+ | ===AKS environment setup=== | ||
+ | |||
+ | #Ensure that the Azure CLI and required Helm version are installed on the host where you will run the deployment. | ||
+ | #Using the CLI, log in to the cluster on the host where you will run the deployment. | ||
+ | #:<source lang="bash"> | ||
+ | az aks get-credentials --resource-group <resource-group-name> --name <cluster-name> --admin | ||
+ | </source> | ||
+ | #If the cluster administrator has not already done so, create a new namespace <code>gsp</code> for GSP. | ||
+ | #*Create a JSON file that specifies the namespace metadata. As an example, the file '''create-gsp-namespace.json''' has the JSON shown below. | ||
+ | #:<source lang="bash">{ | ||
+ | "apiVersion": "v1", | ||
+ | "kind": "Namespace", | ||
+ | "metadata": | ||
+ | "name": "gsp", | ||
+ | "labels": { | ||
+ | "name": "gsp" | ||
+ | } | ||
+ | } | ||
+ | }</source> | ||
+ | #*Create the namespace. The following example applies the '''create-gsp-namespace.json''' file to create the <code>gsp</code> namespace. | ||
+ | #:<source lang="text">kubectl apply -f create-gsp-namespace.json</source> | ||
+ | #*Confirm that the namespace was successfully created. | ||
+ | #:<source lang="text">kubectl describe namespace gsp</source> | ||
+ | #Create the pull secret for the image registry. | ||
+ | #*This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as <code>docker-registry</code> in the system. For information about downloading artifacts from the repository, see {{Link-AnywhereElse|product=PrivateEdition|version=Current|manual=PEGuide|topic=ManageServices}}. | ||
+ | #*When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see {{Link-SomewhereInThisVersion|manual=GIMPEGuide|topic=ConfigureGSP|anchor=GSP_HelmCharts|display text=GSP Helm chart overrides}}. | ||
+ | #:<source lang="text">kubectl create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp</source> | ||
+ | #Create the Kafka secret. | ||
+ | #*Kafka requires a separate access credential. | ||
+ | #*This credential is represented as <code>kafka-secrets</code> in the system, as in the following syntax. | ||
#:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp</source> | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp</source> | ||
#:For example: | #:For example: | ||
#:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp</source> | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp</source> | ||
+ | #:Note: Kafka can be deployed without authentication, as in the following example. | ||
+ | #:<source lang="text">kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp</source> | ||
+ | |||
+ | {{AnchorDiv|GSP_Env_AKS}} | ||
|Status=No | |Status=No | ||
}}{{Section | }}{{Section | ||
− | |sectionHeading=Deploy | + | |sectionHeading=Deploy the GSP |
+ | |anchor=GSP_Deploy | ||
|alignment=Vertical | |alignment=Vertical | ||
− | |structuredtext= | + | |structuredtext=After the environment has been set up, deploying the GSP is a matter of executing the following command: |
<source lang="text">helm install gsp <gsp-helm-artifact> -f <gsp-values.yaml> -n gsp</source> | <source lang="text">helm install gsp <gsp-helm-artifact> -f <gsp-values.yaml> -n gsp</source> | ||
|Status=No | |Status=No | ||
Line 89: | Line 135: | ||
#Review the logs to verify no errors. | #Review the logs to verify no errors. | ||
#Monitor the operations dashboard to verify that the services report their status as Ready, and pods are not continually restarting. | #Monitor the operations dashboard to verify that the services report their status as Ready, and pods are not continually restarting. | ||
− | |||
|Status=No | |Status=No | ||
}} | }} | ||
|PEPageType=45d1441f-dc69-4a17-bd47-af5d811ce167 | |PEPageType=45d1441f-dc69-4a17-bd47-af5d811ce167 | ||
}} | }} |
Revision as of 17:01, September 29, 2022
Contents
Learn how to deploy GIM Stream Processor (GSP) into a private edition environment.
Assumptions
- The instructions on this page assume you are deploying the service in a service-specific namespace, named in accordance with the requirements on Creating namespaces. If you are using a single namespace for all private edition services, replace the namespace element in the commands on this page with the name of your single namespace or project.
- Similarly, the configuration and environment setup instructions assume you need to create namespace-specific (in other words, service-specific) secrets. If you are using a single namespace for all private edition services, you might not need to create separate secrets for each service, depending on your credentials management requirements. However, if you do create service-specific secrets in a single namespace, be sure to avoid naming conflicts.
Set up your environment
To prepare your environment for the deployment, complete the steps in this section. Use the instructions for your environment:
OpenShift environment setup
- Using the CLI, log in to the OpenShift cluster on the host where you will run the deployment.
oc login --token <token> --server <URL of the API server>
- (Optional) Check the cluster version.
oc get clusterversion
- If the cluster administrator has not already done so, create the new project
gsp
for GSP:oc new-project gsp
- Set the default project to
gsp
:oc project gsp
- Create the pull secret for the image registry.
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
docker-registry
in the system. For information about downloading artifacts from the repository, see Downloading your Genesys Multicloud CX containers. - When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see GSP Helm chart overrides.
oc create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
- Create the Kafka secret.
- Kafka requires a seperate access credential.
- This credential is represented as kafka-secrets in the system.
oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp
- Note: Kafka can be deployed without authentication, using the following syntax:
oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp
- The following example reflects a Kafka deployment without authentication.
oc create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp
GKE environment setup
- Ensure that the gcloud CLI and required Helm version are installed on the host where you will run the deployment.
- Using the CLI, log in to the GKE cluster on the host where you will run the deployment.
gcloud container clusters get-credentials <cluster>
- If the cluster administrator has not already done so, create a new namespace
gsp
for GSP.- Create a JSON file that specifies the namespace metadata. As an example, the file create-gsp-namespace.json. has the following JSON
{ "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "gsp", "labels": { "name": "gsp" } } }
- Create the namespace. The following example applies the create-gsp-namespace.json file to create the
gsp
namespace.
kubectl apply -f create-gsp-namespace.json
- Confirm that the namespace was successfully created.
kubectl describe namespace gsp
- Create the pull secret for the image registry.
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
docker-registry
in the system. For information about downloading artifacts from the repository, see Downloading your Genesys Multicloud CX containers. - When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see GSP Helm chart overrides.
kubectl create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
- Create the Kafka secret.
- Kafka requires a separate access credential.
- This credential is represented as
kafka-secrets
in the system, as in the following syntax.
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp
- For example:
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp
- Note: Kafka can be deployed without authentication, as in the following example.
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp
AKS environment setup
- Ensure that the Azure CLI and required Helm version are installed on the host where you will run the deployment.
- Using the CLI, log in to the cluster on the host where you will run the deployment.
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name> --admin
- If the cluster administrator has not already done so, create a new namespace
gsp
for GSP.- Create a JSON file that specifies the namespace metadata. As an example, the file create-gsp-namespace.json has the JSON shown below.
{ "apiVersion": "v1", "kind": "Namespace", "metadata": "name": "gsp", "labels": { "name": "gsp" } } }
- Create the namespace. The following example applies the create-gsp-namespace.json file to create the
gsp
namespace.
kubectl apply -f create-gsp-namespace.json
- Confirm that the namespace was successfully created.
kubectl describe namespace gsp
- Create the pull secret for the image registry.
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
docker-registry
in the system. For information about downloading artifacts from the repository, see Downloading your Genesys Multicloud CX containers. - When you configure the GSP, you will reference the registry pull secret as a Helm chart override; see GSP Helm chart overrides.
kubectl create secret docker-registry <repository secret name> --docker-server=<repository> --docker-username=<username> --docker-password=<password/API key> --docker-email=<email id> -n gsp
- This step defines a secret so that Kubernetes can authenticate your image repository and pull artifacts from it. The repository is represented as
- Create the Kafka secret.
- Kafka requires a separate access credential.
- This credential is represented as
kafka-secrets
in the system, as in the following syntax.
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\", \"username\":\"gsp\",\"password\":\"<password>\"} -n gsp
- For example:
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"infra-kafka-cp-kafka.infra.svc.cluster.local:9092\",\"username\":\"gsp\",\"password\":\"kafka-password\"} -n gsp
- Note: Kafka can be deployed without authentication, as in the following example.
kubectl create secret generic kafka-secrets --from-literal=kafka-secrets={\"bootstrap\":\"<kafka-bootstrap-url>\"} -n gsp
Deploy the GSP
After the environment has been set up, deploying the GSP is a matter of executing the following command:
helm install gsp <gsp-helm-artifact> -f <gsp-values.yaml> -n gsp
Validate the deployment
You can consider GSP deployment successful when the pod is running and in Ready state. Genesys Info Mart does not report the Ready state for pods until internal health checks are satisfied and the pods are operational. You can use standard kubectl commands like list and get to verify the successful deployment and readiness status of the Kubernetes objects.
However, from a functional point of view, you cannot validate GSP deployment unless GCA and GIM have been deployed as well. Do not expect consistent data until all three Genesys Info Mart services are up and running. When all three services have been deployed:
- Make a few test calls employing different routing strategies under different scenarios, and verify that all the calls are correctly captured in the Info Mart database. For example:
- The calls appear in the interaction-related tables.
- The calls have been correctly assigned to agents and queues.
- Review the logs to verify no errors.
- Monitor the operations dashboard to verify that the services report their status as Ready, and pods are not continually restarting.