Kubernetes Deployment

To deploy the solution using Kubernetes, you will require a compatible platform, for example:

Amazon Web Services (AWS) Elastic Kubernetes Service (EKS)
Microsoft Azure Kubernetes Service (AKS)
Red Hat OpenShift
MiniKube

For deployment you may require permissions to create Cluster Roles. Support for this is out of the scope of the product.

Support for setting up Ingress providers (e.g. NGINX ingress) and HTTPS certificates (e.g. cert-manager/kcert to provide Lets encrypt certificates) is out of the scope of the product.

Before we start

Remember that eSign Portal requires a database. Ensure that a database instance is already available before starting this guide.
(eSign Portal will be able to deploy the required database table, and other resources, on the first run)

To be able to use Helm you will need to install at least Helm 3.8.0 and you may need to enable the OCI support flag.

export HELM_EXPERIMENTAL_OCI=1

You will also need to login with your registry credentials (i.e. the same ones you use to connect to the Docker registry):

helm registry login -u <USERNAME> -p <PASSWORD> esigncelfocus.azurecr.io/helm

Deployment

Retrieve helm chart

To install the eSign Portal chart just issue the following helm command:

helm upgrade --install oci://esigncelfocus.azurecr.io/helm/esignportal -n <namespace> (1)

1	If you are not installing to a specific namespace, either omit the "-n <namespace>" part or replace <namespace> with "default" (without commas)

This will install the latest version of the eSign Portal container using internal H2 databases and, with the default values, is not suitable for anything other that local development.

By default both deployments and statefulsets will be scaled down to 0 replicas. You will need to scale up either one or the other to the required number of replicas.

Configure your deployment

This chart supports changing values using the normal helm procedures:

helm upgrade --install oci://esigncelfocus.azurecr.io/helm/esignportal --set name=value (1)

1	You can set multiple key/pair values by using multiple --set arguments, the right-most value for a given key will be the version used.

helm upgrade --install oci://esigncelfocus.azurecr.io/helm/esignportal -f overrides.yaml (1)

1	You can pass multiple override files by using multiple -f/--values arguments, the right-most set (which contains the same key) will be the version used.

Configurations

Below are the list of all available configurations in the helm chart.
Use these configurations to create your own overrides.yaml file used when overriding the default configurations as stated above.

eSign Portal Configurations

These configurations must be overridden, otherwise the solution will no work properly.

Table 1. eSign Portal variables
Name	Description	Default Value
conf.esignportal.db.uam.url	JDBC connection to the UAM database	h2:mem:uam
conf.esignportal.db.uam.driverClassName	JDBC driver	org.h2.Driver
conf.esignportal.server.url	URL to the eSign Server instance

Table 2. eSign Portal secrets
Name	Description	Default Value
secret.credential.adminUser	Administrator username (auto-generated on first launch)	admin
secret.credential.adminPassword	Administrator password (auto-generated on first launch)	admin
secret.credential.uamJdbcUser	Username to access the UAM database	sa
secret.credential.uamJdbcPassword	Password to access the UAM database
secret.credential.esignServerUser	Username used to call eSign Server REST API	admin
secret.credential.esignServerPassword	Password used to call eSign Server REST API	admin

Container & Image Configurations

Configure access to eSign Portal image and required credencials to access the containter registry.

Table 3. Container secrets
Name	Description	Default Value
secret.container.name	Container repository	esigncelfocus.azurecr.io
secret.container.user	Container repository user name
secret.container.password	Container repository user password
secret.container.email	Container repository user email

Table 4. Image variables
Name	Description	Default Value
image.repository	Image repository	esigncelfocus.azurecr.io/esign-portal
image.tag	Image tag	1.0.0
image.pullPolicy	Pull Policy	IfNotPresent

Deployment Configurations

Deployment related configuration are available with the configuration below:

