WorkflowGen Helm Chart

Overview

This section presents the WorkflowGen Helm chart including usage, configuration options, and examples. Using the WorkflowGen chart simplifies the deployment of WorkflowGen in a Kubernetes cluster by not having to manage many Kubernetes deployment files. You only have to manage one "values" file.

Prerequisites

  • You must have a working Kubernetes cluster with Windows Server 2019 nodes.
  • You must have installed the kubectl command line tool and it must be connected to the cluster.
  • You must have installed the helm command line tool. See the Installing Helm section on the Helm website for instructions on how to install it. Only the Helm version 3.0+ is supported.

Helm chart primer

From the Helm website:
A chart is a collection of files that describe a related set of Kubernetes resources.
These resources are written in YAML in the chart with the help of the Go templating language. This enables the chart to generate valid Kubernetes resource definition files based on values provided by the user of the chart. Therefore, when you use the chart to install or upgrade WorkflowGen, you can provide some values that will help you deploy the correct resources for WorkflowGen.
A chart has a manifest file called Chart.yaml. It has a version for the chart and a version for the application. For example, the chart version of WorkflowGen could be 0.0.3 and its application version 7.18.3. A chart also has a kubeVersion that tells which versions of Kubernetes are supported. In the case of WorkflowGen, only versions 1.14 and higher are supported since it is the first version to include Windows containers support.
You install a chart using the command line. For example:
1
helm install --set image.tag=7.15.5-win-ltsc2019 release-name ./chart-path
Copied!
This will install the chart that is at the path ./chart-path in the cluster with the release name release-name. It also sets a the value image.tag to 7.15.5-win-ltsc2019. More information about the install command including its --set parameter can be found in Helm Install on the Helm website.
While useful for a few parameters, setting values from the command line can be cumbersome and prone to errors, which is why you can also set values from a YAML or JSON file. The first thing you need to do is to create the file:
YAML
JSON
1
image:
2
tag: 7.15.5-win-ltsc2019
Copied!
1
{
2
"image": {
3
"tag": "7.15.5-win-ltsc2019"
4
}
5
}
Copied!
Then, you can pass that file to the install command:
1
# YAML
2
helm install --set-file ./my-values.yaml release-name ./chart-path
3
4
# JSON
5
helm install --set-file ./my-values.json release-name ./chart-path
Copied!

WorkflowGen values

