Ce guide fournit des instructions sur la configuration, le déploiement et la gestion des intégrations de WorkflowGen avec Docker.

Aperçu

Cette section fournit des instructions sur comment exécuter rapidement le conteneur WorkflowGen avec une architecture minimale sur votre ordinateur local.

Prérequis globaux

• Assurez-vous d'avoir une licence WorkflowGen valide.

• Si vous utilisez Windows Server, assurez-vous qu'il s'agit bien de Windows Server 2019 et utilisez la balise correspondant à cette version. Par exemple, pour Windows Server 2019, utilisez la balise qui se termine par ltsc2019.

Déploiement manuel de Docker sur une machine locale

Aperçu de l'architecture

À la fin de cette section, l’architecture suivante sera déployée sur votre ordinateur local :

Dans le moteur Docker de votre ordinateur, vous aurez un serveur WorkflowGen en cours d'exécution et une base de données WorkflowGen qui utiliseront des volumes mappés sur votre ordinateur local pour conserver les fichiers de données.

Prérequis

Assurez-vous d'avoir installé Docker sur votre ordinateur.

Pour Windows 10 Pro

Suivez les instructions dans le guide (disponible en anglais uniquement) pour installer Docker pour Windows. Vous devez utiliser des conteneurs Windows, donc vous devez utiliser au minimum Windows 10 Pro.

Pour Windows Server

Suivez les instructions dans le guide pour installer Docker sur Windows Server.

Pour cette configuration, il est recommandé d'utiliser l'image Docker de la base de données de WorkflowGen. Vous pouvez également utiliser une base de données SQL installée sur votre ordinateur local.

Exécutez le conteneur de base de données

Pour télécharger l'image de la base de données sur votre ordinateur local, ouvrez PowerShell et entrez ce qui suit :

Pour que WorkflowGen fonctionne, vous devez exécuter la base de données avant d'exécuter WorkflowGen. Avant de créer le conteneur, vous allez créer un volume Docker afin d'externaliser les fichiers de base de données (.mdf et .ldf). Cela garantira que les données sont toujours là après la suppression du conteneur.

L'emplacement physique du volume peut être obtenu à l'aide de la commande suivante :

Généralement, il sera stocké dans C:\ProgramData\Docker\volumes\sqldata\_data. Assurez-vous que le conteneur dispose d'un accès en écriture à ce répertoire (voir l'article Microsoft pour plus d'informations).

Vous êtes maintenant prêt à exécuter le conteneur de base de données. Pour ce faire, exécutez la commande suivante :

Cette dernière commande définira les mots de passe de l'utilisateur SA de la base de données, de l'utilisateur de la base de données WFGEN_USER et du compte wfgen_admin WorkflowGen sur strong(!)Pass. Selon la nature de Docker, les variables d’environnement SA_PASSWORD et ACCEPT_EULA proviennent du conteneur de base microsoft/mssql-server-windows-express et ne sont pas directement traitées par le conteneur WorkflowGen.

Exécutez le conteneur WorkflowGen

Entrez ce qui suit pour télécharger l’image WorkflowGen :

Pour ce conteneur, vous avez besoin de trois volumes afin de conserver correctement les données WorkflowGen :

• Licences WorkflowGen (licences)

