Carte Helm WorkflowGen

PrécédentOutils de gestion de cluster SuivantArchitecture mutualisée

Dernière mise à jour il y a 1 an

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

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

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

{
    "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.

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.

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

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

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

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é

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.

É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

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

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é

Recommandations liées aux infrastructures

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

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

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.

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

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

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

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

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.

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

PrécédentOutils de gestion de cluster SuivantArchitecture mutualisée

Dernière mise à jour il y a 1 an