The following are all of the value names supported by the WorkflowGen chart and their default values. They are accompanied by a brief description.
1
# Default values for WorkflowGen.
2
# This is a YAML-formatted file.
3
# Declare variables to be passed into your templates.
4
5
# replicaCount Number of replicas to create per deployment of WorkflowGen. Doesn't impact database.
6
replicaCount: 1
7
# scalable Deploy WorkflowGen and its database in a scalable architecture.
8
scalable: true
9
# tenantName For multi-tenancy, it is recommended to populate this value in a multi-tenant architecture. This name will be put as a prefix for resources' name and the label "workflowgen.com/tenant: tenantName" will be added as a selector label.
10
tenantName: ""
11
12
# workflowgen Configuration related to the WorkflowGen pod.
13
workflowgen:
14
# image Configuration related to the image to be used for the WorkflowGen pod.
15
image:
16
# repository The repository to use to pull the image.
17
repository: advantys/workflowgen
18
# tag The image tag to use.
19
tag: ""
20
# pullPolicy The pull policy to adopt for this image.
21
pullPolicy: Always
22
# nameOverride Override the name of the chart.
23
nameOverride: ""
24
# fullnameOverride Override the name of the WorkflowGen deployment. It is based on the name by default.
25
fullnameOverride: ""
26
# runtimeClassName Runtime class to use with the deployment.
27
runtimeClassName: ""
28
# strategy The update strategy for the WorkflowGen deployment.
29
strategy:
30
type: Recreate
31
# nodeSelector Node selectors to use for the WorkflowGen pod. WorkflowGen only works on Windows Server.
32
nodeSelector:
33
kubernetes.io/os: windows
34
# annotations Annotations to attach to the WorkflowGen deployment. You can attach annotations to the deployment itself or its template.
35
annotations: {}
36
# deployment: {}
37
# template: {}
38
# tolerations Tolerations to apply to the WorkflowGen pod.
39
tolerations: []
40
# affinity Affinities to apply to the WorkflowGen pod.
41
affinity: {}
42
# createConfigMap Create a ConfigMap for WorkflowGen's configuration.
43
createConfigMap: true
44
# configMapNameOverride Override the name of WorkflowGen's ConfigMap.
45
configMapNameOverride: ""
46
# config The configuration to put in the ConfigMap.
47
config: {}
48
# createSecret Create a Secret for WorkflowGen's secret values.
49
createSecret: true
50
# secretNameOverride Override the name of WorkflowGen's Secret.
51
secretNameOverride: ""
52
# secretMountPath The mount path inside WorkflowGen's containers where to put the secret files.
53
secretMountPath: C:\secrets
54
# secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
55
secret: {}
56
# license Configuration related to WorkflowGen's license.
57
license:
58
# volumeNameOverride Override the name of the license's volume.
59
volumeNameOverride: ""
60
# secretName The name of the secret that contains WorkfowGen's license.
61
secretName: ""
62
# items The specific items to use from the secret to inject in WorkflowGen's containers.
63
items: []
64
# - key: ""
65
# path: ""
66
# createDataPvc Create a PersistentVolumeClaim for the data volume of WorkflowGen.
67
createDataPvc: true
68
# dataPvcNameOverride Override the name of data's PersistentVolumeClaim.
69
dataPvcNameOverride: ""
70
# dataVolumeNameOverride Override the volume name associated to the PersistentVolumeClaim.
71
dataVolumeNameOverride: ""
72
# dataPvcSpec The data PersistentVolumeClaim specifications.
73
dataPvcSpec: {}
74
# accessModes:
75
# - ReadWriteMany
76
# storageClassName: storageclass
77
# resources:
78
# requests:
79
# storage: 4Gi
80
# additionalVolumes Additional volumes to attach to WorkflowGen's deployment.
81
additionalVolumes: []
82
# additionalVolumeMounts Additional volumes to mount in WorkflowGen's container.
83
additionalVolumeMounts: []
84
# podSecurityContext The security context of the pod.
85
podSecurityContext: {}
86
# fsGroup: 2000
87
# securityContext The security context of WorkflowGen's container.
88
securityContext: {}
89
# capabilities:
90
# drop:
91
# - ALL
92
# readOnlyRootFilesystem: true
93
# runAsNonRoot: true
94
# runAsUser: 1000
95
# runAsUserName: ContainerUser
96
# resources Configuration related to the resources of the container.
97
resources: {}
98
# limits:
99
# cpu: '1'
100
# memory: 2Gi
101
# requests:
102
# cpu: '1'
103
# memory: 2Gi
104
# service Configuration related to the service associated with WorkflowGen's deployment.
105
service:
106
# type The type of the service.
107
type: ClusterIP
108
# port The port exposed from the service.
109
port: 80
110
# clusterIP The cluster IP address to use.
111
clusterIP: ""
112
113
# winServices Configuration related to WorkflowGen's Windows Services deployment. Ignored when release not scalable.
114
winServices:
115
# nameOverride Override the chart name of this deployment.
116
nameOverride: ""
117
# runtimeClassName Runtime class to use with the deployment.
118
runtimeClassName: ""
119
# nodeSelector Node selectors to use for the WorkflowGen Windows Services pod. WorkflowGen only works on Windows Server.
120
nodeSelector:
121
kubernetes.io/os: windows
122
# annotations Annotations to attach to the WorkflowGen Windows services deployment.
123
annotations: {}
124
# fullnameOverride Override the name of the Windows services deployment.
125
fullnameOverride: ""
126
# tolerations Tolerations to apply to the WorkflowGen Windows services pod.
127
tolerations: []
128
# affinity Affinities to apply to the WorkflowGen Windows services pod.
129
affinity: {}
130
# podSecurityContext The security context of the pod.
131
podSecurityContext: {}
132
# fsGroup: 2000
133
# dirSync Configuration related to the directory synchronization Windows service container.
134
dirSync:
135
# securityContext The security context of the directory synchronization Windows service container.
136
securityContext: {}
137
# capabilities:
138
# drop:
139
# - ALL
140
# readOnlyRootFilesystem: true
141
# runAsNonRoot: true
142
# runAsUser: 1000
143
# runAsUserName: ContainerUser
144
# resources Configuration related to the resources of the container.
145
resources: {}
146
# limits:
147
# cpu: '1'
148
# memory: 2Gi
149
# requests:
150
# cpu: '1'
151
# memory: 2Gi
152
# engine Configuration related to the engine Windows service container.
153
engine:
154
# securityContext The security context of the engine Windows service container.
155
securityContext: {}
156
# capabilities:
157
# drop:
158
# - ALL
159
# readOnlyRootFilesystem: true
160
# runAsNonRoot: true
161
# runAsUser: 1000
162
# runAsUserName: ContainerUser
163
# resources Configuration related to the resources of the container.
164
resources: {}
165
# limits:
166
# cpu: '1'
167
# memory: 2Gi
168
# requests:
169
# cpu: '1'
170
# memory: 2Gi
171
172
# database Configuration related to the database deployment.
173
database:
174
# image Configuration related to the image to be used for the database pod.
175
image:
176
# repository The repository to use to pull the image.
177
repository: advantys/workflowgen-sql
178
# tag The image tag to use.
179
tag: ""
180
# pullPolicy The pull policy to adopt for this image.
181
pullPolicy: Always
182
# create Create a database deployment to be used with the WorkflowGen deployment.
183
create: true
184
# createConfigMap Create a ConfigMap for the database configuration.
185
createConfigMap: true
186
# configMapNameOverride Override the name of the database ConfigMap.
187
configMapNameOverride: ""
188
# config The configuration to put in the ConfigMap.
189
config: {}
190
# createSecret Create a Secret for the database secret values.
191
createSecret: true
192
# secretNameOverride Override the name of the database Secret.
193
secretNameOverride: ""
194
# secretMountPath The mount path inside the database container where to put the secret files.
195
secretMountPath: /mnt/secrets
196
# secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
197
secret: {}
198
# useEnv Indicates to use additional environement variables.
199
useEnv: false
200
# env Definition of the environment variables.
201
env: []
202
# - name: test
203
# value: value
204
# - name: test2
205
# valueFrom:
206
# secretKeyRef:
207
# key: test-key
208
# name: secret-name
209
# For MSSQL Linux, you may want to put this here or in the config section:
210
# - name: MSSQL_PID
211
# value: Express # You can replace with the edition you want: "Enterprise" or "Developer" or "Express"
212
# fullnameOverride Override the name of the database deployment.
213
fullnameOverride: ""
214
# nameOverride Override the chart name of this deployment.
215
nameOverride: ""
216
# args The arguments to pass to the database container.
217
args: []
218
# tolerations Tolerations to apply to the database pod.
219
tolerations: []
220
# affinity Affinities to apply to the database pod.
221
affinity: {}
222
# runtimeClassName Runtime class to use with the stateful set.
223
runtimeClassName: ""
224
# nodeSelector Node selectors to use for the database pod.
225
nodeSelector: {}
226
# kubernetes.io/os: linux
227
# annotations Annotations to attach to the database deployment. You can add annotations for the StatefulSet or its template.
228
annotations: {}
229
# statefulset: {}
230
# template: {}
231
# podSecurityContext The security context of the pod.
232
podSecurityContext: {}
233
# fsGroup: 2000
234
# securityContext The security context of the database container.
235
securityContext: {}
236
# capabilities:
237
# drop:
238
# - ALL
239
# readOnlyRootFilesystem: true
240
# runAsNonRoot: true
241
# runAsUser: 1000
242
# runAsUserName: ContainerUser
243
# With MSSQL, you may want to use the mssql (10001) account
244
# runAsUser: 10001
245
# runAsGroup: 0
246
# If you can't configure the volumes with the correct permissions for mssql, you may want to run the container as root:
247
# runAsUser: 0
248
# runAsGroup: 0
249
# resources Configuration related to the resources of the container.
250
resources: {}
251
# limits:
252
# cpu: '1'
253
# memory: 2Gi
254
# requests:
255
# cpu: '1'
256
# memory: 2Gi
257
# volumeClaimTemplateSpec PersistentVolumeClaim specification for the StatefulSet PersistentVolumeClaimTemplate.
258
volumeClaimTemplateSpec: {}
259
# accessModes:
260
# - ReadWriteOnce
261
# storageClassName: default
262
# resources:
263
# requests:
264
# storage: 4Gi
265
# service Configuration related to the database cluster service.
266
service:
267
# type The type of the service.
268
type: ClusterIP
269
# port The port exposed from the service.
270
port: 1433
271
# clusterIP The cluster IP address to use.
272
clusterIP: None
273
274
# imagePullSecrets Secrets to inject in order to pull images from private repositories.
275
imagePullSecrets: []
276
277
# ingress Configuration related to the ingress rules.
278
ingress:
279
# enabled Whether or not to enable the ingress rules defined here.
280
enabled: true
281
# annotations Additional annotations to put on the Ingress object.
282
annotations: {}
283
# kubernetes.io/ingress.class: nginx
284
# cert-manager.io/cluster-issuer: letsencrypt
285
# kubernetes.io/tls-acme: "true"
286
# hosts List of hosts and routes for routing purposes.
287
hosts:
288
- host: chart-example.local
289
paths: []
290
# - host: example
291
# paths: []
292
# tls List of TLS hosts associated with a secret containing the proper TLS certificates.
293
tls: []
294
# - secretName: chart-example-tls
295
# hosts:
296
# - chart-example.local
297
298
# hooks Configuration related to the Helm hooks of this chart
299
hooks:
300
# preupgrade
301
preupgrade:
302
# enabled Enables the use of the pre-upgrade hook which will migrate WorkflowGen's data when upgrading.
303
enabled: true
304
# image Configuration related to the image to be used for the pre-upgrade pod.
305
image:
306
# repository The repository to use to pull the image.
307
repository: advantys/workflowgen-upgrade
308
# tag The image tag to use.
309
tag: ""
310
# args The arguments to pass to the migration container.
311
args: []
312
# env Definition of the environment variables.
313
env: []
314
# - name: test
315
# value: value
316
# - name: test2
317
# valueFrom:
318
# secretKeyRef:
319
# key: test-key
320
# name: secret-name
321
# connectionStringSecretKey The key to pick for the WFGEN_DATABASE_CONNECTION_STRING environment variable. Defaults to WFGEN_DATABASE_CONNECTION_STRING.
322
connectionStringSecretKey: ""
323
# secret The secret values to put in the Secret object for this hook. Values will be automatically endoded in base64.
324
secret: {}
325
# runtimeClassName The name of the RuntimeClass to use with this pod.
326
runtimeClassName: ""
327
# podSecurityContext The security context for the pod specification.
328
podSecurityContext: {}
329
# nodeSelector Node selectors to use for the pre-upgrade pod.
330
nodeSelector:
331
kubernetes.io/os: linux
332
# affinity Affinities to apply to the pre-upgrade pod.
333
affinity: {}
334
# tolerations Tolerations to apply to the pre-upgrade pod.
335
tolerations: []
336
Copied!
The chart is divided in groups of configuration:
  • Global
  • WorkflowGen
  • WorkflowGen Windows services
  • Database
  • Ingress
  • Hooks

