7.14 à 7.22
Documentation Forum Support

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 (disponible en anglais uniquement) sur le site Web de Helm pour savoir comment l'installer. Seules les versions Helm 3.0 et ultérieures sont supportées.

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 :

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.

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.

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.

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.

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, consultez 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 la section Options de montage de l'article Microsoft Créer et utiliser un volume 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.

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.

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

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

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:
      - ReadWriteMany
    storageClassName: azurefile
    resources:
      requests:
        storage: 50Gi
  service:
    type: LoadBalancer
    
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

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.

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 :

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

replicaCount: 3

workflowgen:
  resources:
    limits:
      cpu: '1'
      memory: 2Gi
    requests:
      cpu: '1'
      memory: 2Gi
  config:
    WFGEN_APP_SETTING_ApplicationUrl: http://10.0.1.1/wfgen
    WFGEN_DATABASE_CONNECTION_STRING_FILE: C:\secrets\WFGEN_DATABASE_CONNECTION_STRING
    WFGEN_APP_SETTING_ApplicationSerialNumber_FILE: C:\secrets\ApplicationSerialNumber
    WFGEN_APP_SETTING_ApplicationSecurityPasswordSymmetricEncryptionKey_FILE: C:\secrets\ApplicationSecurityPasswordSymmetricEncryptionKey
    WFGEN_MACHINE_KEY_DECRYPTION_KEY_FILE: C:\secrets\WFGEN_MACHINE_KEY_DECRYPTION_KEY
    WFGEN_MACHINE_KEY_VALIDATION_KEY_FILE: C:\secrets\WFGEN_MACHINE_KEY_VALIDATION_KEY
  secret:
    ApplicationSerialNumber: <YOUR_WFG_LIC_KEY>
    ApplicationSecurityPasswordSymmetricEncryptionKey: <YOUR_NEW_GUID>
    WFGEN_DATABASE_CONNECTION_STRING: 'Server=wfgen-database-0.wfgen-database.default.svc.cluster.local,1433;Database=WFGEN;User ID=WFGEN_USER;Password=strong(!)Pass;'
    WFGEN_MACHINE_KEY_DECRYPTION_KEY: '39B3AE9CCCF94AA47D795EC84F7CCB7928F5D59BE2EB2BBA4FE2AC0B3C8D0C85'
    WFGEN_MACHINE_KEY_VALIDATION_KEY: '82F6247A5DBF8666FB60B8EFE6483360436F0EC426CC0351A9569C607B46C1FAD6497406DD8B0B519DD83CAA6764904C89999D742638ECE756E7C0B8799B45E9'
  license:
    secretName: wfgen-license-secret
    items:
      - key: WorkflowGen.lic
        path: WorkflowGen.lic
  dataPvcSpec:
    accessModes:
      - ReadWriteMany
    storageClassName: azurefile
    resources:
      requests:
        storage: 50Gi
  service:
    type: LoadBalancer

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

database:
  fullnameOverride: wfgen-database
  nodeSelector:
    kubernetes.io/os: linux
  securityContext:
    runAsUser: 0
    runAsGroup: 0
  resources:
    limits:
      cpu: '1'
      memory: 2Gi
    requests:
      cpu: '500m'
      memory: 1Gi
  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
  volumeClaimTemplateSpec:
    accessModes:
      - ReadWriteOnce
    storageClassName: default
    resources:
      requests:
        storage: 100Gi

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.

  • Le modèle de revendication de volume persistant utilisé dans la partie base de données utilise une classe de stockage appelée default. Il est présent par défaut sur un cluster Azure Kubernetes Service et représente le service Azure Disks. Voir l'article Microsoft Créer et utiliser un volume persistant de manière dynamique avec des disques Azure sur Azure Kubernetes Service (AKS) pour plus d'informations.

Il s'agit du même exemple que précédemment, sauf qu'une section de base de données a été ajoutée. Le contexte de sécurité spécifie que le conteneur doit s'exécuter en tant que root. Cela devrait être évité en tant que bonne pratique de sécurité générale. C'est là pour la simplicité. Vous devez toujours utiliser un utilisateur différent de root et vérifier les autorisations sur les volumes, par exemple avec un conteneur init.

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 :

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 pod WorkflowGen fonctionnel dans votre cluster.

PrécédentOutils de gestion de clusterSuivantArchitecture mutualisée

Dernière mise à jour