Deploy and Manage the EJBCA Application¶

This section describes the EJBCA application lifecycle on StarlingX, including application upload, configuration, deployment, updates, removal, and deletion.

Upload the EJBCA Application ¶

Upload the application tarball to register it with the platform.

~(keystone_admin)]$ system application-upload /path/to/ejbca-<version>.tgz

For Distributed Cloud deployments, ensure that registry.central contains the required application images before you apply the application on subclouds. You can populate registry.central in one of the following ways:

Apply the application on the System Controller to automatically pull the required images into registry.central.

or
Upload the application on the System Controller with the –images option to import the required images into registry.central before deploying the application on subclouds.
```
~(keystone_admin)]$ system application-upload /path/to/ejbca-<version>.tgz --images
```

Apply the EJBCA Application ¶

Before you apply the EJBCA application, configure the required Helm overrides.

Procedure

Set the EJBCA hostname (required). Specify the FQDN that users will use to access EJBCA externally:
```
~(keystone_admin)]$ system helm-override-update ejbca ejbca ejbca \
    --set ejbca.hostname=<ejbca.example.com>
```
Note

In a lab environment where a DNS server is not available:
- To access the EJBCA service by hostname from inside the StarlingX system, add a record to the DNS service to resolve the EJBCA hostname to the OAM floating IP address:
  ~(keystone_admin)]$ system service-parameter-add dns host-record \ <ejbca.example.com>=<ejbca.example.com>,<OAM_floating_IP>
- To access the EJBCA service by hostname from outside the StarlingX system, add an entry to the /etc/hosts file on the machine from which the EJBCA access is initiated:
  <OAM_floating_IP> <ejbca.example.com>
(Optional) Specify the PostgreSQL storage class. By default, the application uses the cluster’s default StorageClass (for example, ceph-rbd on systems with Ceph). If the cluster does not define a default StorageClass, specify one explicitly:
```
~(keystone_admin)]$ system helm-override-update ejbca ejbca-pg-cluster ejbca \
    --set postgresql.storageClass=<your-storage-class>
```
In a laboratory environment without Ceph, install and use a local-path provisioner:
```
~(keystone_admin)]$ kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
~(keystone_admin)]$ kubectl get storageclass
~(keystone_admin)]$ system helm-override-update ejbca ejbca-pg-cluster ejbca \
    --set postgresql.storageClass=local-path
```
Note
- The platform rejects the apply operation if the specified storageClass override does not exist in the cluster.
- If you do not specify a StorageClass and the cluster does not have a default StorageClass, the platform rejects the apply operation and prompts you to provide one.
- If the cluster has a default StorageClass and you do not specify an override, the platform automatically uses the default StorageClass.

Apply the application:

~(keystone_admin)]$ system application-apply ejbca

If you do not set the hostname override, the platform rejects the apply with an error message:

Application-apply rejected: ejbca: required helm override 'ejbca.hostname'
is not set. Set it before applying the app:
system helm-override-update ejbca ejbca ejbca --set ejbca.hostname=<ejbca.example.com>

Verify the application status:

~(keystone_admin)]$ system application-show ejbca
~(keystone_admin)]$ kubectl get pods -n ejbca

Remove the EJBCA Application ¶

Use this operation to stop the EJBCA application while preserving all application data. You can reapply the application at any time.

~(keystone_admin)]$ system application-remove ejbca

After you remove the application:

The ejbca namespace, PVCs, PostgreSQL cluster, secrets, certificates, keys, and configuration remain intact.
Cluster-scoped resources (CertificateRequestPolicy, ClusterRoles, ClusterRoleBindings) are also preserved.
The application returns to the uploaded state, ready to reapplied.

Delete the EJBCA Application ¶

Use this operation to completely remove the EJBCA application and all its data from the platform.

Note

Unlike the remove operation, this operation is irreversible. Ensure you have a backup of CA keys, certificates, and PKI data before proceeding.

~(keystone_admin)]$ system application-delete ejbca

This operation:

Deletes the ejbca namespace, including PVCs, the database, and secrets.
Removes cluster-scoped resources (CertificateRequestPolicy, ClusterRoles, ClusterRoleBindings).
Unregisters the application from the platform.

Update the EJBCA Application ¶

Procedure

Update the application to a new version:
```
~(keystone_admin)]$ system application-update /path/to/ejbca-<new-version>.tgz
```
The update preserves all existing configuration and PKI data, including user helm overrides, and performs a rolling update of pods.

Monitor the update progress:

~(keystone_admin)]$ system application-show ejbca
~(keystone_admin)]$ kubectl rollout status deployment -n ejbca

Note

Use the application-update command for all application version changes. The platform does not provide an application-upgrade command. Platform upgrades can automatically update the application if the application metadata specifies auto_update: true.

Related Information