Global values

Global values control the overall deployment that results from the Helm generation. For example, the scalable value indicates if the resulting deployment should be scalable or not. If true, the resulting deployment will have a separate pod for the WorkflowGen Windows services that will be deployed using the Singleton deployment pattern. The WorkflowGen web services will be deployed with the number of replicas indicated by the replicaCount global value.If false, WorkflowGen web and Windows services will be deployed in a single pod using the Singleton pattern.
To deploy multiple WorkflowGen instances that must be isolated, the use of the tenantName value is recommended because it will prefix each object created by the installation with the name of the tenant and add a selector label named workflowgen.com/tenant=tenantName.

WorkflowGen & Windows services

The WorkflowGen part groups the configuration options related to the WorkflowGen web and Windows services pods when configuring the WorkflowGen product. For infrastructure-related configuration, configuration options are in separate groups in order to be able to properly deploy each part individually but still having the same WorkflowGen-specific configuration.

WorkflowGen configuration

There are two main ways to configure WorkflowGen with the chart: with the values file or by providing your own ConfigMap or Secret.
Helm
Manual
In your values file, you can use the sub YAML object workflowgen.config and workflowgen.secret to configure WorkflowGen's environment variables. Let's begin with an example:
1
workflowgen:
2
config:
3
WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
4
WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
5
WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
6
WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
7
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
8
secret:
9
WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
10
WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
11
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
Copied!
Each key and value in the config part will be added as in a ConfigMap object and will be used by the WorkflowGen deployments. Concretely, the keys and values of the ConfigMap will be injected as environment variables in WorkflowGen's container. Each value must be of the string type. Therefore, YAML boolean values such as true, yes, and Y will be rejected. Use single or double quotes when needed, as in the example.
For secret values, you can do exactly like the config part. You only have to provide the name of the secret and its concrete value. The chart will add them to a Secret object and encode the value in Base64. The Secret object will then get injected as a volume inside WorkflowGen's container. Each key will become a file with its concrete value written inside it. Therefore, you need a corresponding config value that will tell the container to pick up the value in a specific file using the _FILE suffix. For more information about how to configure WorkflowGen including secrets, see the Configuration page in the WorkflowGen Image section. The default location of the secrets inside the container is C:\secrets. You can customize this path by providing the value workflowgen.secretMountPath.
You also have the option to use your own ConfigMap and Secret objects. Keep in mind that these objects will not be managed by Helm or the WorkflowGen chart. Here's the same example as for the "Helm" method:

