Version: 1.3.2

Kubernetes deployment

Prerequisites

Kubernetes

Kubernetes 1.14+
Helm 3.1.0+
(optional: PersistentVolume (PV) provisioner support in the underlying infrastructure - if job metadata are stored in the MariaDB)
(optional: sealed secrets )

Container Image Access

Because the images used in this chart are from a private container registry you need to have

access to the container registry registry.jadice.com
OR access to a proxy registry of registry.jadice.com

Since the used Helm charts come from a private container registry, they also require

access to the helm registry artifacts.jadice.com

For details see image pull secrets.

Installing the Chart

On this page we showcase how to install a jadice flow product via its corresponding Helm Chart.

Download Helm Chart

There is the option to download a Helm Chart with the command:

$ helm pull levigo/jf-ocr-bundle

Install from jadice helm repository

In this case our release name will be my-release:

$ helm repo add levigo https://artifacts.jadice.com/repository/helm-charts/ --username <username>
Password: <enter your password>
$ helm install my-release levigo/jf-ocr-bundle

These commands deploy the OCR (optical character recognition) product (described here as an example product) on the Kubernetes cluster with the default configuration.

The first command adds a Helm repository to your repositories. You now have access to the Helm chart in your helm cli. The second command install the chart with the release name my-release.

Detailed instructions for products can be found in the products section. The configuration section lists the parameters that can be configured - in this case for the ocr product.

Tip: Show all installed (deployed) releases using helm list

Uninstalling the Chart

To uninstall and delete the deployment you can execute the command:

$ helm uninstall my-release

This command removes all the Kubernetes components associated with the chart and deletes the Helm release.

Parameters

Required Parameters

By default, the jadice flow products use the eureka storage backend and an embedded H2 database. This means only the access to the jadice container registry must be configured as described below.

On how-to replace eureka with S3 or WebDAV see in the optional parameters section and secrets and if you don't want to use the embedded H2 database follow the instructions in database.

Image pull secrets

To access the container registry with the jadice flow images you have the following three options:

provide the name of an existing Kubernetes registry-secret via jadiceFlow.image.pullSecrets.

For instructions on how to create a Kubernetes docker-registry secret check out the Documentation or the output of kubectl create secret docker-registry --help
provide the credentials to the registry via the following parameters:

Parameter	Description	Default
`secrets.imageRegistry.server`	server of the container Registry	`registry.jadice.com`
`secrets.imageRegistry.username`	username for the container Registry	`nil`
`secrets.imageRegistry.password`	password for the container Registry	`nil`

For sealed secrets, you can encrypt the content of a ~/.docker/config.json file as a String and provide this as the value for the parameter secrets.imageRegistry.dockerconfigjson.

To create this String you could run the following command:
```
kubectl create secret docker-registry registry-secret \
  --docker-username=<user> \
  --docker-password=<password> \
  --docker-server=registry.jadice.com \
  --dry-run=client -o json | jq -r '.data[".dockerconfigjson"]' | base64 -d | kubeseal --raw --from-file=/dev/stdin --namespace <namespace> --name registry-secret
```
Note:
- requires jq and kubeseal
- replace <user>, <password>, <namespace> with the respective values.

Optional Parameters

Global Parameters

These values can be defined globally, overwriting the values defined for each component, including the MariaDB chart.

Parameter	Description	Default
`global.imageRegistry`	Global Docker image registry	`nil`
`global.imagePullSecrets`	Global Docker registry secret names as an array	`[]` (does not add image pull secrets to deployed pods)
`global.storageClass`	Global storage class for dynamic provisioning	`nil`
`global.jadiceFlow.storageType`	Define what type of storage to use ("eureka","s3","webdav").	`eureka`

jadiceFlow

These parameters configure all jadice flow components but not the MariaDB. They overwrite the component-specific parameters for "jf-controller" and "jfWorker".

Parameter	Description	Default
`jadiceFlow.serviceAccount.create`	Sets whether a ServiceAccount name shall be created automatically	`true`
`jadiceFlow.serviceAccount.name`	If not set and jadiceFlow.serviceAccount.create is true, a name is generated using the filename template	`nil`
`jadiceFlow.serviceAccount.annotations`	Additional annotations for configuring the ServiceAccount	`nil`

secrets

If you want to use your own storage or database, you can provide the credentials via the following values.

The charts also support the use of Sealed Secrets instead of regular Kubernetes secrets. Simply set secrets.useSealedSecrets to true and use the encrypted values for the parameters below.

Parameter	Description	Default
`secrets.useSealedSecrets`	usage of sealed secretes	`false`
`secrets.controller.accessToken`	the jadice flow access token	`nil`
`secrets.controller.database.password`	the controller DB password	`nil`
`secrets.controller.database.username`	the controller DB username	`nil`
`secrets.s3.bucket`	the S3 bucket	`nil`
`secrets.s3.endpoint`	the URL of the S3 server	`nil`
`secrets.s3.accessKey`	the S3 access key	`nil`
`secrets.s3.secretKey`	the S3 secret key	`nil`
`secrets.s3.protocol`	HTTP or HTTPS	`https`
`secrets.webdav.endpoint`	the URL of the WebDAV server	`nil`
`secrets.webdav.username`	the username for the WebDAV server	`nil`
`secrets.webdav.password`	the password for the WebDAV server	`nil`
`secrets.webdav.outputPath`	the WebDAV path where the result are put	`nil`
`secrets.eureka.username`	the username for the eureka server	`nil`
`secrets.eureka.password`	the password for the eureka server	`nil`

