Skip to content

Commit 596da5d

Browse files
Dhruv-Soni11Dhruv-Soni11
committed
RHDEVDOCS-5562: Creating content for Adding OpenShift Routes as a traffic manager for Argo Rollouts
1 parent 07d169c commit 596da5d

4 files changed

+302
-2
lines changed

‎argo_rollouts/using-argo-rollouts-for-progressive-deployment-delivery.adoc‎

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ Progressive delivery reduces the risk of a release by exposing the new version o
1616

1717
With Argo Rollouts, you can use automation and metric analysis to support progressive deployment delivery and drive the automated rollout or rollback of a new version of an application.
1818
Argo Rollouts provide advanced deployment capabilities and enable integration with ingress controllers and service meshes.
19-
You can use Argo Rollouts to manage multiple replica sets that represent different versions of the deployed application. Depending on your deployment strategy, you can handle traffic to these versions during an update by optimizing their existing traffic shaping abilities and gradually shifting traffic to the new version. You can combine Argo Rollouts with a metric provider like Prometheus to do metric-based and policy-driven rollouts and rollbacks based on the parameters set.
19+
You can use Argo Rollouts to manage multiple replica sets that represent different versions of the deployed application. Depending on your deployment strategy, you can handle traffic to these versions during an update by optimizing their existing traffic shaping abilities and gradually shifting traffic to the new version. You can combine Argo Rollouts with a metric provider like Prometheus to do metric-based and policy-driven rollouts and rollbacks based on the parameters set.
2020