Step 1: Create ConfigMap and Secret files

my-configmap.yaml
1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
name: my-configmap
5
data:
6
WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
7
WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
8
WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
9
WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
10
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
Copied!
my-secret.yaml
1
apiVersion: v1
2
kind: Secret
3
metadata:
4
name: my-secret
5
type: Opaque
6
data:
7
WFGEN_DATABASE_CONNECTION_STRING: U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
8
WFGEN_APP_SETTING_ApplicationSerialNumber: TVktV0ZHLUxJQy1OVU1CRVIK
9
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
Copied!
In the case of the secret, you have to encode the values in base64 yourself. For this, you can use the following code sample:
PowerShell
1
using namespace System.Text
2
3
function ConvertTo-Base64String {
4
[CmdletBinding()]
5
[OutputType([string])]
6
param (
7
[Parameter(Mandatory=$true,ValueFromPipeline=$true)]
8
[ValidateNotNullOrEmpty()]
9
[string]$Value
10
)
11
12
process {
13
return [Convert]::ToBase64String([Encoding]::UTF8.GetBytes($Value))
14
}
15
}
16
17
'Server=some.sql.server.com,1433;...' | ConvertTo-Base64String # U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
18
'MY-WFG-LIC-NUMBER' | ConvertTo-Base64String # TVktV0ZHLUxJQy1OVU1CRVIK
19
'1f73c842692f436b92411641c46fb338' | ConvertTo-Base64String # MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
Copied!
Bash
1
echo 'Server=some.sql.server.com,1433;...' | base64 # U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
2
echo 'MY-WFG-LIC-NUMBER' | base64 # TVktV0ZHLUxJQy1OVU1CRVIK
3
echo '1f73c842692f436b92411641c46fb338' | base64 # MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
Copied!

Step 2: Create the objects from the files

Then, you have to deploy the objects by using the following command:
1
kubectl apply -f ./my-configmap.yaml
2
kubectl apply -f ./my-secret.yaml
Copied!

Step 3: Reference the objects' names in the chart

The last step is to reference the objects that you've just deployed in your values file before installing:
my-values.yaml
1
workflowgen:
2
createConfigMap: false
3
configMapNameOverride: my-configmap
4
createSecret: false
5
secretNameOverride: my-secret
Copied!

File storage

The chart generates a PersistentVolumeClaim (PVC) object based on values that you've provided. As with the WorkflowGen configuration, you can specify your own PVC outside of the chart and reference it.
Helm
Manual
In your values file, you can use the sub YAML object workflowgen.dataPvcSpec to configure the PersistentVolumeClaim for WorkflowGen's data (App_Data and wfapps). Let's begin with an example:
1
workflowgen:
2
dataPvcSpec:
3
accessModes:
4
- ReadWriteMany
5
storageClassName: azurefile
6
resources:
7
requests:
8
storage: 50Gi
Copied!
The content of the object is exactly the Kubernetes PersistentVolumeClaim specification. What you write in there will be taken as-is in the object definition.
In this example, the storage class azurefile is specific to Azure Kubernetes Service.
You also have to option to use your own PVC object. Keep in mind that this object will not be managed by Helm or the WorkflowGen chart. Here's an example:

Step 1: Create the PersistentVolumeClaim definition file

my-wfg-pvc.yaml
1
apiVersion: v1
2
kind: PersistentVolumeClaim
3
metadata:
4
name: my-wfg-pvc
5
spec:
6
accessModes:
7
- ReadWriteMany
8
storageClassName: azurefile
9
resources:
10
requests:
11
storage: 50Gi
Copied!

Step 2: Deploy the definition into the cluster

1
kubectl apply -f ./my-wfg-pvc.yaml
Copied!

Step 3: Reference the object in your values

The last step is to reference the objects that you've just deployed in your values file before installing:
1
workflowgen:
2
createDataPvc: false
3
dataPvcNameOverride: my-wfg-pvc
Copied!

License

The license must be stored on the Kubernetes cluster before installing the chart. This is because it's more efficient to store it in a secret and inject it as a volume in the WorkflowGen pods instead of provisioning a file share and connecting it to the pods. For the chart to handle it, you need to specify the secret name where the license is stored and the license item name in the secret. Here's an example:
Step 1: Store your license in the cluster
The secret object must be in the same namespace as the WorkflowGen pods.
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
This command will create a secret named wfgen-license-secret with an item named WFG.lic and its value will be the content of the file.
Step 2: Reference this secret in the values file
1
workflowgen:
2
license:
3
secretName: wfgen-license-secret
4
items:
5
- key: WFG.lic
6
path: WFG.lic
Copied!
For more information about how to inject files from a Secret object into pods, see Secrets in the Kubernetes documentation.

Custom image reference

To use your own WorkflowGen image, you can change the default reference like this:
1
workflowgen:
2
image:
3
reference: mycorporation/workflowgen
4
tag: 7.18.3-win-ltsc2019
Copied!

