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
BASHhelm upgrade <deployment-name> -f ejbca-values.yaml \ oci://repo.keyfactor.com/charts/ejbca --version <version>
Community
BASHhelm 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
docker run --rm registry.primekey.com/primekey/ejbca-ee:<version> \
tar -cC /opt/keyfactor/ejbca/ conf | tar x
Community
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
helm upgrade <deployment-name> -f ejbca-values.yaml \
oci://repo.keyfactor.com/charts/ejbca --version <new-version>
Community
helm upgrade <deployment-name> -f ejbca-values.yaml \
oci://repo.keyfactor.com/charts/ejbca-ce --version <new-version>