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 :
helm install --set image.tag=7.15.5-win-ltsc2019 release-name ./chart-path
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
image:
  tag: 7.15.5-win-ltsc2019
{
    "image": {
        "tag": "7.15.5-win-ltsc2019"
    }
}
Ensuite, vous pouvez transmettre ce fichier à la commande d'installation :
# YAML
helm install --set-file ./my-values.yaml release-name ./chart-path
​
# JSON
helm install --set-file ./my-values.json release-name ./chart-path
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.
# Default values for WorkflowGen.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
​
# replicaCount Number of replicas to create per deployment of WorkflowGen. Doesn't impact database.
replicaCount: 1
# scalable Deploy WorkflowGen and its database in a scalable architecture.
scalable: true
# 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.
tenantName: ""
​
# workflowgen Configuration related to the WorkflowGen pod.
workflowgen:
  # image Configuration related to the image to be used for the WorkflowGen pod.
  image:
    # repository The repository to use to pull the image.
    repository: advantys/workflowgen
    # tag The image tag to use.
    tag: ""
    # pullPolicy The pull policy to adopt for this image.
    pullPolicy: Always
  # nameOverride Override the name of the chart.
  nameOverride: ""
  # fullnameOverride Override the name of the WorkflowGen deployment. It is based on the name by default.
  fullnameOverride: ""
  # runtimeClassName Runtime class to use with the deployment.
  runtimeClassName: ""
  # strategy The update strategy for the WorkflowGen deployment.
  strategy:
    type: Recreate
  # nodeSelector Node selectors to use for the WorkflowGen pod. WorkflowGen only works on Windows Server.
  nodeSelector:
    kubernetes.io/os: windows
  # annotations Annotations to attach to the WorkflowGen deployment. You can attach annotations to the deployment itself or its template.
  annotations: {}
    # deployment: {}
    # template: {}
  # tolerations Tolerations to apply to the WorkflowGen pod.
  tolerations: []
  # affinity Affinities to apply to the WorkflowGen pod.
  affinity: {}
  # createConfigMap Create a ConfigMap for WorkflowGen's configuration.
  createConfigMap: true
  # configMapNameOverride Override the name of WorkflowGen's ConfigMap.
  configMapNameOverride: ""
  # config The configuration to put in the ConfigMap.
  config: {}
  # createSecret Create a Secret for WorkflowGen's secret values.
  createSecret: true
  # secretNameOverride Override the name of WorkflowGen's Secret.
  secretNameOverride: ""
  # secretMountPath The mount path inside WorkflowGen's containers where to put the secret files.
  secretMountPath: C:\secrets
  # secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
  secret: {}
  # license Configuration related to WorkflowGen's license.
  license:
    # volumeNameOverride Override the name of the license's volume.
    volumeNameOverride: ""
    # secretName The name of the secret that contains WorkfowGen's license.
    secretName: ""
    # items The specific items to use from the secret to inject in WorkflowGen's containers.
    items: []
      # - key: ""
      #   path: ""
  # createDataPvc Create a PersistentVolumeClaim for the data volume of WorkflowGen.
  createDataPvc: true
  # dataPvcNameOverride Override the name of data's PersistentVolumeClaim.
  dataPvcNameOverride: ""
  # dataVolumeNameOverride Override the volume name associated to the PersistentVolumeClaim.
  dataVolumeNameOverride: ""
  # dataPvcSpec The data PersistentVolumeClaim specifications.
  dataPvcSpec: {}
    # accessModes:
    #   - ReadWriteMany
    # storageClassName: storageclass
    # resources:
    #   requests:
    #     storage: 4Gi
  # additionalVolumes Additional volumes to attach to WorkflowGen's deployment.
  additionalVolumes: []
  # additionalVolumeMounts Additional volumes to mount in WorkflowGen's container.
  additionalVolumeMounts: []
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # securityContext The security context of WorkflowGen's container.
  securityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true
    # runAsUser: 1000
    # runAsUserName: ContainerUser
  # resources Configuration related to the resources of the container.
  resources: {}
    # limits:
    #   cpu: '1'
    #   memory: 2Gi
    # requests:
    #   cpu: '1'
    #   memory: 2Gi
  # service Configuration related to the service associated with WorkflowGen's deployment.
  service:
    # type The type of the service.
    type: ClusterIP
    # port The port exposed from the service.
    port: 80
    # clusterIP The cluster IP address to use.
    clusterIP: ""
