Getting Started
Overview
This section presents how to quickly run the WorkflowGen container with a minimal architecture on Kubernetes.
There are known limitations when using Hyper-V isolation with the WorkflowGen container in WorkflowGen versions 7.19.x and earlier. It's recommended to use process isolation exclusively. This limitation no longer applies as of WorkflowGen version 7.20.0.
Kubernetes with AKS
This example is designed for Azure Kubernetes Service (AKS). To get started with AKS, see the Create a Windows Server container on an Azure Kubernetes Service (AKS) cluster using the Azure CLI Microsoft article.
Architecture overview
At the end of this section, you'll have this cluster configuration:
Every container in the cluster will have access to the configuration and secrets inside their namespaces. Several Azure services will be deployed by Azure Kubernetes Service. This doesn't require any manual steps other than interacting with Kubernetes itself. The load balancer that the service will create will dispatch the requests between the WorkflowGen server replicas.
Prerequisites
You must have a working Kubernetes cluster with Windows Server 2019 nodes. See the Azure resources view above for a basic AKS setup. See Deploy a Windows Server container on an Azure Kubernetes Service (AKS) cluster using Azure CLI to get started with creating an AKS cluster with Windows nodes support.
You must have installed the kubectl command line tool and it must be connected to the cluster. See the Connect to the cluster section in the Deploy a Windows Server container on an Azure Kubernetes Service (AKS) cluster using Azure CLI Microsoft article for instructions on how to connect kubectl with AKS.
As well, note that you should not create any other resources in Azure besides the cluster and its nodes. All required resources for the containers will be created by Kubernetes automatically. AKS is a fully-managed platform.
Add a PersistentVolumeClaim for shared storage
Now, you need to add a claim that represent the WorkflowGen data volume that will be used by your deployment. To do this, apply the following YAML to your cluster:
Then, apply it to the cluster using the following command:
Add your WorkflowGen license file to the cluster
Kubernetes enables you to manage secrets and configurations as files inside the cluster and inject them into pods. In this case, you'll add your license file as a secret and later inject it to the WorkflowGen pod. To add your license to the cluster, execute the following command:
Add ConfigMaps for the services
As mentioned earlier, there is a mechanism in Kubernetes that allows you to manage your containers' configurations. Here, you'll create one for WorkflowGen and another for the database:
Don't forget to apply this configuration:
Add secrets for the services
Kubernetes also manages secrets for you. They are securely stored and only given to the containers as files.
You need an encryption key to put as a secret:
Before creating the secrets, you must encode them in base64:
Those encoded values will go into the secrets declaration. To create the required secrets for the services, apply the following YAML:
Don't forget to apply this:
Deploy the containers
You're now ready to deploy the services. You'll create two Deployment objects and one ReplicaSet object. The deployment will create ReplicaSets for all the services with different configurations. Those deployments can later be configured to automatically scale with the pods' usage. The ReplicaSet will provide the necessary services to the database container in order to run properly and avoid data losses. Don't forget that there should only be one instance of each WorkflowGen Windows Service running at all time. This container pattern is called a Singleton.
Database
This configuration will deploy the StatefulSet database along with a headless service. This object will also create a persistent volume claim based on the template provided in the declaration.
Apply the database first:
WorkflowGen web applications
Apply this replication controller:
Windows Services deployment
Apply the Windows Services:
Add a load balancer
Now, you need to add a public-facing load balancer in order to dispatch requests to your pods. To do this, execute the following command:
You now need to wait for the IP to be provisioned. Execute the following command periodically until you get the load balancer's public IP:
Once the value of EXTERNAL-IP is provisioned, copy it and modify the WorkflowGen configuration to change the WFGEN_APP_SETTING_ApplicationUrl value:
Apply it:
Then, restart all of the pods in the WorkflowGen deployment to apply the changes to them. You have to do this for the Windows services as well. To do this, execute the following commands:
You should now have a working WorkflowGen with a load balancer and a database.
Kubernetes with AKS using Helm
Helm is a package manager–like tool for Kubernetes. It manages the sharing, deployment, updates and rollbacks of software developed for Kubernetes. Based on values provided, Helm generates definition files for the cluster with the template engine from the Go programming language. For each release, WorkflowGen now produces a chart that you can use with your cluster. To have the latest bug fixes and features from the chart, make sure to always pick the chart released with the latest update of WorkflowGen.
Architecture overview
At the end of this section, you'll have this cluster configuration:
Every container in the cluster will have access to the configuration and secrets inside their namespaces. Several Azure services will be deployed by Azure Kubernetes Service. This doesn't require any manual steps other than interacting with Kubernetes itself. The load balancer that the service will create will dispatch the requests between the WorkflowGen server replicas.
Prerequisites
You must have a working Kubernetes cluster with Windows Server 2019 nodes. See the Azure resources view above for a basic AKS setup. See Deploy a Windows Server container on an Azure Kubernetes Service (AKS) cluster using Azure CLI to get started with creating an AKS cluster with Windows node support.
You must have installed the kubectl command line tool and it must be connected to the cluster. See the Connect to the cluster section in the Deploy a Windows Server container on an Azure Kubernetes Service (AKS) cluster using Azure CLI Microsoft article for instructions on how to connect kubectl with AKS.
You must have installed the Helm command line tool. See the Installing Helm section on the Helm website for instructions on how to install it. Only Helm versions 3.0 and later are supported.
As well, note that you should not create any other resources in Azure besides the cluster and its nodes. All required resources for the containers will be created by Kubernetes automatically. AKS is a fully-managed platform.
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:
Add your WorkflowGen license file to the cluster
Kubernetes enables you to manage secrets and configurations as files inside the cluster and inject them into pods. In this case, you'll add your license file as a secret and later inject it to the WorkflowGen pod. To add your license to the cluster, execute the following command:
Create a file with your values for the chart
In order to generate the templates tailored to your configuration expectations, you have to provide some values to the helm command when you install or update a release. You can specify those values using the command line interface or with a file. In the case of a new installation, it will be easier with a file. Here are the values that you will need:
You can save this file as values.yaml. The name is not important.
Install the WorkflowGen chart
You now need to install the chart with those values. To do this, execute the following command:
Helm will generate Kubernetes deployment files for you and install them on the cluster.
Update the application URL
This configuration will create a load balancer in front of the WorkflowGen containers. You will need to wait for it to get a public IP address. Execute the following command periodically until you get the load balancer's public IP:
Once the value of EXTERNAL-IP is provisioned, copy it and modify the WorkflowGen configuration to change the WFGEN_APP_SETTING_ApplicationUrl value. To do this, you first need to get the name of the ConfigMap associated with the WorkflowGen deployment. The following command will give you all the ConfigMap objects in the default namespace:
Copy the WorkflowGen ConfigMap name and replace <WFG_CONFIG_MAP> with the value in the following command:
This will bring up an editor so you can replace the WFGEN_APP_SETTING_ApplicationUrl value with the correct IP address from the load balancer service. Save the file and exit the editor. To apply the changes made to the ConfigMap object, restart all of the pods in the WorkflowGen deployment. You have to do this for the Windows services as well. Get the name of the deployments with the following command:
Replace <WEB_APPS_DEPLOYMENT_NAME> and <WIN_SERVICES_DEPLOYMENT_NAME> in the following script with the correct deployment names to restart all containers:
You should now have a working WorkflowGen with a load balancer and a database.
Last updated