Configuration

Overview

This section explains how to completely configure a WorkflowGen database container. Everything is configurable via an environment variable.

Environment variables

Variables specific to the base images

Some variables are available in the base images that provide functionalities related to SQL Server. For the Linux version, see the mcr.microsoft.com/mssql/server Docker Hub page and the Configure SQL Server container images on Docker Microsoft article. For the Windows version, see the microsoft/mssql-server-windows-express Docker Hub page.
Some environment variables in the base images are required. For example, you have to provide a value for the SA_PASSWORD environment variable.

Variables specific to WorkflowGen

The WorkflowGen database container adds special environment variables to enable additional features related to WorkflowGen. The following table provides descriptions for each of them:
Variable
Description & values
WFGEN_DATABASE_NAME
The name of the WorkflowGen database
Default value: WFGEN
WFGEN_DATABASE_CONTAINMENT
Sets the WorkflowGen database to contain database users for more portability (see contained database authentication Server Configuration Option for more information)
Possible values: Y (default), N
WFGEN_DATABASE_USER_USERNAME
The username of the database user that has access to the WorkflowGen database
Default value: WFGEN_USER
WFGEN_DATABASE_USER_PASSWORD
Required variable
The password of the database user that has access to the WorkflowGen database
WFGEN_DATABASE_FILE_PATH
Do not modify for Linux version
Internal path to the .mdf and .ldf database files inside the container
Default value:
  • Windows: C:\wfgen\sql
  • Linux: /var/opt/mssql/data
WFGEN_ADMIN_USERNAME
The username of the WorkflowGen administrative user
Default value: wfgen_admin
WFGEN_ADMIN_PASSWORD
Required variable
The password of the WorkflowGen administrative user
WFGEN_AUTH_APPLICATION
Indicates if the authentication method of WorkflowGen is applicative or not
Possible values: Y (default), N

Format-based environment variables

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.
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 in 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 sa account password in SQL Server to strong(!)Pass using the environment variable SA_PASSWORD, but you want to use a secret for the value. All you have to do is suffix the environment variable name with _FILEso that it becomes SA_PASSWORD_FILE. Then, set the value of this variable to the path of the file containing the password.

📌 Example with Docker Swarm orchestrator

