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:

1. 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

2. 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

3. 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

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

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

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

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

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

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

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.