Page History

...

This chapter provides information on how to deploy the product for testing purposes. Keep in mind that the guidelines provided below are not considered the best practices and do not take into account security settings and password encryption. This deployment has been tested with a specific Kubernetes version, CNI, container runtime, and OS. If you use other solutions, use them at your own risk.

...

1. Install kubectl as described at https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/.
2. Install the helm to the K8S cluster admin host as described at https://helm.sh/docs/intro/install.

3. Execute the following command to copy cluster config files to the K8S cluster admin host:

   Code Block
   scp -r <user@control_plane_address>:.kube ~ Edit ~/.kube/config

   
   

   Note
   Replace the localhost IP address with your control plane IP address or hostname, e.g., https://127.0.0.1:6443.

   
   

4. Prepare the required files and directories:

   1. Download and extract the webapp-charts.zip file.
   2. Download the installation package for your product version. For more information, refer to Downloading installation files.

   3. Extract the packaged files, and inside the webapp-charts root directory (where you extracted the webapp-charts.zip file), extract the twcloud_<version>_no_install_linux64.zip file. After extracting the files, you should have the following folder structure: <webapp-charts_root>/CATIANoMagicServices/TeamworkCloud/.

      Note

      You will find all files mentioned in this chapter in twcloud_<version>_no_install_linux64.zip or on the software download website (except for Teamwork Cloud keystore and SSL certificate): The <webapp-charts_root>/CATIANoMagicServices/WebAppPlatform/webapps directory contains application .war files. The <webapp-charts_root>/CATIANoMagicServices/WebAppPlatform/shared/conf directory contains other configuration files. The <webapp-charts_root>/CATIANoMagicServices/WebAppPlatform/conf directory contains server.xml. The <webapp-charts_root>/CATIANoMagicServices/WebAppPlatform/shared/conf/data directory contains files for Cameo Collaborator and document-exporter. The <webapp-charts_root>/CATIANoMagicServices/TeamworkCloud/configuration directory contains Teamwork Cloud configuration files. The <webapp-charts_root>/CATIANoMagicServices/Utilities/Cassandra contains the .jar file for Cassandra's communication with Zookeeper.

      
      

5. Use the same SSL certificate and key that were used for the Teamwork Cloud server. You can copy the key and certificate files from the Teamwork Cloud server.

6. If you use only the .p12 file on the Teamwork Cloud server, execute the following command to extractthe certificate and keyfrom the .p12 file:

   Code Block
   openssl pkcs12 -in INFILE.p12 -out tls.crt -nokeys openssl pkcs12 -in INFILE.p12 -out tls.key -nodes –nocerts

   
   

   Note
   The tls.crt and tls.key files will be used for ingress-nginx, so file names in ingress-nginx must be exactly the same.

   
   

7. Execute the following commands to prepare the webapp-charts root directory:

   Code Block
   cd <webapp-charts_root>/webapp-charts mkdir -p configs/{auth,cassandra,ssl,tomcat,twcloud,wap} configs/twcloud/ssl

   
   

8. Copy all files listed below into their directories:

   auth
   authserver.properties
   cassandra
   cassandra.yaml logback.xml
   ssl
   tls.crt tls.key
   tomcat
   catalina.properties server.xml
   wap
   revision.txt log4j2.properties webappplatform.properties
   twcloud
   application.conf logback.xml jvm.options
   twcloud/ssl
   keystore.p12 (from the Teamwork Cloud server) teamworkcloud.crt

   
   

9. Execute the following command to copy the generated Teamwork Cloud certificates:

   Code Block
   cp keystore.p12 teamworkcloud.crt configs/twcloud/ssl

   
   

10. Edit the application.conf file as shown below:
    

    Code Block
    sed -i 's/contact-points.*/contact-points = [${?CASSANDRA_SEED0}][${?CASSANDRA_SEED1}][${?CASSANDRA_SEED2}]/g' application.conf sed -i "s/local.size.*/local.size = 3/g" application.conf sed -i "s/remote.size.*/remote.size = 3/g" application.conf sed -i "s/replication-factor.*/replication-factor = 3/g" application.conf

11. Edit the jvm.options file as shown below:
    

    Code Block
    sed -i 's/-Xmx.*/-Xmx=${TWC_XMX}/g' jvm.options