• Les données WorkflowGen (data), qui contiennent les éléments suivants :

  • Le dossier App_data (appdata

Vous devez maintenant copier votre licence WorkflowGen dans le volume de licences. Pour ce faire, exécutez la commande suivante :

De cette façon, le conteneur WorkflowGen pourra récupérer la license via le volume. Vous avez également besoin d'une clé de chiffrement pour le conteneur. Utilisez la commande suivante pour en générer une :

Pour exécuter le conteneur actuel, remplacez <YOUR_WFG_LIC_KEY> par votre clé de licence WorkflowGen et <YOUR_NEW_GUID> par le GUID que vous avez généré à l'étape précédente, puis exécutez la commande suivante :

Lorsque le conteneur est prêt, ouvrez un navigateur et accédez à http://localhost:8080/wfgen, où vous serez invité à vous authentifier par WorkflowGen. Par défaut, le conteneur est configuré avec la méthode d'authentification applicative.

Fermez les conteneurs

Une fois que vous avez terminé avec cet environnement, vous pouvez fermer les conteneurs en les arrêtant. Ils peuvent être redémarrés plus tard.

Enlevez les conteneurs

Pour supprimer complètement les conteneurs, exécutez la commande suivante :

Cela supprimera la base de données et les conteneurs WorkflowGen, y compris toute modification manuelle du système de fichiers du conteneur qui ne fait pas partie d'un volume. Même si les conteneurs ne sont plus là, les données des volumes sont conservées et peuvent être utilisées par d'autres conteneurs. Par exemple, vous pouvez lancer trois autres conteneurs WorkflowGen qui utilisent les mêmes volumes et ils obtiendront tous exactement les mêmes fichiers au point de montage du volume.

Déploiement Docker Compose sur une machine locale

Cette section décrit la méthode recommandée pour déployer facilement un environnement de développement local sans avoir à entrer beaucoup de commandes. Pour en savoir plus sur Docker Compose, consultez la (disponible en anglais uniquement).

Aperçu de l'architecture

À la fin de cette section, l’architecture suivante sera déployée sur votre ordinateur local :

Dans le moteur Docker de votre ordinateur, vous aurez un serveur WorkflowGen en fonctionnement et une base de données WorkflowGen. Ces deux conteneurs utiliseront des volumes mappés sur votre ordinateur local pour conserver les fichiers de données.

Prérequis

Pour Windows 10 Pro

Suivez les instructions dans le guide pour installer Docker pour Windows. Vous devez utiliser des conteneurs Windows, donc vous devez utiliser au minimum Windows 10 Pro.

Pour Windows Server

Suivez les instructions dans le guide pour installer Docker sur Windows Server.

Pour Windows Server uniquement, vous devez également installer l’outil Docker Compose, car il n’est pas installé par défaut. Suivez les instructions pour Windows Server dans le guide . Pour vérifier que Docker Compose est correctement installé, exécutez la commande suivante

Pour cette configuration, il est recommandé d'utiliser l'image Docker de la base de données de WorkflowGen. Vous pouvez également utiliser une base de données SQL installée sur votre ordinateur local.

Créez le volume de licences

Avant de créer les services, vous devez créer le volume de licences en externe à partir de la composition afin que les licences soient présentes au moment de la création du conteneur. Pour ce faire, exécutez la commande suivante:

Ensuite, vous devez copier votre fichier de licence dans le répertoire des licences. La commande suivante vous montrera où la licence sera stockée :

Pour copier votre licence, exécutez la commande suivante :

Créez la clé de chiffrement symétrique

Cette valeur devrait être générée par vous. Un simple GUID suffira puisqu'il contient une entropie suffisante pour ne pas être deviné :

Créez les fichiers d'environnement

Pour chaque service que vous allez créer (un pour WorkflowGen et un pour la base de données), vous aurez besoin d'un fichier contenant toutes les variables d'environnement de ce service.

Base de données

Utilisez le fichier suivant comme modèle :

Enregistrez-le sous le nom database.env en utilisant le chemin où vous placerez le fichier Compose.

WorkflowGen

Utilisez le fichier suivant comme modèle :

Enregistrez ce fichier sous le nom workflowgen.env en utilisant le chemin où vous placerez le fichier Compose.

Déployez les services

Pour déployer des services avec Docker Compose, vous avez besoin d'un fichier Compose qui les décrit. Utilisez le fichier Compose suivant pour cet exemple :

Enregistrez ce fichier sous le nom docker-compose.yml en utilisant le chemin où vous avez placé vos fichiers de variables d’environnement, puis exécutez la commande suivante :

Attendez quelques minutes que les conteneurs soient lancés, puis ouvrez un navigateur et accédez à http://localhost:8080/wfgen, où vous serez invité à vous authentifier. Entrez les informations d'identification (nom d'utilisateur wfgen_admin et mot de passe strong(!)Pass). La page d'accueil de WorkflowGen devrait s'afficher.

Aperçu

Cette section explique les configurations recommandées pour la base de données en production.

Déploiement d'une base de données

Azure SQL

Consultez la documentation suivante pour l'installation d'Azure SQL:

Sur place

Consultez la documentation suivante sur la configuration requise pour les bases de données sur site :

À base de conteneurs

WorkflowGen propose une image de base de données prête pour la production basée sur l'image Microsoft SQL Server pour Linux. Elle a les mêmes options que l'image Microsoft avec quelques fonctionnalités supplémentaires telles que la création automatique de la base de données WorkflowGen et la définition du nom d'utilisateur et du mot de passe wfgen_admin. L'image est disponible sur Docker Hub :

Pour plus d'informations sur l'image de base de données WorkflowGen, voir dans la section Image de base de données WorkflowGen.

Aperçu

Cette section indique quelles données persistantes sont exposées et où. Il recommande également certaines façons de conserver, partager et sauvegarder les données. Pour les stratégies et recommandations de sauvegarde, voir la section Continuité des activités et reprise après sinistre.

Données persistantes dans la base de données WorkflowGen

Les données persistantes sont différentes selon que vous utilisez la version Linux ou la version Windows.

Linux

La version Linux a un moyen plus géré de persister les données de la base de données. Au lieu de ne conserver que les fichiers .mdf et .ldf de la base de données WorkflowGen, vous conservez à la place toutes les données d'état SQL Server, y compris les fichiers de base de données master. Pour plus d'informations sur la persistance des données dans Linux, consultez l'article dans la documentation Microsoft officielle pour SQL Server.

Windows

Étant donné que l'image de base de la version Windows n'a pas été mise à jour par Microsoft depuis un certain temps, les fichiers de base de données de WorkflowGen doivent être persistés manuellement. Par conséquent, le conteneur de base de données a un volume défini qui contiendra uniquement les fichiers de base de données WorkflowGen. De plus, il est recommandé d'utiliser la fonction de base de données autonome de SQL Server pour conserver les informations d'identification au niveau de la base de données plutôt qu'au niveau du système SQL Server. Pour plus d'informations sur la fonctionnalité de base de données autonome, consultez l'article dans la documentation officielle de Microsoft.

Particularité des conteneurs Windows

Les volumes sont traités différemment avec les conteneurs Windows par rapport aux conteneurs Linux. Le modèle d'autorisation change et est différent selon que vous utilisez l'isolation de processus ou l'isolation Hyper-V. Avant de poursuivre les procédures de cette section, vous devez lire .

Manuel

Dans Kubernetes, il existe des outils pour vous aider à gérer les certificats et à établir une connexion TLS. C'est plus facile que de créer une architecture personnalisée à l'aide de la méthode du proxy inverse. Pour en savoir plus sur la gestion des certificats avec Kubernetes, voir la page suivante (disponible en anglais uniquement) :

• Manage TLS Certificates in a Cluster

Utilisation de cert-manager

est une application cloud native qui gère les certificats pour vous. Il comprend des mécanismes pour demander automatiquement les certificats Let's Encrypt et obtenir des certificats de , ou vous pouvez utiliser vos propres certificats générés par une autorité de certification (CA) ou un certificat auto-signé.

Aperçu

Cette section présente des indications permettant de se familiariser avec différentes solutions de création de sauvegardes et de récupération après une perte de données imprévue.

Aperçu

Cette section contient des détails sur l'architecture recommandée à utiliser lors du déploiement de WorkflowGen pour Docker. Le schéma suivant illustre tous les composants en action :

Comme vous pouvez le constater, tous les composants d'exécution se trouvent dans un ou plusieurs hôtes Docker. Vous pouvez utiliser autant de conteneurs d'applications Web que vous le souhaitez pour une disponibilité et des performances accrues, mais vous ne pouvez disposer que d'une seule instance de chaque service Windows WorkflowGen. Vous n'avez pas non plus à utiliser le conteneur de base de données, si vous le souhaitez, vous pouvez externaliser la base de données vers un fournisseur de cloud tel qu'Azure SQL ou votre propre SQL Server sur site.

Comme d'habitude, vous pouvez configurer le service SMTP que vous souhaitez utiliser avec le conteneur de WorkflowGen. Aucune configuration spéciale n'est requise pour cela.

Toutes les données persistantes sont externalisées. Les licences utilisées pour WorkflowGen, les données d'application (App_Data) et les applications de workflow (wfapps) sont toutes conservées dans un espace partagé distinct (wfgdata dans le diagramme). Par exemple, il peut s’agir d’un partage de fichiers, d’un service Azure Files, d'un disque Azure Disk ou de tout autre service capable d’agir en tant que répertoire sur un hôte Docker.

De plus, dans ce diagramme, les fichiers de base de données se trouvent dans un volume Docker. Ce volume doit être un disque, tel qu'un disque local sur l'hôte Docker dont vous pouvez contrôler les sauvegardes, ou quelque chose comme un disque Azure Disk pour que vous puissiez prendre des copies de sauvegarde. Dans le cas de la base de données, il est important d'avoir un disque pour maintenir de bonnes performances. Pour des résultats optimaux, vous devez externaliser la base de données. Consultez la page pour plus de détails.

Services WorkflowGen

Cette section décrit chacun des environnements d'exécution du conteneur WorkflowGen. N'oubliez pas que tous les environnements sont regroupés dans une seule image.

Applications Web

Lorsque vous exécutez les applications Web du conteneur, les composants suivants sont en cours d'exécution :

• Portail utilisateur

• Module d'administration

• Toutes les APIs :

  • GraphQL

Ce sont tous les composants dont vous avez besoin pour faire fonctionner chaque service Web et interface graphique.

Services Windows

Lorsque vous exécutez les services Windows du conteneur, les composants suivants sont en cours d'exécution :

• Service de la synchronisation des annuaires

• Service du moteur

Stockage des fichiers

Ce sont des espaces partagés entre les conteneurs où se trouvent des données qui devraient être persistantes et qui ne peuvent pas être dans la base de données. Un espace partagé pour les licences WorkflowGen est requis car une licence ne peut pas être stockée directement dans une image. Au lieu de cela, il est récupéré au moment de l'exécution à partir du conteneur et placé à l'emplacement correct à l'intérieur du conteneur.

Le dossier WorkflowGen App_Data doit être partagé entre les conteneurs. Il contient les informations suivantes dont WorkflowGen a besoin pour fonctionner correctement :

• Fichiers de processus au moment du design

• Fichiers de processus d'exécution

• Fichiers de log

• Fichiers temporaries des applications de workflow

L'application Web IIS de wfapps est également partagée entre les conteneurs car les formulaires Web contenus à cet emplacement sont des fichiers ASP.NET générés au moment de la conception. C'est pourquoi ils sont considérés comme un stockage. Les dossiers App_Data et wfapps sont regroupés dans le même espace partagé appelé wfgdata.

Conteneur de base de données et stockage

Dans cette architecture, la base de données WorkflowGen est conteneurisée et ses données sont stockées dans un espace partagé, de préférence également soutenu par un disque haute performance. Vous pouvez ajouter d'autres bases de données conteneurisées en tant que réplicas en lecture avec leur propre espace partagé pour leurs données. Pour plus de détails sur le conteneur de base de données ou la gestion de base de données avec des conteneurs, voir la section .

Service SMTP

WorkflowGen s'appuie sur une passerelle SMTP pour envoyer des notifications par courrier électronique. Un serveur ou un service SMTP avec une latence réseau faible et une haute disponibilité est recommandé.

Aperçu

Cette section présente comment réaliser la mutualisation (« multitenancy ») avec des images WorkflowGen et Kubernetes. De par la nature des conteneurs et des outils présents dans Kubernetes, un cluster unique peut avoir plusieurs instances de WorkflowGen avec une isolation relative les unes des autres. La meilleure isolation peut être obtenue avec plusieurs clusters.

À titre de référence pour les meilleures pratiques, consultez les liens suivants vers la documentation de Google Kubernetes Engine et Azure Kubernetes Service :

Problèmes de sécurité

Avant de commencer avec les architectures recommandées, il est important de noter quelques problèmes de sécurité liés à l'utilisation de conteneurs Windows. L'image WorkflowGen est une image de conteneur Windows. Certaines fonctionnalités de sécurité présentes dans les conteneurs Linux ne sont pas nécessairement disponibles dans les conteneurs Windows, comme les profils AppArmor et SELinux et les capacités Linux. Consultez l'article Kubernetes (disponible en anglais uniquement) pour toutes les limitations actuelles.

L'important dans les clusters multi-locataires est d'isoler les locataires les uns des autres et de limiter les actions possibles en cas d'intrusion. Vous pouvez atteindre un bon niveau d'isolement avec les stratégies réseau sur Kubernetes. Ce sont des spécifications qui nécessitent l'installation d'un logiciel tiers pour appliquer ces politiques. Pour le moment, seul le projet Calico a un support Windows (consultez le site pour plus d'informations).

Pour la sécurité dans le conteneur, à l'heure actuelle, seul runAsUserName est disponible pour exécuter l'instance de conteneur sous un nom d'utilisateur différent de ContainerAdministrator (consultez l'article Kubernetes pour plus d'informations). Il n'est pas nécessaire pour le conteneur WorkflowGen car les applications Web s'exécutent en tant qu'utilisateur du groupe IIS_IUSRS.

Recommandations

• Assurez-vous que le trafic entrant des services Windows WorkflowGen est refusé. Il ne doit pas être ouvert au public.

• Assurez-vous que les pods de base de données WorkflowGen ne sont pas accessibles au public. Ils sont uniquement utilisés par le conteneur WorkflowGen.

• Les pods des applications Web WorkflowGen ne doivent être accessibles au public que via HTTPS. HTTP est fortement déconseillé. Cependant, vous ne devriez pas du tout pouvoir accéder à WorkflowGen depuis l'intérieur du cluster, même en HTTPS.

Architecture

L'idée de base derrière la mutualisation est d'avoir un déploiement reproductible. Ce schéma montre deux déploiements identiques mais dans des espaces de noms différents. Chacun a ses propres données, configuration et licence. L'isolement entre les espaces de noms doit être appliqué par les stratégies réseau. Vous pouvez éventuellement utiliser un contrôleur Ingress avec cert-manager pour gérer facilement le routage et les certificats.

Cette architecture s'applique également aux environnements multicluster (multirégion). La seule chose qui changera est la façon dont vous acheminez vers l'instance correcte. Les mêmes problèmes de sécurité s'appliquent.

Aperçu

Cette section présente quelques outils que vous pouvez utiliser pour administrer un cluster de conteneurs.

Kubernetes

Kubernetes est installé avec son propre portail de gestion appelé Dashboard (tableau de bord). Consultez l'article de Kubernetes (disponible en anglais uniquement) pour plus d'informations.

Consultez l'article Microsoft pour obtenir des instructions sur comment s'y connecter dans Azure Kubernetes Service.

VMware Octant

est un logiciel open source de VMware pour visualiser les clusters Kubernetes. Vous pouvez également éditer certaines définitions YAML et transférer des ports directement vers votre machine.

Aperçu

Cette section présente différentes manières de configurer une connexion sécurisée (HTTPS) au conteneur WorkflowGen à l'aide d'un certificat. Avec Docker, les conteneurs s'exécutent sur un réseau interne et seuls les ports exposés seront disponibles publiquement. Par conséquent, vous ne pouvez pas configurer une connexion TLS sur un seul conteneur; vous devez le faire pour tous les conteneurs, mais cette méthode n'est pas très évolutive.

Utilisation d'un conteneur Nginx

Cette méthode utilise le serveur Web Nginx en tant que proxy inverse configuré avec une connexion TLS qui redirigera tout le trafic vers le ou les conteneurs WorkflowGen. Cette méthode peut être appliquée que vous ayez ou non une orchestration.

Consultez les pages suivantes (disponible en anglais uniquement) pour plus d'informations :

Utilisation de Traefik

Traefik est un proxy inverse qui gère le routage, la terminaison TLS et l'équilibrage de charge, entre autres. Il est disponible en tant que conteneur et vous pouvez l'utiliser devant le conteneur WorkflowGen. Pour plus d'informations sur Traefik, consultez (disponible en anglais uniquement).

Utilisation d'Azure Application Gateway

Dans Azure, vous pouvez utiliser le service Application Gateway pour obtenir une connexion TLS pour les domaines que vous possédez. Consultez l'article Microsoft pour vous aider à démarrer.

Kubernetes

Pour plus d'informations et de recommandations sur la gestion TLS / SSL dans Kubernetes, consultez la page dans la section Kubernetes.

Aperçu

Cette section décrit certaines manières de configurer les noms de domaine dans Docker.

Aperçu

Cette section explique comment gérer les mises à jour de WorkflowGen et les déployer en toute sécurité dans vos environnements.

Aperçu

Cette section indique quelles données persistantes sont exposées et où. Il recommande également des moyens de persister, de partager et de sauvegarder les données. Pour des stratégies et des recommandations de sauvegarde, consultez la section Continuité des activités et reprise après sinistre.

Données persistantes dans WorkflowGen

Trois éléments doivent être conservés dans WorkflowGen : le dossier App_Data, le dossier de l'application Web wfapps et les données SQL. Pour déployer une base de données, consultez la section .

Les deux autres sont des fichiers de WorkflowGen, et la raison pour laquelle ils doivent être conservés via un partage de fichiers est expliquée dans la section .

Vous devez aussi disposer d'un partage de fichier contenant une licence WorkflowGen valide pour que le conteneur puisse le récupérer. Ces dossiers doivent être exposés aux conteneurs WorkflowGen via des volumes. Pour plus d'informations sur les volumes Docker, consultez l'article de Docker (disponible en anglais uniquement).

Particularité des conteneurs Windows

Les volumes sont traités différemment avec les conteneurs Windows par rapport aux conteneurs Linux. Le modèle d'autorisation change et diffère selon que vous utilisez l'isolation de processus ou l'isolation Hyper-V. Avant de poursuivre les procédures décrites dans cette section, vous devez lire l'article de Microsoft.

Pour l'essentiel, vous devez vous assurer que les conteneurs WorkflowGen peuvent lire et écrire sur le volume wfgdata et lire à partir du volume de licences. L'utilisateur du conteneur qui accédera aux volumes s'appelle IIS_IUSRS.

Moyens recommandés pour persister

Chemin du système de fichiers local sur l'hôte Docker

Ceci est le moyen le plus simple de conserver les fichiers WorkflowGen avec les conteneurs. Cela consiste à créer un volume local ou à utiliser un montage de liaison sur votre hôte Docker qui conservera les fichiers après la suppression d'un conteneur. Les volumes sont le moyen préféré pour conserver les fichiers par rapport aux montages liés, car ils sont gérés par Docker. Cette méthode ne s'adapte pas bien à plusieurs hôtes Docker, cependant, d'autres méthodes doivent être considérées dans ce cas.

Volumes

Pour créer un volume pour chaque chemin de données du conteneur, exécutez la commande suivante :

Ensuite, vous devez copier (ou déplacer) votre fichier de licence sur le volume de licences en exécutant la commande suivante :

Vous pouvez maintenant exécuter le conteneur WorkflowGen avec ces volumes pour conserver les données. Voici un exemple de commande d'exécution :

Vous avez maintenant correctement conservé les fichiers de WorkflowGen.

Montages de liaisons

N'oubliez pas que vous gérez les montages liés manuellement. Ce sont des chemins spécifiques sur l'hôte Docker que vous contrôlez. Pour utiliser les montages de liaisons en tant que volumes, il vous suffit de passer les chemins lorsque vous exécutez la commande d'exécution de la manière suivante :

Partage de fichiers réseau

Vous pouvez utiliser un partage de fichiers SMB avec des conteneurs Windows tels que Azure Files. Concrètement, vous connectez le partage à l'hôte Docker, puis vous le montez comme un montage lié dans des conteneurs. Cela s'appelle un montage SMB. Pour en savoir plus sur les montages SMB, consultez l'article de Microsoft.

Utilisation d'un orchestrateur

Kubernetes

Dans Kubernetes, vous utiliserez un objet Persistent Volume pour spécifier un endroit où Kubernetes placera les données des pods. Pour plus d'informations sur les volumes persistants, consultez la page sur le site Web de Kubernetes (disponible en anglais uniquement).

Concrètement, pour WorkflowGen, vous devrez configurer un volume qui peut gérer l'autorisation ReadWriteMany pour le volume de données WorkflowGen car plusieurs pods en même temps accéderont à ce volume pour lire et écrire des données. En règle générale, pour ce faire, vous devrez créer une revendication de stockage sur le cluster comme suit :

Dans cet exemple, la revendication fait référence à une classe de stockage (Storage Class), mais vous pouvez référencer directement un volume persistant ou d'autres services de stockage spécifiques au cloud en fonction du fournisseur de cloud. Ici, la classe de stockage azurefile est fournie par Azure Kubernetes Service. L'attribution du stockage se fera automatiquement par le service. Il créera un compte de stockage avec un partage de fichiers d'une capacité de 50 Go.

Répertoire de collecte

Si vous configurez WorkflowGen pour utiliser un répertoire de collecte pour les notifications, vous devez également spécifier un volume afin d'exposer les notifications à d'autres services qui les traiteront.

Le chemin par défaut du répertoire de collecte est C:\inetpub\mailroot\Pickup. Vous pouvez le changer en fournissant à la variable d'environnement WFGEN_APP_SETTING_ApplicationSmtpPickupDirectory un chemin quelconque à l'intérieur du conteneur. Ensuite, vous devez créer un volume pour les fichiers de la manière suivante :

Vous pouvez maintenant mapper ce volume sur le répertoire de collecte configuré :

À ce stade, vous pouvez déployer un autre conteneur avec votre service pour prendre en charge les notifications et lier le même volume pour partager les fichiers de notification.

Aperçu

Cette section présente ce qui est enregistré dans l’image WorkflowGen et comment. Il indique également les pointeurs permettant de configurer la journalisation centralisée avec certains services et orchestrateurs.

WorkflowGen n'a pas de génération de métriques prête à l'emploi. Néanmoins, vous pouvez configurer certains logiciels ou services existants avec le conteneur de WorkflowGen afin d'obtenir des indicateurs de valeur pour la surveillance des performances et du trafic.

Aperçu

Cette page explique comment créer une image personnalisée de la base de données WorkflowGen afin d'ajouter du code personnalisé ou des scripts SQL à exécuter. Gardez à l'esprit que ce guide fournit des exemples simples, vous n'êtes donc pas limité à ce qui est montré ici. Les exemples utiliseront la version Linux de l'image. Tous les exemples de code sont dans PowerShell.

Aperçu

Cette page présente les cas d'utilisation courants de l'image de mise à jour de WorkflowGen. Cette image est disponible en tant que conteneurs Linux et Windows et est conçue pour être un conteneur à usage unique qui s'exécute jusqu'à la fin. Vous devez le supprimer une fois que vous en avez terminé.

Aperçu

Cette section explique comment créer votre propre image WorkflowGen personnalisée afin de personnaliser les fichiers et les DLL de WorkflowGen.

Prérequis

• Windows 10 Pro avec Docker pour Windows installé et les conteneurs Windows activés OU

• Windows Server 2019 avec Docker Enterprise installé

Description

L'image WorkflowGen fournit une variante utile nommée advantys/workflowgen:7.18.3-win-ltsc2019-onbuild qui permet de personnaliser facilement tout fichier contenu dans C:\inetpub\wwwroot ou C: Program Files\Advantys\WorkflowGen. Tout ce que vous avez à faire est de créer votre propre image avec un fichier Docker héritant de la variante onbuild et de placer les fichiers personnalisés dans le contexte de build de Docker.

Exemple simple

Voici un exemple simple qui remplace le fichier web.config, personnalise la bannière et ajoute une bibliothèque personnalisée.

Étape 1 : Ajoutez vos fichiers modifiés à la racine du contexte

Voici l'arborescence de fichiers du répertoire de contexte à partir duquel vous allez générer votre image WorkflowGen personnalisée :

Étape 2 : Ajoutez un Dockerfile dans le répertoire de contexte

Arborescence des fichiers :

Voici le contenu du Dockerfile :

Étape 3 : Générez votre image WorkflowGen personnalisée

Génération avec Docker Compose

Avec Docker Compose, vous pouvez spécifier les paramètres de build dans un format déclaratif afin d’intégrer le processus de génération de Docker à l’exécution. Par exemple, vous pourriez avoir le fichier Compose suivant nommé docker-compose.yml dans votre répertoire de contexte :

(Ce fichier provient de la section .)

Ensuite, pour générer et baliser automatiquement, vous pouvez exécuter la commande suivante :

Docker Compose va alors générer et baliser votre image avec la balise présente dans la propriété image. Si vous souhaitez mettre à jour immédiatement votre déploiement Compose sur votre ordinateur local ou exécuter immédiatement ce déploiement après la génération, exécutez la commande suivante, qui générera votre conteneur en plus de l'exécution des services après la génération :

Pour pousser l'image à l'aide de Docker Compose, exécutez la commande suivante :

Vous avez maintenant une image WorkflowGen personnalisée. Pour en savoir plus sur la mise à jour de votre conteneur lorsqu'une nouvelle version de WorkflowGen est disponible, voir la section .

Exemple avec une application / procédure Web WorkflowGen personnalisée patrimoniale

Supposons qu'en plus des DLLs et des bannières personnalisées, vous ayez une application Web ASP.NET 2.0 à ajouter au dossier wfapps et à configurer dans IIS. Vous devez suivre les mêmes étapes que précédemment, mais ajouter un script Docker CMD personnalisé qui configurera l'application dans IIS.

Plusieurs scripts PowerShell sont fournis avec l'image WorkflowGen et ont des objectifs différents :

• docker-entrypoint.ps1 : Le script principal à exécuter lorsque vous exécutez un conteneur. Il gère l'analyse des variables d'environnement, la configuration des méthodes d'authentification, etc.

• monitor-services.ps1 : Ce script gère la surveillance des processus (services IIS et Windows), ainsi que la collecte des logs du conteneur et leur redirection vers la sortie standard.

• healthcheck.ps1 : Ce script gère la vérification périodique qui indique si WorkflowGen fonctionne correctement ou non. Ceci est défini dans le Dockerfile WorkflowGen et est géré par le moteur Docker.

En créant votre propre image WorkflowGen dans Docker, vous pouvez remplacer n'importe quel script par le vôtre qui fait complètement autre chose, et il est recommandé de le faire si les scripts de stock ne font pas ce que vous voulez. Dans le cas de cet exemple, les scripts de stock ne se chargent pas de définir l'application Web ajoutée comme dans IIS; vous devez développer votre propre script pour cela. Voici celui que vous utiliserez dans cet exemple :

Dans ce script, notez ce qui suit :

1. Vous vérifiez le type de service de démarrage et vérifiez si vous avez déjà ajouté le service Web en tant qu'application Web dans IIS. Raisonnement En effet, le script de point d'entrée est réexécuté entre les redémarrages du conteneur. Par conséquent, ce script sera également réexécuté après un redémarrage. Lors du redémarrage d'un conteneur, la configuration IIS est conservée et la commande ConvertTo-WebApplication provoque l'échec de la procédure de démarrage lors de la tentative d'ajout d'une application Web déjà ajoutée. Par conséquent, vous devez vérifier que vous n'avez pas déjà ajouté l'application. En outre, vous vérifiez si le conteneur s'exécute en mode applications Web. Dans le cas contraire, vous n'avez pas besoin d'ajouter votre service Web dans IIS car seuls les services Windows seront exécutés.

2. Vous vérifiez les arguments et les exécutez s'il y en a. Sinon, vous commencez à surveiller les services du conteneur.

   Raisonnement

Votre Dockerfile sera alors comme suit :

Après cela, vous effectuerez les mêmes étapes de génération et de poussée que dans l'exemple précédent.

Aperçu

Cette section explique comment configurer complètement un conteneur de mise à jour WorkflowGen. Certaines options sont configurées en tant que variables d'environnement et d'autres sont transmises directement au script du point d'entrée. Il est disponible sous forme d'images Linux et Windows.

Variables d'environnement

Dans le cas de l'image de mise à niveau, les variables d'environnement sont des arguments que vous ne devriez pas avoir à changer souvent lors de la mise à jour de WorkflowGen. De cette façon, vous pouvez facilement passer un fichier qui définit ces variables et le réutiliser entre les exécutions. Voici la liste des variables d'environnement disponibles avec leurs descriptions :

Paramètres de script

Les paramètres de script définissent des options à transmettre en tant qu'arguments directement au conteneur de mise à jour. Ces arguments sont plus susceptibles d'être définis chaque fois que vous exécutez le conteneur, c'est pourquoi ils ne sont pas dans des variables d'environnement. Voici le fichier d'aide du script de point d'entrée. Il décrit tous les paramètres et leurs regroupements et fournit quelques exemples :

Utilisation d'un gestionnaire de configuration externe

Certains gestionnaires de configuration populaires supportent les conteneurs Docker prêts à l'emploi. Vous utiliseriez un gestionnaire de configuration externe uniquement pour la définition des variables d'environnement. Voici quelques liens vers leur documentation spécifique pour vous aider à démarrer :

Chef

Ansible

Puppet

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.

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 et l'article Microsoft . Pour la version Windows, consultez la page Docker Hub .

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 :

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 .

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

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

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

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

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 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 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 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 de cette section. Pour plus d'informations sur la configuration de la réplication dans SQL Server, consultez l'article 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 :

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 dans la documentation Kubernetes. Vous aurez peut-être besoin d'un code personnalisé pour pouvoir configurer correctement plusieurs instances. Voir la page de cette section pour plus d'informations sur la façon d'ajouter du code personnalisé au conteneur.

Aperçu

Cette section présente l'architecture de conteneur recommandée pour WorkflowGen afin d'exécuter les portails Web et les services Windows. Il y aura de nombreuses références aux propriétés de configuration de l'image; consultez la section Configuration pour plus d'informations.

Consultez la section pour plus d'informations sur les déploiements de bases de données SQL et la section pour obtenir des informations sur le déploiement de volumes.

Conteneur unique

C'est l'architecture la plus simple que vous puissiez utiliser avec WorkflowGen. Il s'agit d'un conteneur unique sans répliques qui exécute à la fois des applications Web et services Windows. Par conséquent, vous définissez la variable d'environnement WFGEN_START_SERVICE sur all. Cette architecture convient bien aux environnements de développement et de test, mais elle peut également être considérée lorsque les performances avec un seul conteneur correspondent à l'utilisation du produit. Vous ne pouvez pas répliquer le conteneur car il ne devrait y avoir qu'une seule instance de chaque service Windows WorkflowGen en cours d'exécution.

Exemple Docker Compose

Voici le même exemple que dans la section . Il contient un conteneur WorkflowGen qui exécute tous les services (applications Web et services Windows).

Exemple Helm

Cet exemple est différent de l'exemple dans la section . Cette version de Helm n'est pas évolutive dans le cluster. Il a un pod qui exécute tous les services WorkflowGen (applications Web et services Windows) et un autre pod pour la base de données. Vous pouvez utiliser les étapes de l'exemple dans la section pour générer les valeurs demandées. N'oubliez pas d'obtenir l'adresse IP externe de l'équilibreur de charge une fois qu'il est créé.

Plusieurs instances d'applications Web, instance unique de services Windows

Puisqu'il ne peut y avoir qu'une seule instance de chaque service Windows WorkflowGen exécutée à la fois, cette architecture vous permet d'exécuter plusieurs répliques des applications Web afin de faire évoluer WorkflowGen pour répondre à vos besoins en matière de trafic et de traitement sans disposer d'instances supplémentaires des services Windows.

Vous devez définir la variable d'environnement WFGEN_START_SERVICE sur web_apps pour les conteneurs des applications Web et sur win_services pour le conteneur unique afin d'exécuter tous les services Windows sans applications Web. Cette architecture est idéale pour adapter les portails Web au trafic et aux besoins de traitement, sans trop de pression sur les services Windows.

Exemple Docker Compose

Exemple Helm

Cet exemple est le même que dans la section . Les conteneurs des services Windows seront toujours dans le même pod lorsque vous utilisez la carte Helm WorkflowGen. Vous pouvez utiliser les étapes de l'exemple dans la section pour générer les valeurs demandées. N'oubliez pas d'obtenir l'adresse IP externe de l'équilibreur de charge une fois qu'il est créé.

Plusieurs instances d'applications Web, conteneurs de services Windows dédiés

Cette architecture recommandée est la plus évolutive. Il comporte plusieurs conteneurs pour les applications Web pouvant être adaptés à l'augmentation du trafic ou à des besoins de traitement, ainsi que des conteneurs dédiés pour chaque service Windows : un pour le service de synchronisation d'annuaires et un pour le service de moteur. Par conséquent, vous devez définir la variable d'environnement WFGEN_START_SERVICE sur web_apps pour les conteneurs des applications Web, sur dir_sync pour le conteneur de service de synchronisation d'annuaires et sur engine pour le conteneur du service de moteur. Cette architecture convient aux scénarios de haute disponibilité et de performances élevées.

Exemple Docker Compose

Exemple Helm

Cet exemple est le même que dans la section . Les conteneurs des services Windows seront toujours dans le même pod lorsque vous utilisez la carte Helm WorkflowGen. Vous pouvez utiliser les étapes de l'exemple dans la section pour générer les valeurs demandées. N'oubliez pas d'obtenir l'adresse IP externe de l'équilibreur de charge une fois qu'il est créé.

Aperçu

Cette section explique comment configurer complètement un conteneur WorkflowGen, y compris le fichier web.config, la configuration d'iisnode pour les applications Node.js, les chaînes de connexion à la base de données, etc. Tout est configurable via une variable d'environnement, à l'exception du fichier de licence configuré via un volume.

Variables d'environnement WorkflowGen

L'image WorkflowGen fournit un certain nombre de variables d'environnement spécifiques permettant des configurations spécifiques. Le tableau suivant décrit chacun d’entre eux :

Variables d'environnement basées sur le format

L'image WorkflowGen expose également diverses variables d'environnement basées sur un format spécifique afin de configurer des éléments plus génériques.

web.config

Dans WorkflowGen, le fichier web.config est le point principal de la configuration. Dans la mesure où un conteneur est par définition éphémère, toute modification apportée dans le Panneau de configuration ne persisterait pas entre les redémarrages de conteneur.

Pour définir les propriétés de configuration dans le fichier web.config, vous devez utiliser un format spécifique pour une variable d'environnement qui contiendra la valeur de la propriété que vous souhaitez définir. Ce format est WFGEN_APP_SETTING_<nom>.

Par exemple, si vous souhaitez définir la propriété ApplicationUrl dans le fichier web.config sur https://macompagnie.fr/wfgen, vous devez définir la variable d'environnement WFGEN_APP_SETTING_ApplicationUrl=https://macompagnie.fr/wfgen dans le conteneur.

📌 Exemple avec la commande run

Pour une liste des paramètres web.config, ainsi que leurs descriptions et leurs valeurs possibles, consultez l'annexe du .

Configuration iisnode pour les applications Node.js

Vous pouvez également définir des propriétés iisnode spécifiques pour chaque application Node.js. Pour ce faire, vous devez définir une variable d’environnement au format suivant : WFGEN_IISNODE_<nom de l'application NodeJS>_<nom de la propriété>.

• Remplacez <nom de l'application NodeJS> par le nom de l'application Node.js (AUTH, HOOKS, GRAPHQL ou SCIM).

• Remplacez <nom de la propriété> par le nom de la propriété que vous souhaitez définir pour le nœud XML <iisnode/> dans le fichier

Par exemple, si vous souhaitez définir la propriété iisnode loggingEnabled dans l'application Auth sur true, vous devez définir la variable d'environnement WFGEN_IISNODE_AUTH_loggingEnabled=true.

📌 Exemple avec la commande run

Options iisnode spéciales pour les applications Node.js

Il existe des options spéciales que vous pouvez activer pour chaque application Node.js en définissant une variable d'environnement qui a le modèle suivant : WFGEN_ENABLE_IISNODE_OPTION_<nom app NodeJS>. Ensuite, vous remplacez <nom app NodeJS> par le nom de l'application Node.js (AUTH par exemple) et la valeur doit être l'une des suivantes :

Configuration de trace

Vous pouvez activer le traçage .NET pour différents composants WorkflowGen à l'aide de variables d'environnement. Utilisez le modèle WFGEN_TRACE_<component>_<option>=<value> avec <component> comme nom du composant sur lequel vous souhaitez définir l'option, <option> comme nom de l'option à définir et <value> comme valeur de l'option.

Composants disponibles

• WEB_APPS (applications Web)

• ENGINE (service de moteur)

• DIR_SYNC (service de synchronisation d'annuaire)

Options

📌 Exemple

Pour activer le traçage pour les applications Web avec une indentation de 2 et tracer uniquement les erreurs pour le moteur avec une indentation de 0, vous devez configurer les variables d'environnement comme suit :

Configuration de la base de données

Chaîne de connexion principale

La chaîne de connexion principale peut être configurée via la variable d'environnement WFGEN_DATABASE_CONNECTION_STRING. Vous pouvez mettre n'importe quelle chaîne dans cette variable et sa valeur sera placée dans le fichier web.config de WorkflowGen au niveau de la chaîne de connexion MainDbSource.

Voici comment spécifier la chaîne de connexion à l'aide de la commande run :

Chaîne de connexion en lecture seule

Si vous avez un réplica en lecture seule, vous pouvez également le configurer dans le conteneur. Vous pouvez le spécifier avec la variable d'environnement WFGEN_DATABASE_READONLY_CONNECTION_STRING. Il sera ajoutée au fichier web.config de WorkflowGen en tant que nouvelle entrée dans les chaînes de connexion sous le nom ReadOnlyDbSource.

Voici comment spécifier la chaîne de connexion en lecture seule avec la commande run :

Chaînes de connexion personnalisées

Vous pouvez également configurer davantage de connexions aux sources de données personnalisées si vous en avez besoin. Ils peuvent être configurés à l'aide d'un format de variable d'environnement spécifique : WFGEN_CUSTOM_CONNECTION_STRING_<nom>=<chaîne_connexion>.

Par exemple, si vous souhaitez une source de données nommée MyDataSource avec la valeur de chaîne de connexion MyConnectionString dans le fichier web.config de WorkflowGen, spécifiez la variable d'environnement suivante : WFGEN_CUSTOM_CONNECTION_STRING_MyDataSource=MyConnectionString.

📌 Exemple avec la commande run

Secrets

Lorsque vous utilisez un orchestrateur tel que Kubernetes, vous souhaiterez probablement sécuriser les secrets à l'aide de leurs outils de gestion de secrets intégrés. Suivez le guide spécifique destiné à votre orchestrateur pour savoir comment créer un secret.

Pour Kubernetes, consultez (disponible en anglais uniquement).

Il est recommandé d'injecter ces secrets dans les 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é.

Pour obtenir la valeur secrète dans le fichier, vous devez suffixer toute variable d'environnement pour laquelle vous voulez 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 alors la valeur dans le fichier au niveau du chemin spécifié et définira la variable d'environnement sans le suffixe avec cette valeur.

Par exemple, supposons que vous souhaitiez définir le numéro de série de la licence dans le fichier web.config sur WFG-SOME-LICENSE-KEY à l'aide de la variable d'environnement WFGEN_APP_SETTING_ApplicationSerialNumber, mais que vous souhaitiez utiliser un secret pour la valeur. Il vous suffit de suffixer le nom de la variable d'environnement avec _FILE pour qu'il devienne WFGEN_APP_SETTING_ApplicationSerialNumber_FILE. Définissez ensuite la valeur de cette variable sur le chemin du fichier contenant le numéro de série.

📌 Exemple avec l'orchestrateur Docker Swarm

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

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

Configuration du mode d'authentification

Authentification d'application

Pour laisser WorkflowGen gérer l'authentification et le stockage des mots de passe utilisateur, vous n'avez pas besoin de configurer quoi que ce soit de spécial dans le conteneur. Gardez à l'esprit que le nom d'utilisateur par défaut du compte administratif WorkflowGen est wfgen_admin.

Authentification Windows et de base

Pour que les modes d'authentification Windows ou de base fonctionnent, votre hôte doit se trouver dans une forêt Active Directory. La création d'un compte d'utilisateur sur l'hôte pour l'authentification de base ne fonctionnera pas, car le serveur Web IIS à l'intérieur du conteneur tentera de trouver un compte d'utilisateur enregistré dans le conteneur au lieu de l'hôte. Pour cette raison, vous avez besoin d'Active Directory.

Pour configurer votre hôte Docker pour qu'il fonctionne avec Active Directory pour authentifier les utilisateurs, suivez le guide de de Microsoft dans sa documentation Conteneurs Windows.

Kubernetes supporte les gMSA pour les pods et conteneurs Windows à partir de la version 1.18. Consultez l'article Kubernetes pour plus de détails sur la façon de le configurer. Gardez à l'esprit que tous les fournisseurs de cloud ne supportent pas les gMSA avec Kubernetes. Par exemple, Azure Kubernetes Service ne supporte pas cette fonctionnalité.

Azure v1 et Microsoft Identity Platform

Pour ces fournisseurs, il n'y a pas de configuration spéciale à faire autre que la définition de la variable WFGEN_AUTH_MODE. Pour obtenir des instructions de configuration, consultez le guide .

Active Directory Federation Services (AD FS), Auth0 et Okta

Pour ces fournisseurs, il n'y a pas de configuration spéciale à faire autre que la définition de la variable WFGEN_AUTH_MODE. Pour obtenir des instructions de configuration, consultez le .

Configuration de votre licence

Pour configurer votre licence, vous devez définir une variable d'environnement spécifique avec votre licence et copier votre fichier de licence dans un volume exposé au conteneur WorkflowGen. Pour ce faire, vous devez d’abord créer un volume de licence ou disposer de votre licence sur un chemin spécifique.

Créez un volume

Cela créera un volume sur un chemin spécifique de votre système de fichiers (généralement C:\ProgramData\Docker\volumes\licenses\_data) géré par Docker. Vous pouvez obtenir le chemin du volume en exécutant la commande suivante :

Ensuite, vous devez copier votre fichier de licence à cet emplacement :

Maintenant, vous pouvez exécuter le conteneur WorkflowGen comme suit :

Utilisez un chemin spécifique

Ici, vous fournissez un chemin que vous contrôlez en tant que volume vers le conteneur. Il vous suffit de passer le chemin lorsque vous exécutez WorkflowGen :

Mettre le site Web WorkflowGen hors ligne

Vous pouvez mettre les applications Web dans le conteneur WorkflowGen hors ligne en exécutant un script intégré à l'image. Cela est utile pour garantir que le site est toujours disponible lorsque vous souhaitez effectuer des tâches de maintenance sur ses données sans que rien de nouveau ne soit écrit. Avec des conteneurs purs, vous pouvez exécuter la commande suivante :

Avec Kubernetes, vous pouvez utiliser kubectl :

Si vous accédez à votre site Web WorkflowGen, vous verrez la page Web hors ligne par défaut. Vous pouvez personnaliser cette page Web en ajoutant votre propre fichier HTML dans le chemin <wfgen appdata>\Templates\server\offline.htm. Si ce fichier est présent, il sera pris à la place du fichier par défaut. Si vous disposez d'un volume pour les données de WorkflowGen, vous pouvez exécuter le script suivant:

Vous pouvez remettre le site en ligne en exécutant la commande suivante :

Utilisation d'un orchestrateur

Kubernetes

Kubernetes dispose également d’un outil intégré de gestion de la configuration appelé ConfigMaps. Consultez l'article de Kubernetes (disponible en anglais uniquement) pour plus d'informations. Vous devez utiliser cet objet pour configurer les variables d'environnement pour WorkflowGen.

Vous pouvez également gérer des informations sensibles en les protégeant davantage dans l'orchestrateur dans une zone sécurisée. Consultez l'article de Kubernetes (disponible en anglais uniquement) pour plus d'informations et des 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 de vos propres fichiers de configuration

Pour utiliser vos propres fichiers de configuration, vous devez créer votre propre image WorkflowGen à l'aide de la variante d'image WorkflowGen onbuild. Consultez la page dans la section Image WorkflowGen pour plus d'informations.

Utilisation d'un gestionnaire de configuration externe

Certains gestionnaires de configuration courants supportent les conteneurs Docker prêts à l'emploi. Voici quelques liens vers leur documentation spécifique (disponible en anglais uniquement) pour vous aider à démarrer :

Chef

Ansible

Puppet

Aperçu

Cette section présente comment exécuter rapidement le conteneur WorkflowGen avec une architecture minimale sur Kubernetes.

Kubernetes avec AKS

Cet exemple est conçu pour Azure Kubernetes Service (AKS). Pour commencer avec AKS, consultez l'article Microsoft .

Aperçu de l'architecture

À la fin de cette section, vous aurez cette configuration de cluster :

Chaque conteneur du cluster aura accès à la configuration et aux secrets à l'intérieur de leurs espaces de noms. Plusieurs services Azure seront déployés par Azure Kubernetes Service. Cela ne nécessite aucune étape manuelle autre que l'interaction avec Kubernetes lui-même. L'équilibreur de charge que le service créera répartira les demandes entre les répliques de serveur WorkflowGen.

Prérequis

• Vous devez avoir un cluster Kubernetes fonctionnel avec des nœuds Windows Server 2019. Voir la vue des ressources Azure ci-dessus pour une configuration AKS de base. Consultez l'article Microsoft pour commencer à créer un cluster AKS avec le support des nœuds Windows.

• Vous devez avoir installé l'outil de ligne de commande kubectl et il doit être connecté au cluster. Consultez la section de l'article Microsoft pour obtenir des instructions sur la connexion de kubectl à AKS.

Notez également que vous ne devez pas créer d'autres ressources dans Azure en dehors du cluster et ses nœuds. Toutes les ressources requises pour les conteneurs seront créées automatiquement par Kubernetes. AKS est une plateforme entièrement gérée.

Ajoutez un PersistentVolumeClaim pour le stockage partagé

Maintenant, vous devez ajouter une revendication qui représente le volume de données WorkflowGen qui sera utilisé par votre déploiement. Pour ce faire, appliquez le YAML suivant à votre cluster :

Ensuite, appliquez-le au cluster à l'aide de la commande suivante :

Ajoutez votre fichier de licence WorkflowGen au cluster

Kubernetes vous permet de gérer les et les sous forme de fichiers à l'intérieur du cluster et de les injecter dans des pods. Dans ce cas, vous ajouterez votre fichier de licence en tant que secret et l'injecterez plus tard au module WorkflowGen. Pour ajouter votre licence au cluster, exécutez la commande suivante :

Ajoutez des ConfigMap pour les services

Comme mentionné précédemment, il existe un mécanisme dans Kubernetes qui vous permet de gérer les configurations de vos conteneurs. Ici, vous allez en créer un pour WorkflowGen et un autre pour la base de données :

N'oubliez pas d'appliquer cette configuration :

Ajoutez des secrets pour les services

Kubernetes gère également des secrets pour vous. Ils sont stockés en toute sécurité et ne sont remis aux conteneurs que sous forme de fichiers.

Vous avez besoin d'une clé de cryptage pour mettre comme secret :

Avant de créer les secrets, vous devez les encoder en base64 :

Ces valeurs encodées iront dans la déclaration des secrets. Pour créer les secrets requis pour les services, appliquez le code YAML suivant :

N'oubliez pas d'appliquer ceci :

Déployez les conteneurs

Vous êtes maintenant prêt à déployer les services. Vous allez créer deux objets et un objet . Le déploiement créera des ReplicaSet pour tous les services avec différentes configurations. Ces déploiements peuvent ensuite être configurés pour évoluer automatiquement avec l'utilisation des pods. Le ReplicaSet fournira les services nécessaires au conteneur de base de données afin de fonctionner correctement et d'éviter les pertes de données. N'oubliez pas qu'il ne doit y avoir qu'une seule instance de chaque service Windows WorkflowGen en cours d'exécution à tout moment. Ce est appelé Singleton.

Base de données

Cette configuration déploiera la base de données StatefulSet avec un service en mode sans affichage (« »). Cet objet créera également une revendication de volume persistante basée sur le modèle fourni dans la déclaration.

Appliquez d'abord la base de données :

Applications Web WorkflowGen

Appliquez ce contrôleur de réplication :

Déploiement des services Windows

Appliquez les services Windows :

Ajoutez un équilibreur de charge

Maintenant, vous devez ajouter un équilibreur de charge public pour envoyer des demandes à vos pods. Pour ce faire, exécutez la commande suivante :

Vous devez maintenant attendre que l'IP soit approvisionné. Exécutez périodiquement la commande suivante jusqu'à obtenir l'adresse IP publique de l'équilibreur de charge :

Une fois que la valeur de EXTERNAL-IP est provisionnée, copiez-la et modifiez la configuration de WorkflowGen pour modifier la valeur WFGEN_APP_SETTING_ApplicationUrl :

Appliquez-le :

Ensuite, redémarrez tous les pods du déploiement WorkflowGen pour leur appliquer les modifications. Vous devez également le faire pour les services Windows. Pour ce faire, exécutez les commandes suivantes :

Vous devriez maintenant avoir un WorkflowGen fonctionnel avec un équilibreur de charge et une base de données.

Kubernetes avec AKS utilisant Helm

Helm est un outil de type gestionnaire de packages pour Kubernetes. Il gère le partage, le déploiement, les mises à jour et les restaurations des logiciels développés pour Kubernetes. En fonction des valeurs fournies, Helm génère des fichiers de définition pour le cluster avec le moteur de modèle à partir du langage de programmation Go. Pour chaque version, WorkflowGen produit désormais une carte que vous pouvez utiliser avec votre cluster. Pour obtenir les dernières corrections de bogues et fonctionnalités de la carte, assurez-vous de toujours choisir la carte publiée avec la dernière mise à jour de WorkflowGen.

Aperçu de l'architecture

À la fin de cette section, vous aurez cette configuration de cluster :

Chaque conteneur du cluster aura accès à la configuration et aux secrets à l'intérieur de leurs espaces de noms. Plusieurs services Azure seront déployés par Azure Kubernetes Service. Cela ne nécessite aucune étape manuelle autre que l'interaction avec Kubernetes lui-même. L'équilibreur de charge que le service créera répartira les demandes entre les répliques de serveur WorkflowGen.

Prérequis

• Vous devez avoir un cluster Kubernetes fonctionnel avec des nœuds Windows Server 2019. Voir la vue des ressources Azure ci-dessus pour une configuration AKS de base. Consultez l'article Microsoft pour commencer à créer un cluster AKS avec le support des nœuds Windows.

• Vous devez avoir installé l'outil de ligne de commande kubectl et il doit être connecté au cluster. Consultez la section de l'article Microsoft pour obtenir des instructions sur la connexion de kubectl à AKS.

• Vous devez avoir installé l'outil de ligne de commande Helm. Consultez la section (disponible en anglais uniquement) sur le site Web de Helm pour savoir comment l'installer. Seules les versions Helm 3.0 et ultérieures sont supportées.

Notez également que vous ne devez pas créer d'autres ressources dans Azure en dehors du cluster et ses nœuds. Toutes les ressources requises pour les conteneurs seront créées automatiquement par Kubernetes. AKS est une plateforme entièrement gérée.

Créez la clé de chiffrement symétrique

Cette valeur doit être générée par vous. Un GUID simple suffira car il a une entropie suffisante pour ne pas être deviné :

Ajoutez votre fichier de licence WorkflowGen au cluster

Kubernetes vous permet de gérer les et les sous forme de fichiers à l'intérieur du cluster et de les injecter dans des pods. Dans ce cas, vous ajouterez votre fichier de licence en tant que secret et l'injecterez plus tard au module WorkflowGen. Pour ajouter votre licence au cluster, exécutez la commande suivante :

Créez un fichier avec vos valeurs pour la carte

Afin de générer les modèles adaptés à vos attentes de configuration, vous devez fournir certaines valeurs à la commande helm lorsque vous installez ou mettez à jour une version. Vous pouvez spécifier ces valeurs à l'aide de l'interface de ligne de commande ou avec un fichier. Dans le cas d'une nouvelle installation, ce sera plus facile avec un fichier. Voici les valeurs dont vous aurez besoin :

Vous pouvez enregistrer ce fichier sous values.yaml. Le nom n'est pas important.

Installez la carte WorkflowGen

Vous devez maintenant installer la carte avec ces valeurs. Pour ce faire, exécutez la commande suivante :

Helm va générer des fichiers de déploiement Kubernetes pour vous et les installer sur le cluster.

Mettez à jour l'URL de l'application

Cette configuration créera un équilibreur de charge devant les conteneurs WorkflowGen. Vous devrez l'attendre pour obtenir une adresse IP publique. Exécutez périodiquement la commande suivante jusqu'à obtenir l'adresse IP publique de l'équilibreur de charge :

Une fois la valeur de EXTERNAL-IP approvisionnée, copiez-la et modifiez la configuration de WorkflowGen pour modifier la valeur WFGEN_APP_SETTING_ApplicationUrl. Pour ce faire, vous devez d'abord obtenir le nom du ConfigMap associé au déploiement de WorkflowGen. La commande suivante vous donnera tous les objets ConfigMap dans l'espace de noms par défaut :

Copiez le nom de WorkflowGen ConfigMap et remplacez <WFG_CONFIG_MAP> par la valeur dans la commande suivante :

Cela fera apparaître un éditeur afin que vous puissiez remplacer la valeur WFGEN_APP_SETTING_ApplicationUrl par l'adresse IP correcte du service d'équilibrage de charge. Enregistrez le fichier et quittez l'éditeur. Pour appliquer les modifications apportées à l'objet ConfigMap, redémarrez tous les pods du déploiement WorkflowGen. Vous devez également le faire pour les services Windows. Obtenez le nom des déploiements avec la commande suivante :

Remplacez <WEB_APPS_DEPLOYMENT_NAME> et <WIN_SERVICES_DEPLOYMENT_NAME> dans le script suivant par les noms de déploiement corrects pour redémarrer tous les conteneurs :

Vous devriez maintenant avoir un WorkflowGen fonctionnel avec un équilibreur de charge et une base de données.