parasoft/lss-helm repository overview

⁠Quick reference

Maintained by: Parasoft⁠

Where to get help: Parasoft Documentation⁠, Parasoft Forums⁠, or Parasoft Support and Technical Services⁠

⁠What is License Server Standalone?

License Server Standalone (LSS) is a tool that enables you to manage licenses for Parasoft products deployed to your network. In standalone edition, this tool works as standalone application - independently from other Parasoft products. Please see the product's documentation⁠.

⁠Prerequisites

• Helm version 3+ installed

⁠How to use this Helm Chart

⁠Download the Parasoft License Server Standalone Helm Chart

Download the License Server Standalone chart archive and (optionally) unpack it in a local directory with command:

$ helm pull oci://registry-1.docker.io/parasoft/lss-helm --version TAG --untar

• --version TAG - Tag for the version of the Helm Chart to download
• --untar - Optional flag that unpacks the chart archive (.tgz) in a local directory called lss-helm

⁠Install Parasoft License Server Standalone

Install License Server Standalone with command:

$ helm install RELEASE_NAME [ PACKAGED_CHART_PATH | UNPACKAGED_CHART_PATH ] --namespace NAMESPACE --create-namespace 

• RELEASE_NAME - Name for the new release being installed
• PACKAGED_CHART_PATH - Path of the downloaded chart archive
• UNPACKAGED_CHART_PATH - Path of the lss-helm local directory unpacked from the downloaded chart archive
• --namespace NAMESPACE - Namespace for the new release being installed
• --create-namespace - Creates the namespace for the new release being installed if it does not exist already

⁠Note about persistent volume claim when upgrading helm chart:

If you are upgrading from a version of the License Server Standalone Helm Chart that is 2024.1.0 or older and you intend to pass in a pre-configured values.yaml during the upgrade, you will need to specify a value for persistence.claimExists. This value must be set to "true" if a persistent volume claim was created manually outside of the Helm Chart. This can either be specified in the values.yaml file itself or passed in as a flag during the upgrade.

Example upgrade command:

$ helm upgrade --values=VALUES_YAML_PATH RELEASE_NAME [ PACKAGED_CHART_PATH | UNPACKAGED_CHART_PATH ] --set persistence.claimExists=true --namespace=NAMESPACE

⁠Uninstall Parasoft License Server Standalone

Uninstall License Server Standalone with command:

$ helm uninstall RELEASE_NAME

• RELEASE_NAME - Name for the release being uninstalled

⁠Setting up a persistent volume

If using a persistent volume, then a persistent volume claim will need to be set up before installing LSS. LSS can be configured to use an existing persistent volume claim in two ways.

If you unpacked the chart archive, then you can edit the values.yaml to set the value of persistence.name to the name of the existing persistent volume claim and also set the value of persistence.claimExists to "true".

If you did not unpack the chart archive, then you can create a myvalues.yaml file to pass custom values to the LSS install command using the flag -f myvalues.yaml. Here is an example of what that could look like if the existing persistent volume claim was called lss-pvc:

myvalues.yaml

persistence:
  name: lss-pvc
  claimExists: true

If you unpacked the chart archive, then you will also find the pv.yaml, pvc.yaml, and storageclass.yaml templates. These templates are configured to use hostPath or nfs persistent volume types using values defined in the persistence section of the values.yaml. It is also possible via the values in the persistence section to only use the pvc.yaml to configure a custom persistent volume claim if hostPath or nfs persistent volume types do not suit your needs. These values are not enabled by default, so the templates are not used to create any resources when installing LSS as is. In order to use these templates, the values in the persistence section of the values.yaml need to be manually enabled by uncommenting lines. Keep in mind that these templates are meant to show how to define custom persistent volumes, persistent volume claims, and storage classes. As such, these templates may be removed or modified to fit individual deployment needs.

⁠Advanced settings

⁠Overriding Tomcat configuration

Parasoft LSS runs on Tomcat. Tomcat and its configuration files are embedded in the Docker image. If you need to customize the Tomcat settings or provide your keystore or truststore, here are two ways to do it:

1. Use a reverse proxy to configure ports and keystore. This eliminates the need to make changes to the default Tomcat settings and keystore in the container.

2. Create configuration maps with file mappings for the custom configuration files and set each configuration map as a volume mount in the pod definition. Note that after deploying the configuration maps as volume mounts, any external updates made to the custom configuration files will not be reflected inside the container. To deploy external updates to the custom configuration files, the container will need to be restarted.

   Create the custom keystore configuration map with command:

   $ kubectl create configmap keystore-cfgmap --from-file=keystore=KEYSTORE_CFG_PATH --from-file=server-config=SERVER_CFG_PATH
   

   Copy
   • KEYSTORE_CFG_PATH - Path to the custom .keystore configuration file
   • SERVER_CFG_PATH - Path to the custom server.xml configuration file

   Create the custom truststore configuration map with command:

   $ kubectl create configmap truststore-cfgmap --from-file=truststore=TRUSTSTORE_CFG_PATH
   

   Copy
   • TRUSTSTORE_CFG_PATH - Path to the custom cacerts configuration file

   To enable the use of custom Tomcat configurations, you have two choices:

   If you unpacked the chart archive, then you can edit the values.yaml to set the values of deployment.customKeystore.enabled and deployment.customTruststore.enabled to true.

   If you did not unpack the chart archive, then you can create a myvalues.yaml file to pass custom values to the LSS install command using the flag -f myvalues.yaml.

   myvalues.yaml

   deployment:
     customKeystore:
       enabled: true
     customTruststore:
       enabled: true
   

   Copy

⁠Parasoft LSS internal variables

It is possible to inject the Parasoft LSS environment variable LSS_JAVA_OPTS into the Parasoft LSS container. To enable the use of custom JVM arguments, you have two choices:

If you unpacked the chart archive, then you can edit the values.yaml to set the value of deployment.jvmArgs.enabled to true. Then, set the value of deployment.jvmArgs.value to the arguments you want to use. For example:

• "-Dcom.parasoft.oauth2.jwks.uri=https://server.company.com:8443/auth/realms/demo/protocol/openid-connect/certs"

If you did not unpack the chart archive, then you can create a myvalues.yaml file to pass custom values to the LSS install command using the flag -f myvalues.yaml.

myvalues.yaml

deployment:
  jvmArgs:
    enabled: true
    value: "-Dcom.parasoft.oauth2.jwks.uri=https://server.company.com:8443/auth/realms/demo/protocol/openid-connect/certs"

⁠License

You need to view and agree to the Parasoft End User License Agreement (EULA)⁠ for the software contained in the underlying image.

As with all Docker images, these likely also contain other software which may be under other licenses. As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.