12. Copy the application.conf, jvm.options, and logback.xml files to the configs/twcloud directory.

13. Execute the following command to copy the extracted Teamwork Cloud certificates:

    Code Block
    cp tls.crt tls.key configs/ssl

    
    

14. Go to https://archive.apache.org/dist/cassandra/4.1.4/apache-cassandra-4.1.4-bin.tar.gz and download the Cassandra configuration file.

15. Execute the following command to extract the Cassandra .tar file:

    Code Block
    tar -xzf apache-cassandra-4.1.4-bin.tar.gz

    
    

16. In the cassandra.yaml file edit Cassandra settings as shown below.
    

    Code Block

    sed -i "s/# commitlog_total_space:.*/commitlog_total_space: 8192MiB/g" cassandra.yaml sed -i "s/commitlog_segment_size:.*/commitlog_segment_size: 192MiB/g" cassandra.yaml sed -i "s/read_request_timeout:.*/read_request_timeout: 1800000ms/g" cassandra.yaml sed -i "s/range_request_timeout:.*/range_request_timeout: 1800000ms/g" cassandra.yaml sed -i "s/^write_request_timeout:.*/write_request_timeout: 1800000ms/g" cassandra.yaml sed -i "s/cas_contention_timeout:.*/cas_contention_timeout: 1000ms/g" cassandra.yaml sed -i "s/truncate_request_timeout:.*/truncate_request_timeout: 1800000ms/g" cassandra.yaml sed -i "s/request_timeout:.*/request_timeout: 1800000ms/g" cassandra.yaml sed -i "s/batch_size_warn_threshold:.*/batch_size_warn_threshold: 3000KiB/g" cassandra.yaml sed -i "s/batch_size_fail_threshold:.*/batch_size_fail_threshold: 5000KiB/g" cassandra.yaml sed -i "s/# internode_application_send_queue_reserve_endpoint_capacity:.*/internode_application_send_queue_reserve_endpoint_capacity: 512MiB/g" cassandra.yaml sed -i "s/# internode_application_receive_queue_reserve_endpoint_capacity:.*/internode_application_receive_queue_reserve_endpoint_capacity: 512MiB/g" cassandra.yaml

     

17. Execute the following command to copy files:

    Code Block
    cp apache-cassandra-4.1.4/conf/cassandra.yaml logback.xml configs/cassandra

    
    

18. Execute the following command to create a directory for each application you are going to use:

    Code Block
    mkdir -p imagebuild/{admin-console,authentication,collaborator,document-exporter,oslc,reports,resources,resource-usage-map,simulation,webapp,twc}

    
    

19. Copy all files listed below to their directories (except the artemis directory). You will find the Docker files for each service in dockerfiles.zip. After placing the Docker files in their appropriate directories, rename them to Dockerfile as shown below:

    admin-console
    admin.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    authentication
    authentication.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    collaborator
    collaborator.war Dockerfile data (The directory is located in <install_root>/WebAppPlatform/shared/conf/. Before copying, remove the document-exporter directory from the data directory.) ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    document-exporter
    document-exporter.war Dockerfile data (This directory is located in <webapp-charts_root>/CATIANoMagicServices/WebAppPlatform/shared/conf/. Remove the collaborator directory from the data directory.) ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    oslc
    oslc.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    reports
    reports.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    resource-usage-map
    resource-usage-map.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    resources
    resources.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    simulation
    simulation.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    webapp
    webapp.war Dockerfile ROOT (The directory is located in CATIANoMagicServices/WebAppPlatform/webapps.)
    twcloud
    Dockerfile TeamworkCloud (The directory is located in CATIANoMagicServices.)

    
    

    
    

20. Execute the following command to start the local Docker registry:

    Code Block
    docker run -d -p 5000:5000 --restart=always --name registry registry:2

    
    

    Note
    In this case, a local Docker registry is run on the K8S cluster admin host. It uses port 5000, so make sure this port is open on your host firewall and accessible to your Kubernetes cluster.

    
    

    Warning
    This local Docker registry should be used for testing purposes only and is not considered production-ready. In the production environment, run the image registry with TLS and authentication.

    
    

