1 of 27

7.14 to 7.22

WorkflowGen for Docker

This guide provides instructions on how to set up, configure, deploy, and manage WorkflowGen integrations with Docker and Kubernetes.

Getting Started

Overview

This section presents how to quickly run the WorkflowGen container with a minimal architecture on your local machine.

There are known limitations when using Hyper-V isolation with the WorkflowGen container in WorkflowGen versions 7.19.2 and earlier. It's recommended to use process isolation exclusively. This limitation no longer applies as of WorkflowGen version 7.20.0.

Global prerequisites

Make sure to have a valid WorkflowGen license.
If you're using Windows Server, make sure that it's Windows Server 2019, and use the tag that corresponds to that version. For example, for Windows Server 2019, use the tag that ends with ltsc2019.

Docker manual local machine deployment

Architecture overview

At the end of this section, the following architecture will be deployed on your local machine:

Inside the Docker engine on your machine, you'll have a running WorkflowGen server and a WorkflowGen database. Both of these will use volumes mapped to your local machine to persist data files.

Prerequisites

Make sure to have installed Docker on your machine.

For Windows 10 Pro

Follow the instructions in the guide to install Docker for Windows. You must be using Windows containers, so you need at least Windows 10 Pro.

For Windows Server

Do not install Docker for Windows on Windows Server. It is designed for development only.

If you've provisioned a virtual machine on your cloud provider where the template indicates something like Windows Server with Containers, it's probably safe to assume that Docker is already installed. Execute docker version on the machine to verify that it is. If so, you can skip the installation process.

Follow the instructions in the guide to install Docker on Windows Server.

For this setup, it's recommended to use WorkflowGen's database Docker image. You can also use a SQL database installed on your local machine.

Run the database container

To download the database image into your local machine, open PowerShell and enter the following:

Don't forget to use the correct tag for your version of Windows.
The Windows version of the advantys/workflowgen-sql image is designed for development or testing only. It is not suited for production workloads. Instead, consider using the Linux version of the image (e.g. advantys/workflowgen-sql:7.18.2-ubuntu-18.04).

For WorkflowGen to work, you need to run the database before running WorkflowGen. Before creating the container, create a Docker volume in order to externalize the database files (.mdf and .ldf). This will ensure that the data are still there after the deletion of the container.

The physical location of the volume can be obtained using the following command:

Typically, it will be stored in C:\ProgramData\Docker\volumes\sqldata\_data. Make sure that the container has write access to this directory (see the Microsoft article for information).

You're now ready to run the database container. To do this, execute the following command:

This last command will set the passwords of the SA database user, the WFGEN_USER database user, and the wfgen_admin WorkflowGen account asstrong(!)Pass. Per the nature of Docker, the SA_PASSWORD and ACCEPT_EULA environment variables come from the microsoft/mssql-server-windows-express base container and are not directly handled by the WorkflowGen container.

Run the WorkflowGen container

Enter the following to download the WorkflowGen image:

Don't forget to use the correct tag for your version of Windows (see above).

For this container, you need two volumes in order to correctly persist the WorkflowGen data:

