Configuration

Rechercher…
7.14 à 7.22
Configuration
Aperçu
Cette section explique comment configurer complètement un conteneur de base de données WorkflowGen. Tout est configurable via une variable d'environnement.
Cette image est basée sur microsoft/mssql-server-windows-express (SQL Server 2017) pour la version Windows LTSC 2019 et sur mcr.microsoft.com/mssql/server (SQL Server 2019) pour la version Linux (Ubuntu 18.04).

Pour supporter Windows LTSC 2019, l'image de base a été reconstruite à l'aide du Dockerfile open source et hébergée sur le référentiel Docker Hub d'Advantys. Par conséquent, l'image de base réelle est advantys/mssql-server-windows-express.

La version Windows de cette image est destinée au développement et aux tests uniquement. Pour les charges de travail de production, utilisez la version Linux.
Variables d'environnement
Variables spécifiques aux images de base
Certaines variables sont disponibles dans les images de base qui fournissent des fonctionnalités liées à SQL Server. Pour la version Linux, voir la page Docker Hub mcr.microsoft.com/mssql/server et l'article Microsoft Configurer des images de conteneur SQL Server sur Docker. Pour la version Windows, voir la page Docker Hub microsoft/mssql-server-windows-express. 
Certaines variables d'environnement dans les images de base sont requises. Par exemple, vous devez fournir une valeur pour la variable d'environnement SA_PASSWORD.
Variables spécifiques à WorkflowGen
Le conteneur de base de données WorkflowGen ajoute des variables d'environnement spéciales pour activer des fonctionnalités supplémentaires liées à WorkflowGen. Le tableau suivant fournit des descriptions pour chacun d'eux :
Variable
Description et valeurs
WFGEN_DATABASE_NAME
Le nom de la base de données WorkflowGen
​
Valeur par défaut : WFGEN
WFGEN_DATABASE_CONTAINMENT
Définit la base de données WorkflowGen pour contenir les utilisateurs de base de données pour plus de portabilité (voir l'article Microsoft Authentification de la base de données autonome (option de configuration de serveur) pour plus d'informations)
​
Valeurs possibles : Y (par défaut), N
WFGEN_DATABASE_USER_USERNAME
Le nom d'utilisateur de l'utilisateur de la base de données qui a accès à la base de données WorkflowGen
​
Valeur par défaut :WFGEN_USER
WFGEN_DATABASE_USER_PASSWORD
Variable requise

Le mot de passe de l'utilisateur de la base de données qui a accès à la base de données WorkflowGen
WFGEN_DATABASE_FILE_PATH
Ne pas modifier pour la version Linux
​
Chemin d'accès interne aux fichiers de base de données .mdf et .ldf à l'intérieur du conteneur
​
Valeur par défaut :
Windows : C:\wfgen\sql
Linux : /var/opt/mssql/data
WFGEN_ADMIN_USERNAME
Le nom d'utilisateur de l'utilisateur administratif WorkflowGen
​
Valeur par défaut : wfgen_admin
WFGEN_ADMIN_PASSWORD
Variable requise
​
Le mot de passe de l'utilisateur administratif WorkflowGen
WFGEN_AUTH_APPLICATION
Indique si la méthode d'authentification de WorkflowGen est applicative ou non
​
Valeurs possibles :Y (par défaut), N
Variables d'environnement basées sur le format
Secrets
Lorsque vous utilisez un orchestrateur tel que Kubernetes, vous souhaiterez probablement sécuriser des secrets à l'aide de leurs outils de gestion des secrets intégrés. Suivez le guide spécifique de votre orchestrateur pour savoir comment créer un secret.
Pour Kubernetes, voir https://kubernetes.io/docs/concepts/configuration/secret/.
Il est recommandé d'injecter des secrets dans des conteneurs WorkflowGen sous forme de fichiers car ils ne seront pas exposés en tant que variables d'environnement et ils seront supprimés du conteneur lorsqu'il sera arrêté ou supprimé.
La gestion des secrets est possible uniquement au moyen d'un orchestrateur.
Afin d'obtenir la valeur secrète dans le fichier, vous devez suffixer toute variable d'environnement dont vous souhaitez obtenir la valeur de cette manière avec _FILE et définir sa valeur sur le chemin du fichier contenant le secret. Le conteneur obtiendra ensuite la valeur dans le fichier au chemin spécifié et définira la variable d'environnement sans le suffixe avec cette valeur.
Par exemple, supposons que vous souhaitiez définir un mot de passe de compte sa dans SQL Server sur Strong(!)Pass en utilisant la variable d'environnement SA_PASSWORD, mais que vous souhaitez utiliser un secret pour la valeur. Tout ce que vous avez à faire est de suffixer le nom de la variable d'environnement avec _FILE pour qu'il devienne SA_PASSWORD_FILE. Ensuite, définissez la valeur de cette variable sur le chemin du fichier contenant le mot de passe.
📌 Exemple avec l'orchestrateur Docker Swarm
PowerShell
Bash
1
# Create the secret for the license serial number
2
'strong(!)Pass' | docker secret create SA_PASSWORD -
3
​
4
# Create the container service in Docker Swarm
5
docker service create `
6
    # ...
7
    --env WFGEN_APP_SETTING_ApplicationSerialNumber_FILE=/run/secrets/SA_PASSWORD `
