JavaScript is not currently enabled, but is required for full
CodeSonar manual search and browse functionality.
If you are viewing this file in your hub's Web GUI, enable
JavaScript in your browser: you will also need it for GUI
functionality.
If you opened this file directly from disk, your browser may be
directly suppressing JavaScript functionality: certain browsers
perform this suppression on local files (but not files delivered by
web servers) for security reasons.
-
If you access the manual through the hub's Web GUI, the
functionality will not be suppressed because the hub is a web
server.
-
Alternatively, your browser may allow you to explicitly
disable the security setting that suppresses functionality. See
the CodeSonar
FAQ for more information.
Install CodeSonar on a Kubernetes Cluster: Building Your Own Images
This page describes how to set up and deploy CodeSonar on a
Kubernetes cluster, with images you build yourself.
If you want to set up and deploy CodeSonar on a Kubernetes
cluster but prefer to use official images, follow the instructions in
Install CodeSonar on a Kubernetes Cluster: From artifacts.codesonar.com instead.
You can also run the CodeSonar hub and launch daemons in Docker
containers without Kubernetes:
This page describes how to set up and deploy CodeSonar on a
Kubernetes cluster, with images you build yourself.
The process of setting up and deploying CodeSonar on a Kubernetes
cluster has three parts.
If you want to set up and deploy CodeSonar on a Kubernetes cluster
but prefer to use official images, follow the instructions in
Install CodeSonar on a Kubernetes Cluster: From artifacts.codesonar.com instead.
You can also run the CodeSonar hub and launch daemons in Docker
containers without Kubernetes:
Before you start, make sure you have the following.
| CodeSonar Installer |
Obtain the CodeSonar64-bit Linux installer from CodeSecure.
The file name will be something like codesonar-9.2p0.20260428-x86_64-pc-linux.tar.gz (the date stamp
part of the name may vary). |
| Private Docker Registry
|
You will need a private Docker registry to store your
CodeSonar images.
The Docker registry must not be visible to the entire internet:
your CodeSonar images must only be available to the users covered
by your CodeSonar license.
These instructions will use <docker-registry> to
refer to the address of your Docker registry. |
| Kubernetes Cluster |
A Kubernetes cluster, running 64-bit Linux. |
| Ingress |
Your Kubernetes cluster must be running an ingress controller. |
| Local Tools |
The following tools must be available on the machine where you
perform the setup process.
|
| (Optional) SMTP Server |
If you want to configure your hub to send email, you will
need an SMTP server for it to connect to. |
First, you will build Docker images for the CodeSonar hub and
CodeSonar analysis, and push these images to your private Docker registry.
- If you have not already done so, download the CodeSonar 64-bit
Linux installer and save it to your system.
- Open the download site in your web browser. If you cannot
locate the email with the URL, use https://links.codesonar.com/support/login/.
- Authenticate using the download credentials provided in the
email from CodeSecure. If you don't recall your password,
click the Please remind me link at the bottom of the
page and follow the password recovery instructions
provided.
- Download the CodeSonar installation file for 64-bit
Linux.
- Change to the directory of your choice and extract the
installer.
cd /<setupdir>
gzip -cd /path/to/codesonar-9.2p0.20260428-x86_64-pc-linux.tar.gz | tar xf -
The contents of the tarball will be extracted into ./codesonar-9.2p0.
- Change to the codesonar-9.2p0/k8s/cso-components
directory.
cd codesonar-9.2p0/k8s/cso-components
This directory contains Dockerfiles for the CodeSonar hub and
analysis, along with a build script to build these images and
push them to a Docker repository.
- Copy the installer tarball to this directory.
cp /path/to/codesonar-9.2p0.20260428-x86_64-pc-linux.tar.gz .
- Log in to your private Docker
registry, if you are not already logged in.
- Run the following command to build and push CodeSonar images to
your private Docker registry, tagging them with the version of the
installer.
./build.sh <docker-registry>
codesonar-9.2p0.20260428-x86_64-pc-linux.tar.gz
- Inspect your Docker registry. You should see the following.
- A repository <docker-registry>/codesonar-k8s-analysis,
containing a CodeSonar analysis image tagged with the version
of the installer (in this case, 9.2p0).
- A repository <docker-registry>/codesonar-k8s-hub,
containing a CodeSonar hub image tagged with the version of the
installer (in this case, 9.2p0).
These repositories will also contain any other CodeSonar analysis
and hub images that have been pushed previously.
Once your Docker images are ready, you will use one or both to
deploy CodeSonar on Kubernetes.
- 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.
- Change to the
codesonar-9.2p0/k8s/helm
directory.
cd codesonar-9.2p0/k8s/cso-components/helm
- Open values.yaml for editing.
- Do you want to set up a hub only deployment, or hub
and analysis?
-
hub only
- Set analysis.enabled=false.
- Go on to the next
step.
-
hub and analysis
- Set analysis.enabled=true.
- Set other analysis
values as shown in the following table.
| Value |
Setting |
| analysis.image.repository |
<docker-registry>/codesonar-k8s-analysis
Where <docker-registry>
is your private Docker registry. |
| analysis.image.tag
|
Leave blank to default to the tag that was
assigned to your images in part
A. |
| analysis.replicas |
The number of analysis pods to run. |
| analysis.storage
|
Persistent storage per replica, in GiB. |
| analysis.image.distributed.enabled
|
false
|
- Go on to the next
step.
-
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.
|
|
|
image.*
|
The CodeSonar hub image.
| image.repository
|
<docker-registry>/codesonar-k8s-hub
Where <docker-registry> is
your private Docker registry. |
| analysis.image.tag
|
Leave blank to default to the same tag that was
assigned to your images in part
A. |
|
| 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.
|
- Save your changes to values.yaml.
-
Deploy the Helm
charts.
helm upgrade --install --create-namespace --namespace codesonar
codesonar --values=values.yaml .
If the hub started
successfully, the command output will explain how to obtain your
CodeSonar hub address.
- Run the command provided in the helm
upgrade output.
It will output the URL for your hub home page.
- Connect to the specified URL (you may need to wait a short time
while the hub starts).
You should see the home
page.
- Communicate the hub address to any users who require it.
Before you can use your new hub, you will need to obtain
and then set up a license key.
There are very few differences between using a hub that is running
under Kubernetes and using any other hub.
| Hub interaction |
Procedure
(<public_hub_addr> represents the hub address that
you determined after deploying the
Helm charts) |
Same as other hubs? |
| access the hub's web
GUI |
Use a web browser to access
<public_hub_addr>. |
YES |
| use the hub HTTP
API |
Specify API endpoints with respect to
<public_hub_addr>. |
YES |
| CodeSonar build/analysis |
Specify <public_hub_addr> as the hub
address. |
YES |
| other codesonar
commands |
For commands other than codesonar hub-start and codesonar hub-stop, specify
<public_hub_addr> as the hub address. |
YES |
| start a hub |
Your hub will start when you deploy the Helm chart. If the
hub shuts down, Kubernetes will restart it automatically. |
no |
| shut down a hub |
If you shut down your hub with the configuration tool or
codesonar hub-stop, Kubernetes will
restart it automatically.
To stop the hub without restarting it, scale the hub
StatefulSet to 0:
kubectl scale -n codesonar statefulset/codesonar-hub
--replicas=0
(If you used a different namespace when you set up the pods,
use the same namespace here.)
When you want the hub back up, run the kubectl scale command with
--replicas=1.
|
no |
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.
To upgrade your CodeSonar hub and analysis pods, do the
following.
- 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.
- Build and push hub and
analysis images for the new CodeSonar version, following the steps
from A. Build and push CodeSonar images.
- Change to the codesonar-9.2p0/k8s/helm directory in your
newly unpackaged tarball.
cd codesonar-9.2p0/k8s/cso-components/helm
- Open values.yaml for editing.
- Transfer the settings from values.yaml.prev to values.yaml and save your changes.
- 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.)
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.
- Change to the <setupdir>/codesonar-9.2p0/k8s/helm/aws
directory, where <setupdir> is the directory where
you performed the original setup (or a directory with the same
contents, including your customizations).
cd <setupdir>/codesonar-9.2p0/k8s/helm
- 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.)
- Delete the hub's volume claim.
kubectl delete pvc -n codesonar hub-volume-codesonar-hub-0
- Save a copy of recovery.yaml (right-click on the link and select
Save Target As... or equivalent).
- Open recovery.yaml for
editing.
- In recovery.yaml, set
spec.resources.requests.storage to
a value large enough to accommodate the standby database.
Save your changes.
- Apply recovery.yaml to copy
the backup
kubectl apply -n codesonar -f recovery.yaml
- 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
- Wait until the hub has started up.
- Delete the snapshot.
kubectl delete volumesnapshot -n codesonar hub-recovery