PowerShell
Bash
1
# Create the secret for the license serial number
2
'strong(!)Pass' | docker secret create SA_PASSWORD -
3
4
# Create the container service in Docker Swarm
5
docker service create `
6
# ...
7
--env WFGEN_APP_SETTING_ApplicationSerialNumber_FILE=/run/secrets/SA_PASSWORD `
8
--secret SA_PASSWORD `
9
# ...
10
advantys/workflowgen-sql:7.18.3-ubuntu-18.04
Copied!
1
# Create the secret for the license serial number
2
echo 'strong(!)Pass' | docker secret create SA_PASSWORD -
3
4
# Create the container service in Docker Swarm
5
docker service create \
6
# ...
7
--env WFGEN_APP_SETTING_ApplicationSerialNumber_FILE=/run/secrets/SA_PASSWORD \
8
--secret SA_PASSWORD \
9
# ...
10
advantys/workflowgen-sql:7.18.3-ubuntu-18.04
Copied!
For Kubernetes, you would create a ConfigMap that complements your secret like this:
1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
name: database-config
5
data:
6
SA_PASSWORD_FILE: /mnt/secrets/SA_PASSWORD
7
---
8
apiVersion: v1
9
kind: Secret
10
type: Opaque
11
metadata:
12
name: database-secret
13
data:
14
# "c3Ryb25nKCEpUGFzcwo=" is the base64-encoded value of "strong(!)Pass"
15
SA_PASSWORD: 'c3Ryb25nKCEpUGFzcwo='
16
Copied!
Then, you would map the ConfigMap as environment variables and mount the secret as a volume like this:
1
apiVersion: apps/v1
2
kind: StatefulSet
3
metadata:
4
name: wfgen-database
5
spec:
6
selector:
7
matchLabels:
8
# ...
9
template:
10
metadata:
11
labels:
12
# ...
13
spec:
14
containers:
15
- name: database
16
image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
17
# ...
18
envFrom: # ConfigMap as environment variables
19
- configMapRef:
20
name: database-config
21
# ...
22
volumeMounts:
23
# ...
24
- mountPath: /mnt/secrets # Mount Secret as a volume
25
readOnly: true
26
name: secrets
27
volumes:
28
# ...
29
- name: secrets # Mount Secret as a volume
30
secret:
31
secretName: database-secret
Copied!

Using an orchestrator

Kubernetes

Kubernetes also has a built-in object called ConfigMap to manage pod configuration. See the Configure a Pod to Use a ConfigMap Kubernetes article for more information and 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 Secrets 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 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

About security features

The Linux version of the database has some security features that can be used to improve the overall security of the database. For more information on security features in SQL Server for Linux, see Configure SQL Server container images on Docker in the Microsoft SQL Server documentation.
The Windows version of the container doesn't have the security features of the Linux version. It's advised to use the Windows version only for development and testing purposes.

Performance & high availability

You can configure replication with this container, but you'll have to make a custom image. For more information about making a custom image, see the Custom Image page of this section. For more information about configuring replication in SQL Server, see Configure a SQL Server Availability Group for read-scale on Linux in the Microsoft documentation.

Use with Kubernetes

You should always deploy the database container within a StatefulSet so that each container has its own separated storage. It also ensures that each container has a unique DNS name inside the cluster so that it can be found easily by other containers. You can also configure each of the instances based on an incremental identifier so that you can set a read/write instance and several read-only instances. Here's an example of a simple StatefulSet deployment with the WorkflowGen database container:
1
apiVersion: v1
2
kind: Service
3
metadata:
4
name: database
5
spec:
6
type: ClusterIP
7
clusterIP: None
8
ports:
9
- port: 1433
10
targetPort: mssql
11
protocol: TCP
12
name: mssql
13
selector:
14
app.kubernetes.io/name: workflowgen
15
app.kubernetes.io/component: database
16
---
17
apiVersion: apps/v1
18
kind: StatefulSet
19
metadata:
20
name: database
21
spec:
22
replicas: 1
23
serviceName: database
24
selector:
25
matchLabels:
26
app.kubernetes.io/name: workflowgen
27
app.kubernetes.io/component: database
28
template:
29
metadata:
30
labels:
31
app.kubernetes.io/name: workflowgen
32
app.kubernetes.io/component: database
33
spec:
34
terminationGracePeriodSeconds: 10
35
nodeSelector:
36
kubernetes.io/os: linux
37
containers:
38
- name: database
39
image: advantys/workflowgen-sql:7.18.3-ubuntu-18.04
40
imagePullPolicy: Always
41
securityContext:
42
runAsUser: 0
43
runAsGroup: 0
44
resources:
45
requests:
46
memory: "1Gi"
47
cpu: "500m"
48
limits:
49
memory: "2Gi"
50
cpu: "1"
51
envFrom:
52
- configMapRef:
53
name: database-config
54
ports:
55
- name: mssql
56
containerPort: 1433
57
livenessProbe:
58
initialDelaySeconds: 30
59
timeoutSeconds: 5
60
exec:
61
command:
62
- pwsh
63
- -NoLogo
64
- -NoProfiles
65
- /usr/local/bin/healthcheck.ps1
66
readinessProbe:
67
initialDelaySeconds: 20
68
timeoutSeconds: 5
69
exec:
70
command:
71
- pwsh
72
- -NoLogo
73
- -NoProfiles
74
- /usr/local/bin/healthcheck.ps1
75
volumeMounts:
76
- mountPath: /var/opt/mssql
77
name: sqldata
78
- mountPath: /mnt/secrets
79
readOnly: true
80
name: secrets
81
volumes:
82
- name: secrets
83
secret:
84
secretName: database-sec
85
volumeClaimTemplates:
86
- metadata:
87
name: sqldata
88
spec:
89
accessModes:
90
- ReadWriteOnce
91
storageClassName: default
92
resources:
93
requests:
94
storage: 100Gi
Copied!
You can use this example as a starting point to configure multiple database containers. For more information about StatefulSets, see StatefulSets in the Kubernetes documentation. You might need custom code to be able to configure multiple instances properly. See the Custom Image page of this section for more information about how you can add custom code to the container.
Last modified 10mo ago