# 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](https://helm.sh/docs/intro/install/) (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](https://helm.sh/) :

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

```bash
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](https://helm.sh/docs/helm/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 :

{% tabs %}
{% tab title="YAML" %}

```yaml
image:
  tag: 7.15.5-win-ltsc2019
```

{% endtab %}

{% tab title="JSON" %}

```javascript
{
    "image": {
        "tag": "7.15.5-win-ltsc2019"
    }
}
```

{% endtab %}
{% endtabs %}

Ensuite, vous pouvez transmettre ce fichier à la commande d'installation :

```bash
# 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.

```yaml
# 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.

{% tabs %}
{% tab title="Helm" %}
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 :

```yaml
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](https://docs.workflowgen.com/docker-fr/7.14-7.22/image-workflowgen/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`.
{% endtab %}

{% tab title="Manuel" %}
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**

{% code title="my-configmap.yaml" %}

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

{% endcode %}

{% code title="my-secret.yaml" %}

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

{% endcode %}

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

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

```bash
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 :

{% code title="my-values.yaml" %}

```yaml
workflowgen:
  createConfigMap: false
  configMapNameOverride: my-configmap
  createSecret: false
  secretNameOverride: my-secret
```

{% endcode %}
{% endtab %}
{% endtabs %}

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

{% tabs %}
{% tab title="Helm" %}
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 :

```yaml
workflowgen:
  dataPvcSpec:
    accessModes:
      - ReadWriteMany
    storageClassName: azurefile
    resources:
      requests:
        storage: 50Gi
```

Le contenu de l'objet correspond exactement à [la spécification Kubernetes PersistentVolumeClaim](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#persistentvolumeclaim-v1-core). Ce que vous y écrivez sera pris tel quel dans la définition de l'objet.

{% hint style="info" %}
Dans cet exemple, la classe de stockage `azurefile` est spécifique à Azure Kubernetes Service.
{% endhint %}
{% endtab %}

{% tab title="Manuel" %}
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

{% code title="my-wfg-pvc.yaml" %}

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-wfg-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile
  resources:
    requests:
      storage: 50Gi
```

{% endcode %}

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

```bash
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 :

```yaml
workflowgen:
  createDataPvc: false
  dataPvcNameOverride: my-wfg-pvc
```

{% endtab %}
{% endtabs %}

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

{% hint style="info" %}
L'objet secret doit se trouver dans le même espace de noms que les pods WorkflowGen.
{% endhint %}

```bash
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**

```yaml
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](https://kubernetes.io/docs/concepts/configuration/secret/#best-practices) 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 :

```yaml
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](https://kubernetes.io/docs/concepts/services-networking/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 :

```yaml
workflowgen:
  service:
    kind: LoadBalancer
```

{% hint style="info" %}
Le type `LoadBalancer` fonctionne uniquement avec les fournisseurs de cloud. Pour les clusters sur site, vous devez utiliser une autre technique. 
{% endhint %}

#### 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)](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#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](https://learn.microsoft.com/fr-fr/azure/aks/azure-csi-files-storage-provision#mount-options) de l'article Microsoft [Créer et utiliser un volume avec Azure Files dans Azure Kubernetes Service (AKS)](https://learn.microsoft.com/fr-fr/azure/aks/azure-csi-files-storage-provision) 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 :

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

{% hint style="info" %}
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. 
{% endhint %}

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

```yaml
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.

{% tabs %}
{% tab title="Helm" %}
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 :

```yaml
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](https://docs.workflowgen.com/docker-fr/7.14-7.22/image-workflowgen/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](https://hub.docker.com/_/microsoft-mssql-server). 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.
{% endtab %}

{% tab title="Manuel" %}
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**

{% code title="my-db-configmap.yaml" %}

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

{% endcode %}

{% code title="my-db-secret.yaml" %}

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

{% endcode %}

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

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

```bash
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 :

{% code title="my-values.yaml" %}

```yaml
database:
  createConfigMap: false
  configMapNameOverride: my-db-configmap
  createSecret: false
  secretNameOverride: my-db-secret
```

{% endcode %}
{% endtab %}
{% endtabs %}

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

```yaml
database:
  volumeClaimTemplateSpec:
    accessModes:
      - ReadWriteOnce
    storageClassName: default
    resources:
      requests:
        storage: 100Gi
```

Le contenu du modèle est exactement [la spécification Kubernetes PersistentVolumeClaim](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#persistentvolumeclaim-v1-core). 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)](https://docs.microsoft.com/fr-fr/azure/aks/azure-disks-dynamic-pv) 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 :

```yaml
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](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) »). 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](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) 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 :