21. Add your repo URL (FQDN of the K8S cluster admin host) to the Docker /etc/docker/daemon.json file.

22. If the daemon.json file does not exist, create it. Assuming there are no other settings in the file, it should have the following content:
    

    Code Block
    { "insecure-registries": ["admin.example.com:5000"] }

    
    

23. Execute the following command to restart the Docker service:

    Code Block
    sudo systemctl restart docker

    
    

24. Execute the commands below for each service that you want to build images for inside their own directories, as shown in the examples in steps 24a, 24b, and 24c.

    Code Block
    docker build -f Dockerfile -t {APP_NAME} . docker tag {APP_NAME}:{VERSION} {IMAGE_REPO_URL}:5000/{APP_NAME}:{VERSION} docker push {IMAGE_REPO_URL}/{APP_NAME}:{VERSION}

    
    

    Note
    {IMAGE_REPO_URL} - your image repository URL. It can differ depending on the image registry provider. {APP_NAME} - application name. {VERSION} - version to be used for the tag.

    
    

    1. The following command example builds images for Admin Console:

       Code Block
       cd imagebuild/admin-console docker build -f Dockerfile -t admin .

       
       

    2. The following command example tags the built image:

       Code Block
       docker tag admin: latest admin.example.com:5000/admin:latest

       
       

    3. The following command example pushes the image to the registry:

       Code Block
       docker push admin.example.com:5000/admin:latest

25. To be able to pull images to your Kubernetes cluster nodes, add your image repository to the Containerd configuration on all cluster nodes.

    1. Edit the /etc/containerd/config.toml file by adding the following lines to the "mirrors" part:

       Code Block
       [plugins."io.containerd.grpc.v1.cri".registry.mirrors."admin.exmple.com:5000"] endpoint = ["http://admin.example.com:5000"] [plugins."io.containerd.grpc.v1.cri".registry.configs." admin.example.com"] [plugins."io.containerd.grpc.v1.cri".registry.configs." admin.example.com".tls] insecure_skip_verify = true

       
       

       Note
       Keep in mind that alignment is very important, as shown in the example below.

       
       

    2. Execute the following command to restart Containerd services on all cluster nodes:

       Code Block
       sudo systemctl restart containerd

       
       

26. Execute the following commands to add dependency repos:

    Code Block
    helm repo add kedacore https://kedacore.github.io/charts helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update cd ${webapp-charts_directory}

    
    

27. Execute the following command to update chart dependencies:
    

    Code Block
    helm dependency update

    
    

28. Execute the command below to install Custom Resource Definitions (CRD). This will create all services and deployments.

    Code Block
    helm install keda kedacore/keda --namespace keda --create-namespace --wait --version 2.13.2

    
    

    Note
    You can check the status of the services and pods with this command: kubectl get all -n keda

    
    

    Info
    Keda and MetalLB should be added as separate resources. Since CRDs (being a globally shared resource) are fragile, you have to assume that it is shared across multiple namespaces and groups of users once a CRD is installed. For that reason, installing, modifying, and deleting CRDs is a process that has ramifications for all users and systems of that cluster.

    
    

29. Execute the following command to deploy MetalLB:

    Code Block
    helm install metallb bitnami/metallb --namespace metallb-system --create-namespace --wait

    
    

30. To check the MetalLB deployment status, execute the following command on the control plane node or the K8S cluster admin host:

    Code Block
    kubectl get -n metallb-system all

    You should see an output similar to this:
    

    Note
    If you see that the MetalLB status is 'Running,' but READY is 0/1, give it some time to start and repeat the command.

    
    

