You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can deploy your local workflow on {ocp-product-title}in Dev mode. You can use this deployment to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Dev mode is designed for development and testing purposes. It is ideal for initial development stages and for testing new changes.
9
+
You can deploy your local workflow on {ocp-product-title}using the Dev profile. You can use this deployment to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Dev profile is designed for development and testing purposes. Because it automatically reloads the workflow without restarting the container, it is ideal for initial development stages and for testing workflow changes in a live environment.
10
10
11
11
.Prerequisites
12
12
@@ -66,8 +66,8 @@ spec:
66
66
end: true
67
67
----
68
68
+
69
-
<1> is a workflow_name
70
-
<2> indicates that you must deploy the workflow in Dev mode
69
+
<1> Is a <workflow_name>.
70
+
<2> Indicates that you must deploy the workflow using the Dev profile.
71
71
72
72
. To deploy the application, apply the YAML file by entering the following command:
You can deploy your local workflow on {ocp-product-title} in Preview mode. This allows you to experiment and modify your workflow directly on the cluster, seeing changes almost immediately. Preview mode is used for final testing and validation before deploying to production. It also ensures that workflows will run smoothly in a production-like setting.
22
+
You can deploy your local workflow on {ocp-product-title} using the Preview profile. This allows you to validate and test workflows in a production-like environment directly on the cluster. Preview profile is ideal for final testing and validation before moving workflows to production, as well as for quick iteration without directly managing the build pipeline. It also ensures that workflows will run smoothly in a production-like setting.
17
23
18
24
.Prerequisites
19
25
20
26
* You have an {ServerlessLogicOperatorName} installed on your cluster.
21
27
* You have access to an {ServerlessLogicProductName} project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
22
28
* You have installed the OpenShift CLI `(oc)`.
23
29
24
-
To deploy a workflow in Preview mode, {ServerlessLogicOperatorName} uses the build system on {ocp-product-title}, which automatically creates the image for deploying your workflow.
30
+
To deploy a workflow in Preview profile, {ServerlessLogicOperatorName} uses the build system on {ocp-product-title}, which automatically creates the image for deploying your workflow.
25
31
26
32
The following sections explain how to build and deploy your workflow on a cluster using the {ServerlessLogicOperatorName} with a `SonataFlow` custom resource.
Use the GitOps profile only for production deployments.
53
+
For development, rapid iteration, or testing, use the Dev or Preview profiles instead.
54
+
====
55
+
56
+
You can deploy your local workflow on {ocp-product-title} using the GitOps profile. The GitOps profile provides full control over the workflow container image by allowing you to build and manage the image externally, typically through a CI/CD pipeline such as ArgoCD or Tekton. When a container image is defined in the `SonataFlow` custom resource (CR), the Operator automatically assumes the GitOps profile is being used and it does not attempt to build or modify the image in any way.
57
+
58
+
.Prerequisites
59
+
60
+
* You have {ServerlessLogicOperatorName} installed on your cluster.
61
+
* You have access to a {ServerlessLogicProductName} project with the appropriate roles and permissions to create applications and other workloads in {ocp-product-title}.
62
+
* You have installed the OpenShift CLI `(oc)`.
63
+
64
+
.Procedure
65
+
66
+
. Specify your container image in your SonataFlow CR:
67
+
+
68
+
.Example SonataFlow CR with set GitOps profile
69
+
[source,yaml]
70
+
----
71
+
apiVersion: sonataflow.org/v1alpha08
72
+
kind: SonataFlow
73
+
metadata:
74
+
annotations:
75
+
sonataflow.org/profile: gitops
76
+
name: workflow_name
77
+
spec:
78
+
flow: <1>
79
+
#...
80
+
podTemplate:
81
+
container:
82
+
image: your-registry/workflow_name:tag
83
+
#...
84
+
----
85
+
<1> The `flow` definition must match the workflow definition used during the build process. When you deploy your workflow using the GitOps profile, the Operator compares this definition with the workflow files embedded in the container image. If the definition and files do not match, the deployment fails.
0 commit comments