2121
[id="prerequisites_using-argo-rollouts-for-progressive-deployment-delivery"]
2222
== Prerequisites
@@ -39,6 +39,12 @@ include::modules/gitops-creating-rolloutmanager-custom-resource.adoc[leveloffset
3939
// Deleting a RolloutManager custom resource
4040
include::modules/gitops-deleting-rolloutmanager-custom-resource.adoc[leveloffset=+1]
4141

42+
// Routing traffic by using Argo Rollouts
43+
include::modules/con_routing-traffic-by-using-argo-rollouts.adoc[leveloffset=+1]
44+
45+
// Configuring Argo Rollouts to route traffic by using OpenShift Routes
46+
include::modules/gitops-configure-rollout-route-traffic-using-openshift-routes.adoc[leveloffset=+2]
47+
4248
[role="_additional-resources"]
4349
[id="additional-resources_argo-rollouts-in-gitops"]
4450
== Additional resources
@@ -48,4 +54,7 @@ include::modules/gitops-deleting-rolloutmanager-custom-resource.adoc[leveloffset
4854
* link:https://docs.openshift.com/container-platform/latest/applications/deployments/route-based-deployment-strategies.html#deployments-blue-green_route-based-deployment-strategies[Blue-green deployments]
4955
* link:https://argo-rollouts-manager.readthedocs.io/en/latest/crd_reference/[`RolloutManager` Custom Resource specification]
5056
* link:https://www.redhat.com/architect/blue-green-canary-argo-rollouts[Blue-green and canary deployments with Argo Rollouts]
57+
* xref:../installing_gitops/installing-argocd-gitops-cli.adoc#installing-argocd-gitops-cli[Installing the GitOps CLI]
58+
* xref:../gitops_cli_argocd/configuring-argocd-gitops-cli.adoc#configuring-argocd-gitops-cli[Configuring the GitOps CLI]
59+
* xref:../argo_rollouts/using-argo-rollouts-for-progressive-deployment-delivery.adoc#gitops-creating-rolloutmanager-custom-resource_using-argo-rollouts-for-progressive-deployment-delivery[Creating a RolloutManager custom resource]
5160
* link:https://cloud.redhat.com/blog/trying-out-argo-rollouts-in-openshift-gitops-1.9/[Argo Rollouts tech preview limitations]

‎modules/con_routing-traffic-by-using-argo-rollouts.adoc‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * argo_rollouts/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
:_mod-docs-content-type: CONCEPT
5+
[id="routing-traffic-by-using-argo-rollouts_{context}"]
6+
= Routing traffic by using Argo Rollouts
7+
8+
You can progressively route a subset of user traffic to a new application version by using Argo Rollouts and its traffic-splitting mechanisms. This allows you to test if the application is deployed and working.
9+
10+
With Openshift Routes, you can configure Argo Rollouts to reduce or increase the amount of traffic by directing it to various applications in a cluster environment based on your requirements.
11+
12+
You can use OpenShift Routes to split traffic between two application versions:
13+
14+
* *Canary version*: A new version of an application where you gradually route the traffic.
15+
* *Stable version*: The current version of an application. After the canary version is stable and has all the user traffic directed to it, it becomes the new stable version. The previous stable version is discarded.

‎modules/gitops-argo-rollouts-architecture-overview.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88

99
Argo Rollouts support is enabled on a cluster by installing the {gitops-title} Operator and configuring a `RolloutManager` custom resource (CR) instance.
1010

11-
After a RolloutManager CR is created, the {gitops-title} Operator installs Argo Rollouts into that same namespace. This step includes the installation of the Argo Rollouts controller and the resources required for handling Argo Rollouts, such as CRs, roles, role bindings, and configuration data.
11+
After a `RolloutManager` CR is created, the {gitops-title} Operator installs Argo Rollouts into that same namespace. This step includes the installation of the Argo Rollouts controller and the resources required for handling Argo Rollouts, such as CRs, roles, role bindings, and configuration data.
1212

1313
The Argo Rollouts controller can be installed in two different modes:
1414

‎modules/gitops-configure-rollout-route-traffic-using-openshift-routes.adoc‎

Lines changed: 276 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,276 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * argo_rollouts/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="gitops-configure-rollout-route-traffic-using-openshift-routes_{context}"]
7+
= Configuring Argo Rollouts to route traffic by using OpenShift Routes
8+
9+
You can use OpenShift Routes to configure Argo Rollouts to create routes, rollouts, and services.
10+
11+
The following example procedure creates a route, a rollout, and two services. It then gradually routes an increasing percentage of traffic to a canary version of the application before that canary state is marked as successful and becomes the new stable version.
12+
13+
.Prerequisites
14+
15+
* You have logged in to the {OCP} cluster as an administrator.
16+
* You have installed the {gitops-title} on your {OCP} cluster.
17+
* You have installed Argo Rollouts on your {OCP} cluster. For more information, see "Creating a RolloutManager custom resource".
18+
* You have installed the {gitops-title} CLI on your system. For more information, see "Installing the {gitops-shortname} CLI".
19+
* You have installed the Argo Rollouts CLI on your system. For more information, see "Argo Rollouts CLI overview".
20+
21+
.Procedure
22+
23+
. Create a `Route` object.
24+
.. In the *Administrator* perspective of the web console, click *Networking* -> *Routes*.
25+
.. Click *Create Route*.
26+
.. On the *Create Route* page, click *YAML view* and add the following snippet:
27+
The following example creates a route called `rollouts-demo-route`:
28+
+
29+
[source,yaml]
30+
----
31+
apiVersion: route.openshift.io/v1
32+
kind: Route
33+
metadata:
34+
name: rollouts-demo-route
35+
spec:
36+
port:
37+
targetPort: http #<1>
38+
tls: #<2>
39+
insecureEdgeTerminationPolicy: Redirect
40+
termination: edge
41+
to:
42+
kind: Service
43+
name: argo-rollouts-stable-service #<3>
44+
weight: 100 # <4>
45+
46+
alternateBackends:
47+
- kind: Service
48+
name: argo-rollouts-canary-service #<5>
49+
weight: 0 #<6>
50+
----
51+
<1> Specifies the name of the port used by the application for running inside the container.
52+
<2> Specifies the TLS configuration used to secure the route.
53+
<3> The name of the targeted stable service.
54+
<4> This field is automatically modified to stable weight by Route Rollout plugin.
55+
<5> The name of the targeted canary service.
56+
<6> This field is automatically modified to canary weight by Route Rollout plugin.
57+
+
58+
.. Click *Create* to create the route. It is then displayed on the *Routes* page.
59+
. Create the services, canary and stable, to be referenced in the route.
60+
.. In the *Administrator* perspective of the web console, click *Networking* -> *Services*.
61+
.. Click *Create Service*.
62+
.. On the *Create Service* page, click *YAML view* and add the following snippet:
63+
The following example creates a canary service called `argo-rollouts-canary-service`. Canary traffic is directed to this service.
64+
+
65+
[source,yaml]
66+
----
67+
apiVersion: v1
68+
kind: Service
69+
metadata:
70+
name: argo-rollouts-canary-service
71+
spec:
72+
ports: #<1>
73+
- port: 80
74+
targetPort: http
75+
protocol: TCP
76+
name: http
77+
78+
selector: #<2>
79+
app: rollouts-demo
80+
----
81+
<1> Specifies the name of the port used by the application for running inside the container.
82+
<2> Ensure that the contents of the `selector` field are the same as in stable service and `Rollout` custom resource (CR).
83+
+
84+
[IMPORTANT]
85+
====
86+
Ensure that the name of the canary service specified in the `Route` object matches with the name of the canary service specified in the `Service` object.
87+
====
88+
.. Click *Create* to create the canary service.
89+
+
90+
Rollouts automatically update the created service with pod template hash of the canary `ReplicaSet`. For example, `rollouts-pod-template-hash: 7bf84f9696`.
91+
.. Repeat these steps to create the stable service:
92+
The following example creates a stable service called `argo-rollouts-stable-service`. Stable traffic is directed to this service.
93+
+
94+
[source,yaml]
95+
----
96+
apiVersion: v1
97+
kind: Service
98+
metadata:
99+
name: argo-rollouts-stable-service
100+
spec:
101+
ports: #<1>
102+
- port: 80
103+
targetPort: http
104+
protocol: TCP
105+
name: http
106+
107+
selector: #<2>
108+
app: rollouts-demo
109+
----
110+
<1> Specifies the name of the port used by the application for running inside the container.
111+
<2> Ensure that the contents of the `selector` field are the same as in canary service and `Rollout` CR .
112+
+
113+
[IMPORTANT]
114+
====
115+
Ensure that the name of the stable service specified in the `Route` object matches with the name of the stable service specified in the `Service` object.
116+
====
117+
.. Click *Create* to create the stable service.
118+
+
119+
Rollouts automatically update the created service with pod template hash of the stable `ReplicaSet`. For example, `rollouts-pod-template-hash: 1b6a7733`.
120+
. Create the `Rollout` CR to reference the `Route` and `Service` objects.
121+
.. In the *Administrator* perspective of the web console, go to *Operators* -> *Installed Operators* -> *Red Hat OpenShift GitOps* -> *Rollout*.
122+
.. On the *Create Rollout* page, click *YAML view* and add the following snippet:
123+
The following example creates a `Rollout` CR called `rollouts-demo`:
124+
+
125+
[source,yaml]
126+
----
127+
apiVersion: argoproj.io/v1alpha1
128+
kind: Rollout
129+
metadata:
130+
name: rollouts-demo
131+
spec:
132+
template: #<1>
133+
metadata:
134+
labels:
135+
app: rollouts-demo
136+
spec:
137+
containers:
138+
- name: rollouts-demo
139+
image: argoproj/rollouts-demo:blue
140+
ports:
141+
- name: http
142+
containerPort: 8080
143+
protocol: TCP
144+
resources:
145+
requests:
146+
memory: 32Mi
147+
cpu: 5m
148+
149+
revisionHistoryLimit: 2
150+
replicas: 5
151+
strategy:
152+
canary:
153+
canaryService: argo-rollouts-canary-service #<2>
154+
stableService: argo-rollouts-stable-service #<3>
155+
trafficRouting:
156+
plugins:
157+
argoproj-labs/openshift:
158+
routes:
159+
- rollouts-demo-route #<4>
160+
steps: #<5>
161+
- setWeight: 30
162+
- pause: {}
163+
- setWeight: 60
164+
- pause: {}
165+
selector: #<6>
166+
matchLabels:
167+
app: rollouts-demo
168+
----
169+
<1> Specifies the pods that are to be created.
170+
<2> This value must match the name of the created canary `Service`.
171+
<3> This value must match the name of the created stable `Service`.
172+
<4> This value must match the name of the created `Route` CR.
173+
<5> Specify the steps for the rollout. This example gradually routes 30%, 60%, and 100% of traffic to the canary version.
174+
<6> Ensure that the contents of the `selector` field are the same as in canary and stable service.
175+
.. Click *Create*.
176+
+
177+
After the Rollout has been created, you can verify that the *Status* field of the Rollout shows *Phase: Healthy*.
178+
.. In the *RolloutManager* tab, under the *RolloutManagers* section, verify that the *Status* field of the *RolloutManager* instance shows as *Phase: Available*.
179+
180+
. Verify that the route is directing 100% of the traffic towards the stable version of the application.
181+
+
182+
[NOTE]
183+
====
184+
When the first instance of the `Rollout` resource is created, the rollout regulates the amount of traffic to be directed towards the stable and canary application versions. In the initial instance, the creation of the `Rollout` resource routes all of the traffic towards the stable version of the application and skips the part where the traffic is sent to the canary version.
185+
====
186+
.. Go to *Networking* -> *Routes* and look for the `Route` resource you want to verify.
187+
.. Select the *YAML* tab and view the following snippet:
188+
+
189+
.Example: `Route`
190+
[source,yaml]
191+
----
192+
kind: Route
193+
metadata:
194+
name: rollouts-demo-route
195+
spec:
196+
alternateBackends:
197+
- kind: Service
198+
name: argo-rollouts-canary-service
199+
weight: 0 #<1>
200+
# (...)
201+
to:
202+
kind: Service
203+
name: argo-rollouts-stable-service
204+
weight: 100 #<2>
205+
----
206+
<1> A value of `0` means that 0% of traffic is directed to the canary version.
207+
<2> A value of `100` means that 100% of traffic is directed to the stable version.
208+
. Simulate the new canary version of the application by modifying the container image deployed in the rollout.
209+
.. In the *Administrator* perspective of the web console, go to *Operators* -> *Installed Operators* -> *Red Hat OpenShift GitOps* -> *Rollout*.
210+
211+
.. Select the existing *Rollout* and modify the `.spec.template.spec.containers.image` value from `argoproj/rollouts-demo:blue` to `argoproj/rollouts-demo:yellow`.
212+
+
213+
As a result, the container image deployed in the rollout is modified and the rollout initiates a new canary deployment.
214+
+
215+
[NOTE]
216+
====
217+
As per the `setWeight` property defined in the `.spec.strategy.canary.steps` field of the `Rollout` resource, initially 30% of traffic to the route reaches the canary version and 70% of traffic is directed towards the stable version. The rollout is paused after 30% of traffic is directed to the canary version.
218+
====
219+
+
220+
.Example route with 30% of traffic directed to the canary version and 70% directed to the stable version.
221+
[source,yaml]
222+
----
223+
spec:
224+
alternateBackends:
225+
- kind: Service
226+
name: argo-rollouts-canary-service
227+
weight: 30
228+
# (...)
229+
to:
230+
kind: Service
231+
name: argo-rollouts-stable-service
232+
weight: 70
233+
----
234+
235+
. Simulate another new canary version of the application by running the following command in the Argo Rollouts CLI:
236+
+
237+
[source,terminal]
238+
----
239+
$ oc argo rollouts promote rollouts-demo -n <namespace> <1>
240+
----
241+
<1> Specify the namespace where the `Rollout` resource is defined.
242+
+
243+
This increases the traffic weight to 60% in the canary version and 40% in the stable version.
244+
+
245+
.Example route with 60% of traffic directed to the canary version and 40% directed to the stable version.
246+
[source,yaml]
247+
----
248+
spec:
249+
alternateBackends:
250+
- kind: Service
251+
name: argo-rollouts-canary-service
252+
weight: 60
253+
# (...)
254+
to:
255+
kind: Service
256+
name: argo-rollouts-stable-service
257+
weight: 40
258+
----
259+
. Increase the traffic weight in the canary version to 100% and discard the traffic in the old stable version of the application by running the following command:
260+
+
261+
[source,terminal]
262+
----
263+
$ oc argo rollouts promote rollouts-demo -n <namespace> <1>
264+
----
265+
<1> Specify the namespace where the `Rollout` resource is defined.
266+
+
267+
.Example route with 0% of traffic directed to the canary version and 100% directed to the stable version.
268+
[source,yaml]
269+
----
270+
spec:
271+
# (...)
272+
to:
273+
kind: Service
274+
name: argo-rollouts-stable-service
275+
weight: 100
276+
----

0 commit comments

Comments
 (0)