Carte Helm WorkflowGen

Aperçu

Cette section présente la carte Helm WorkflowGen, y compris l'utilisation, les options de configuration et des exemples. L'utilisation de la carte WorkflowGen simplifie le déploiement de WorkflowGen dans un cluster Kubernetes en n'ayant pas à gérer de nombreux fichiers de déploiement Kubernetes. Vous n'avez qu'à gérer un seul fichier « values ».

Prérequis

  • Vous devez avoir un cluster Kubernetes fonctionnel avec des nœuds Windows Server 2019.
  • Vous devez avoir installé l'outil de ligne de commande kubectl et il doit être connecté au cluster.
  • Vous devez avoir installé l'outil de ligne de commande Helm. Consultez la section Installing Helm sur le site Web de Helm pour savoir comment l'installer. Seule la version Helm 3.0+ est supportée.

Introduction aux cartes Helm

Citation du site Web Helm :
A chart is a collection of files that describe a related set of Kubernetes resources.
(Une carte est une collection de fichiers qui décrivent un ensemble connexe de ressources Kubernetes.)
Ces ressources sont écrites en YAML dans la carte à l'aide du langage de modèles Go. Cela permet au graphique de générer des fichiers de définition de ressources Kubernetes valides en fonction des valeurs fournies par l'utilisateur du graphique. Par conséquent, lorsque vous utilisez la carte pour installer ou mettre à jour WorkflowGen, vous pouvez fournir certaines valeurs qui vous aideront à déployer les ressources appropriées pour WorkflowGen.
Une carte a un fichier manifeste appelé Chart.yaml. Il a une version pour la carte et une version pour l'application. Par exemple, la version de la carte WorkflowGen pourrait être 0.0.3 et sa version d'application 7.18.3. Une carte a également kubeVersion qui indique quelles versions de Kubernetes sont supportées. Dans le cas de WorkflowGen, seule les versions 1.14 et supérieures sont supportées car c'est la première version à inclure le support des conteneurs Windows.
Vous installez une carte à l'aide de la ligne de commande. Par exemple :
1
helm install --set image.tag=7.15.5-win-ltsc2019 release-name ./chart-path
Copied!
Cela installera la carte qui se trouve sur le chemin ./chart-path dans le cluster avec le nom de version release-name. Il définit également la valeur image.tag sur 7.15.5-win-ltsc2019. Vous trouverez plus d'informations sur la commande install, y compris son paramètre --set, dans la page Helm Install sur le site Web de Helm.
Bien qu'utile pour quelques paramètres, la définition de valeurs à partir de la ligne de commande peut être lourde et sujette à des erreurs, c'est pourquoi vous pouvez également définir des valeurs à partir d'un fichier YAML ou JSON. La première chose que vous devez faire est de créer le fichier :
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!
Ensuite, vous pouvez transmettre ce fichier à la commande d'installation :
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!

Valeurs WorkflowGen

Voici tous les noms des valeurs supportées par le graphique WorkflowGen et leurs valeurs par défaut. Ils sont accompagnés d'une brève 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: []
Copied!
La carte est divisée en groupes de configuration :
  • Global
  • WorkflowGen
  • WorkflowGen Windows services
  • Database
  • Ingress
  • Hooks

Valeurs globales

Les valeurs globales contrôlent le déploiement global résultant de la génération Helm. Par exemple, la valeur scalable indique si le déploiement résultant doit être évolutif ou non. Si la valeur est true, le déploiement résultant aura un pod distinct pour les services Windows WorkflowGen qui seront déployés à l'aide du modèle de déploiement Singleton. Les services Web WorkflowGen seront déployés avec le nombre de répliques indiqué par la valeur globale replicaCount. Si false, les services Web et Windows WorkflowGen seront déployés dans un seul pod à l'aide du modèle Singleton.

Services WorkflowGen et Windows

