<< PREVIOUS  NEXT >>

 

 VSP CMS


 

VSP CMS is installed as a Load Balancer service.This section describes the process CMS upgrade:

  1. For upgrade from VSP CMS 2.4.x or previous versions, execute the commands:

    1. rm -rf /home/virsec/kafkavolume

       

    2. rm -rf /home/virsec/zookeepervolume

       

  2. For an EKS environment, execute the below commands to delete PV and PVC for jreports-content and jreports-database

    1. Execute the commands below for upgrade from all VSP versions 2.2.x and below:

      1. Delete PVC

        kubectl -n virsec delete pvc jreports-content-claim

         

        kubectl -n virsec delete pvc jreports-database-claim

         

      2. Delete PV

        kubectl -n virsec delete pv jreports-content

         

        kubectl -n virsec delete pv jreports-database

         

        kubectl get pv | grep virsec/jreports-database-claim | awk '{print $1}' | xargs -I {} kubectl delete pv {}

         

        kubectl get pv | grep virsec/jreports-content-claim | awk '{print $1}' | xargs -I {} kubectl delete pv {}

         

      3. Verification: Ensure that the command below does not give any output list 

        kubectl get pv,pvc,storageclass --all-namespaces

         

    2. Execute the commands below for upgrade from VSP 2.2.3 only

      1. Delete PVC (SSL)

        kubectl delete pvc ssl-certs-content-claim -n virsec

         

      2. Delete PV (SSL)

        kubectl delete pv ssl-certs-content

         

        kubectl get pv | grep virsec/ssl-certs-content-claim | awk '{print $1}' | xargs -I {} kubectl delete pv {}

         

  3. Log in to the Worker Node where JReports service is deployed. Stop the existing CMS instance and execute the below commands to remove the existing report image:

     

    1. docker images | grep jreport

       

       

    2. docker rmi <JReportsImageId>

       

       

  4. Log in to the Management Node. Execute the below commands to download the file vsp_get_yaml.sh

     

    1. cd vsp/cms

       

       

    2. wget http://<LFR_IPAddress>/vsp/vsp_download_files.sh

       

    3. chmod +x ./vsp_download_files.sh

       

       

  5. To configure the build scripts for a specific environment, execute the below commands:

    1. ./vsp_download_files.sh

       

       

  6. Execute the below commands to deploy CMS:

    1. CMS URL is provided at the end of script execution

    2. cd cms_serviceperpod

       

       

    3. To view the help menu, execute the below command:

      ./vsp_deploy_cms.sh -h

       

       

      Picture 25

    4. Execute the same command using one of the below parameters to remove the previous version

       

      NOTE:

      Ensure that the executed script is from the installed CMS version directory

       

      1. -S (Optional): For a clean CMS setup. This deletes the previous setup (if any) including the infrastructure services (MongoDB, Kafka and Redis containers). This option can be used if the core CMS services and infrastructure services need updates. It is applicable for major release updates. Example: VSP 2.2 TO VSP 2.3

        ./vsp_deploy_cms.sh -S

         

         

        OR

      2. -s (Optional): For clean CMS setup. This deletes the previous setup (if any) excluding the infrastructure services (MongoDB, Kafka and Redis containers). This option can be used if only the core CMS services need updates. It is applicable for minor release updates if there are no updates to the infrastructure services. Example: VSP 2.3.0 TO VSP 2.3.2

        ./vsp_deploy_cms.sh -s

         

         

        OR

      3. -c (Optional): This deletes all the CMS deployments and services, including the infrastructure services (MongoDB, Kafka and Redis containers). When CMS is reinstalled, Probes might need reconfiguration as the CMS IP address might have changed

        ./vsp_deploy_cms.sh -c

         

         

         

        NOTE:

        Ensure that when the parameter -s, -S OR -c are utilized, only one of them is provided as per the requirement and never both

        Provide -s OR -S as the parameter in AWS EKS setup. Do not use the parameter -c

         

    5. Execute the same command using the below parameters to install the latest version: 

      ./vsp_deploy_cms.sh

       

       

       

      NOTE:

      Ensure that the executed script is from the new CMS version directory

       

      1. -u (Optional): To disable SSL hostname verification between CMS and Probe. This is useful when customized domain name is desired for CMS (Default Domain Name: int.cms.virsec.com). Utilize this option in ECS Fargate environment

      2. -n: DO NOT utilize this parameter to provide a namespace. CMS MUST be deployed in the default namespace virsec

      3. -x (Optional): To expose VSP Kafka service Externally. Kafka Service must be exposed externally only when the Applications are deployed on different Kubernetes Cluster than VSP CMS

      4. -C: Node name where Client service must be deployed (CMS UI)

      5. -K: Node name where Kafka service must be deployed

      6. -M: Node name where Mongo service must be deployed

      7. -R: Node name where Redis service must be deployed

      8. -k: Use this option during CMS installation or startup or upgrade. Allowed Kafka options:

        0: For Unsecure Kafka connection. By default, the value is set to 0 if not specified

        1: For One-way SSL where the Client verifies the server

        2: For Two-way SSL where both the Client and Server verify each other

         

        NOTE:

        If the Probes are of version 2.4.x and below, ensure that only option 0 is used for Kafka. Do not use options 1 or 2. as they are not supported

         

      9. -Z: When CMS services are running. Allowed Kafka options:

        0: For Unsecure Kafka connection. By default, the value is set to 0 if not specified

        1: For One-way SSL where the Client verifies the server

        2: For Two-way SSL where both the Client and Server verify each other

         

        NOTE:

        If the Probes are of version 2.4.x and below, ensure that only option 0 is used for Kafka. Do not use options 1 or 2. as they are not supported

         

    6. The CMS URL is provided at the end of script execution

  7. To ensure that CMS maintains the same IP address and worker node, execute the below commands:

    1. kubectl -n virsec patch deployments vsp-cms-client -p '{"spec": {"template": {"spec": {"nodeSelector": {"kubernetes.io/hostname": "<WORKER_NODE_NAME>"}}}}}'

       

    2. kubectl -n virsec patch service vsp-cms -p '{"spec" : {"type": "LoadBalancer", "externalIPs":["<WORKER_NODE_IP>"]}}'

       

     

    NOTE:

    If a proxy server is configured for internet access, ensure that the root certificate information is added to the property file, as described in the Deploy Custom SSL Certificates topic of the Maintenance Section

     

  8. Verification: To verify the CMS deployment, execute the below command on the Management node to list all the deployments and pods

    1. kubectl get pods -n virsec 

       

       

      Picture 26

 

NOTE:  

After the upgrade, ensure that the below steps are executed:

 

 

<< PREVIOUS    NEXT >>