31. Create configuration files for MetalLB:

    Note
    Make sure to complete all the substeps of this step to create and apply both configurations. Otherwise, the product will not work properly.

    
    

    1. Edit the metalLB/metallb_ipadresspool.yaml file as shown below:

       Code Block
       apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.1.1/32 #- 192.168.10.0/24 #- 192.168.9.1-192.168.9.5 #- fc00:f853:0ccd:e799::/124

       
       

       Note
       Your IT department should give you a reserved IP address or a range of IP addresses (depending on your needs) with a DNS A record that points to this IP address. Configuration files should be formatted in .yaml.

       
       

    2. Edit the metalLB/l2advertisement.yaml file as shown below. You can change the metadata name as needed. Keep in mind that the ipAddressPool name should match the specifications.

       Code Block
       apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: example namespace: metallb-system spec: ipAddressPools: - first-pool

       
       

    3. Execute the following command to apply the MetalLB configuration:
       

       Code Block
       kubectl apply -f metalLB/metallb_ipaddresspool.yaml

       
       

    4. Execute the following command to check the applied configuration:
       

       Code Block
       kubectl describe ipaddresspools.metallb.io first-pool -n metallb-system

       
       

    5. Execute the following command to create the MetalLB advertisement:
       

       Code Block
       kubectl apply -f metalLB/l2advertisement.yaml

       
       

    6. Execute the following command to check the advertisement configuration:
       

       Code Block
       kubectl describe l2advertisements.metallb.io example -n metallb-system

       
       

32. Find the Values.yaml file in the parent helm chart and provide the values of the parameters in the file to enable or disable specific applications or parts of the configuration.

33. Do one of the following:

    • Execute this command in the helm parent chart directory to deploy services to the default namespace:

      Code Block
      helm install webapp .

      
      

    • Execute this command in the helm parent chart directory to create a namespace and deploy services in this namespace:
      

      Code Block
      helm install webapp . --namespace=wap --create-namespace --wait

      
      

      Note
      This helm chart includes Zookeeper and Ingress-nginx as dependencies. They will be deployed automatically.

      
      

34. After all web applications are deployed, execute the following command to check their status:

    Code Block
    kubectl get all

    
    

    Note
    All pods should be READY:1/1, STATUS:Running. The ingress-nginx service should be Type:LoadBalancer. EXTERNAL-IP should match the address that you provided in the MetalLB configuration. If pods do not run, check for problems by executing this command: kubectl describe pod pod_name

    
    

35. Execute the following command to check Ingress rules:
    

    Code Block
    kubectl describe ingress

    You should get an output similar to this:
    

    Code Block

    Name: ingress.resource Namespace: default Address: **.**.***.*** Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>) TLS: webapp-tls-secret terminates nm-wap10639.dsone.3ds.com Rules: Host Path Backends ---- ---- -------- nm-wap10639.dsone.3ds.com /admin webapp-adminconsole:8443 (10.233.105.39:8443) /authentication webapp-authentication:8443 (10.233.88.69:8443) /collaborator webapp-collaborator:8443 (10.233.88.75:8443) /document-exporter webapp-docexporter:8443 (10.233.105.22:8443) /oslc webapp-oslc:8443 (10.233.105.23:8443) /reports webapp-reports:8443 (10.233.73.246:8443) /resources webapp-resources:8443 (10.233.88.67:8443) /resource-usage-map webapp-rum:8443 (10.233.105.40:8443) /simulation webapp-simulation:8443 (10.233.88.123:8443) /webapp webapp-webapp:8443 (10.233.105.29:8443) Annotations: meta.helm.sh/release-name: webapp meta.helm.sh/release-namespace: default nginx.ingress.kubernetes.io/affinity: cookie nginx.ingress.kubernetes.io/affinity-canary-behavior: sticky nginx.ingress.kubernetes.io/affinity-mode: persistent nginx.ingress.kubernetes.io/backend-protocol: https nginx.ingress.kubernetes.io/proxy-body-size: 100m nginx.ingress.kubernetes.io/proxy-connect-timeout: 600 nginx.ingress.kubernetes.io/proxy-read-timeout: 600 nginx.ingress.kubernetes.io/proxy-send-timeout: 600 nginx.ingress.kubernetes.io/send-timeout: 600 nginx.ingress.kubernetes.io/session-cookie-name: COOKIE Events: <none>

     

36. Test the product deployment:

    1. In an internet browser, go to domain_name/webapp (the DNS A record that points to the Ingress external IP).

       Note
       If you added a DNS record to bind the domain name to the IP address, you can use the domain name instead of the IP. The browser should show a warning because of the self-signed certificate. Accept it to proceed, and you will be redirected to the Teamwork Cloud Authentication web page.

       
       
       

    2. Log in with your credentials, and you will be redirected back to Web Application Platform.