La partie WorkflowGen regroupe les options de configuration liées aux pods des services Web et Windows de WorkflowGen lors de la configuration du produit WorkflowGen. Pour la configuration liée à l'infrastructure, les options de configuration se trouvent dans des groupes distincts afin de pouvoir déployer correctement chaque partie individuellement mais toujours avec la même configuration spécifique à WorkflowGen.

Configuration de WorkflowGen

Il existe deux façons principales de configurer WorkflowGen avec la carte : avec le fichier de valeurs ou en fournissant votre propre ConfigMap ou Secret.
Helm
Manuel
Dans votre fichier de valeurs, vous pouvez utiliser les sous-objets YAML workflowgen.config et workflowgen.secret pour configurer les variables d'environnement de WorkflowGen. Commençons par un exemple :
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!
Chaque clé et valeur dans la partie config sera ajoutée comme dans un objet ConfigMap et sera utilisée par les déploiements WorkflowGen. Concrètement, les clés et les valeurs du ConfigMap seront injectées en tant que variables d'environnement dans le conteneur de WorkflowGen. Chaque valeur doit être du type chaîne. Par conséquent, les valeurs booléennes YAML telles que true, yes et Y seront rejetées. Utilisez des guillemets simples (') ou doubles (") si nécessaire, comme dans l'exemple.
Pour les valeurs secrètes, vous pouvez faire exactement comme la partie config. Vous n'avez qu'à fournir le nom du secret et sa valeur concrète. La carte les ajoutera à un objet Secret et encodera la valeur en Base64. L'objet Secret sera ensuite injecté en tant que volume à l'intérieur du conteneur de WorkflowGen. Chaque clé deviendra un fichier avec sa valeur concrète écrite à l'intérieur. Par conséquent, vous avez besoin d'une valeur de configuration correspondante qui indiquera au conteneur de récupérer la valeur dans un fichier spécifique à l'aide du suffixe _FILE. Pour plus d'informations sur la configuration de WorkflowGen, y compris les secrets, consultez la page Configuration de la section Image WorkflowGen. L'emplacement par défaut des secrets à l'intérieur du conteneur est C:\secrets. Vous pouvez personnaliser ce chemin en fournissant la valeur workflowgen.secretMountPath.
Vous avez également la possibilité d'utiliser vos propres objets ConfigMap et Secret. Gardez à l'esprit que ces objets ne seront pas gérés par Helm ou la carte WorkflowGen. Voici le même exemple que pour la méthode « Helm » :

Étape 1 : Créez des fichiers ConfigMap et Secret

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!
Dans le cas du secret, vous devez encoder vous-même les valeurs en base64. Pour cela, vous pouvez utiliser l'exemple de code suivant :
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!

Étape 2 : Créez les objets à partir des fichiers

Ensuite, vous devez déployer les objets à l'aide de la commande suivante :
1
kubectl apply -f ./my-configmap.yaml
2
kubectl apply -f ./my-secret.yaml
Copied!

Étape 3 : Référencez les noms des objets dans la carte

La dernière étape consiste à référencer les objets que vous venez de déployer dans votre fichier de valeurs avant d'installer :
my-values.yaml
1
workflowgen:
2
createConfigMap: false
3
configMapNameOverride: my-configmap
4
createSecret: false
5
secretNameOverride: my-secret
Copied!

Stockage de fichiers

La carte génère un objet PersistentVolumeClaim (PVC) basé sur les valeurs que vous avez fournies. Comme pour la configuration WorkflowGen, vous pouvez spécifier votre propre PVC en dehors du graphique et le référencer.
Helm
Manuel
Dans votre fichier de valeurs, vous pouvez utiliser l'objet sous YAML workflowgen.dataPvcSpec pour configurer le PersistentVolumeClaim pour les données de WorkflowGen (App_Data et wfapps). Commençons par un exemple :
1
workflowgen:
2
dataPvcSpec:
3
accessModes:
4
- ReadWriteMany
5
storageClassName: azurefile
6
resources:
7
requests:
8
storage: 50Gi
Copied!
Le contenu de l'objet correspond exactement à la spécification Kubernetes PersistentVolumeClaim. Ce que vous y écrivez sera pris tel quel dans la définition de l'objet.
Dans cet exemple, la classe de stockage azurefile est spécifique à Azure Kubernetes Service.
Vous avez également la possibilité d'utiliser votre propre objet PVC. Gardez à l'esprit que cet objet ne sera pas géré par Helm ou la carte WorkflowGen. Voici un exemple :

Étape 1 : Créez le fichier de définition PersistentVolumeClaim

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!

Étape 2 : Déployez la définition dans le cluster

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

Étape 3 : Référencez l'objet dans vos valeurs

La dernière étape consiste à référencer les objets que vous venez de déployer dans votre fichier de valeurs avant d'installer :
1
workflowgen:
2
createDataPvc: false
3
dataPvcNameOverride: my-wfg-pvc
Copied!

Licence

La licence doit être stockée sur le cluster Kubernetes avant d'installer la carte. En effet, il est plus efficace de la stocker dans un secret et de l'injecter en tant que volume dans les pods WorkflowGen au lieu de provisionner un partage de fichiers et de le connecter aux pods. Pour que la carte la gère, vous devez spécifier le nom secret où la licence est stockée et le nom de l'élément de licence dans le secret. Voici un exemple :
Étape 1 : Stockez votre licence dans le cluster
L'objet secret doit se trouver dans le même espace de noms que les pods WorkflowGen.
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
Cette commande créera un secret nommé wfgen-license-secret avec un élément nommé WFG.lic et sa valeur sera le contenu du fichier.
Étape 2 : Référencez ce secret dans le fichier de valeurs
1
workflowgen:
2
license:
3
secretName: wfgen-license-secret
4
items:
5
- key: WFG.lic
6
path: WFG.lic
Copied!
Pour plus d'informations sur la façon d'injecter des fichiers d'un objet Secret dans des pods, consultez la page Secrets dans la documentation de Kubernetes.

Référence d'image personnalisée

Pour utiliser votre propre image WorkflowGen, vous pouvez modifier la référence par défaut comme ceci :
1
workflowgen:
2
image:
3
reference: mycorporation/workflowgen
4
tag: 7.18.3-win-ltsc2019
Copied!

Service

Il existe un service créé par la carte avec le pod WorkflowGen pour sa découverte. Par défaut, le graphique crée un service ClusterIP qui fournit une adresse IP et un nom de domaine à l'échelle du cluster que vous pouvez référencer de n'importe où dans le cluster. Cela fonctionne mieux avec un contrôleur Ingress pour acheminer le trafic externe vers celui-ci. Pour plus d'informations sur les contrôleurs Ingress, voir la page Ingress Controllers dans la documentation de Kubernetes.
Vous pouvez le personnaliser pour créer automatiquement un équilibreur de charge à la place en fournissant la valeur suivante :
1
workflowgen:
2
service:
3
kind: LoadBalancer
Copied!
Le type LoadBalancer fonctionne uniquement avec les fournisseurs de cloud. Pour les clusters sur site, vous devez utiliser une autre technique.

Sécurité

Il existe de nombreuses fonctionnalités de sécurité qui ne sont pas encore supportées ou qui ne fonctionnent pas sous Windows mais le font sous Linux. Il est important de planifier la sécurité des déploiements. Pour en savoir plus sur les fonctionnalités de sécurité non prises en charge sur les conteneurs Windows dans Kubernetes, consultez la page Intro to Windows support in Kubernetes (section Security) dans la documentation de Kubernetes.
Les applications Web du conteneur WorkflowGen s'exécutent en tant qu'utilisateur faisant partie du groupe IIS_IUSRS. Ceci est important pour définir les autorisations pour le stockage de fichiers. Si ce groupe n'a pas l'autorisation MODIFY sur le volume des fichiers, le conteneur ne parviendra pas à écrire sur le volume. En règle générale, vous pouvez définir des options de montage pour un volume persistant en fonction du fournisseur de stockage ou vous pouvez exécuter un conteneur init pour définir les autorisations. Pour Azure Files, consultez l'article Microsoft Créer et utiliser un volume persistant de manière dynamique avec Azure Files dans Azure Kubernetes Service (AKS) pour obtenir les options de montage.

Recommandations liées aux infrastructures

Il existe de nombreuses autres options pour personnaliser votre version de Helm. La majorité d'entre eux dépendent de votre environnement de cluster. Ce sont tous des termes Kubernetes, vous pouvez donc les rechercher dans un moteur de recherche et obtenir des informations utiles. La seule dont cette section traitera est resources. L'objet YAML resources vous permet de limiter et de demander la consommation de ressources pour un pod donné. Les requêtes doivent aider le planificateur à affecter des pods aux nœuds. Les limites sont pour limiter la quantité de ressources que le pod peut utiliser. Les requêtes et limites suivantes sont connues pour fonctionner correctement pour les pods WorkflowGen :
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!
Gardez à l'esprit que les conteneurs Windows sont beaucoup plus importants en termes de stockage, de processeur et de consommation de mémoire. Par conséquent, vous aurez probablement besoin de nœuds Windows plus grands que ceux de Linux.

Base de données

La partie base de données contient les valeurs utilisées pour générer les fichiers de déploiement pour le StatefulSet de la base de données WorkflowGen et ses objets associés. Il s'agit d'une fonctionnalité facultative pour déployer un pod de base de données avec un pod WorkflowGen. Vous pouvez désactiver la création de StatefulSet en définissant les valeurs suivantes :
1
database:
2
create: false
Copied!

Configuration

Il existe deux façons principales de configurer la base de données avec la carte : avec le fichier de valeurs ou en fournissant votre propre ConfigMap ou Secret.
Helm
Manuel
Dans votre fichier de valeurs, vous pouvez utiliser les sous-objets YAML database.config et database.secret pour configurer les variables d'environnement de la base de données. Commençons par un exemple :
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!
Chaque clé et valeur de la partie config sera ajoutée comme dans un objet ConfigMap. Il sera utilisé par le StatefulSet. Concrètement, les clés et les valeurs du ConfigMap seront injectées en tant que variables d'environnement dans le conteneur de base de données. Chaque valeur doit être du type chaîne. Par conséquent, les valeurs booléennes YAML telles que true, yes et Y seront rejetées. Utilisez des guillemets simples (') ou doubles (") si nécessaire, comme dans l'exemple.
Pour les valeurs secrètes, vous pouvez faire exactement comme la partie config. Vous n'avez qu'à fournir le nom du secret et sa valeur concrète. La carte les ajoutera à un objet Secret et encodera la valeur en Base64. L'objet Secret sera ensuite injecté en tant que volume à l'intérieur du conteneur de WorkflowGen. Chaque clé deviendra un fichier avec sa valeur concrète écrite à l'intérieur. Par conséquent, vous avez besoin d'une valeur de configuration correspondante qui indiquera au conteneur de récupérer la valeur dans un fichier spécifique à l'aide du suffixe _FILE. Pour plus d'informations sur la configuration de WorkflowGen, y compris les secrets, consultez la page Configuration de la section Image de base de données WorkflowGen. L'emplacement par défaut des secrets à l'intérieur du conteneur est C:\secrets. Vous pouvez personnaliser ce chemin en fournissant la valeur database.secretMountPath.
L'image de la base de données WorkflowGen est basée sur l'image SQL Server Linux. Il s'agit de l'image recommandée à utiliser pour les charges de travail de production. La version Windows de l'image ne doit être utilisée que pour les environnements de développement et de test.
Vous avez également la possibilité d'utiliser vos propres objets ConfigMap et Secret. Gardez à l'esprit que ces objets ne seront pas gérés par Helm ou la carte WorkflowGen. Voici le même exemple que pour la méthode « Helm » :

Étape 1 : Créez des fichiers ConfigMap et Secret

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!
Dans le cas du secret, vous devez encoder vous-même les valeurs en base64. Pour cela, vous pouvez utiliser l'exemple de code suivant :
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!

Étape 2 : Créez les objets à partir des fichiers

Ensuite, vous devez déployer les objets à l'aide de la commande suivante :
1
kubectl apply -f ./my-db-configmap.yaml
2
kubectl apply -f ./my-db-secret.yaml
Copied!

Étape 3 : Référencez les noms des objets dans la carte

La dernière étape consiste à référencer les objets que vous venez de déployer dans votre fichier de valeurs avant d'installer :
my-values.yaml
1
database:
2
createConfigMap: false
3
configMapNameOverride: my-db-configmap
4
createSecret: false
5
secretNameOverride: my-db-secret
Copied!

Stockage de fichiers

Un StatefulSet a besoin d'un modèle PersistentVolumeClaim pour générer une revendication de volume pour chacune de ses répliques. Vous ne pouvez pas utiliser votre propre PVC cette fois car c'est un modèle, pas un objet concret. Ce modèle fait partie de la spécification StatefulSet. Voici un exemple :
1
database:
2
volumeClaimTemplateSpec:
3
accessModes:
4
- ReadWriteOnce
5
storageClassName: default
6
resources:
7
requests:
8
storage: 100Gi
Copied!
Le contenu du modèle est exactement la spécification Kubernetes PersistentVolumeClaim. Tout ce que vous écrivez sera ajouté tel quel à la spécification StatefulSet. Dans cet exemple, le mode d'accès est ReadWriteOnly car la classe de stockage par défaut fait référence à un disque Azure. Les disques Azure ne peuvent être liés qu'à un seul nœud et pod à la fois. Les disques physiques sont le moyen préféré de stocker les fichiers de base de données pour de meilleures performances. Pour plus d'informations sur les disques Azure, consultez l'article Créer et utiliser un volume persistant de manière dynamique avec des disques Azure sur Azure Kubernetes Service (AKS) dans la documentation Azure Kubernetes Service.

Référence d'image personnalisée

Pour utiliser votre propre image de base de données WorkflowGen, vous pouvez modifier la référence par défaut comme ceci :
1
database:
2
image:
3
reference: mycorporation/workflowgen-sql
4
tag: 7.18.3-ubuntu-18.04
Copied!

Service

Il existe un service créé par la carte avec le pod de base de données pour sa découverte. Par défaut, le graphique crée un service ClusterIP sans adresse IP de cluster (clusterIP: None). C'est ce qu'on appelle un service en mode sans affichage (« headless service »). Il fournit un moyen d'obtenir un nom de domaine à l'échelle du cluster pour chaque module de StatefulSet. Par conséquent, vous pouvez vous référer directement à l'instance de base de données de votre choix. Il est recommandé de ne pas modifier les valeurs par défaut. Ils sont disponibles au cas où vous souhaiteriez personnaliser davantage le service. Pour plus d'informations sur les services en mode sans affichage dans Kubernetes, voir Service dans sa documentation.
En outre, pour rendre les noms de domaine prévisibles, vous souhaiterez peut-être remplacer le nom complet du StatefulSet, car le nom est généré en fonction du nom de la carte et du nom de la version, et vous ne connaissez peut-être pas le nom de la version à l'avance. Dans ce cas, vous pouvez effectuer les opérations suivantes :
1
database:
2
fullnameOverride: my-database
Copied!
Cela garantira que chaque pod du StatefulSet possède un nom de domaine unique basé sur ce nom. Si cette version se trouve dans l'espace de noms default, le premier pod aura le nom de domaine my-database-0.my-database.default.svc.cluster.local. Vous référencez ensuite ce nom de domaine dans la chaîne de connexion de la configuration WorkflowGen au port 1433 et il devrait se connecter avec succès.

Sécurité

Étant donné que l'image de base de données utilisée est une image Linux par défaut, toutes les fonctions de sécurité sont disponibles. Vous pouvez exécuter la base de données avec un utilisateur et un groupe non racine. Pour plus d'informations sur l'exécution du conteneur de base de données en tant qu'utilisateur non root, consultez l'article Configurer des images de conteneur SQL Server sur Docker dans la documentation SQL Server. Gardez à l'esprit que vous devez également configurer les autorisations pour le stockage pour pouvoir y lire et y écrire. Il existe une section à ce sujet dans la même page de documentation. Vous souhaiterez peut-être utiliser un conteneur init pour configurer les autorisations.
Pour plus d'informations sur les fonctionnalités de sécurité de Docker, voir la page Docker Security dans la documentation Docker. Pour savoir comment configurer ces fonctionnalités de sécurité dans Kubernetes, voir la page Configure a Security Context for a Pod or Container dans la documentation de Kubernetes.

Recommandations liées aux infrastructures

Il existe de nombreuses autres options pour personnaliser votre version de Helm. La majorité d'entre eux dépendent de votre environnement de cluster. Ce sont tous des termes Kubernetes, vous pouvez donc les rechercher dans un moteur de recherche et obtenir des informations utiles. La seule dont cette section traitera est resources. L'objet YAML resources vous permet de limiter et de demander la consommation de ressources pour un pod donné. Les requêtes doivent aider le planificateur à affecter des pods aux nœuds. Les limites sont pour limiter la quantité de ressources que le pod peut utiliser. Les requêtes et limites suivantes sont connues pour fonctionner correctement pour les pods WorkflowGen :
1
database:
2
resources:
3
limits:
4
cpu: '2'
5
memory: 4Gi
6
requests:
7
cpu: '1'
8
memory: 2Gi
Copied!
Étant donné que WorkflowGen ne peut gérer qu'une chaîne de connexion principale et une réplique en lecture seule, vous souhaiterez peut-être limiter le nombre de pods dans le StatefulSet à deux et évoluer verticalement si vous avez besoin de plus de performances.

Ingress

La section Ingress des valeurs est une vue simplifiée de la spécification d'objet Ingress complète. Il est facultatif de générer l'objet de règle Ingress. Pour le désactiver, vous pouvez ajouter les valeurs suivantes :
1
ingress:
2
enabled: false
Copied!
Sinon, voici un exemple d'utilisation de la section Ingress :
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!
Ceci est un exemple complet sur la façon de l'utiliser. Dans cet exemple, des annotations sont définies pour ajouter des informations sur la façon de les gérer. La classe ingress.class indique à Kubernetes d'utiliser le contrôleur d'entrée (ingress) Nginx pour gérer cette règle d'ingress. Le contrôleur d'entrée Nginx doit être installé dans votre cluster pour que le routage fonctionne. Pour plus d'informations sur le contrôleur d'entrée Nginx, consultez la page du projet de communauté open source ou la page commerciale. Les deux ont des ensembles de fonctionnalités différents et ne sont pas développés par la même entité. L'annotation cert-manager.io/cluster-issuer est une annotation spécifique à Cert-Manager qui lui indique d'utiliser l'émetteur de cluster letsencrypt pour le certificat TLS. Voir la page TLS / SSL de cette section pour plus d'informations sur cert-manager.
La section hosts est une liste de noms de domaine et où ils mènent dans le conteneur. Dans ce cas, lorsqu'un utilisateur accède à myinstance.example.com, il sera routé vers / sur le conteneur WorkflowGen que IIS gérera. La section tls indique quel secret utiliser pour quel hôte. Les certificats TLS sont stockés dans ce secret.

Hooks

Dans Helm, il existe un concept de « hooks » qui permet au développeur de déployer certaines ressources (temporaires ou permanentes) à différents événements du cycle de vie d'un graphique.

Hook de pré-mise à jour

Le hook de pré-mise à jour déploie une tâche (« job ») Kubernetes qui ajoutera les éventuels fichiers et modèles manquants à votre volume de base de données WorkflowGen et migrera la base de données automatiquement. Ce déploiement se produit uniquement lorsque vous utilisez la commande helm upgrade. Il attendra que la tâche se termine avec succès avant de mettre à jour les pods de WorkflowGen et de la base de données. Ce hook est facultatif et vous pouvez le désactiver en utilisant les valeurs suivantes :
1
hooks:
2
preupgrade:
3
enabled: false
Copied!
Ce hook de pré-mise à jour utilise l'image de mise à jour de WorkflowGen pour effectuer des migrations. Voici un exemple complet de configuration du 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!
Aucune balise par défaut n'est spécifiée pour l'image car les versions Windows et Linux de celle-ci sont prêtes pour la production. Pour une meilleure expérience et performance, il est recommandé d'utiliser la version Linux. La section secret de cet exemple vous permet de spécifier des valeurs secrètes à placer dans un objet Secret qui sera déployé avec la tâche. L'objet sera supprimé à la fin de la tâche. Le nom du secret est généré à partir du nom de la version. Si le nom de votre version est wfgen, le nom secret sera wfgen-migrations-secret. Le secret WFGEN_DATABASE_CONNECTION_STRING est requis. Il est automatiquement injecté en tant que variable d'environnement dans le conteneur. Pour personnaliser le nom du secret à utiliser pour la variable d'environnement WFGEN_DATABASE_CONNECTION_STRING du conteneur de mise à jour, vous pouvez remplir la valeur hooks.preupgrade.connectionStringSecretKey. Vous pouvez également ajouter vos propres variables d'environnement.
La dernière partie est constituée des arguments à transmettre au conteneur. Voir la page Configuration pour plus d'informations sur la configuration du conteneur de mise à jour de WorkflowGen.

Scénarios courants

Déployer un pod WorkflowGen simple

Aperçu

Déploiement de pod WorkflowGen simple
Ce déploiement est destiné à une installation simple avec une base de données déployée en dehors du cluster. Il déploiera un seul pod WorkflowGen avec tous ses services, y compris les services Windows WorkflowGen. Ce diagramme montre une vue de haut niveau des objets qui seront créés lors de l'installation de la version avec les valeurs données dans la partie suivante. Cette architecture n'est évolutive que verticalement. Vous pouvez uniquement augmenter les limites du pod pour avoir une instance plus performante.

Comment déployer

Créez d'abord le fichier de valeurs :
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 est une valeur d'espace réservé. Vous devez le remplacer par votre propre numéro de série.
  • Ces valeurs créeront un service de type LoadBalancer. Si vous êtes sur un fournisseur de cloud, il déploiera une ressource dans le service d'équilibrage de charge spécifique du fournisseur de cloud (p.ex. Azure Load Balancer, AWS Elastic Load Balancer, etc...).
  • Ces valeurs supposent que vous êtes propriétaire du nom de domaine example.com et qu'il pointe vers l'adresse IP publique de l'équilibreur de charge. Dans ce cas particulier, le HTTPS signifie que l'équilibreur de charge doit fonctionner au niveau de la couche réseau 7 et fournir une terminaison TLS. Pour plus d'informations sur la gestion TLS dans Kubernetes, consultez la page TLS / SSL de cette section.
  • La revendication de volume persistant qui sera créée suppose que vous avez déjà une classe de stockage dans le cluster nommé azurefile. Il est présent par défaut sur un cluster Azure Kubernetes Service. Voir l'article Microsoft Créer et utiliser un volume persistant de manière dynamique avec Azure Files dans Azure Kubernetes Service (AKS) pour plus d'informations.
Avant d'installer une version du graphique, vous devez créer l'objet secret de licence WorkflowGen dans votre cluster. Pour cet exemple particulier, le nom du fichier de licence est WFG.lic et le nom de l'objet secret est wfgen-license-secret. Exécutez la commande suivante pour le créer :
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
Cela fait, vous pouvez maintenant installer la version :
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!
Le dernier argument est le chemin (ou l'URL) de la carte WorkflowGen. Vous pouvez utiliser l'URL directement ou la télécharger et utiliser un chemin local. À partir de ce moment, vous devriez avoir un module WorkflowGen fonctionnel dans votre cluster.

Déploiement d'une architecture WorkflowGen évolutive

Déploiement évolutif de pod WorkflowGen
Cette architecture est la mieux adaptée aux charges de travail de production qui ont une base de données externe. Ce déploiement vous permet de faire évoluer les applications Web WorkflowGen horizontalement (en ajoutant des répliques), ce qui présente de nombreux avantages tels qu'une disponibilité et des performances accrues. Les services Windows WorkflowGen doivent être mis à l'échelle verticalement et ne peuvent pas être mis à l'échelle horizontalement. Assurez-vous de déployer ce pod sur un nœud disposant de ressources suffisantes.

Comment déployer

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 est une valeur d'espace réservé. Vous devez le remplacer par votre propre numéro de série.
  • Ces valeurs créeront un service de type LoadBalancer. Si vous êtes sur un fournisseur de cloud, il déploiera une ressource dans le service d'équilibrage de charge spécifique du fournisseur de cloud (p.ex. Azure Load Balancer, AWS Elastic Load Balancer, etc...).
  • Ces valeurs supposent que vous êtes propriétaire du nom de domaine example.com et qu'il pointe vers l'adresse IP publique de l'équilibreur de charge. Dans ce cas particulier, le HTTPS signifie que l'équilibreur de charge doit fonctionner au niveau de la couche réseau 7 et fournir une terminaison TLS. Pour plus d'informations sur la gestion TLS dans Kubernetes, consultez la page TLS / SSL de cette section.
  • La revendication de volume persistant qui sera créée suppose que vous avez déjà une classe de stockage dans le cluster nommé azurefile. Il est présent par défaut sur un cluster Azure Kubernetes Service. Voir l'article Microsoft Créer et utiliser un volume persistant de manière dynamique avec Azure Files dans Azure Kubernetes Service (AKS) pour plus d'informations.
Il s'agit du même exemple que pour le déploiement simple, sauf que la propriété scalable a disparu (true par défaut), le nombre de réplicas est de trois et il existe des requêtes et des limites de ressources pour les services Windows.
Avant d'installer une version de la carte, vous devez créer l'objet secret de la licence WorkflowGen dans votre cluster. Pour cet exemple particulier, le nom du fichier de licence est WFG.lic et le nom de l'objet secret est wfgen-license-secret. Exécutez la commande suivante pour le créer :
1
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Copied!
Cela fait, vous pouvez maintenant installer la version:
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!
Le dernier argument est le chemin (ou l'URL) de la carte WorkflowGen. Vous pouvez utiliser l'URL directement ou la télécharger et utiliser un chemin local. À partir de ce moment, vous devriez avoir un module WorkflowGen fonctionnel dans votre cluster.

Déploiement d'une architecture WorkflowGen évolutive avec un conteneur de base de données

Architecture évolutive avec un conteneur de base de données
Cette architecture est la mieux adaptée à l'expérience d'automatisation complète et peut aider à réduire les coûts en ayant le conteneur à l'intérieur du cluster plutôt que dans un environnement externe. Il s'agit d'une architecture évolutive dans laquelle les applications Web WorkflowGen peuvent être mises à l'échelle horizontalement et verticalement, les services Windows peuvent être mis à l'échelle verticalement uniquement et la base de données WorkflowGen peut être mise à l'échelle horizontalement jusqu'à deux répliques (lecture / écriture et lecture seule) et verticalement.

Comment déployer

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