Table 5. Deployment variables
Name	Description	Value
app.stateless.replicaCount	Deployment replica count	0
app.updateStrategy	Update strategy	RollingUpdate
app.restartPolicy	Restart policy	Always
app.antiAffinity	Anti Affinity
app.revisionHistoryLimit	Revision History Limit	10
app.terminationGracePeriodSeconds	Termination Grace Period (s)	60

Ingress Configurations

By default the helm chart creates an ingress entry with the default rules for eSign Portal.

If your balancing rules are enforced base on a different approach, change ingress.enabled to false.

Unless you don’t plan to access the container using Ingress rules, please make sure to edit these values accordingly.

Table 6. Ingress variables
Name	Description	Default Value
ingress.enabled	Whether or not the ingress should be created	true
ingress.class	Ingress class	nginx
ingress.rewriteTarget	Rewrite target
ingress.maxBodySize	Maximum body size
ingress.forceHTTPSResponse	Whether or not to force HTTPS responses	true
ingress.proxyNextUpstream	Whether or not to call the next Proxy Upstream
ingress.hosts	Hosts	["esignportal.loc"]
ingress.tls.enabled	Whether or not TLS is enabled	false
ingress.tls.issuer	TLS issuer
ingress.tls.secretName	TLS secret name	esignportal-tls
ingress.paths	Ingress paths	["/"]
ingress.altPathsEnabled	Whether or not alternate ingress paths are enabled	false
ingress.altPaths	Alternate ingress paths	[]

Service Configurations

By default the helm chart creates service for the eSign Portal application, bellow are the available configurations

Table 7. Service variables
Name	Description	Value
service.httpProtocol	HTTP protocol	http
service.httpExternalPort	HTTP external port	9000
service.httpInternalPort	HTTP internal Port	9000
service.readinessProbe.enabled	Whether or not the readiness probe is enabled	false
service.readinessProbe.initialDelaySeconds	Initial delay, in seconds, for the readiness probe	15
service.readinessProbe.periodSeconds	Period, in seconds, between probe runs	30
service.readinessProbe.timeoutSeconds	Timeout, in seconds, to wait for a probe result	5
service.readinessProbe.successThreshold	Number of successes to consider before marking the container as ready	1
service.readinessProbe.failureThreshold	Number of consecutive failures before marking the container as not ready	3
service.livenessProbe.enabled	Whether or not the liveness probe is enabled	false
service.livenessProbe.initialDelaySeconds	Initial delay, in seconds, for the liveness probe	15
service.livenessProbe.periodSeconds	Period, in seconds, between probe runs	30
service.livenessProbe.timeoutSeconds	Timeout, in seconds, to wait for a probe result	5
service.livenessProbe.successThreshold	Number of successes to consider before marking the container as alive	1
service.livenessProbe.failureThreshold	Number of consecutive failures before killing the container	3
service.startupProbe.enabled	Whether or not the startup probe is enabled	false
service.startupProbe.initialDelaySeconds	Initial delay, in seconds, for the startup probe	15
service.startupProbe.periodSeconds	Period, in seconds, between probe runs	10
service.startupProbe.timeoutSeconds	Timeout, in seconds, to wait for a probe result	5
service.startupProbe.successThreshold	Number of successes to consider before marking the container as started	1
service.startupProbe.failureThreshold	Number of consecutive failures before killing the container	20

Please remember that failing a liveness probe check (for the number of consecutive times defined) will kill and soft restart your container. Under load situations the probe may take longer to respond than normal, so remember do adjust the timeouts accordingly.

Resource Configurations

You can impose limits over the resource usage, bellow are the available configurations:

Table 8. Resources variables
Name	Description	Default Value
resources.enabled	Whether or not the container has resource limitations	true
resources.requests.cpu	Requested vCPUs	500m
resources.requests.memory	Requested memory	256Mi
resources.limits.cpu	Limit for vCPU usage	1
resources.limits.memory	Limit for memory usage	512Mi