​
# winServices Configuration related to WorkflowGen's Windows Services deployment. Ignored when release not scalable.
winServices:
  # nameOverride Override the chart name of this deployment.
  nameOverride: ""
  # runtimeClassName Runtime class to use with the deployment.
  runtimeClassName: ""
  # nodeSelector Node selectors to use for the WorkflowGen Windows Services pod. WorkflowGen only works on Windows Server.
  nodeSelector:
    kubernetes.io/os: windows
  # annotations Annotations to attach to the WorkflowGen Windows services deployment.
  annotations: {}
  # fullnameOverride Override the name of the Windows services deployment.
  fullnameOverride: ""
  # tolerations Tolerations to apply to the WorkflowGen Windows services pod.
  tolerations: []
  # affinity Affinities to apply to the WorkflowGen Windows services pod.
  affinity: {}
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # dirSync Configuration related to the directory synchronization Windows service container.
  dirSync:
    # securityContext The security context of the directory synchronization Windows service container.
    securityContext: {}
      # capabilities:
      #   drop:
      #   - ALL
      # readOnlyRootFilesystem: true
      # runAsNonRoot: true
      # runAsUser: 1000
      # runAsUserName: ContainerUser
    # resources Configuration related to the resources of the container.
    resources: {}
      # limits:
      #   cpu: '1'
      #   memory: 2Gi
      # requests:
      #   cpu: '1'
      #   memory: 2Gi
  # engine Configuration related to the engine Windows service container.
  engine:
    # securityContext The security context of the engine Windows service container.
    securityContext: {}
      # capabilities:
      #   drop:
      #   - ALL
      # readOnlyRootFilesystem: true
      # runAsNonRoot: true
      # runAsUser: 1000
      # runAsUserName: ContainerUser
    # resources Configuration related to the resources of the container.
    resources: {}
      # limits:
      #   cpu: '1'
      #   memory: 2Gi
      # requests:
      #   cpu: '1'
      #   memory: 2Gi
​
# database Configuration related to the database deployment.
database:
  # image Configuration related to the image to be used for the database pod.
  image:
    # repository The repository to use to pull the image.
    repository: advantys/workflowgen-sql
    # tag The image tag to use.
    tag: ""
    # pullPolicy The pull policy to adopt for this image.
    pullPolicy: Always
  # create Create a database deployment to be used with the WorkflowGen deployment.
  create: true
  # createConfigMap Create a ConfigMap for the database configuration.
  createConfigMap: true
  # configMapNameOverride Override the name of the database ConfigMap.
  configMapNameOverride: ""
  # config The configuration to put in the ConfigMap.
  config: {}
  # createSecret Create a Secret for the database secret values.
  createSecret: true
  # secretNameOverride Override the name of the database Secret.
  secretNameOverride: ""
  # secretMountPath The mount path inside the database container where to put the secret files.
  secretMountPath: /mnt/secrets
  # secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
  secret: {}
  # useEnv Indicates to use additional environement variables.
  useEnv: false
  # env Definition of the environment variables.
  env: []
    # - name: test
    #   value: value
    # - name: test2
    #   valueFrom:
    #     secretKeyRef:
    #       key: test-key
    #       name: secret-name
    # For MSSQL Linux, you may want to put this here or in the config section:
    # - name: MSSQL_PID
    #   value: Express # You can replace with the edition you want: "Enterprise" or "Developer" or "Express"
  # fullnameOverride Override the name of the database deployment.
  fullnameOverride: ""
  # nameOverride Override the chart name of this deployment.
  nameOverride: ""
  # args The arguments to pass to the database container.
  args: []
  # tolerations Tolerations to apply to the database pod.
  tolerations: []
  # affinity Affinities to apply to the database pod.
  affinity: {}
  # runtimeClassName Runtime class to use with the stateful set.
  runtimeClassName: ""
  # nodeSelector Node selectors to use for the database pod.
  nodeSelector: {}
    # kubernetes.io/os: linux
  # annotations Annotations to attach to the database deployment. You can add annotations for the StatefulSet or its template.
  annotations: {}
    # statefulset: {}
    # template: {}
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # securityContext The security context of the database container.
  securityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true
    # runAsUser: 1000
    # runAsUserName: ContainerUser
    # With MSSQL, you may want to use the mssql (10001) account
    # runAsUser: 10001
    # runAsGroup: 0
    # If you can't configure the volumes with the correct permissions for mssql, you may want to run the container as root:
    # runAsUser: 0
    # runAsGroup: 0
  # resources Configuration related to the resources of the container.
  resources: {}
    # limits:
    #   cpu: '1'
    #   memory: 2Gi
    # requests:
    #   cpu: '1'
    #   memory: 2Gi
  # volumeClaimTemplateSpec PersistentVolumeClaim specification for the StatefulSet PersistentVolumeClaimTemplate.
  volumeClaimTemplateSpec: {}
    # accessModes:
    #   - ReadWriteOnce
    # storageClassName: default
    # resources:
    #   requests:
    #     storage: 4Gi
  # service Configuration related to the database cluster service.
  service:
    # type The type of the service.
    type: ClusterIP
    # port The port exposed from the service.
    port: 1433
    # clusterIP The cluster IP address to use.
    clusterIP: None