jf-controller

These parameters configure the jadice flow controller component.

Parameter	Description	Default
`jf-controller.image.registry`	jf container registry	`registry.jadice.com`
`jf-controller.image.repository`	image name	`jf-controller`
`jf-controller.image.tag`	image tag	`1.0.0`
`jf-controller.image.pullPolicy`	image pull policy	`IfNotPresent`
`jf-controller.ingress.enabled`	Enable / Disable the ingress for the jf-controller service. In order for this service to work user access is needed, hence some kind of access for an operator has to be provided.	`true`
`jf-controller.ingress.annotations`	Additional annotations for configuring the ingress (in this case an nginx ingress).	Depends on the specific ingress implementation.
`jf-controller.ingress.hosts`	The hostname of the jf-controller service and eventual path rewrites. In this case most likely on the hostname has to be adjusted to the new stack.	Desired hostname
`jf-controller.ingress.tls`	For configuring the corresponding TLS secrets of the previously defined hostnames.	Related tls secrets for the previous hostnames
`jf-controller.ingress.className`	The ingress class name.	`nil`
`jf-controller.jobtemplatesConfigMap`	use this ConfigMap instead of the default 'jobtemplates.yaml'	`nil`
`jf-controller.workersConfigMap`	use this ConfigMap instead of the default 'workers.yaml'	`nil`
`jf-controller.concurrentWorkerInvocationsPerType`	set concurrent worker invocations per type	`1`
`jf-controller.concurrentJobCount`	set concurrent job count	`4`

If you want access the bundle from outside the cluster you can define Ingress resources that could look like this:

Ingress Example

jf-controller:
 ingress:
   enabled: true
   className: "nginx"
   annotations:
     cert-manager.io/cluster-issuer: letsencrypt-prod
     nginx.ingress.kubernetes.io/configuration-snippet: |
       server_tokens off;
       location /actuator {
         deny all;
         return 403;
       }
   hosts:
     - host: jf-controller.acme.com
       paths:
         - path: /
           pathType: Prefix
   tls:
     - secretName: jf-controller.acme.com
       hosts:
         - jf-controller.acme.com

Keep in mind this is only an example making certain assumptions. E.g. this assumes you are using Cert Manager and have defined a cluster-issuer with the name of letsencrypt-prod. For more information on Cert Manager and how to create a certificate, see Certificate. It also hides the actuator endpoints from external access. Depending on your monitoring solution this may not be feasible.

jf-worker

All workers support the following parameters. Worker specific parameters are described in the worker section.

worker example: jf-worker-tessocr:

Parameter	Description	Default
`jf-worker-tessocr.image.registry`	jf container registry	`registry.jadice.com`
`jf-worker-tessocr.image.repository`	image name	`jf-worker-tessocr`
`jf-worker-tessocr.image.tag`	image tag	`1.0.0`
`jf-worker-tessocr.image.pullPolicy`	image pull policy	`IfNotPresent`
`jf-worker-tessocr.replicaCount`	Number of replicas to start	`1`
`jf-worker-tessocr.worker.monitoring.enabled`	Enable Prometheus monitoring	`false`
`jf-worker-tessocr.worker.tracing.enabled`	Enable Jaeger tracing	`false`

Database

The default database is an embedded H2-Database. If required, jadice flow controller can be configured to use a different database. To use an existing external database set these parameters:

Parameter	Description	Default
`secrets.controller.database.password`	the controller DB password	`nil`
`secrets.controller.database.username`	the controller DB username	`nil`
`jf-controller.datasource.jdbcUrl`	example: "jdbc:mariadb://mariadb/jadice-flow-db"	`nil`

Data Storage

The default data store for job results is a eureka service, but other types like S3 and WebDAV are also supported. It requires zero configuration for test installations. It's also possible to enabling persistence and configuring other storage backends.

By default, the expiration time of saved job results is 3 minutes. The expiryTimeMinutes can be configured in the values.yaml:

eureka:
     storage:
       ehcache:
   #      enabled: true
   #      rootPath: ${user.dir}/neverpile-eureka_default
   #      heapEntries: 500
   #      diskSize: 1024
   expiryTimeMinutes: 5

Sample values.yaml configuration

A minimal values.yaml containing only the necessary parameters:

minimal-values.yaml

secrets:
   imageRegistry:
      server: registry.jadice.com
      username: <username>
      password: <password>

Further customization options, as well as the default values file can be found in the repository in the values.yaml, as well as in the products section or the README.md of the respective product.

$ helm pull "levigo/jf-ocr-bundle" --untar
$ cat jf-ocr-bundle/README.md

Validate Installation with Postman

To validate your deployment you can use the Postman collection jadice-flow tutorial ocr.postman_collection.json that is part of this Helm chart. For instructions on how to import a collection see Importing data into Postman.

After you have imported the collection you need to create a variable JF_CONTROLLER_URL pointing to your jf-controller (e.g. https://jf-controller.email.acme.com) and add your access token as a Bearer Token to the collection. Information about the jadice flow REST-API can be found here.

Prerequisites​

Kubernetes​

Container Image Access​

Installing the Chart​

Download Helm Chart​

Install from jadice helm repository​

Uninstalling the Chart​

Parameters​

Required Parameters​

Image pull secrets​

Optional Parameters​

Global Parameters​

jadiceFlow​

secrets​

jf-controller​

jf-worker​

Database​

Data Storage​

Sample values.yaml configuration​

Validate Installation with Postman​