Install CodeSonar on a Kubernetes Cluster: From artifacts.codesonar.com

• Overview
• Prerequisites
• Installation
• Using your hub and analysis pods
• Upgrading
• Restoring from warm standby

Overview

This page describes how to set up and deploy CodeSonar on a Kubernetes cluster, using official images from artifacts.codesonar.com.

The process of setting up and deploying CodeSonar on a Kubernetes cluster has three parts.

• A. Authenticate with artifacts.codesonar.com
• B. Customize and deploy Helm charts
• C. Set up your hub license key

If you want to set up and deploy CodeSonar on a Kubernetes cluster but prefer to build your own images, follow the instructions in Install CodeSonar on a Kubernetes Cluster: Building Your Own Images instead.

You can also run the CodeSonar hub and launch daemons in Docker containers without Kubernetes:

• Installation: Hub Setup: Starting a New Hub from artifacts.codesonar.com with Docker
• The CodeSonar Launch Daemon: Starting a Launch Daemon with the official cso/codesonar-launchd Docker Image

Prerequisites

Before you start, make sure you have the following.

Installation

A. Authenticate with artifacts.codesonar.com

1. If you haven't already done so, obtain your artifacts.codesonar.com CLI secret.
   1. Navigate to https://artifacts.codesonar.com/.
   2. Sign in with your CodeSonar Support credentials.
   3. Select User Profile from the menu at top right.
      Your User Profile page will open.
   4. Make a note of the Username.
   5. Click the copy icon on the CLI secret line to copy the CLI secret to your clipboard.

   Note. Your CLI secret will expire after a month. If necessary, repeat these steps obtain a new secret from https://artifacts.codesonar.com/.

2. Log in to the registry.
   helm registry login https://artifacts.codesonar.com

   Provide your credentials when prompted.

   • User name is your artifacts.codesonar.com Username.
   • Password is your artifacts.codesonar.com CLI secret.
   (Helm will store these credentials in ~/.config/helm/registry/config.json; you will use this file in step 4.)
3. Create a namespace for CodeSonar
   kubectl create namespace codesonar
4. Add your artifacts.codesonar.com credentials to the namespace.
   kubectl create secret generic -n codesonar regcred \
   --from-file=.dockerconfigjson=~/.config/helm/registry/config.json \
   --type=kubernetes.io/dockerconfigjson

B. Customize and deploy Helm charts

Once your Docker images are ready, you will use one or both to deploy CodeSonar on Kubernetes.

1. Decide how you want to deploy CodeSonar on Kubernetes. There are two main options.
   • Hub only. The CodeSonar hub runs in a Kubernetes pod, but CodeSonar analyses do not.
     You can optionally enable a second pod to maintain a warm standby of the hub database.
   • Hub and analysis. The CodeSonar hub runs in a Kubernetes pod. A CodeSonar launch daemon runs in a separate pod, and can be used to perform remote-managed analysis or to manage remote archiving for analyses performed elsewhere. You can duplicate the analysis pod to run multiple launch daemons.
     As with the hub only option, you can also enable a warm standby pod for hub database backup.
   A third option, hub and distributed analysis, is more complicated to set up and is not recommended. See the comments in values.yaml to learn more.
2. Pull and unpack the cso/codesonar Helm chart.
   helm pull oci://artifacts.codesonar.com/cso/codesonar --untar
3. Change to the codesonar directory.
   cd codesonar
4. Open values.yaml for editing.
5. Do you want to set up a hub only deployment, or hub and analysis?
   • hub only
     1. Set analysis.enabled=false.
     2. Go on to the next step.
   • hub and analysis
     1. Set analysis.enabled=true.
     2. Set other analysis values as shown in the following table.

        Value	Setting
        analysis.replicas	The number of analysis pods to run.
        analysis.storage	Persistent storage per replica, in GiB.
        analysis.image.distributed.enabled	false

     3. Go on to the next step.
6. Edit values.yaml to specify values for the CodeSonar hub.

   	Value	Setting
   Basic hub setup
   	ingress.*	Ingress settings to expose the hub outside the Kubernetes cluster. ingress.enabled true remaining ingress.* Set as usual for your Ingress.
   	hostNetwork	false
   	port	Ignored when hostNetwork=false.
   	tls.*	Hub TLS settings. tls.enabled true to enable HTTPS for the hub now, using the hub server certificate specified by the remaining arguments. false to disable HTTPS. tls.secretName The name of a Kubernetes TLS secret (kubernetes.io/tls). If a secret with this name already exists, the TLS certificate and private key contained in the secret will be used as the hub server certificate. (Do not specify a value for tls.combinedPem in this case.) Otherwise, a new TLS secret with this name will be created and populated with the certificate and private key that you provide. tls.combinedPem The TLS certificate that you want to use as the hub server certificate and its private key. You have two options for providing this information. Leave this value empty and load from a file. Specify --set-file path/to/certfile.pem when you deploy the Helm charts. Populate this value directly with PEM-encoded text. For example: tls: combinedPem: | -----BEGIN RSA PRIVATE KEY----- Hiy29[...remainder of private key] -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- DIdfj/5FxUu6[...remainder of certificate] -----END CERTIFICATE----- Once you have enabled TLS with a particular hub server certificate, changes to the tls.secretName and tls.combinedPem settings will have no effect unless you disable and then reenable TLS. In particular, you do not need to provide the hub server certificate every time you restart the hub. Note: If you want to reconfigure or disable HTTPS, update these settings and then run your helm upgrade command. Do not use the hub's web GUI to modify your HTTPS settings: the updated information will not be propagated to your analysis pods.
   	dbStorage	The persistent storage to be allocated for the hub database, in GiB.
   	password	A password for the hub's special Administrator account. This will be stored in a Kubernetes Secret. The Administrator password will be reset to the password value every time you deploy the chart. Note: If you want to change the Administrator password, update this setting and then run your helm upgrade command. Do not use other methods (such as changing the password in the hub's web GUI): the updated information will not be propagated to your analysis pods.
   Warm standby
   	standby.enabled	Set to true if you want to set up a standby pod to back up your hub database via streaming replication; false otherwise. If you later need to restore the hub database from this backup, follow the Restoring instructions in Task: Back Up and Restore a Hub Database: Unencrypted Communication. If you have subsequently configured your hub to use TLS for database communication, follow the Restoring instructions in Task: Back Up and Restore a Hub Database: TLS Communication instead. Note that you don't need to manually perform the "Backing Up" steps on either of these pages: setting up the standby pod serves this need.

