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, consultez la page Docker Hub mcr.microsoft.com/mssql/server et l'article Microsoft Déployer et se connecter à des conteneurs Linux SQL Server. Pour la version Windows, consultez 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é (consultez l'article Microsoft contained database authentication (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, consultez 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

# Create the secret for the license serial number
'strong(!)Pass' | docker secret create SA_PASSWORD -

# Create the container service in Docker Swarm
docker service create `
    # ...
    --env WFGEN_APP_SETTING_ApplicationSerialNumber_FILE=/run/secrets/SA_PASSWORD `
    --secret SA_PASSWORD `
    # ...
    advantys/workflowgen-sql:7.18.3-ubuntu-18.04

Bash

Pour Kubernetes, vous créez un ConfigMap qui complète votre secret comme ceci :

apiVersion: v1
kind: ConfigMap
metadata:
  name: database-config
data:
  SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: database-secret
data:
  # "c3Ryb25nKCEpUGFzcwo=" is the base64-encoded value of "strong(!)Pass"
  SA_PASSWORD: 'c3Ryb25nKCEpUGFzcwo='

Ensuite, vous devez mapper le ConfigMap en tant que variables d'environnement et monter le secret en tant que volume comme ceci :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wfgen-database
spec:
  selector:
    matchLabels:
      # ...
  template:
    metadata:
      labels:
        # ...
    spec:
      containers:
        - name: database
          image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
          # ...
          envFrom: # ConfigMap as environment variables
            - configMapRef:
                name: database-config
          # ...
          volumeMounts:
            # ...
            - mountPath: /mnt/secrets # Mount Secret as a volume
              readOnly: true
              name: secrets
      volumes:
        # ...
        - name: secrets # Mount Secret as a volume
            secret:
              secretName: database-secret

Utilisation d'un orchestrateur

Kubernetes

Kubernetes a également un objet intégré appelé ConfigMap pour gérer la configuration des pods (capsules). Consultez 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 and Kubernetes

Ansible

• Ansible and Docker

• k8s – Manage Kubernetes (K8s) objects

Puppet

• How to run Puppet in Docker

• How to Install and Configure Kubernetes with the 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 Déployer et se connecter à des conteneurs Linux SQL Server 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, consultez 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 :

apiVersion: v1
kind: Service
metadata:
  name: database
spec:
  type: ClusterIP
  clusterIP: None
  ports:
    - port: 1433
      targetPort: mssql
      protocol: TCP
      name: mssql
  selector:
    app.kubernetes.io/name: workflowgen
    app.kubernetes.io/component: database
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  replicas: 1
  serviceName: database
  selector:
    matchLabels:
      app.kubernetes.io/name: workflowgen
      app.kubernetes.io/component: database
  template:
    metadata:
      labels:
        app.kubernetes.io/name: workflowgen
        app.kubernetes.io/component: database
    spec:
      terminationGracePeriodSeconds: 10
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: database
          image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
          imagePullPolicy: Always
          securityContext:
            runAsUser: 0
            runAsGroup: 0
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "2Gi"
              cpu: "1"
          envFrom:
            - configMapRef:
                name: database-config
          ports:
            - name: mssql
              containerPort: 1433
          livenessProbe:
            initialDelaySeconds: 30
            timeoutSeconds: 5
            exec:
              command:
                - pwsh
                - -NoLogo
                - -NoProfiles
                - /usr/local/bin/healthcheck.ps1
          readinessProbe:
            initialDelaySeconds: 20
            timeoutSeconds: 5
            exec:
              command:
                - pwsh
                - -NoLogo
                - -NoProfiles
                - /usr/local/bin/healthcheck.ps1
          volumeMounts:
            - mountPath: /var/opt/mssql
              name: sqldata
            - mountPath: /mnt/secrets
              readOnly: true
              name: secrets
      volumes:
        - name: secrets
            secret:
              secretName: database-sec
  volumeClaimTemplates:
    - metadata:
        name: sqldata
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: default
        resources:
          requests:
            storage: 100Gi

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