```yaml
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](https://docs.microsoft.com/fr-fr/sql/linux/sql-server-linux-configure-docker?view=sql-server-ver15#nonrootuser) 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](https://docs.microsoft.com/fr-fr/sql/linux/sql-server-linux-configure-docker?view=sql-server-ver15#storagepermissions) 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](https://docs.docker.com/engine/security/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](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) 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 :

```yaml
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](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) 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 :

```yaml
ingress:
  enabled: false
```

Sinon, voici un exemple d'utilisation de la section Ingress :

```yaml
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](https://kubernetes.github.io/ingress-nginx/) ou [la page commerciale](https://www.nginx.com/products/nginx/kubernetes-ingress-controller/). 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](https://docs.workflowgen.com/docker-fr/7.14-7.22/kubernetes/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 :

```yaml
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 :

```yaml
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](https://docs.workflowgen.com/docker-fr/7.14-7.22/image-de-mise-a-jour-workflowgen/configuration) pour plus d'informations sur la configuration du conteneur de mise à jour de WorkflowGen.

## Scénarios courants

### Déployer un pod WorkflowGen simple

#### Aperçu

![Déploiement de pod WorkflowGen simple](https://content.gitbook.com/content/CAEFS9T9LtiiLe4X7z8d/blobs/5Eb8aJQQ2zbdB2pwFgDu/helm_guide_single_wfg.png)

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 :

{% code title="my-values.yaml" %}

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

```

{% endcode %}

{% hint style="info" %}

* `MY-WFG-LIC-NUMBER` est une valeur d'espace réservé. Vous devez le remplacer par votre propre numéro de série.<br>
* 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...).<br>
* 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](https://docs.workflowgen.com/docker-fr/7.14-7.22/kubernetes/tls-ssl) de cette section.<br>
* 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)](https://docs.microsoft.com/fr-fr/azure/aks/azure-files-dynamic-pv) pour plus d'informations.
  {% endhint %}

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 :

```bash
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
```

Cela fait, vous pouvez maintenant installer la version :

```
helm install -f ./my-values.yaml wfgen https://github.com/advantys/workflowgen-releases/releases/download/7.18.2/workflowgen-0.0.3.tgz
```

Le dernier argument est le chemin (ou l'URL) de la carte WorkflowGen. Vous pouvez utiliser l'URL directement ou la télécharger et utiliser un chemin local. À partir de ce moment, vous devriez avoir un module WorkflowGen fonctionnel dans votre cluster.

### Déploiement d'une architecture WorkflowGen évolutive

![Déploiement évolutif de pod WorkflowGen](https://content.gitbook.com/content/CAEFS9T9LtiiLe4X7z8d/blobs/yB5C6XrZSBQ4okLGPTk3/helm_guide_scalable_wfg.png)

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

{% code title="my-values.yaml" %}

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

{% endcode %}

{% hint style="info" %}

* `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...).<br>

* 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](https://docs.workflowgen.com/docker-fr/7.14-7.22/kubernetes/tls-ssl) de cette section.<br>

* 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)](https://docs.microsoft.com/fr-fr/azure/aks/azure-files-dynamic-pv) pour plus d'informations.
  {% endhint %}

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 :

```bash
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
```

Cela fait, vous pouvez maintenant installer la version:

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

![Architecture évolutive avec un conteneur de base de données](https://content.gitbook.com/content/CAEFS9T9LtiiLe4X7z8d/blobs/4UvINhLBExgJ2LGISVJG/getting_started_k8s_view.png)

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

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

```

{% hint style="info" %}

* `MY-WFG-LIC-NUMBER` est une valeur d'espace réservé. Vous devez le remplacer par votre propre numéro de série.<br>

* 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](https://docs.workflowgen.com/docker-fr/7.14-7.22/kubernetes/tls-ssl) de cette section.<br>

* 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)](https://docs.microsoft.com/fr-fr/azure/aks/azure-files-dynamic-pv) pour plus d'informations.<br>

* 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)](https://docs.microsoft.com/fr-fr/azure/aks/azure-disks-dynamic-pv) pour plus d'informations.
  {% endhint %}

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 :

```bash
kubectl create secret generic wfgen-license-secret --from-file ./WFG.lic
```

Cela fait, vous pouvez maintenant installer la version :

```bash
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.