​
# imagePullSecrets Secrets to inject in order to pull images from private repositories.
imagePullSecrets: []
​
# ingress Configuration related to the ingress rules.
ingress:
  # enabled Whether or not to enable the ingress rules defined here.
  enabled: true
  # annotations Additional annotations to put on the Ingress object.
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # cert-manager.io/cluster-issuer: letsencrypt
    # kubernetes.io/tls-acme: "true"
  # hosts List of hosts and routes for routing purposes.
  hosts:
    - host: chart-example.local
      paths: []
    # - host: example
    #   paths: []
  # tls List of TLS hosts associated with a secret containing the proper TLS certificates.
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local
​
# hooks Configuration related to the Helm hooks of this chart
hooks:
  # preupgrade
  preupgrade:
    # enabled Enables the use of the pre-upgrade hook which will migrate WorkflowGen's data when upgrading.
    enabled: true
    # image Configuration related to the image to be used for the pre-upgrade pod.
    image:
      # repository The repository to use to pull the image.
      repository: advantys/workflowgen-upgrade
      # tag The image tag to use.
      tag: ""
    # args The arguments to pass to the migration container.
    args: []
    # env Definition of the environment variables.
    env: []
    # - name: test
    #   value: value
    # - name: test2
    #   valueFrom:
    #     secretKeyRef:
    #       key: test-key
    #       name: secret-name
    # connectionStringSecretKey The key to pick for the WFGEN_DATABASE_CONNECTION_STRING environment variable. Defaults to WFGEN_DATABASE_CONNECTION_STRING.
    connectionStringSecretKey: ""
    # secret The secret values to put in the Secret object for this hook. Values will be automatically endoded in base64.
    secret: {}
    # runtimeClassName The name of the RuntimeClass to use with this pod.
    runtimeClassName: ""
    # podSecurityContext The security context for the pod specification.
    podSecurityContext: {}
    # nodeSelector Node selectors to use for the pre-upgrade pod.
    nodeSelector:
      kubernetes.io/os: linux
    # affinity Affinities to apply to the pre-upgrade pod.
    affinity: {}
    # tolerations Tolerations to apply to the pre-upgrade pod.
    tolerations: []
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 :
workflowgen:  
  config:
    WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
    WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
    WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
    WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
  secret:
    WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
    WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
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
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
  WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
  WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
  WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
  WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
