To configure VMware Telco Cloud Service Assurance with private network, update the parameters in the deploy.settings and values-user-overrides file.

Note: Before deploying VMware Telco Cloud Service Assurance on AWS private network, ensure that you configure EKS cluster with two subnets. For more information, see Prerequisites for Deploying VMware Telco Cloud Service Assurance on AWS.

Step 1 Deployment

  • To obtain the <config> for EKS cluster, run the following command inside the Deployment Container:
    eksctl utils write-kubeconfig --cluster=<cluster-name> --profile <your-profile-ID> 
    --region <your-region> --kubeconfig=~/.kube/<config>
  • Update VMware Telco Cloud Service Assurance product details and deployment timeout period.
    # Name of the product to be deployed/installed
    PRODUCT=tcsa
    # Product helm config
    
    # allowed values for footprint "demo", "25k", "50k", "75k", "100k", "125k", "150k", "175k", "200k"
    FOOTPRINT=
    # Time to wait for the deployment to complete, in seconds. Maximum timeout is 3600 seconds. 
    # For deployment above 50K footprint, specify the deployment timeout value in seconds to a higher value.
    PRODUCT_DEPLOYMENT_TIMEOUT=1800
    
    # ========= Deployment modes and actions ========== #
    # Options are "init", "deploy-all", "deploy-apps" or "cleanup"
    DEPLOYMENT_ACTION="deploy-all"
    ## Set this to '--force' if you want to cleanup by force without waiting for user confirmation
    DELETE_ARGS=
  • Update the deployment location and AWS configuration.
    • Set AWS_REGION to the same region as your EKS cluster.
    • Set AWS_PROFILE to the profile ID associated with your account.
    # ========== Deployment Location ========== #
    # LOCATION can be "on-prem", "aws", "tkg", or "azure"
    LOCATION=aws
    
    # ======== Cloud specific configuration ======
    # AWS specific configuration
    AWS_REGION=<your-region>
    AWS_PROFILE=<your-profile-ID>
  • Update registry details of the AWS.
    • For the REGISTRY_URL, use the same region as your EKS cluster.
      Note: The username and password are automatically picked if you use the Docker login command for the ECR registry.
    # ========== Registry details ========== #
    # Enclose the REGISTRY_USERNAME and REGISTRY_PASSWORD in single quotes
    REGISTRY_URL=<your-profile-ID>.dkr.ecr.<aws-region>.amazonaws.com/<unique-name-for-your-cluster>/tcx
    REGISTRY_USERNAME
    REGISTRY_PASSWORD
    # If the registry uses certificates, path to the certificates file (.crt)
    REGISTRY_CERTS_PATH=
  • Uncomment and update the subnet-ID values in the values-user-overrides.yaml file available in the <TCSA_WORK_SPACE>/product-helm-chart/tcsa directory. For more information on subnet ID, see Prerequisites for Deploying VMware Telco Cloud Service Assurance on AWS.
    eks:
      # YAML list of subnets
      loadBalancerSubnets:
        - <subnet-ID>
        - <subnet-ID>
      edge:
        # YAML list of subnets
        loadBalancerSubnets:
          - <subnet-ID>
          - <subnet-ID>
    
    privateNetwork: true
  • Trigger deployment by running the following installation scripts inside the Deployment Container.
    root [ ~ ]# cd /root/tcx-deployer/scripts/deployment/
    root [ ~/tcx-deployer/scripts/deployment ]# ./tcx_app_deployment.sh
    After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
    root [ ~/tcx-deployer/scripts ]# kubectl get tcxproduct 
     OR
    root [ ~/tcx-deployer/scripts ]# kubectl get apps
    Note: After successful deployment, you can launch the VMware Telco Cloud Service Assurance UI. For more information, see Accessing VMware Telco Cloud Service Assurance UI topic.

Step 2 Deployment

  • Run the following command against your EKS cluster to get the DNS name assigned by AWS loadbalancer controller and get the ExternalIP output.
        root [ ~/tcx/scripts ]# kubectl get svc istio-ingressgateway -n istio-system
        NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP                                                                     PORT(S)                                     E
        istio-ingressgateway   LoadBalancer   172.20.80.229    k8s-istiosys-istioing-7f6b68cc6f-d4c37fd861fdc68d.elb.us-west-2.amazonaws.com   15021:30022/TCP,80:30081/TCP,443:30003/TCP
    Uncomment and assign the ExternalIP output to the grafana.accessIp and ingressHostname.product parameters in the values-user-overrides.yaml file.
    ingressHostname:
      product: <ExternalIP>
      edgeServices: null
      
    grafana:
     accessIp: <ExternalIP>
    
    privateNetwork: true
  • If you want to update the metrics retention interval period during deployment, see Configure Metrics Retention Interval Period topic.
  • Set the DEPLOYMENT_ACTION to deploy-apps in deploy.settings file.
    DEPLOYMENT_ACTION="deploy-apps"
  • Trigger deployment by running the following installation scripts:
    root [ ~ ]# cd /root/tcx-deployer/scripts/deployment/
    root [ ~/tcx-deployer/scripts/deployment ]# ./tcx_app_deployment.sh
    After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
    root [ ~/tcx-deployer/scripts ]# kubectl get tcxproduct 
     OR
    root [ ~/tcx-deployer/scripts ]# kubectl get apps
    For all the apps, the reconciliation status must be successful.
    root [ ~/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
    NAME   STATUS            READY   MESSAGE                               AGE
    tcsa   updateCompleted   True    All App CRs reconciled successfully   30h
    Note: After successful deployment, you can launch the VMware Telco Cloud Service Assurance UI. For more information, see Accessing VMware Telco Cloud Service Assurance UI topic.

    If all the apps are not reconciled, the deployment fails. For more information, see VMware Telco Cloud Automation Installation Issue in the VMware Telco Cloud Service Assurance Troubleshooting Guide.

Note: If you want to deploy on vSAN without any other storage available for AWS S3 compatible storage, you must deploy MinIO. For more information, see Customizing Backup and Restore Configurations topic.