7. Save your changes to values.yaml.
8. Deploy the Helm charts.
   helm upgrade --install --create-namespace --namespace codesonar codesonar --values=values.yaml .
   • If you have set tls.enabled=true and want to use the certificate and key from an existing file, use the following command instead.
     helm upgrade --install --create-namespace --namespace codesonar codesonar --values=values.yaml --set-file path/to/certfile.pem .
     where path/to/certfile.pem is a PEM-encoded file containing both the TLS certificate and its private key.
   If the hub started successfully, the command output will explain how to obtain your CodeSonar hub address.
9. Run the command provided in the helm upgrade output.
   It will output the URL for your hub home page.
10. Connect to the specified URL (you may need to wait a short time while the hub starts).
    You should see the home page.
11. Communicate the hub address to any users who require it.

C. Set up your hub license key

Before you can use your new hub, you will need to obtain and then set up a license key.

• Installation: Hub License Key: Obtaining a License Key
• Installation: Hub License Key: Set Up a Standard License Key

Using your hub and analysis pods

• Hub pod
• Analysis pod

Hub pod

There are very few differences between using a hub that is running under Kubernetes and using any other hub.

Analysis pod

To use the launch daemon in your analysis pod, you will need to identify it. You have several options.

• Identify a single launch daemon by its Launch Daemon ID or Path.
  You can find these on the hub's Analysis Cloud page (use the column management menu to add the ID and Path columns to the table).
• Specify a launchd group to collectively refer to all launch daemons in that group.
  The launch daemon in each analysis pod is created as a member of the /k8s launchd group.

You can use the CodeSonar launch daemon in your analysis pod to remote-manage an analysis.

• To remotely manage the analyze phase, specify the -remote option in your codesonar analyze command. Data and control will remain with the same launch daemon when the analysis transitions to daemon mode, unless you also specify a separate -remote-archive setting.
• To use the launch daemon with ID <ld-id> to remotely manage the analysis data after the analysis has transitioned to daemon mode, specify the -remote-archive option in your codesonar analyze command.
• For example:

  -remote -<ld-id> -remote-archive -<ld-id>	The launch daemon with ID <ld-id> is used.
  -remote "/k8s/*" -remote-archive "/k8s/*"	The hub selects a launch daemon from the /k8s launchd group.

• See Analysis: Local and Remote Analysis Management for more information.

If you set up multiple replicas, each analysis pod contains a separate CodeSonar launch daemon. You can use these individually to manage individual analyses; you can also use them to contribute to distributed analyses.

• For detailed instructions, see Task: Distribute Analysis Work Over Specific Machines
  Note that you will not need to perform the steps in "Stage B. Start launch daemons", because your launch daemons are already running in the analysis pods.

Upgrading

To upgrade your CodeSonar hub and analysis pods, do the following.

1. Before upgrading, make a copy of the values.yaml file that you are currently using (that is, the one you customized and deployed in B. Customize and deploy Helm charts). Call this copy values.yaml.prev.
2. Log in to the artifacts.codesonar.com registry, following the steps from A. Authenticate with artifacts.codesonar.com.
3. Pull and unpack the cso/codesonar Helm chart.
   helm pull oci://artifacts.codesonar.com/cso/codesonar --untar
4. Change to the codesonar directory.
   cd codesonar
5. Open values.yaml for editing.
6. Transfer the settings from values.yaml.prev to values.yaml and save your changes.
7. Run the following command to update your pods.
   helm upgrade --namespace codesonar codesonar --values=values.yaml .
   (If you used a different namespace when you set up the pods, use the same namespace here.)

Restoring your Kubernetes hub database from warm standby

If you have configured your deployment to include a standby pod for backing up your hub database, you can use this pod for recovery as follows.

1. Shut down the hub and standby by scaling their StatefulSets to 0.
   kubectl scale --replicas=0 -n codesonar statefulset/codesonar-hub
   kubectl scale --replicas=0 -n codesonar statefulset/codesonar-replica
   (If you used a different namespace when you set up the pods, use the same namespace here.)
2. Delete the hub's volume claim.
   kubectl delete pvc -n codesonar hub-volume-codesonar-hub-0
3. Save a copy of recovery.yaml (right-click on the link and select Save Target As... or equivalent).
4. Open recovery.yaml for editing.
5. In recovery.yaml, set spec.resources.requests.storage to a value large enough to accommodate the standby database.
   Save your changes.
6. Apply recovery.yaml to copy the backup
   kubectl apply -n codesonar -f recovery.yaml
7. Bring the hub and standby back up by rescaling their StatefulSets.
   kubectl scale --replicas=1 -n codesonar statefulset/codesonar-hub
   kubectl scale --replicas=1 -n codesonar statefulset/codesonar-replica
8. Wait until the hub has started up.
9. Delete the snapshot.
   kubectl delete volumesnapshot -n codesonar hub-recovery