my-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  WFGEN_DATABASE_CONNECTION_STRING: U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
  WFGEN_APP_SETTING_ApplicationSerialNumber: TVktV0ZHLUxJQy1OVU1CRVIK
  WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
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
using namespace System.Text
​
function ConvertTo-Base64String {
    [CmdletBinding()]
    [OutputType([string])]
    param (
        [Parameter(Mandatory=$true,ValueFromPipeline=$true)]
        [ValidateNotNullOrEmpty()]
        [string]$Value
    )
​
    process {
        return [Convert]::ToBase64String([Encoding]::UTF8.GetBytes($Value))
    }
}
​
'Server=some.sql.server.com,1433;...' | ConvertTo-Base64String # U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
'MY-WFG-LIC-NUMBER' | ConvertTo-Base64String # TVktV0ZHLUxJQy1OVU1CRVIK
'1f73c842692f436b92411641c46fb338' | ConvertTo-Base64String # MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
Bash
echo 'Server=some.sql.server.com,1433;...' | base64 # U2VydmVyPXNvbWUuc3FsLnNlcnZlci5jb20sMTQzMzsuLi4K
echo 'MY-WFG-LIC-NUMBER' | base64 # TVktV0ZHLUxJQy1OVU1CRVIK
echo '1f73c842692f436b92411641c46fb338' | base64 # MWY3M2M4NDI2OTJmNDM2YjkyNDExNjQxYzQ2ZmIzMzgK
Étape 2 : Créez les objets à partir des fichiers
Ensuite, vous devez déployer les objets à l'aide de la commande suivante :
kubectl apply -f ./my-configmap.yaml
kubectl apply -f ./my-secret.yaml
É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
workflowgen:
  createConfigMap: false
  configMapNameOverride: my-configmap
  createSecret: false
  secretNameOverride: my-secret
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 :
workflowgen:
  dataPvcSpec:
    accessModes:
      - ReadWriteMany
    storageClassName: azurefile
    resources:
      requests:
        storage: 50Gi
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
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-wfg-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile
  resources:
    requests:
      storage: 50Gi
Étape 2 : Déployez la définition dans le cluster
kubectl apply -f ./my-wfg-pvc.yaml
É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 :
workflowgen:
  createDataPvc: false
  dataPvcNameOverride: my-wfg-pvc
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.
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
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
workflowgen:
  license:
    secretName: wfgen-license-secret
    items:
      - key: WFG.lic
        path: WFG.lic
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 :
workflowgen:
  image:
    reference: mycorporation/workflowgen
    tag: 7.18.3-win-ltsc2019
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 :
workflowgen:
  service:
    kind: LoadBalancer
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 :
workflowgen:
  resources:
    limits:
      cpu: '1'
      memory: 2Gi
    requests:
      cpu: '1'
      memory: 2Gi
​
# Used when "scalable: true"
winServices:
  dirSync:
    resources:
      limits:
        cpu: '1'
        memory: 1Gi
      requests:
        cpu: '500M'
        memory: 1Gi
  engine:
    resources:
      limits:
        cpu: '1'
        memory: 1Gi
      requests:
        cpu: '500M'
        memory: 1Gi
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 :
database:
  create: false
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 :
database:  
  config:
    ACCEPT_EULA: 'Y'
    SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
    WFGEN_DATABASE_USER_USERNAME_FILE: /mnt/secrets/WFGEN_DATABASE_USER_USERNAME
    WFGEN_DATABASE_USER_PASSWORD_FILE: /mnt/secrets/WFGEN_DATABASE_USER_PASSWORD
    WFGEN_ADMIN_PASSWORD_FILE: /mnt/secrets/WFGEN_ADMIN_PASSWORD
  secret:
    SA_PASSWORD: 'strong(!)Pass'
    WFGEN_DATABASE_USER_PASSWORD: 'strong(!)Pass'
    WFGEN_ADMIN_PASSWORD: 'strong(!)Pass'
    WFGEN_DATABASE_USER_USERNAME: WFGEN_USER
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
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-db-configmap
data:
  ACCEPT_EULA: 'Y'
  SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
  WFGEN_DATABASE_USER_USERNAME_FILE: /mnt/secrets/WFGEN_DATABASE_USER_USERNAME
  WFGEN_DATABASE_USER_PASSWORD_FILE: /mnt/secrets/WFGEN_DATABASE_USER_PASSWORD
  WFGEN_ADMIN_PASSWORD_FILE: /mnt/secrets/WFGEN_ADMIN_PASSWORD