WorkflowGen licenses (licenses)
WorkflowGen's data (data), which contains the following:
- The App_data folder (appdata

You now need to copy your WorkflowGen license into the licenses volume. To do this, execute the following command:

This way, the WorkflowGen container will be able to pick it up via the volume. You also need an encryption key for the container; use the following command to generate one:

To run the actual container, replace <YOUR_WFG_LIC_KEY> with your WorkflowGen license key and <YOUR_NEW_GUID> with the GUID that you generated in the last step, then execute the following command:

When the container is ready, open a browser and go to http://localhost:8080/wfgen, where you'll be prompted for WorkflowGen authentication. By default, the container is configured with the application authentication method.

Shut down the containers

Once you're done with this environment, you can shut down containers by stopping them. They can be restarted later.

Any environment variable defined will be reapplied after restarting a container. Therefore, any changes made to a web.config file without environment variables will not be carried between restarts or re-runs.
This action keeps data in the container's file system between restarts. If you add a file that isn't in a volume, it will be kept after restarting.

Remove the containers

To completely remove containers, there's only one command to execute:

This will remove the database and WorkflowGen containers including, any manual change in the container's file system that is not part of a volume. Even if the containers are gone, the data in the volumes are retained and can be used by other containers. For example, you could launch three other WorkflowGen containers that use the same volumes and they will all get the exact same files at the mount point of the volume.

Docker Compose local machine deployment

This section describes the recommended way to easily deploy a local development environment without having to enter a lot of commands. You can find out more about Docker Compose in the Docker documentation at .

Architecture overview

At the end of this section, the following architecture will be deployed on your local machine:

Inside the Docker engine on your machine, you'll have a running WorkflowGen server and a WorkflowGen database. Both of these will use volumes mapped to your local machine to persist data files.

Prerequisites

For Windows 10 Pro

Follow the instructions in the guide to install Docker for Windows. You must be using Windows containers, so you need at least Windows 10 Pro.

For Windows Server

Do not install Docker for Windows on Windows Server. It is designed for development only.

If you've provisioned a virtual machine on your cloud provider where the template indicates something like Windows Server with Containers, it's probably safe to assume that Docker is already installed; execute docker version on the machine to verify that it is. If so, you can skip the installation process.

Follow the instructions for Windows Server in the guide to install Docker on Windows Server.

On Windows Server only, you also need to install the Docker Compose tool, since it's not installed by default. Follow the instructions for Windows Server in the guide. To verify that Docker Compose is properly installed, run the following command:

For this setup, it's recommended to use WorkflowGen's database Docker image. You can also use a SQL database installed on your local machine.

Create the license volume

Before creating the services, you need to create the license volume externally from the composition in order to have the licenses present at the time of container creation. To do this, execute the following command:

Then, you need to copy your license file to the licenses directory. The following command will show you where the license will be stored:

To copy your license, execute the following command:

Create the symmetric encryption key

This value should be generated by you. A simple GUID will suffice since it has sufficient entropy not to be guessed:

Create the environment files

For each service that you'll create (one for WorkflowGen and one for the database), you'll need a file that contains all of the environment variables for that service.

Database

Use the following file as a template:

Save it as database.env using the path where you'll put the Compose file.

WorkflowGen

Use the following file as a template:

Replace <YOUR_WFG_LIC_KEY> with the value of your WorkflowGen license key. Replace <YOUR_NEW_GUID> with the symmetric encryption key that you have generated earlier.

Save this file as workflowgen.env using the path where you'll put the Compose file.

Deploy the services

To deploy services with Docker Compose, you need a Compose file that describes them. Use the following Compose file for this example:

Save this file as docker-compose.yml using the path where you put your environment variable files, then execute the following command:

Wait a few minutes for the containers to get started, then open a browser and navigate to http://localhost:8080/wfgen, where you will be prompted for authentication. Enter the credentials (username wfgen_admin and password strong(!)Pass) and it should display the WorkflowGen home page.

Main Architecture Description

Overview

This section contains details on the recommended architecture to use when deploying WorkflowGen for Docker. The following schema illustrates all of the components in action:

As shown, all runtime components are inside one or more Docker hosts. You can use as many web application containers as you want for higher availability and better performance, but you can only have one instance of each WorkflowGen Windows Service. You also don't have to use the database container; if you want, you can externalize the database to a cloud provider such as Azure SQL or your own on-premise SQL Server.

As usual, you can configure the SMTP service that you want to use with WorkflowGen's container. There is no special setup needed for this.

SQL Server Hosting Options

Overview

This section explains the recommended configurations for the database in production.

Deploying a database

Business Continuity & Disaster Recovery

Overview

This section contains pointers to get started with different solutions for creating backups and recovering from an unforeseen data loss.

In production, you should be using an orchestrator like Docker Swarm, Kubernetes, or Kubernetes in Azure Kubernetes Service.

Log Gathering & Application Metrics

Overview

This section presents what is logged in the WorkflowGen image and how. It also shows pointers to configure centralized logging with some services and orchestrators.

WorkflowGen doesn't come with metrics generation out-of-the-box. Nevertheless, you can configure some existing software or services with WorkflowGen's container in order to get more valuable metrics for monitoring performance and traffic.

Log sources

When deploying WorkflowGen, many applications provide logs through different streams. This table lists the different log sources and their streams:

As you can see, there are many log sources and not all are handled directly by the container. Some of them need to be managed manually.

WorkflowGen web application logs

These logs are written in files in the App_Data folder, which is exposed through a volume. For more information about exposed volumes, see the section.

In order to centralize these logs in a logging service or system, you need to develop your own script or application that will periodically read the logs in the App_Data volume and push them to the service. Concretely, this is done by developing a Singleton container that has access to the WorkflowGen data volume. In Kubernetes, you would deploy this container inside a pod that has only one replica to avoid problems with concurrency.

WorkflowGen Windows Services logs

These logs are written to the Windows Events API and are retrieved by the WorkflowGen container only when the start mode is win_services, dir_sync, or engine. In any other case, it's the IIS logs that are redirected to the standard output and the Windows Services logs are discarded.

To get all the logs from WorkflowGen, you should use the architecture that separates each start mode into its own container. For more information, see the section.

IIS logs

IIS logs are written in multiple files inside the WorkflowGen container. You don't have to manually manage them. The container reads the logs and directs them to the standard output of the container. The standard output of each container is picked up by the Docker logging system.

There are many Docker logging drivers to indicate to Docker where to put these logs. By default, they are written on the host in JSON format at the C:\ProgramData\Docker\logs path. The rest of this section provides more information about the Docker logging system and how to use it to centralize logs.

In Kubernetes, you can configure your own logging agent or use the default one provided. For more details about logging in Kubernetes, see its page. Many cloud providers offer a centralized service to visualize logs from pods in their Kubernetes service. Refer to your cloud provider's documentation for details.

iisnode logs

These logs are disabled by default and can be enabled by setting the following environment variables for the WorkflowGen container:

It's recommended to activate these logs in a development environment only because they can be exposed through HTTP.

As shown, the logging is done on a per application and per container basis. To get these logs from the container, you have to use volumes and a custom application to centralize the logs, or build your own image based on the WorkflowGen image that will redirect those logs in some way to the container's standard output. For more information about making a custom WorkflowGen image, see the section.

Capturing logs and metrics

In order to centralize logs outside of a Docker host, you first need to choose a logging system or service. Once this is done, you need to use your orchestrator's specific method to link the service to the logs.

Kubernetes

Kubernetes has a similar functionality available to manage logs for containers. See the following link for more information:

You can also use Azure Monitor with your Kubernetes Cluster. See the following link for more information:

Azure Kubernetes Service

The Azure Kubernetes Service documentation recommends using Azure Monitor for containers. See its documentation page for more details:

Other monitoring services

Prometheus

This software can help you reduce costs related to monitoring applications using a cloud service. Prometheus can be deployed as a container inside your cluster alongside WorkflowGen. You'll need to add a utility to the WorkflowGen container, so you'll need to make a custom WorkflowGen image. For more information about making a custom WorkflowGen image, see the section.

Here are some links to the Prometheus documentation and Dockerfile examples to help you get started with application metrics with Prometheus:

Grafana

Grafana can help you visualize metrics coming from the cluster. It also has a paid cloud service. Here are some links to get you started:

In-container IIS log gathering

If you prefer to gather only IIS logs directly from the container, Azure Application Insights provides a PowerShell tool called Application Insights Agent that's installed directly in the container. See for more information. You'll need to create your own image that incorporates this tool inside the container. For more information about custom WorkflowGen images, see the section.

This approach should be considered only if your Kubernetes cluster is not managed by Azure Kubernetes Service and you want Application Insights to gather the logs. Otherwise, use the default logging agent or something like an ELK stack (ElasticSearch, Logstash and Kibana) or EFK stack (ElasticSearch, fluentd, and Kibana).

Update Management

Overview

This section presents how to manage WorkflowGen updates and deploy them safely in your environments.

You can use the WorkflowGen upgrade container to automatically apply files and database operations when upgrading from one version to another. For more information about the upgrade container, see the Configuration page in the WorkflowGen Upgrade Image section.

Prerequisites

Back up all of the file shares.
Back up the database.

For more information about business continuity and disaster recovery, see the section.

Manual update

Step 1: Execute all required actions

These actions can include moving, deleting, or adding some files around in the file shares, updating some configuration in your orchestrator or configuration files, adding secrets, adding or removing services, etc. The actions are detailed in the (choose the version to which you want to upgrade).

Only execute the actions that concern the files in the file shares. Any actions pertaining to files or services in WorkflowGen's container must be ignored. These will already be done once the new version of the image is in place. For example, don't stop the IIS service, since it's useless with a Docker container.

Step 2: Upgrade the database

See the section in the (choose the version to which you want to upgrade).

If you're using the WorkflowGen database image, after upgrading the database, you need to update the container as well:

Step 3: Custom WorkflowGen image actions

Skip this step if you don't have a custom WorkflowGen image. See the section for more information.

Execute any actions on your image's files

If you have a custom WorkflowGen image, you have to perform the actions required for the web.config files if you have custom web.config files. Carefully read the section in the to see if you need to change anything in your files.

Update the WorkflowGen version in your Dockerfile

Your Dockerfile should be based on the WorkflowGen image (FROM instruction). Update the version number of the WorkflowGen image, build your image, and push it to your container registry. For example, if your version of WorkflowGen is 7.16.0 and you want to update to 7.16.1, execute the following change on the FROM instruction line:

Then, build your custom WorkflowGen image:

Finally, push the image to your container registry:

Step 4: Roll the update to your containers

In production, you should use an orchestrator and therefore use the mechanism for rolling updates provided by that orchestrator.

Since containers are stateless, updating them is as simple as replacing currently running ones with the new version. To do this:

Pull the new version of the container.
Remove containers with the old version.
Run containers with the new version.

For example, if you want to update to WorkflowGen version 7.16.1:

Custom Domain Names

Overview

This section describes some ways to configure domain names in Docker.

To configure a domain name in a WorkflowGen container, you can pass the WFGEN_APP_SETTING_ApplicationUrl=https://somedomain.com/wfgen

WorkflowGen Image

File Management

Overview

This section shows which persistent data are exposed and where. It also recommends some ways to persist, share, and back up the data. For backup strategies and recommendations, see the Business Continuity & Disaster Recovery section.

Persistent data in WorkflowGen

There are three elements that must be persisted in WorkflowGen: the App_Data folder, the wfapps web application folder, and the SQL data. The first two are grouped in the same file share for simplicity and ease of use. To deploy a database, see the section.

The other two are files from WorkflowGen, and the reasons they must be persisted through a file share is explained in the section.

Additionally, you must have a file share with a valid WorkflowGen license in it so that the container can pick it up. Those folders must be exposed to the WorkflowGen containers through volumes. For more information about Docker volumes, see the Docker article.

Particularity of Windows Containers

Volumes are handled differently with Windows Containers compared to Linux Containers. The permission model changes and is different depending on whether you use process isolation or Hyper-V isolation. Before continuing with the procedures in this section, you should read the Microsoft documentation on .

Essentially, you must ensure that WorkflowGen containers can read and write to the wfgdata volume and read from the licenses volume. The group in the container that will access the volumes is named IIS_IUSRS.

Recommended ways to persist

Local file system path on the Docker host

This is the simplest way to persist WorkflowGen files with the containers. It consists of creating a local volume or using a bind mount on your Docker host that will retain the files after a container is removed. Volumes are the preferred way to persist files versus bind mounts because they're managed by Docker. This method doesn't scale well across multiple Docker hosts, however, so other methods should be considered in this case.

Volumes

To create a volume for each data path in the container, execute the following command:

Then, you need to copy (or move) your license file to the licenses volume by executing the following command:

Now, you can run WorkflowGen container with those volumes to persist the data.

📌 Example of a `run` command

You have now successfully persisted WorkflowGen's files.

Bind mounts

Remember that you manage bind mounts manually. They are specific paths on the Docker host that you control. To use bind mounts as volumes, you only need to pass the paths when you execute the run command like so:

You can use an SMB file share with Windows Containers such as Azure Files. Concretely, you connect the share to the Docker host and then mount it like a bind mount to containers; this is called an SMB mount. You can read more about SMB mounts in the Microsoft documentation.

Using an orchestrator

Kubernetes

In Kubernetes, you'll use a Persistent Volume object to specify a place where Kubernetes will put data from pods. For more information about persistent volumes, see the page on the Kubernetes website.

Concretely, for WorkflowGen, you'll have to configure a volume that can handle the permission ReadWriteMany for the WorkflowGen data volume because multiple pods at the same time will access this volume to read and write data. Typically, to do this, you'll have to create a storage claim on the cluster like so:

In this example, the claim references a Storage Class, but you can reference a persistent volume directly, or other cloud-specific storage services depending on the cloud provider. Here, the azurefile storage class is provided by Azure Kubernetes Service. The allocation of the storage will be done automatically by the service. It will create a storage account with a file share that has 50 GB capacity.

Pickup directory

If you configure WorkflowGen to use a pickup directory for notifications, you'll also need to specify a volume in order to expose the notifications to other services that will process them.

The default path for the pickup directory is C:\inetpub\mailroot\Pickup. You can change it by supplying the WFGEN_APP_SETTING_ApplicationSmtpPickupDirectory environment variable with any path inside the container. Then, you'll need to create a volume for the files like so:

You can now map this volume to the configured pickup directory:

At this point, you could deploy another container with your service to take care of the notifications and bind the same volume to share the notification files.

Custom Image

Overview

This section shows how to create your own custom WorkflowGen image in order to customize WorkflowGen's files and DLLs.

Prerequisites

TLS/SSL

Overview

This section presents ways to configure a secure connection (HTTPS) to the WorkflowGen container using a certificate. With Docker, containers run on an internal network, and only exposed ports will be available publicly. Therefore, you can't set up a TLS connection on one container only; you have to do it for all the containers, but this method doesn't scale well.

WorkflowGen Database Image

File Management

Overview

This section shows which persistent data are exposed and where. It also recommends some ways to persist, share, and back up the data. For backup strategies and recommendations, see the section.

WorkflowGen Upgrade Image

Usage

Overview

This page presents the common use cases of the WorkflowGen upgrade image. This image is available as Linux and Windows containers, and is meant to be a single use container that runs until completion. You should delete it once you're done with it.

Upgrade steps

Kubernetes

TLS/SSL

Manual

In Kubernetes, there are tools to help you manage certificates and achieve a TLS connection. This is easier than making a custom architecture using the reverse proxy method. You can read more about managing certificates with Kubernetes at the following link:

Manage TLS Certificates in a Cluster

Using cert-manager

is a cloud native application that manages certificates for you. It includes mechanisms to ask for Let's Encrypt certificates automatically and get certificates from , or you can use your own certificates generated by a certificate authority (CA) or a self-signed certificate.

Multitenancy

Overview

This section presents how to achieve multitenancy with WorkflowGen images and Kubernetes. By the nature of containers and tools present in Kubernetes, a single cluster can have multiple instances of WorkflowGen with relative isolation from one another. The best isolation can be achieved with multiple clusters.

As reference for best practices, see the following links to Google Kubernetes Engine and Azure Kubernetes Service documentation:

Getting Started

Overview

This section presents how to quickly run the WorkflowGen container with a minimal architecture on your local machine.

Global prerequisites

Make sure to have a valid WorkflowGen license.
If you're using Windows Server, make sure that it's Windows Server 2019, and use the tag that corresponds to that version. For example, for Windows Server 2019, use the tag that ends with ltsc2019.

Docker manual local machine deployment

Architecture overview

At the end of this section, the following architecture will be deployed on your local machine:

Inside the Docker engine on your machine, you'll have a running WorkflowGen server and a WorkflowGen database. Both of these will use volumes mapped to your local machine to persist data files.

Prerequisites

Make sure to have installed Docker on your machine.

For Windows 10 Pro

Follow the instructions in the guide to install Docker for Windows. You must be using Windows containers, so you need at least Windows 10 Pro.

For Windows Server

Do not install Docker for Windows on Windows Server. It is designed for development only.

Follow the instructions in the guide to install Docker on Windows Server.

For this setup, it's recommended to use WorkflowGen's database Docker image. You can also use a SQL database installed on your local machine.

Run the database container

To download the database image into your local machine, open PowerShell and enter the following:

Don't forget to use the correct tag for your version of Windows.
The Windows version of the advantys/workflowgen-sql image is designed for development or testing only. It is not suited for production workloads. Instead, consider using the Linux version of the image (e.g. advantys/workflowgen-sql:7.18.2-ubuntu-18.04).

The physical location of the volume can be obtained using the following command:

Typically, it will be stored in C:\ProgramData\Docker\volumes\sqldata\_data. Make sure that the container has write access to this directory (see the Microsoft article for information).

You're now ready to run the database container. To do this, execute the following command:

Run the WorkflowGen container

Enter the following to download the WorkflowGen image:

Don't forget to use the correct tag for your version of Windows (see above).

For this container, you need two volumes in order to correctly persist the WorkflowGen data:

WorkflowGen licenses (licenses)
WorkflowGen's data (data), which contains the following:
- The App_data folder (appdata

You now need to copy your WorkflowGen license into the licenses volume. To do this, execute the following command:

This way, the WorkflowGen container will be able to pick it up via the volume. You also need an encryption key for the container; use the following command to generate one:

Shut down the containers

Once you're done with this environment, you can shut down containers by stopping them. They can be restarted later.

Any environment variable defined will be reapplied after restarting a container. Therefore, any changes made to a web.config file without environment variables will not be carried between restarts or re-runs.
This action keeps data in the container's file system between restarts. If you add a file that isn't in a volume, it will be kept after restarting.

Remove the containers

To completely remove containers, there's only one command to execute:

Docker Compose local machine deployment

Architecture overview

At the end of this section, the following architecture will be deployed on your local machine:

Inside the Docker engine on your machine, you'll have a running WorkflowGen server and a WorkflowGen database. Both of these will use volumes mapped to your local machine to persist data files.

Prerequisites

For Windows 10 Pro

Follow the instructions in the guide to install Docker for Windows. You must be using Windows containers, so you need at least Windows 10 Pro.

For Windows Server

Do not install Docker for Windows on Windows Server. It is designed for development only.

If you've provisioned a virtual machine on your cloud provider where the template indicates something like Windows Server with Containers, it's probably safe to assume that Docker is already installed; execute docker version on the machine to verify that it is. If so, you can skip the installation process.

Follow the instructions for Windows Server in the guide to install Docker on Windows Server.

For this setup, it's recommended to use WorkflowGen's database Docker image. You can also use a SQL database installed on your local machine.

Create the license volume

Then, you need to copy your license file to the licenses directory. The following command will show you where the license will be stored:

To copy your license, execute the following command:

Create the symmetric encryption key

This value should be generated by you. A simple GUID will suffice since it has sufficient entropy not to be guessed:

Create the environment files

For each service that you'll create (one for WorkflowGen and one for the database), you'll need a file that contains all of the environment variables for that service.

Database

Use the following file as a template:

Save it as database.env using the path where you'll put the Compose file.

WorkflowGen

Use the following file as a template:

Replace <YOUR_WFG_LIC_KEY> with the value of your WorkflowGen license key. Replace <YOUR_NEW_GUID> with the symmetric encryption key that you have generated earlier.

Save this file as workflowgen.env using the path where you'll put the Compose file.

Deploy the services

To deploy services with Docker Compose, you need a Compose file that describes them. Use the following Compose file for this example:

Save this file as docker-compose.yml using the path where you put your environment variable files, then execute the following command:

Configuration

Overview

This section explains how to completely configure a WorkflowGen container, including the web.config file, iisnode configuration for Node.js applications, database connection strings, etc. Everything is configurable via an environment variable except the license file, which is configured via a volume.

WorkflowGen environment variables

WorkflowGen's image provides a number of specific environment variables that makes specific configurations possible. The following table provides descriptions of each of them:

Format-based environment variables

WorkflowGen's image also exposes various environment variables based on a specific format in order to configure more generic elements.

`web.config`

In WorkflowGen, the web.config file is the main point of configuration. Since a container is by definition ephemeral, any changes made in the Configuration Panel would not persist between container restarts.

In order to set configuration properties in the web.config file, you need to use a specific format for an environment variable that will contain the value of the property you want to set; this format is WFGEN_APP_SETTING_<name>.

For example, if you want to set the ApplicationUrl property in the web.config to https://mycorporation.com/wfgen, you would set the WFGEN_APP_SETTING_ApplicationUrl=https://mycorporation.com/wfgen environment variable in the container.

📌 Example with the `run` command

For a list of web.config parameters and their descriptions and possible values, see the appendix in the .

iisnode configuration for Node.js applications

You can also set specific iisnode properties for each Node.js application. To do this, you need to set an environment variable with the following format: WFGEN_IISNODE_<node name>_<property name>.

Replace <node name> with the name of the Node.js application (AUTH, HOOKS, GRAPHQL, or SCIM).
Replace <property name> with the name of the property you want to set for the <iisnode/> XML node in the specific Node.js application's web.config

For example, if you want to set the iisnode loggingEnabled property in the Auth application to true, you would set the environment variable WFGEN_IISNODE_AUTH_loggingEnabled=true.

📌 Example with the `run` command

Special iisnode options for Node.js applications

There are some special options that you can enable for each Node.js application by setting an environment variable that has the following template: WFGEN_ENABLE_IISNODE_OPTION_<node app name>. Then, you replace <node app name> with the name of the Node.js application (AUTH for example) and the value must be one of the following:

Database configuration

Main connection string

The main connection string can be configured via the WFGEN_DATABASE_CONNECTION_STRING environment variable. You can put any string in this variable and its value will be put in WorkflowGen's web.config file at the MainDbSource connection string.

Here's how to specify the connection string with the run command:

Read-only connection string

If you have a read-only replica, you can configure it in the container as well. You can specify it with the WFGEN_DATABASE_READONLY_CONNECTION_STRING environment variable. It will be added to WorkflowGen's web.config file as a new entry in the connection strings with the name ReadOnlyDbSource.

Here's how to specify the read-only connection string with the run command:

Custom connection strings

You can also configure more connections to custom data sources if you need to. They can be configured using a specific environment variable format: WFGEN_CUSTOM_CONNECTION_STRING_<name>=<connection_string>.

For example, if you want a data source named MyDataSource with the connection string value of MyConnectionString in the WorkflowGen web.config, you would specify the following environment variable: WFGEN_CUSTOM_CONNECTION_STRING_MyDataSource=MyConnectionString.

📌 Example with the `run` command

Secrets

When using an orchestrator such as Kubernetes, you'll probably want to secure secrets using their built-in secret management tools. Follow the specific guide for your orchestrator to know how to create a secret.

For Kubernetes, see .

It's recommended to inject secrets into WorkflowGen containers as files because they won't be exposed as environment variables and they'll be removed from the container when it's stopped or removed.

Secrets management is only possible using an orchestrator.

In order to get the secret value in the file, you need to suffix any environment variable you want to get the value of this way with _FILE and set its value to the path of the file containing the secret. The container will then get the value in the file at the specified path and set the environment variable without the suffix with that value.

For example, let's say you want to set the license serial number in the web.config to WFG-SOME-LICENSE-KEY using the environment variable WFGEN_APP_SETTING_ApplicationSerialNumber, but you want to use a secret for the value. All you have to do is suffix the environment variable name with _FILE so it becomes WFGEN_APP_SETTING_ApplicationSerialNumber_FILE. Then, set the value of this variable to the path of the file containing the serial number.

📌 Example with Docker Swarm orchestrator

For Kubernetes, you would create a ConfigMap that complements your secret like this:

Then, you would map the ConfigMap as environment variables and mount the secret as a volume like this:

Configuring the authentication mode

For all authentication modes, you need to set WFGEN_APP_SETTING_ApplicationUrl and WFGEN_APP_SETTING_ApplicationSerialNumber in order to avoid unwanted behaviors.

Application authentication

In order to let WorkflowGen handle authentication and the storage of user passwords, you don't need to configure anything special in the container. Keep in mind that the default username for the WorkflowGen administrative account is wfgen_admin.

Windows and Basic authentication

In order to make Windows or Basic authentication modes work, your host needs to be in an Active Directory forest. Creating a user account on the host for Basic authentication won't work, because the IIS web server inside the container will try to find a user account registered inside the container instead of the host. For this reason, you need Active Directory.

To configure your Docker host to work with Active Directory to authenticate users, follow the (gMSA) guide from Microsoft in its Windows Containers documentation.

Kubernetes supports gMSAs for Windows pods and containers as of version 1.18. See the Kubernetes article for details on how to configure it. Keep in mind that not all cloud providers supports gMSAs with Kubernetes. For example, Azure Kubernetes Service doesn't support this feature.

You can't use Basic authentication with Kubernetes.

Azure v1 and Microsoft Identity Platform

For these providers, there is no special configuration to do other than setting the WFGEN_AUTH_MODE variable. For configuration instructions, see the guide.

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

For these providers, there is no special configuration to do other than setting the WFGEN_AUTH_MODE variable. For configuration instructions, see the .

Configuring your license

In order to configure your license, you need to set a specific environment variable with your license and copy your license file into a volume exposed to the WorkflowGen container. To do this, you first need to create a license volume or have your license at a specific path.

Create a volume

This will create a volume at a specific path on your file system (typically C:\ProgramData\Docker\volumes\licenses\_data) managed by Docker. You can get the path to the volume by executing the following command:

Then, you need to copy your license file to this location:

Now, you can run the WorkflowGen container like so:

Use a specific path

Here, you'll provide a path that you control as a volume to the container. You only need to pass the path when you run WorkflowGen:

Bringing the WorkflowGen website offline

You can bring the web applications inside WorkflowGen's container offline by executing a script embedded in the image. This is useful to ensure that the site is still available when you want to perform maintenance tasks on its data without anything new being written. With pure containers, you can execute the following command:

With Kubernetes, you can use kubectl:

You must do this for each WorkflowGen container that is running. The recommended approach is to scale down the number of containers to one and execute the set-state.ps1 script once.

If you browse to your WorkflowGen website, you'll see the default offline web page. You can customize this web page by adding your own HTML file at the path <wfgen appdata>\Templates\server\offline.htm. If this file is present, it will be taken instead of the default one. If you have a volume for WorkflowGen's data, you can execute the following script:

You can bring the site back online by executing the following command:

Using an orchestrator

Kubernetes

Kubernetes also has a built-in object called ConfigMap to manage pod configuration. See the Kubernetes article for more information and instructions on how to use it. You should use this object to configure environment variables for WorkflowGen.

You can also manage sensitive information by protecting it further in the orchestrator in a secure area. See the Kubernetes article for more information and instructions on how to use it. You should use this object to protect sensitive information such as the WorkflowGen license key, usernames, passwords, cryptographic keys, API keys, etc.

Using your own configuration files

In order to use your own configuration files, you should build your own WorkflowGen image using the WorkflowGen onbuild image variant. See the page in the WorkflowGen Image section for more information.

Using an external configuration manager

Some popular configuration managers support Docker containers out-of-the-box. Here are a few links to their specific documentation to get you started:

Chef

Ansible

Puppet

WorkflowGen Helm Chart

Overview

This section presents the WorkflowGen Helm chart including usage, configuration options, and examples. Using the WorkflowGen chart simplifies the deployment of WorkflowGen in a Kubernetes cluster by not having to manage many Kubernetes deployment files. You only have to manage one "values" file.

Prerequisites

You must have a working Kubernetes cluster with Windows Server 2019 nodes.
You must have installed the kubectl command line tool and it must be connected to the cluster.
You must have installed the helm command line tool. See the section on the Helm website for instructions on how to install it. Only the Helm version 3.0+ is supported.

Helm chart primer

From the :

A chart is a collection of files that describe a related set of Kubernetes resources.

These resources are written in YAML in the chart with the help of the Go templating language. This enables the chart to generate valid Kubernetes resource definition files based on values provided by the user of the chart. Therefore, when you use the chart to install or upgrade WorkflowGen, you can provide some values that will help you deploy the correct resources for WorkflowGen.

A chart has a manifest file called Chart.yaml. It has a version for the chart and a version for the application. For example, the chart version of WorkflowGen could be 0.0.3 and its application version 7.18.3. A chart also has a kubeVersion that tells which versions of Kubernetes are supported. In the case of WorkflowGen, only versions 1.14 and higher are supported since it is the first version to include Windows containers support.

You install a chart using the command line. For example:

This will install the chart that is at the path ./chart-path in the cluster with the release name release-name. It also sets a the value image.tag to 7.15.5-win-ltsc2019. More information about the install command including its --set parameter can be found in on the Helm website.

While useful for a few parameters, setting values from the command line can be cumbersome and prone to errors, which is why you can also set values from a YAML or JSON file. The first thing you need to do is to create the file:

Then, you can pass that file to the install command:

WorkflowGen values

The following are all of the value names supported by the WorkflowGen chart and their default values, accompanied by brief descriptions.

The chart is divided in groups of configuration:

Global
WorkflowGen
WorkflowGen Windows services
Database

Global values

Global values control the overall deployment that results from the Helm generation. For example, the scalable value indicates if the resulting deployment should be scalable or not. If true, the resulting deployment will have a separate pod for the WorkflowGen Windows services that will be deployed using the Singleton deployment pattern. The WorkflowGen web services will be deployed with the number of replicas indicated by the replicaCount global value.If false, WorkflowGen web and Windows services will be deployed in a single pod using the Singleton pattern.

To deploy multiple WorkflowGen instances that must be isolated, the use of the tenantName value is recommended because it will prefix each object created by the installation with the name of the tenant and add a selector label named workflowgen.com/tenant=tenantName.

WorkflowGen & Windows services

The WorkflowGen part groups the configuration options related to the WorkflowGen web and Windows services pods when configuring the WorkflowGen product. For infrastructure-related configuration, configuration options are in separate groups in order to be able to properly deploy each part individually but still having the same WorkflowGen-specific configuration.

WorkflowGen configuration

There are two main ways to configure WorkflowGen with the chart: with the values file or by providing your own ConfigMap or Secret.

In your values file, you can use the sub YAML object workflowgen.config and workflowgen.secret to configure WorkflowGen's environment variables. Let's begin with an example:

Each key and value in the config part will be added as in a ConfigMap object and will be used by the WorkflowGen deployments. Concretely, the keys and values of the ConfigMap will be injected as environment variables in WorkflowGen's container. Each value must be of the string type. Therefore, YAML boolean values such as true, yes, and Y will be rejected. Use single or double quotes when needed, as in the example.

For secret values, you can do exactly like the config part. You only have to provide the name of the secret and its concrete value. The chart will add them to a Secret object and encode the value in Base64. The Secret object will then get injected as a volume inside WorkflowGen's container. Each key will become a file with its concrete value written inside it. Therefore, you need a corresponding

File storage

The chart generates a PersistentVolumeClaim (PVC) object based on values that you've provided. As with the WorkflowGen configuration, you can specify your own PVC outside of the chart and reference it.

In your values file, you can use the sub YAML object workflowgen.dataPvcSpec to configure the PersistentVolumeClaim for WorkflowGen's data (App_Data and wfapps). Let's begin with an example:

The content of the object is exactly the . What you write in there will be taken as-is in the object definition.

In this example, the storage class azurefile is specific to Azure Kubernetes Service.

License

The license must be stored on the Kubernetes cluster before installing the chart. This is because it's more efficient to store it in a secret and inject it as a volume in the WorkflowGen pods instead of provisioning a file share and connecting it to the pods. For the chart to handle it, you need to specify the secret name where the license is stored and the license item name in the secret. Here's an example:

Step 1: Store your license in the cluster

The secret object must be in the same namespace as the WorkflowGen pods.

This command will create a secret named wfgen-license-secret with an item named WFG.lic and its value will be the content of the file.

Step 2: Reference this secret in the values file

For more information about how to inject files from a Secret object into pods, see in the Kubernetes documentation.

Custom image reference

To use your own WorkflowGen image, you can change the default reference like this:

Service

There is a service that is created by the chart with the WorkflowGen pod for its discovery. By default, the chart will create a ClusterIP service that provides a cluster-wide IP address and domain name that you can reference from anywhere in the cluster. This works best with an Ingress controller to route external traffic to it. For more information about Ingress controllers, see in the Kubernetes documentation.

You can customize this to automatically create a load balancer instead by providing the following value:

The LoadBalancer type only works with cloud providers. For on-premise clusters, you should use another technique.

Security

There are many security features that aren't yet supported, or don't work in Windows but do work in Linux. It's important to plan the security of the deployments. To find out more about unsupported security features on Windows containers in Kubernetes, see the section in the documentation.

The web applications in the WorkflowGen container run as a user that is part of the IIS_IUSRS group. This is important for setting permissions for file storage. If this group doesn't have MODIFY permission on the files volume, the container will fail to write to the volume. Generally, you can set mount options for a persistent volume depending on the storage provider or you can run an init container to set the permissions. To get the mount options for Azure Files, see the section in the Microsoft documentation.

There are many more options for customizing your Helm release. The majority of them are dependent on your cluster environment. They are all Kubernetes terms, so you can search for them in a search engine and get useful information. The only one that this section will discuss is resources. The resources YAML object allows you to limit and request resource consumption for a given pod. Requests are to help the scheduler to assign pods to nodes. Limits are to limit the amount of resources the pod can use. The following requests and limits are known to work well for WorkflowGen pods:

Keep in mind that Windows containers are a lot bigger in terms of storage, CPU, and memory consumption. Therefore, you'll probably need bigger Windows nodes than your Linux ones.

Database

The database part contains the values used to generate the deployment files for the WorkflowGen database StatefulSet and its related objects. It is an optional feature to deploy a database pod along with a WorkflowGen pod. You can disable the creation of the StatefulSet by setting the following values:

Configuration

There are two main ways to configure the database with the chart: with the values file or by providing your own ConfigMap or Secret.

In your values file, you can use the sub YAML object database.config and database.secret to configure the environment variables of the database. Let's begin with an example:

Each key and value in the config part will be added as is in a ConfigMap object. It will be used by the StatefulSet. Concretely, the keys and values of the ConfigMap will get injected as environment variables in the database container. Each value must be of the string type. Therefore, YAML boolean values such as true, yes and Y will be rejected. Use single or double quotes when needed just like in the example.

For secret values, you can do exactly like the config part. You only have to provide the name of the secret and its concrete value. The chart will add them to a Secret object and encode the value in Base64. The Secret object will then get injected as a volume inside the database container. Each key will become a file with its concrete value written inside it. Therefore, you need a corresponding

File storage

A StatefulSet needs a PersistentVolumeClaim template to generate a volume claim for each of its replicas. You can't use your own PVC this time because it is a template, not a concrete object. This template is part of the StatefulSet specification. Here's an example:

The content of the template is exactly the . Anything you write will be added to the StatefulSet specification as-is. In this example, the access mode is ReadWriteOnly because the default storage class refers to an Azure Disk. Azure disks can only be bound to a single node and pod at a time. Physical disks are the preferred way to store database files for better performance. For more information about Azure Disks, see the Microsoft documentation.

Custom image reference

To use your own WorkflowGen database image, you can change the default reference like this:

Service

There is a service that is created by the chart with the database pod for its discovery. By default, the chart will create a ClusterIP service without a cluster IP address (clusterIP: None). This is called a headless service. It provides a way to get a cluster wide domain name to each pod of the StatefulSet. Therefore, you can refer directly to the database instance of your choice. It is recommended to leave the default values untouched. They are available in case you want to customize the service further. For more information about headless services in Kubernetes, see in its documentation.

Additionally, to make domain names predictable, you might want to override the full name of the StatefulSet, because the name is generated based on the chart's name and the release name, and you might not know the release name in advance. In this case, you can do the following:

This will ensure that each pod in the StatefulSet has a unique domain name based on this name. If this release is in the default namespace, the first pod will have the domain name my-database-0.my-database.default.svc.cluster.local. You then reference this domain name in the connection string of the WorkflowGen configuration at port 1433 and it should connect successfully.

Security

Since the database image used is a Linux image by default, all of the security features are available. You can run the database with a non-root user and group. For more information about running the database container as a non-root user, see in the SQL Server documentation. Keep in mind that you also have to setup the permissions for the storage to be able to read and write into it.

For more information about Docker security features, see in the Docker documentation. To find out how to configure these security features in Kubernetes, see in the Kubernetes documentation.

There are many more options you can customize your Helm release with. The majority of them are dependent on your cluster environment. They are all Kubernetes terms, so you can search for them in a search engine and get useful information. The only one that this section will discuss is resources. The resources YAML object allows you to limit and request resource consumption for a given pod. Requests are to help the scheduler to assign pods to nodes. Limits are to limit the amount of resources the pod can use. The following requests and limits are known to work well for database pods:

Since WorkflowGen can only handle a main connection string and a read-only replica, you may want to limit the number of pods in the StatefulSet to two and scale vertically if you need more performance.

Ingress

The ingress section of the values is a simplified view of the complete . It is optional to generate the Ingress rule object. To disable it, you can add the following values:

Otherwise, here's an example of how to use the Ingress section:

This is a complete example on how to use it. In this example, there are annotations set to add some information on how to handle them. The ingress.class tells Kubernetes to use the Nginx ingress controller to handle this Ingress rule. The Nginx ingress controller must be installed in your cluster for the routing to work. For more information about the Nginx ingress controller, see the or . The two have different feature sets and are not developed by the same entity. The cert-manager.io/cluster-issuer annotation is a Cert-Manager specific annotation that tells it to use the letsencrypt cluster issuer for the TLS certificate. See the page of this section for more information about cert-manager.

The hosts section is a list of domain names and where they lead in the container. In this case, when a user goes to myinstance.example.com, it will be routed to / on the WorkflowGen container which IIS will handle. The tls section tells what secret to use for what host. TLS certificates are stored in this secret.

Hooks

In Helm, there is a concept of hooks that enables the developer to deploy some resources (temporary or permanently) at different event in the lifecycle of a chart.

Pre-upgrade hook

The pre-upgrade hook deploys a Kubernetes Job that will add possible missing files and templates to your WorkflowGen database volume and migrate the database automatically. This deployment only occurs when you use the helm upgrade command. It will wait for the job to finish successfully before upgrading the WorkflowGen and database pods. This hook is optional and you can disable it by using the following values:

This pre-upgrade hook uses the WorkflowGen upgrade image to perform migrations. Here's a complete example to how to configure the hook:

There is no default tag specified for the image because both Windows and Linux versions of it are production-ready. For a better experience and performance, it is recommended to use the Linux version. The secret section of this example allows you to specify secret values to be put in a Secret object that will be deployed with the job. It will get deleted when the job is terminated. The name of the secret is generated from the release name. If your release name is wfgen, then the secret name will be wfgen-migrations-secret. The WFGEN_DATABASE_CONNECTION_STRING secret is required. It is automatically injected as an environment variable in the container. To customize the name of the secret to use for the upgrade container'sWFGEN_DATABASE_CONNECTION_STRING environment variable, you can populate the hooks.preupgrade.connectionStringSecretKey value. You can add your own environment variables as well.

The last part consists of the arguments to pass to the container. See for more information about configuring the WorkflowGen upgrade container.

Common scenarios

Deploying a simple WorkflowGen pod

Overview

This deployment is meant for a simple installation with a database deployed outside of the cluster. It will deploy a single WorkflowGen pod with all of its services including WorkflowGen Windows services. This diagram shows a high-level view of the objects that will be created when installing the release with the values given in the next part. This architecture is only vertically scalable. You can only scale up the limits of the pod to have a more performant instance.

How to deploy

First, create the values file:

MY-WFG-LIC-NUMBER is a placeholder value. You should replace it with your own serial number.
These values will create a LoadBalancer-type service. If you are on a cloud provider, it will deploy a resource in the cloud provider's specific load balancer service (e.g. Azure Load Balancer, AWS Elastic Load Balancer, etc).

Before installing a release of the chart, you have to create the WorkflowGen license secret object in your cluster. For this particular example, the name of the license file is WFG.lic and the name of the secret object is wfgen-license-secret. Execute the following command to create it:

With that done, you can now install the release:

The last argument is the path (or URL) to the WorkflowGen chart. You can use the URL directly or download it and use a local path. From this point, you should have a working WorkflowGen pod in your cluster.

Deploying a scalable WorkflowGen architecture

This architecture is best suited for production workloads that have an external database. This deployment enables you to scale WorkflowGen web applications horizontally (by adding replicas), which has many benefits such as increased availability and performance. The WorkflowGen Windows services must be scaled vertically and cannot be scaled horizontally. Make sure to deploy that pod to a node that has sufficient resources.

How to deploy

MY-WFG-LIC-NUMBER is a placeholder value. You should replace it with your own serial number.
These values will create a LoadBalancer-type service. If you are on a cloud provider, it will deploy a resource in the cloud provider's specific load balancer service (e.g. Azure Load Balancer, AWS Elastic Load Balancer, etc).

This is the same example as for the simple deployment, except that the scalable property is gone (true by default), the number of replicas is three, and there are resource requests and limits for the Windows services.

With this done, you can now install the release:

Deploying a scalable WorkflowGen architecture with a database container

This architecture is best suited for the complete automation experience and can help reduce costs by having the container inside the cluster instead of in an external environment. It is a scalable architecture where the WorkflowGen web applications can be scaled horizontally and vertically, the Windows Services can be scaled vertically only, and the WorkflowGen database can be scaled horizontally up to two replicas (read/write and read-only) and vertically.

How to deploy

MY-WFG-LIC-NUMBER is a placeholder value. You should replace it your own serial number.
These values will create a LoadBalancer-typer service. If you are on a cloud provider, it will deploy a resource in the cloud provider's specific load balancer service (e.g. Azure Load Balancer, AWS Elastic Load Balancer, etc).

This is the same example as before, except that a database section has been added. The security context specifies that the container should run as root. This should be avoided as a general security good practice. It is there for simplicity. You should always use a different user than root and check the permissions on the volumes, for example with an init container.

With this done, you can now install the release:

# Default values for WorkflowGen.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# replicaCount Number of replicas to create per deployment of WorkflowGen. Doesn't impact database.
replicaCount: 1
# scalable Deploy WorkflowGen and its database in a scalable architecture.
scalable: true
# tenantName For multi-tenancy, it is recommended to populate this value in a multi-tenant architecture. This name will be put as a prefix for resources' name and the label "workflowgen.com/tenant: tenantName" will be added as a selector label.
tenantName: ""

# workflowgen Configuration related to the WorkflowGen pod.
workflowgen:
  # image Configuration related to the image to be used for the WorkflowGen pod.
  image:
    # repository The repository to use to pull the image.
    repository: advantys/workflowgen
    # tag The image tag to use.
    tag: ""
    # pullPolicy The pull policy to adopt for this image.
    pullPolicy: Always
  # nameOverride Override the name of the chart.
  nameOverride: ""
  # fullnameOverride Override the name of the WorkflowGen deployment. It is based on the name by default.
  fullnameOverride: ""
  # runtimeClassName Runtime class to use with the deployment.
  runtimeClassName: ""
  # strategy The update strategy for the WorkflowGen deployment.
  strategy:
    type: Recreate
  # nodeSelector Node selectors to use for the WorkflowGen pod. WorkflowGen only works on Windows Server.
  nodeSelector:
    kubernetes.io/os: windows
  # annotations Annotations to attach to the WorkflowGen deployment. You can attach annotations to the deployment itself or its template.
  annotations: {}
    # deployment: {}
    # template: {}
  # tolerations Tolerations to apply to the WorkflowGen pod.
  tolerations: []
  # affinity Affinities to apply to the WorkflowGen pod.
  affinity: {}
  # createConfigMap Create a ConfigMap for WorkflowGen's configuration.
  createConfigMap: true
  # configMapNameOverride Override the name of WorkflowGen's ConfigMap.
  configMapNameOverride: ""
  # config The configuration to put in the ConfigMap.
  config: {}
  # createSecret Create a Secret for WorkflowGen's secret values.
  createSecret: true
  # secretNameOverride Override the name of WorkflowGen's Secret.
  secretNameOverride: ""
  # secretMountPath The mount path inside WorkflowGen's containers where to put the secret files.
  secretMountPath: C:\secrets
  # secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
  secret: {}
  # license Configuration related to WorkflowGen's license.
  license:
    # volumeNameOverride Override the name of the license's volume.
    volumeNameOverride: ""
    # secretName The name of the secret that contains WorkfowGen's license.
    secretName: ""
    # items The specific items to use from the secret to inject in WorkflowGen's containers.
    items: []
      # - key: ""
      #   path: ""
  # createDataPvc Create a PersistentVolumeClaim for the data volume of WorkflowGen.
  createDataPvc: true
  # dataPvcNameOverride Override the name of data's PersistentVolumeClaim.
  dataPvcNameOverride: ""
  # dataVolumeNameOverride Override the volume name associated to the PersistentVolumeClaim.
  dataVolumeNameOverride: ""
  # dataPvcSpec The data PersistentVolumeClaim specifications.
  dataPvcSpec: {}
    # accessModes:
    #   - ReadWriteMany
    # storageClassName: storageclass
    # resources:
    #   requests:
    #     storage: 4Gi
  # additionalVolumes Additional volumes to attach to WorkflowGen's deployment.
  additionalVolumes: []
  # additionalVolumeMounts Additional volumes to mount in WorkflowGen's container.
  additionalVolumeMounts: []
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # securityContext The security context of WorkflowGen's container.
  securityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true
    # runAsUser: 1000
    # runAsUserName: ContainerUser
  # resources Configuration related to the resources of the container.
  resources: {}
    # limits:
    #   cpu: '1'
    #   memory: 2Gi
    # requests:
    #   cpu: '1'
    #   memory: 2Gi
  # service Configuration related to the service associated with WorkflowGen's deployment.
  service:
    # type The type of the service.
    type: ClusterIP
    # port The port exposed from the service.
    port: 80
    # clusterIP The cluster IP address to use.
    clusterIP: ""

# winServices Configuration related to WorkflowGen's Windows Services deployment. Ignored when release not scalable.
winServices:
  # nameOverride Override the chart name of this deployment.
  nameOverride: ""
  # runtimeClassName Runtime class to use with the deployment.
  runtimeClassName: ""
  # nodeSelector Node selectors to use for the WorkflowGen Windows Services pod. WorkflowGen only works on Windows Server.
  nodeSelector:
    kubernetes.io/os: windows
  # annotations Annotations to attach to the WorkflowGen Windows services deployment.
  annotations: {}
  # fullnameOverride Override the name of the Windows services deployment.
  fullnameOverride: ""
  # tolerations Tolerations to apply to the WorkflowGen Windows services pod.
  tolerations: []
  # affinity Affinities to apply to the WorkflowGen Windows services pod.
  affinity: {}
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # dirSync Configuration related to the directory synchronization Windows service container.
  dirSync:
    # securityContext The security context of the directory synchronization Windows service container.
    securityContext: {}
      # capabilities:
      #   drop:
      #   - ALL
      # readOnlyRootFilesystem: true
      # runAsNonRoot: true
      # runAsUser: 1000
      # runAsUserName: ContainerUser
    # resources Configuration related to the resources of the container.
    resources: {}
      # limits:
      #   cpu: '1'
      #   memory: 2Gi
      # requests:
      #   cpu: '1'
      #   memory: 2Gi
  # engine Configuration related to the engine Windows service container.
  engine:
    # securityContext The security context of the engine Windows service container.
    securityContext: {}
      # capabilities:
      #   drop:
      #   - ALL
      # readOnlyRootFilesystem: true
      # runAsNonRoot: true
      # runAsUser: 1000
      # runAsUserName: ContainerUser
    # resources Configuration related to the resources of the container.
    resources: {}
      # limits:
      #   cpu: '1'
      #   memory: 2Gi
      # requests:
      #   cpu: '1'
      #   memory: 2Gi

# database Configuration related to the database deployment.
database:
  # image Configuration related to the image to be used for the database pod.
  image:
    # repository The repository to use to pull the image.
    repository: advantys/workflowgen-sql
    # tag The image tag to use.
    tag: ""
    # pullPolicy The pull policy to adopt for this image.
    pullPolicy: Always
  # create Create a database deployment to be used with the WorkflowGen deployment.
  create: true
  # createConfigMap Create a ConfigMap for the database configuration.
  createConfigMap: true
  # configMapNameOverride Override the name of the database ConfigMap.
  configMapNameOverride: ""
  # config The configuration to put in the ConfigMap.
  config: {}
  # createSecret Create a Secret for the database secret values.
  createSecret: true
  # secretNameOverride Override the name of the database Secret.
  secretNameOverride: ""
  # secretMountPath The mount path inside the database container where to put the secret files.
  secretMountPath: /mnt/secrets
  # secret The secret values to put in the Secret object. Values will be automatically endoded in base64.
  secret: {}
  # useEnv Indicates to use additional environement variables.
  useEnv: false
  # env Definition of the environment variables.
  env: []
    # - name: test
    #   value: value
    # - name: test2
    #   valueFrom:
    #     secretKeyRef:
    #       key: test-key
    #       name: secret-name
    # For MSSQL Linux, you may want to put this here or in the config section:
    # - name: MSSQL_PID
    #   value: Express # You can replace with the edition you want: "Enterprise" or "Developer" or "Express"
  # fullnameOverride Override the name of the database deployment.
  fullnameOverride: ""
  # nameOverride Override the chart name of this deployment.
  nameOverride: ""
  # args The arguments to pass to the database container.
  args: []
  # tolerations Tolerations to apply to the database pod.
  tolerations: []
  # affinity Affinities to apply to the database pod.
  affinity: {}
  # runtimeClassName Runtime class to use with the stateful set.
  runtimeClassName: ""
  # nodeSelector Node selectors to use for the database pod.
  nodeSelector: {}
    # kubernetes.io/os: linux
  # annotations Annotations to attach to the database deployment. You can add annotations for the StatefulSet or its template.
  annotations: {}
    # statefulset: {}
    # template: {}
  # podSecurityContext The security context of the pod.
  podSecurityContext: {}
    # fsGroup: 2000
  # securityContext The security context of the database container.
  securityContext: {}
    # capabilities:
    #   drop:
    #   - ALL
    # readOnlyRootFilesystem: true
    # runAsNonRoot: true
    # runAsUser: 1000
    # runAsUserName: ContainerUser
    # With MSSQL, you may want to use the mssql (10001) account
    # runAsUser: 10001
    # runAsGroup: 0
    # If you can't configure the volumes with the correct permissions for mssql, you may want to run the container as root:
    # runAsUser: 0
    # runAsGroup: 0
  # resources Configuration related to the resources of the container.
  resources: {}
    # limits:
    #   cpu: '1'
    #   memory: 2Gi
    # requests:
    #   cpu: '1'
    #   memory: 2Gi
  # volumeClaimTemplateSpec PersistentVolumeClaim specification for the StatefulSet PersistentVolumeClaimTemplate.
  volumeClaimTemplateSpec: {}
    # accessModes:
    #   - ReadWriteOnce
    # storageClassName: default
    # resources:
    #   requests:
    #     storage: 4Gi
  # service Configuration related to the database cluster service.
  service:
    # type The type of the service.
    type: ClusterIP
    # port The port exposed from the service.
    port: 1433
    # clusterIP The cluster IP address to use.
    clusterIP: None

# imagePullSecrets Secrets to inject in order to pull images from private repositories.
imagePullSecrets: []

# ingress Configuration related to the ingress rules.
ingress:
  # enabled Whether or not to enable the ingress rules defined here.
  enabled: true
  # annotations Additional annotations to put on the Ingress object.
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # cert-manager.io/cluster-issuer: letsencrypt
    # kubernetes.io/tls-acme: "true"
  # hosts List of hosts and routes for routing purposes.
  hosts:
    - host: chart-example.local
      paths: []
    # - host: example
    #   paths: []
  # tls List of TLS hosts associated with a secret containing the proper TLS certificates.
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

# hooks Configuration related to the Helm hooks of this chart
hooks:
  # preupgrade
  preupgrade:
    # enabled Enables the use of the pre-upgrade hook which will migrate WorkflowGen's data when upgrading.
    enabled: true
    # image Configuration related to the image to be used for the pre-upgrade pod.
    image:
      # repository The repository to use to pull the image.
      repository: advantys/workflowgen-upgrade
      # tag The image tag to use.
      tag: ""
    # args The arguments to pass to the migration container.
    args: []
    # env Definition of the environment variables.
    env: []
    # - name: test
    #   value: value
    # - name: test2
    #   valueFrom:
    #     secretKeyRef:
    #       key: test-key
    #       name: secret-name
    # connectionStringSecretKey The key to pick for the WFGEN_DATABASE_CONNECTION_STRING environment variable. Defaults to WFGEN_DATABASE_CONNECTION_STRING.
    connectionStringSecretKey: ""
    # secret The secret values to put in the Secret object for this hook. Values will be automatically endoded in base64.
    secret: {}
    # runtimeClassName The name of the RuntimeClass to use with this pod.
    runtimeClassName: ""
    # podSecurityContext The security context for the pod specification.
    podSecurityContext: {}
    # nodeSelector Node selectors to use for the pre-upgrade pod.
    nodeSelector:
      kubernetes.io/os: linux
    # affinity Affinities to apply to the pre-upgrade pod.
    affinity: {}
    # tolerations Tolerations to apply to the pre-upgrade pod.
    tolerations: []

7.14 to 7.22

WorkflowGen for Docker

Getting Started

Overview

Global prerequisites

Docker manual local machine deployment

Architecture overview

Prerequisites

For Windows 10 Pro

Run the database container

Run the WorkflowGen container

Shut down the containers

Remove the containers

Docker Compose local machine deployment

Architecture overview

Prerequisites

For Windows 10 Pro

Create the license volume

Create the symmetric encryption key

Create the environment files

Database

WorkflowGen

Deploy the services

Main Architecture Description

Overview

SQL Server Hosting Options

Overview

Deploying a database

Business Continuity & Disaster Recovery

Overview

Log Gathering & Application Metrics

Overview

Log sources

WorkflowGen web application logs

WorkflowGen Windows Services logs

IIS logs

iisnode logs

Capturing logs and metrics

Kubernetes

Azure Kubernetes Service

Other monitoring services

Prometheus

Grafana

In-container IIS log gathering

Update Management

Overview

Prerequisites

Manual update

Step 1: Execute all required actions

Step 2: Upgrade the database

Step 3: Custom WorkflowGen image actions

Execute any actions on your image's files

Update the WorkflowGen version in your Dockerfile

Step 4: Roll the update to your containers

Custom Domain Names

Overview

WorkflowGen Image

File Management

Overview

Persistent data in WorkflowGen

Particularity of Windows Containers

Recommended ways to persist

Local file system path on the Docker host

Volumes

📌 Example of a run command

Bind mounts

Network file share

Using an orchestrator

Kubernetes

Pickup directory

Custom Image

Overview

Prerequisites

TLS/SSL

Overview

WorkflowGen Database Image

File Management

Overview

WorkflowGen Upgrade Image

Usage

📌 Example of a `run` command