Service

There is a service that is created by the chart with the WorkflowGen pod for its discovery. By default, the chart will create a ClusterIP service that provides a cluster-wide IP address and domain name that you can reference from anywhere in the cluster. This works best with an Ingress controller to route external traffic to it. For more information about Ingress controllers, see Ingress Controllers in the Kubernetes documentation.
You can customize this to automatically create a load balancer instead by providing the following value:
1
workflowgen:
2
service:
3
kind: LoadBalancer
Copied!
The LoadBalancer type only works with cloud providers. For on-premise clusters, you should use another technique.

Security

There are many security features that are not yet supported or don't work in Windows but do in Linux. It's important to plan the security of the deployments. To know more about unsupported security features on Windows containers in Kubernetes, see Intro to Windows support in Kubernetes (Security section) in the Kubernetes documentation.
The web applications in the WorkflowGen container run as a user that is part of the IIS_IUSRS group. This is important for setting permissions for file storage. If this group doesn't have MODIFY permission on the files volume, the container will fail to write to the volume. Generally, you can set mount options for a persistent volume depending on the storage provider or you can run an init container to set the permissions. For Azure Files, see Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service (AKS) to get the mount options.
There are many more options for customizing your Helm release. The majority of them are dependent on your cluster environment. They are all Kubernetes terms, so you can search for them in a search engine and get useful information. The only one that this section will discuss is resources. The resources YAML object allows you to limit and request resource consumption for a given pod. Requests are to help the scheduler to assign pods to nodes. Limits are to limit the amount of resources the pod can use. The following requests and limits are known to work well for WorkflowGen pods:
1
workflowgen:
2
resources:
3
limits:
4
cpu: '1'
5
memory: 2Gi
6
requests:
7
cpu: '1'
8
memory: 2Gi
9
10
# Used when "scalable: true"
11
winServices:
12
dirSync:
13
resources:
14
limits:
15
cpu: '1'
16
memory: 1Gi
17
requests:
18
cpu: '500M'
19
memory: 1Gi
20
engine:
21
resources:
22
limits:
23
cpu: '1'
24
memory: 1Gi
25
requests:
26
cpu: '500M'
27
memory: 1Gi
Copied!
Keep in mind that Windows containers are a lot bigger in terms of storage, CPU, and memory consumption. Therefore, you'll probably need bigger Windows nodes than your Linux ones.

Database

The database part contains the values used to generate the deployment files for the WorkflowGen database StatefulSet and its related objects. It is an optional feature to deploy a database pod along with a WorkflowGen pod. You can disable the creation of the StatefulSet by setting the following values:
1
database:
2
create: false
Copied!

Configuration

There are two main ways to configure the database with the chart: with the values file or by providing your own ConfigMap or Secret.
Helm
Manual
In your values file, you can use the sub YAML object database.config and database.secret to configure the environment variables of the database. Let's begin with an example:
1
database:
2
config:
3
ACCEPT_EULA: 'Y'
4
SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
5
WFGEN_DATABASE_USER_USERNAME_FILE: /mnt/secrets/WFGEN_DATABASE_USER_USERNAME
6
WFGEN_DATABASE_USER_PASSWORD_FILE: /mnt/secrets/WFGEN_DATABASE_USER_PASSWORD
7
WFGEN_ADMIN_PASSWORD_FILE: /mnt/secrets/WFGEN_ADMIN_PASSWORD
8
secret:
9
SA_PASSWORD: 'strong(!)Pass'
10
WFGEN_DATABASE_USER_PASSWORD: 'strong(!)Pass'
11
WFGEN_ADMIN_PASSWORD: 'strong(!)Pass'
12
WFGEN_DATABASE_USER_USERNAME: WFGEN_USER
Copied!
Each key and value in the config part will be added as is in a ConfigMap object. It will be used by the StatefulSet. Concretely, the keys and values of the ConfigMap will get injected as environment variables in the database container. Each value must be of the string type. Therefore, YAML boolean values such as true, yes and Y will be rejected. Use single or double quotes when needed just like in the example.
For secret values, you can do exactly like the config part. You only have to provide the name of the secret and its concrete value. The chart will add them to a Secret object and encode the value in Base64. The Secret object will then get injected as a volume inside the database container. Each key will become a file with its concrete value written inside it. Therefore, you need a corresponding config value that will tell the container to pickup the value in a specific file using the _FILE suffix. For more information about how to configure WorkflowGen including secrets, see the Configuration page of the WorkflowGen database section. The default location of the secrets inside the container is /mnt/secrets. You can customize this path by providing the value database.secretMountPath.
The WorkflowGen database image is based on the SQL Server Linux image. It is the recommended image to use for production workloads. The Windows version of the image should only be used for development and test environments.
You also have the option to use your own ConfigMap and Secret objects. Keep in mind that these objects will not be managed by Helm or the WorkflowGen chart. Here's the same example as for the "Helm" method:

Step 1: Create ConfigMap and Secret files