my-db-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-db-secret
type: Opaque
data:
  SA_PASSWORD: c3Ryb25nKCEpUGFzcwo=
  WFGEN_DATABASE_USER_PASSWORD: c3Ryb25nKCEpUGFzcwo=
  WFGEN_ADMIN_PASSWORD: c3Ryb25nKCEpUGFzcwo=
  WFGEN_DATABASE_USER_USERNAME: V0ZHRU5fVVNFUgo=
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
using namespace System.Text
​
function ConvertTo-Base64String {
    [CmdletBinding()]
    [OutputType([string])]
    param (
        [Parameter(Mandatory=$true,ValueFromPipeline=$true)]
        [ValidateNotNullOrEmpty()]
        [string]$Value
    )
​
    process {
        return [Convert]::ToBase64String([Encoding]::UTF8.GetBytes($Value))
    }
}
​
'strong(!)Pass' | ConvertTo-Base64String # c3Ryb25nKCEpUGFzcwo=
'WFGEN_USER' | ConvertTo-Base64String # V0ZHRU5fVVNFUgo=
Bash
echo 'strong(!)Pass' | base64 # c3Ryb25nKCEpUGFzcwo=
echo 'WFGEN_USER' | base64 # V0ZHRU5fVVNFUgo=
Étape 2 : Créez les objets à partir des fichiers
Ensuite, vous devez déployer les objets à l'aide de la commande suivante :
kubectl apply -f ./my-db-configmap.yaml
kubectl apply -f ./my-db-secret.yaml
É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
database:
  createConfigMap: false
  configMapNameOverride: my-db-configmap
  createSecret: false
  secretNameOverride: my-db-secret
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 :
database:
  volumeClaimTemplateSpec:
    accessModes:
      - ReadWriteOnce
    storageClassName: default
    resources:
      requests:
        storage: 100Gi
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 :
database:
  image:
    reference: mycorporation/workflowgen-sql
    tag: 7.18.3-ubuntu-18.04
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 :
database:
  fullnameOverride: my-database
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 :
database:
  resources:
    limits:
      cpu: '2'
      memory: 4Gi
    requests:
      cpu: '1'
      memory: 2Gi
É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 :
ingress:
  enabled: false
Sinon, voici un exemple d'utilisation de la section Ingress :
ingress:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt
  hosts:
    - host: &wfgenHost myinstance.example.com
      paths:
        - /
  tls:
    - secretName: tls-secret
      hosts:
        - *wfgenHost
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 :
hooks:
  preupgrade:
    enabled: false
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 :
hooks:
  preupgrade:
    image:
      tag: latest-ubuntu-18.04
    secret:
      WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
      mysecret: something secret
    env:
      - name: WFGEN_UPGRADE_EXCLUDE_FILES
        value: file1,file2
      - name: MY_SECRET_ENV
        valueFrom:
          secretKeyRef:
            name: wfgen-migrations-secret # If release name is "wfgen"
            key: mysecret
    args:
      - "-FromVersion"
      - "7.14.10"
      - "-ToVersion"
      - "7.18.2"
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
scalable: false
​
workflowgen:
  resources:
    limits:
      cpu: '1'
      memory: '2Gi'
    requests:
      cpu: '1'
      memory: '2Gi'
  config:
    WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
    WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
    WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
    WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
  secret:
    WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
    WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
  license:
    secretName: wfgen-license-secret
    items:
      - key: WFG.lic
        path: WFG.lic
  dataPvcSpec:
    accessModes:
      - ReadWriteMany
    storageClassName: azurefile
    resources:
      requests:
        storage: 50Gi
  service:
    type: LoadBalancer
  
database:
  create: false
  
ingress:
  enabled: false
​
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 :
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
Cela fait, vous pouvez maintenant installer la version :
helm install -f ./my-values.yaml wfgen https://github.com/advantys/workflowgen-releases/releases/download/7.18.2/workflowgen-0.0.3.tgz
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
replicaCount: 3
​
workflowgen:
  resources:
    limits:
      cpu: '1'
      memory: '2Gi'
    requests:
      cpu: '1'
      memory: '2Gi'
  config:
    WFGEN_APP_SETTING_ApplicationUrl: https://example.com/wfgen
    WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSerialNumber
    WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
    WFGEN_GEN_APP_SYM_ENCRYPT_KEY: 'N'
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey
  secret:
    WFGEN_DATABASE_CONNECTION_STRING: 'Server=some.sql.server.com,1433;...'
    WFGEN_APP_SETTING_ApplicationSerialNumber: MY-WFG-LIC-NUMBER
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey: 1f73c842692f436b92411641c46fb338
  license:
    secretName: wfgen-license-secret
    items:
      - key: WFG.lic
        path: WFG.lic
  dataPvcSpec:
    accessModes: