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

Ansible

Puppet

À 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.
Dernière mise à jour 10mo ago