my-db-configmap.yaml
1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
name: my-db-configmap
5
data:
6
ACCEPT_EULA: 'Y'
7
SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
8
WFGEN_DATABASE_USER_USERNAME_FILE: /mnt/secrets/WFGEN_DATABASE_USER_USERNAME
9
WFGEN_DATABASE_USER_PASSWORD_FILE: /mnt/secrets/WFGEN_DATABASE_USER_PASSWORD
10
WFGEN_ADMIN_PASSWORD_FILE: /mnt/secrets/WFGEN_ADMIN_PASSWORD
Copied!
my-db-secret.yaml
1
apiVersion: v1
2
kind: Secret
3
metadata:
4
name: my-db-secret
5
type: Opaque
6
data:
7
SA_PASSWORD: c3Ryb25nKCEpUGFzcwo=
8
WFGEN_DATABASE_USER_PASSWORD: c3Ryb25nKCEpUGFzcwo=
9
WFGEN_ADMIN_PASSWORD: c3Ryb25nKCEpUGFzcwo=
10
WFGEN_DATABASE_USER_USERNAME: V0ZHRU5fVVNFUgo=
Copied!
In the case of the secret, you have to encode the values in base64 yourself. For this, you can .use the following code sample:
PowerShell
1
using namespace System.Text
2
3
function ConvertTo-Base64String {
4
[CmdletBinding()]
5
[OutputType([string])]
6
param (
7
[Parameter(Mandatory=$true,ValueFromPipeline=$true)]
8
[ValidateNotNullOrEmpty()]
9
[string]$Value
10
)
11
12
process {
13
return [Convert]::ToBase64String([Encoding]::UTF8.GetBytes($Value))
14
}
15
}
16
17
'strong(!)Pass' | ConvertTo-Base64String # c3Ryb25nKCEpUGFzcwo=
18
'WFGEN_USER' | ConvertTo-Base64String # V0ZHRU5fVVNFUgo=
Copied!
Bash
1
echo 'strong(!)Pass' | base64 # c3Ryb25nKCEpUGFzcwo=
2
echo 'WFGEN_USER' | base64 # V0ZHRU5fVVNFUgo=
Copied!

Step 2: Create the objects from the files

Then, you have to deploy the objects by using the following command:
1
kubectl apply -f ./my-db-configmap.yaml
2
kubectl apply -f ./my-db-secret.yaml
Copied!

Step 3: Reference the objects' names in the chart

The last step is to reference the objects that you've just deployed in your values file before installing:
my-values.yaml
1
database:
2
createConfigMap: false
3
configMapNameOverride: my-db-configmap
4
createSecret: false
5
secretNameOverride: my-db-secret
Copied!

File storage

A StatefulSet needs a PersistentVolumeClaim template to generate a volume claim for each of its replicas. You can't use your own PVC this time because it is a template, not a concrete object. This template is part of the StatefulSet specification. Here's an example:
1
database:
2
volumeClaimTemplateSpec:
3
accessModes:
4
- ReadWriteOnce
5
storageClassName: default
6
resources:
7
requests:
8
storage: 100Gi
Copied!
The content of the template is exactly the Kubernetes PersistentVolumeClaim spec. Anything you write will be added to the StatefulSet specification as-is. In this example, the access mode is ReadWriteOnly because the default storage class refers to an Azure Disk. Azure disks can only be bound to a single node and pod at a time. Physical disks are the preferred way to store database files for better performance. For more information about Azure Disks, see Dynamically create and use a persistent volume with Azure disks in Azure Kubernetes Service (AKS) in the Azure Kubernetes Service documentation.

Custom image reference

To use your own WorkflowGen database image, you can change the default reference like this:
1
database:
2
image:
3
reference: mycorporation/workflowgen-sql
4
tag: 7.18.3-ubuntu-18.04
Copied!

Service

There is a service that is created by the chart with the database pod for its discovery. By default, the chart will create a ClusterIP service without a cluster IP address (clusterIP: None). This is called a headless service. It provides a way to get a cluster wide domain name to each pod of the StatefulSet. Therefore, you can refer directly to the database instance of your choice. It is recommended to leave the default values untouched. They are available in case you want to customize the service further. For more information about headless services in Kubernetes, see Service in its documentation.
Additionally, to make domain names predictable, you might want to override the full name of the StatefulSet, because the name is generated based on the chart's name and the release name, and you might not know the release name in advance. In this case, you can do the following:
1
database:
2
fullnameOverride: my-database
Copied!
This will ensure that each pod in the StatefulSet has a unique domain name based on this name. If this release is in the default namespace, the first pod will have the domain name my-database-0.my-database.default.svc.cluster.local. You then reference this domain name in the connection string of the WorkflowGen configuration at port 1433 and it should connect successfully.

Security

Since the database image used is a Linux image by default, all of the security features are available. You can run the database with a non-root user and group. For more information about running the database container as a non-root user, see Configure SQL Server container images on Docker in the SQL Server documentation. Keep in mind that you also have to setup the permissions for the storage to be able to read and write into it. There is a section about this in the same documentation page as the non-root user information. You might want to use an init container to setup the permissions.
For more information about Docker security features, see Docker security in the Docker documentation. To find out how to configure these security features in Kubernetes, see Configure a Security Context for a Pod or Container in the Kubernetes documentation.
There are many more options you can customize your Helm release with. The majority of them are dependent on your cluster environment. They are all Kubernetes terms, so you can search for them in a search engine and get useful information. The only one that this section will discuss is resources. The resources YAML object allows you to limit and request resource consumption for a given pod. Requests are to help the scheduler to assign pods to nodes. Limits are to limit the amount of resources the pod can use. The following requests and limits are known to work well for database pods:
1
database:
2
resources:
3
limits:
4
cpu: '2'
5
memory: 4Gi
6
requests:
7
cpu: '1'
8
memory: 2Gi
Copied!
Since WorkflowGen can only handle a main connection string and a read-only replica, you may want to limit the number of pods in the StatefulSet to two and scale vertically if you need more performance.

Ingress

