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.

or

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.

Environment Configurations

Base Configurations

These are the base variables required to configure eSign Portal:

Env Variable Name Mandatory Description Default Value

ESIGN_ADMIN_USERNAME

false

Username of the administrator user

admin

ESIGN_ADMIN_PASSWORD

false

Password of the administrator user (this is only applied the first time the eSign Portal is installed)

admin

ESIGN_UAM_DB_DRIVER

true

JDBC driver used to connect to the UAM database (ex: org.postgresql.Driver)

org.h2.Driver

ESIGN_UAM_DB_URL

true

JDBC connection to access the database

jdbc:h2:mem:uam

ESIGN_UAM_DB_USERNAME

true

User used to connect to the database

sa

ESIGN_UAM_DB_PASSWORD

true

Password used to connect to the database

<empty>

eSign Server Connectivity

These are the required variables to configure connectivity with eSign Server:

Env Variable Name Mandatory Description Default Value

ESIGN_SERVER_URL

true

Hostname where the eSign Server instance is running (do not include /eSignServer)

<null>

ESIGN_SERVER_USERNAME

true

Username used to authenticate in the eSign Server instance (the user most be previously configured in the eSign Server instance)

<null>

ESIGN_SERVER_PASSWORD

true

password used to authenticate in the eSign Server instance

<null>

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.

Environment Variables

eSign Portal helm chart allows you to add environment variables.

These environment variables can help you create configurations that can vary between environments.

Environment variables can be kept in plain text or within kubernetes secrets.

Plain text variables

Below is an example of how to add two environment variables:

env:
  custom:
    - name: MY_VAR_1
      value: my_value_1
    - name: MY_VAR_2
      value: my_value_2

Secret variables

This helm chart creates a secret called esign-portal-credentials where you can add your secret entries.

If the values to pass as environment variables are sensitive (for instance a password), you can use a special configuration of this helm chart that will automatically add a new entry to the credentials secret and refer to it.

Below is an example of how to custom environment variables stored in a secret:

env:
  customFromCredentialSecret:
    - name: MY_SECRET_VAR_1 (1)
      key: mySecretKey (2)
      value: mySecretValue (3)
1 The name of the environment variable
2 The name of the key added to the esign-portal-credentials secret
3 The value stored in the secret with the key mentioned above
Bring your own secret

It is possible to use your own secret store instead of the automatically created one, to do so:

  • Disable automatic secret creation with secret.credentials.create: true

  • Change value of secret.credentials.name to be the name of your own secret

This will make eSign Portal use your own secure variables stored in your secret.

Note that if you disable automatic secret creation it is up to you to create the required secret entries.

Container & Image Configurations

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

Table 1. 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 2. Image variables
Name Description Default Value

image.repository

Image repository

esigncelfocus.azurecr.io/esign-portal

image.tag

Image tag

1.1.0

image.pullPolicy

Pull Policy

IfNotPresent

Deployment Configurations

Deployment related configuration are available with the configuration below:

Table 3. Deployment variables
Name Description Value

app.stateless.replicaCount

Deployment replica count

1

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 4. 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 5. 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 6. 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

Example of an override.yaml

Below is an example of a heml chart override (overrides.yaml) configured to integrate with an existing eSign Server instance, and to use a postgres database.

conf:
env:
  custom:
    - name: ESIGN_UAM_DB_DRIVER
      value: org.postgresql.Driver (1)
    - name: ESIGN_SERVER_URL
      value: https://my-esign.com (2)
  customFromCredentialSecret:
    - name: ESIGN_ADMIN_PASSWORD
      key: adminPassword
      value: my-admin-pass (3)
    - name: ESIGN_UAM_DB_URL
      key: dbUamUrl
      value: jdbc:postgresql://localhost:5432/esign (4)
    - name: ESIGN_UAM_DB_USERNAME
      key: dbUamUsername
      value: uam (5)
    - name: ESIGN_UAM_DB_PASSWORD
      key: dbUamPassword
      value: uamPassword (6)
    - name: ESIGN_SERVER_USERNAME
      key: eSignServerUsername
      value: esign (7)
    - name: ESIGN_SERVER_PASSWORD
      key: eSignServerPassword
      value: esignPassword (8)
1 Driver to access eSign Portal UAM DB
2 Hostname of eSign Server
3 eSign Portal admin password (stored in a secret with key 'adminPassword')
4 JDBC connection to UAM DB (stored in a secret with key 'dbUamUrl')
5 Username to UAM DB (stored in a secret with key 'dbUamUsername')
6 Password to UAM DB (stored in a secret with key 'dbUamPassword')
7 Username to access eSign Server (stored in a secret with key 'eSignServerUsername')
8 Password to access eSign Server (stored in a secret with key 'eSignServerPassword')