8
    --secret SA_PASSWORD `
9
    # ...
10
    advantys/workflowgen-sql:7.18.3-ubuntu-18.04
Copied!
1
# Create the secret for the license serial number
2
echo 'strong(!)Pass' | docker secret create SA_PASSWORD -
3
​
4
# Create the container service in Docker Swarm
5
docker service create \
6
    # ...
7
    --env WFGEN_APP_SETTING_ApplicationSerialNumber_FILE=/run/secrets/SA_PASSWORD \
8
    --secret SA_PASSWORD \
9
    # ...
10
    advantys/workflowgen-sql:7.18.3-ubuntu-18.04
Copied!
Pour Kubernetes, vous créez un ConfigMap qui complète votre secret comme ceci :
1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
  name: database-config
5
data:
6
  SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
7
---
8
apiVersion: v1
9
kind: Secret
10
type: Opaque
11
metadata:
12
  name: database-secret
13
data:
14
  # "c3Ryb25nKCEpUGFzcwo=" is the base64-encoded value of "strong(!)Pass"
15
  SA_PASSWORD: 'c3Ryb25nKCEpUGFzcwo='
16
​
Copied!
Ensuite, vous devez mapper le ConfigMap en tant que variables d'environnement et monter le secret en tant que volume comme ceci :
1
apiVersion: apps/v1
2
kind: StatefulSet
3
metadata:
4
  name: wfgen-database
5
spec:
6
  selector:
7
    matchLabels:
8
      # ...
9
  template:
10
    metadata:
11
      labels:
12
        # ...
13
    spec:
14
      containers:
15
        - name: database
16
          image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
17
          # ...
18
          envFrom: # ConfigMap as environment variables
19
            - configMapRef:
20
                name: database-config
21
          # ...
22
          volumeMounts:
23
            # ...
24
            - mountPath: /mnt/secrets # Mount Secret as a volume
25
              readOnly: true
26
              name: secrets
27
      volumes:
28
        # ...
29
        - name: secrets # Mount Secret as a volume
30
            secret:
31
              secretName: database-secret
Copied!
Utilisation d'un orchestrateur
Kubernetes
Kubernetes a également un objet intégré appelé ConfigMap pour gérer la configuration des pods (capsules). Voir l'article Kubernetes Configure a Pod to Use a ConfigMap pour plus d'informations et comment l'utiliser. Vous devez utiliser cet objet pour configurer les variables d'environnement pour WorkflowGen.
Vous pouvez également gérer les informations sensibles en les protégeant davantage dans l'orchestrateur dans une zone sécurisée. Consultez l'article Kubernetes Secrets pour plus d'informations et d'instructions sur son utilisation. Vous devez utiliser cet objet pour protéger des informations sensibles telles que la clé de licence WorkflowGen, les noms d'utilisateur, les mots de passe, les clés cryptographiques, les clés API, etc...
Utilisation d'un gestionnaire de configuration externe
Certains gestionnaires de configuration populaires supportent les conteneurs Docker prêts à l'emploi. Voici quelques liens vers leur documentation spécifique pour vous aider à démarrer :
Chef
​Docker Cookbook - Chef Supermarket​
​Chef and Kubernetes​
Ansible
​Ansible and Docker​
​k8s – Manage Kubernetes (K8s) objects​
Puppet
​Puppet in Docker: running Puppet on container-centric infrastructure​
​Installing Kubernetes with the (certified!) Puppet Kubernetes module​
À propos des fonctions de sécurité
La version Linux de la base de données possède certaines fonctionnalités de sécurité qui peuvent être utilisées pour améliorer la sécurité globale de la base de données. Pour plus d'informations sur les fonctionnalités de sécurité de SQL Server pour Linux, consultez l'article Configurer des images de conteneur SQL Server sur Docker dans la documentation Microsoft SQL Server.
La version Windows du conteneur n'a pas les fonctionnalités de sécurité de la version Linux. Il est conseillé d'utiliser la version Windows uniquement à des fins de développement et de test.
Performance et haute disponibilité
Vous pouvez configurer la réplication avec ce conteneur, mais vous devrez créer une image personnalisée. Pour plus d'informations sur la création d'une image personnalisée, voir la page Image personnalisée de cette section. Pour plus d'informations sur la configuration de la réplication dans SQL Server, voir l'article Configurer un groupe de disponibilité SQL Server pour l’échelle lecture sur Linux dans la documentation Microsoft.
Utilisation avec Kubernetes
Vous devez toujours déployer le conteneur de base de données dans un StatefulSet afin que chaque conteneur ait son propre stockage séparé. Il garantit également que chaque conteneur possède un nom DNS unique à l'intérieur du cluster afin qu'il puisse être facilement trouvé par d'autres conteneurs. Vous pouvez également configurer chacune des instances en fonction d'un identifiant incrémentiel afin de pouvoir définir une instance en lecture / écriture et plusieurs instances en lecture seule. Voici un exemple d'un déploiement StatefulSet simple avec le conteneur de base de données WorkflowGen :
1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: database
5
spec:
6
  type: ClusterIP
7
  clusterIP: None
8
  ports:
9
    - port: 1433
10
      targetPort: mssql
11
      protocol: TCP
12
      name: mssql
13
  selector:
14
    app.kubernetes.io/name: workflowgen
15
    app.kubernetes.io/component: database
16
---
17
apiVersion: apps/v1
18
kind: StatefulSet
19
metadata:
20
  name: database
21
spec:
22
  replicas: 1
23
  serviceName: database
24
  selector:
25
    matchLabels:
26
      app.kubernetes.io/name: workflowgen
27
      app.kubernetes.io/component: database
28
  template:
29
    metadata:
30
      labels:
31
        app.kubernetes.io/name: workflowgen
32
        app.kubernetes.io/component: database
33
    spec:
34
      terminationGracePeriodSeconds: 10
35
      nodeSelector:
36
        kubernetes.io/os: linux
37
      containers:
38
        - name: database
39
          image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
40
          imagePullPolicy: Always
41
          securityContext:
42
            runAsUser: 0
43
            runAsGroup: 0
44
          resources:
45
            requests:
46
              memory: "1Gi"
47
              cpu: "500m"
48
            limits:
49
              memory: "2Gi"
50
              cpu: "1"
51
          envFrom:
52
            - configMapRef:
53
                name: database-config
54
          ports:
55
            - name: mssql
56
              containerPort: 1433
57
          livenessProbe:
58
            initialDelaySeconds: 30
59
            timeoutSeconds: 5
60
            exec:
61
              command:
62
                - pwsh
63
                - -NoLogo
64
                - -NoProfiles
65
                - /usr/local/bin/healthcheck.ps1
66
          readinessProbe:
67
            initialDelaySeconds: 20
68
            timeoutSeconds: 5
69
            exec:
70
              command:
71
                - pwsh
72
                - -NoLogo
73
                - -NoProfiles
74
                - /usr/local/bin/healthcheck.ps1
75
          volumeMounts:
76
            - mountPath: /var/opt/mssql
77
              name: sqldata
78
            - mountPath: /mnt/secrets
79
              readOnly: true
80
              name: secrets
81
      volumes:
82
        - name: secrets
83
            secret:
84
              secretName: database-sec
85
  volumeClaimTemplates:
86
    - metadata:
87
        name: sqldata
88
      spec:
89
        accessModes:
90
          - ReadWriteOnce
91
        storageClassName: default
92
        resources:
93
          requests:
94
            storage: 100Gi
Copied!
Vous pouvez utiliser cet exemple comme point de départ pour configurer plusieurs conteneurs de base de données. Pour plus d'informations sur StatefulSets, voir l'article StatefulSets dans la documentation Kubernetes. Vous aurez peut-être besoin d'un code personnalisé pour pouvoir configurer correctement plusieurs instances. Voir la page Image personnalisée de cette section pour plus d'informations sur la façon d'ajouter du code personnalisé au conteneur.