The ingress section of the values is a simplified view of the complete Ingress object specification. It is optional to generate the Ingress rule object. To disable it, you can add the following values:
1
ingress:
2
enabled: false
Copied!
Otherwise, here's an example of how to use the Ingress section:
1
ingress:
2
annotations:
3
kubernetes.io/ingress.class: nginx
4
cert-manager.io/cluster-issuer: letsencrypt
5
hosts:
6
- host: &wfgenHost myinstance.example.com
7
paths:
8
- /
9
tls:
10
- secretName: tls-secret
11
hosts:
12
- *wfgenHost
Copied!
This is a complete example on how to use it. In this example, there are annotations set to add some information on how to handle them. The ingress.class tells Kubernetes to use the Nginx ingress controller to handle this Ingress rule. The Nginx ingress controller must be installed in your cluster for the routing to work. For more information about the Nginx ingress controller, see the open source community project page or the commercial page. The two have different feature sets and are not developed by the same entity. The cert-manager.io/cluster-issuer annotation is a Cert-Manager specific annotation that tells it to use the letsencrypt cluster issuer for the TLS certificate. See the TLS/SSL page of this section for more information about cert-manager.
The hosts section is a list of domain names and where they lead in the container. In this case, when a user goes to myinstance.example.com, it will be routed to / on the WorkflowGen container which IIS will handle. The tls section tells what secret to use for what host. TLS certificates are stored in this secret.

Hooks

In Helm, there is a concept of hooks that enables the developer to deploy some resources (temporary or permanently) at different event in the lifecycle of a chart.

Pre-upgrade hook

The pre-upgrade hook deploys a Kubernetes Job that will add possible missing files and templates to your WorkflowGen database volume and migrate the database automatically. This deployment only occurs when you use the helm upgrade command. It will wait for the job to finish successfully before upgrading the WorkflowGen and database pods. This hook is optional and you can disable it by using the following values:
1
hooks:
2
preupgrade:
3
enabled: false
Copied!
This pre-upgrade hook uses the WorkflowGen upgrade image to perform migrations. Here's a complete example to how to configure the hook:
1
hooks:
2
preupgrade:
3
image:
4
tag: latest-ubuntu-18.04
5
secret:
6
WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
7
mysecret: something secret
8
env:
9
- name: WFGEN_UPGRADE_EXCLUDE_FILES
10
value: file1,file2
11
- name: MY_SECRET_ENV
12
valueFrom:
13
secretKeyRef:
14
name: wfgen-migrations-secret # If release name is "wfgen"
15
key: mysecret
16
args:
17
- "-FromVersion"
18
- "7.14.10"
19
- "-ToVersion"
20
- "7.18.2"
Copied!
There is no default tag specified for the image because both Windows and Linux versions of it are production-ready. For a better experience and performance, it is recommended to use the Linux version. The secret section of this example allows you to specify secret values to be put in a Secret object that will be deployed with the job. It will get deleted when the job is terminated. The name of the secret is generated from the release name. If your release name is wfgen, then the secret name will be wfgen-migrations-secret. The WFGEN_DATABASE_CONNECTION_STRING secret is required. It is automatically injected as an environment variable in the container. To customize the name of the secret to use for the upgrade container'sWFGEN_DATABASE_CONNECTION_STRING environment variable, you can populate the hooks.preupgrade.connectionStringSecretKey value. You can add your own environment variables as well.
The last part consists of the arguments to pass to the container. See Configuration for more information about configuring the WorkflowGen upgrade container.

Common scenarios

Deploying a simple WorkflowGen pod

Overview

Simple WorkflowGen pod deployment
This deployment is meant for a simple installation with a database deployed outside of the cluster. It will deploy a single WorkflowGen pod with all of its services including WorkflowGen Windows services. This diagram shows a high-level view of the objects that will be created when installing the release with the values given in the next part. This architecture is only vertically scalable. You can only scale up the limits of the pod to have a more performant instance.

How to deploy

First, create the values file:
my-values.yaml
1
scalable: false
2
3
workflowgen:
4
resources:
5
limits:
6
cpu: '1'
7
memory: '2Gi'
8
requests:
9
cpu: '1'
10
memory: '2Gi'
11
config:
12
WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
13
WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
14
WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
15
WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
16
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
17
secret:
18
WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
19
WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
20
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
21
license:
22
secretName: wfgen-license-secret
23
items:
24
- key: WFG.lic
25
path: WFG.lic
26
dataPvcSpec:
27
accessModes:
28
- ReadWriteMany
29
storageClassName: azurefile
30
resources:
31
requests:
32
storage: 50Gi
33
service:
34
type: LoadBalancer
35
36
database:
37
create: false
38
39
ingress:
40
enabled: false
41
Copied!
  • MY-WFG-LIC-NUMBER is a placeholder value. You should replace it with your own serial number.
  • These values will create a LoadBalancer-type service. If you are on a cloud provider, it will deploy a resource in the cloud provider's specific load balancer service (e.g. Azure Load Balancer, AWS Elastic Load Balancer, etc).
  • These values assume that you own the example.com domain name and that it points to the load balancer's public IP address. In this particular case, the HTTPS means that the load balancer should work at network layer 7 and provide TLS termination. For more information about TLS handling in Kubernetes see the TLS/SSL page of this section.
  • The persistent volume claim that will be created assumes that you have a storage class already present in the cluster named azurefile. It is present by default on a Azure Kubernetes Service cluster. See Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service (AKS) for more information.
Before installing a release of the chart, you have to create the WorkflowGen license secret object in your cluster. For this particular example, the name of the license file is WFG.lic and the name of the secret object is wfgen-license-secret. Execute the following command to create it:
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
With that done, you can now install the release:
1
helm install -f ./my-values.yaml wfgen https://github.com/advantys/workflowgen-releases/releases/download/7.18.2/workflowgen-0.0.3.tgz
Copied!
The last argument is the path (or URL) to the WorkflowGen chart. You can use the URL directly or download it and use a local path. From this point, you should have a working WorkflowGen pod in your cluster.

Deploying a scalable WorkflowGen architecture

Scalable WorkflowGen pod deployment
This architecture is best suited for production workloads that have an external database. This deployment enables you to scale WorkflowGen web applications horizontally (by adding replicas), which has many benefits such as increased availability and performance. The WorkflowGen Windows services must be scaled vertically and cannot be scaled horizontally. Make sure to deploy that pod to a node that has sufficient resources.

