Upgrade EJBCA Container

Helm offers a streamlined way to modify deployment parameters and upgrade to newer versions. The following sections provide steps needed to ensure a smooth upgrade process, from updating configuration parameters to upgrading to a new release version.

Update parameters for an existing release

To modify EJBCA deployment parameters, you can use the helm upgrade command to update parameters for an existing release.

For example, if you initially deployed EJBCA with the parameter services.proxyHttp.httpPort set to 8081, and now want to change it to 8888, you adjust the value in your chart's values file and run the helm upgrade command using the same values file and chart version.

Example

Modify the property in your char’s value file, for example, ejbca-values.yaml:
YAML
```
# ...
services:
  proxyHttp:
    httpPort: 8888
# ...
```

Run the upgrade command

Enterprise

BASH

helm upgrade <deployment-name> -f ejbca-values.yaml \
    oci://repo.keyfactor.com/charts/ejbca --version <version>

Community

BASH

helm upgrade <deployment-name> -f ejbca-values.yaml \
    oci://repo.keyfactor.com/charts/ejbca-ce --version <version>

Helm will identify the affected Kubernetes resources and redeploy them with the new configuration.

For more complex upgrades, you can use multiple values files, adding --set and --reuse-values flags, and so on. For more information, refer to the Helm Upgrade documentation.

Upgrade to a new release version

The following provides information on upgrading from your current version to a later version of EJBCA.

Before upgrading to a new version of EJBCA, review the EJBCA Upgrade Notes for the version you plan to upgrade to, as well as any intermediate versions.

Upgrade Strategy

When EJBCA is deployed with external Registration Authorities (RAs) and external Validation Authorities (VAs) using peering, the strategy for upgrading is to start with the external EJBCA nodes first. After the external EJBCA nodes are upgraded, upgrade the EJBCA CA nodes.

Upgrading the external EJBCA nodes first ensures the CA node uses the Peering protocol version of the CA instance. Therefore, if the CA is upgraded first, it would use a newer version of the Peering protocol that could be incompatible with the external RA/VA EJBCA nodes. Remember the phrase outside-in when upgrading EJBCA with external RA/VA nodes.

Upgrade Instructions

Make sure to always back up your database before starting the upgrade process. The database contains all CA data, and in case you need to roll back an upgrade, you can restore the database backup and re-deploy the previous Helm Chart version.

Update properties files

Updating properties files is relevant if you are utilizing the ejbca.importEjbcaConfFiles deployment parameter:

Merge changes from the default properties files of the latest container into your customized properties files.
Update the Secret referenced by ejbca.ejbcaConfFilesSecret.

The following command can be used to copy the conf directory with default properties files used by the EJBCA container to your machine:

Enterprise

BASH

docker run --rm registry.primekey.com/primekey/ejbca-ee:<version> \
    tar -cC /opt/keyfactor/ejbca/ conf | tar x

Community

BASH

docker run --rm keyfactor/ejbca-ce:<version> tar -cC /opt/keyfactor/ejbca/ conf | tar x

Update Helm Chart values files

Review the EJBCA Upgrade Notes for any changes that might need to be introduced to your Helm chart's values files and update the files accordingly.

Upgrade to the new Helm Chart version

Use your Helm Chart values file with the new chart version to upgrade an EJBCA deployment:

Enterprise

BASH

helm upgrade <deployment-name> -f ejbca-values.yaml \
    oci://repo.keyfactor.com/charts/ejbca --version <new-version>

Community

BASH

helm upgrade <deployment-name> -f ejbca-values.yaml \
    oci://repo.keyfactor.com/charts/ejbca-ce --version <new-version>