How to deploy

my-values.yaml
1
replicaCount: 3
2
3
workflowgen:
4
resources:
5
limits:
6
cpu: '1'
7
memory: '2Gi'
8
requests:
9
cpu: '1'
10
memory: '2Gi'
11
config:
12
WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
13
WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
14
WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
15
WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
16
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
17
secret:
18
WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
19
WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
20
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
21
license:
22
secretName: wfgen-license-secret
23
items:
24
- key: WFG.lic
25
path: WFG.lic
26
dataPvcSpec:
27
accessModes:
28
- ReadWriteMany
29
storageClassName: azurefile
30
resources:
31
requests:
32
storage: 50Gi
33
service:
34
type: LoadBalancer
35
36
winServices:
37
dirSync:
38
resources:
39
limits:
40
cpu: '1'
41
memory: 1Gi
42
requests:
43
cpu: '500M'
44
memory: 1Gi
45
engine:
46
resources:
47
limits:
48
cpu: '1'
49
memory: 1Gi
50
requests:
51
cpu: '500M'
52
memory: 1Gi
53
54
database:
55
create: false
56
57
ingress:
58
enabled: false
Copied!
  • MY-WFG-LIC-NUMBER is a placeholder value. You should replace it with your own serial number.
  • These values will create a LoadBalancer-type service. If you are on a cloud provider, it will deploy a resource in the cloud provider's specific load balancer service (e.g. Azure Load Balancer, AWS Elastic Load Balancer, etc).
  • These values assume that you own the example.com domain name and that it points to the load balancer's public IP address. In this particular case, the HTTPS means that the load balancer should work at network layer 7 and provide TLS termination. For more information about TLS handling in Kubernetes see the TLS/SSL page of this section.
  • The persistent volume claim that will be created assumes that you have a storage class already present in the cluster named azurefile. It is present by default on a Azure Kubernetes Service cluster. See Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service (AKS) for more information.
This is the same example as for the simple deployment, except that the scalable property is gone (true by default), the number of replicas is three, and there are resource requests and limits for the Windows services.
Before installing a release of the chart, you have to create the WorkflowGen license secret object in your cluster. For this particular example, the name of the license file is WFG.lic and the name of the secret object is wfgen-license-secret. Execute the following command to create it:
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
With this done, you can now install the release:
1
helm install -f ./my-values.yaml wfgen https://github.com/advantys/workflowgen-releases/releases/download/7.18.2/workflowgen-0.0.3.tgz
Copied!
The last argument is the path (or URL) to the WorkflowGen chart. You can use the URL directly or download it and use a local path. From this point, you should have a working WorkflowGen pod in your cluster.

Deploying a scalable WorkflowGen architecture with a database container

Scalable architecture with a database container
This architecture is best suited for the complete automation experience and can help reduce costs by having the container inside the cluster instead of in an external environment. It is a scalable architecture where the WorkflowGen web applications can be scaled horizontally and vertically, the Windows Services can be scaled vertically only, and the WorkflowGen database can be scaled horizontally up to two replicas (read/write and read-only) and vertically.

How to deploy

1
replicaCount: 3
2
3
workflowgen:
4
resources:
5
limits:
6
cpu: '1'
7
memory: 2Gi
8
requests:
9
cpu: '1'
10
memory: 2Gi
11
config:
12
WFGEN_APP_SETTING_ApplicationUrl: http://10.0.1.1/wfgen
13
WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
14
WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\ApplicationSerialNumber
15
WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\ApplicationSecurityPasswordSymmetricEncryptionKey
16
WFGEN_MACHINE_KEY_DECRYPTION_KEY_FILE: C:\secrets\WFGEN_MACHINE_KEY_DECRYPTION_KEY
17
WFGEN_MACHINE_KEY_VALIDATION_KEY_FILE: C:\secrets\WFGEN_MACHINE_KEY_VALIDATION_KEY
18
secret:
19
ApplicationSerialNumber: <YOUR_WFG_LIC_KEY>
20
ApplicationSecurityPasswordSymmetricEncryptionKey: <YOUR_NEW_GUID>
21
WFGEN_DATABASE_CONNECTION_STRING: 'Server=wfgen-database-0.wfgen-database.default.svc.cluster.local,1433;Database=WFGEN;User ID=WFGEN_USER;Password=strong(!)Pass;'
22
WFGEN_MACHINE_KEY_DECRYPTION_KEY: '39B3AE9CCCF94AA47D795EC84F7CCB7928F5D59BE2EB2BBA4FE2AC0B3C8D0C85'
23
WFGEN_MACHINE_KEY_VALIDATION_KEY: '82F6247A5DBF8666FB60B8EFE6483360436F0EC426CC0351A9569C607B46C1FAD6497406DD8B0B519DD83CAA6764904C89999D742638ECE756E7C0B8799B45E9'
24
license:
25
secretName: wfgen-license-secret
26
items:
27
- key: WorkflowGen.lic
28
path: WorkflowGen.lic
29
dataPvcSpec:
30
accessModes:
31
- ReadWriteMany
32
storageClassName: azurefile
33
resources:
34
requests:
35
storage: 50Gi
36
service:
37
type: LoadBalancer
38
39
winServices:
40
dirSync:
41
resources:
42
limits:
43
cpu: '1'
44
memory: 1Gi
45
requests:
46
cpu: '500M'
47
memory: 1Gi
48
engine:
49
resources:
50
limits:
51
cpu: '1'
52
memory: 1Gi
53
requests:
54
cpu: '500M'
55
memory: 1Gi
56
57
database:
58
fullnameOverride: wfgen-database
59
nodeSelector:
60
kubernetes.io/os: linux
61
securityContext: