Skip to content

Commit 32fe19f

Browse files
Merge pull request #61983 from Srivaralakshmi/RHDEVDOCS-5149
2 parents 47355ca + b48c872 commit 32fe19f

6 files changed

+206
-0
lines changed

_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1929,6 +1929,8 @@ Topics:
19291929
File: uninstalling-openshift-gitops
19301930
- Name: Setting up a new Argo CD instance
19311931
File: setting-up-argocd-instance
1932+
- Name: Using Argo Rollouts for progressive deployment delivery
1933+
File: using-argo-rollouts-for-progressive-deployment-delivery
19321934
- Name: Configuring an OpenShift cluster by deploying an application with cluster configurations
19331935
File: configuring-an-openshift-cluster-by-deploying-an-application-with-cluster-configurations
19341936
- Name: Deploying a Spring Boot application with Argo CD
Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
:_content-type: ASSEMBLY
2+
[id="using-argo-rollouts-for-progressive-deployment-delivery"]
3+
= Using Argo Rollouts for progressive deployment delivery
4+
include::_attributes/common-attributes.adoc[]
5+
:context: using-argo-rollouts-for-progressive-deployment-delivery
6+
7+
toc::[]
8+
9+
:FeatureName: Argo Rollouts
10+
include::snippets/technology-preview.adoc[leveloffset=+1]
11+
12+
Progressive delivery is the process of releasing product updates in a controlled and gradual manner.
13+
Progressive delivery reduces the risk of a release by exposing the new version of a product update only to a subset of users initially. The process involves continuously observing and analyzing this new version to verify whether its behavior matches the requirements and expectations set. The verifications continue as the process gradually exposes the product update to a broader and wider audience.
14+
15+
{product-title} provides some progressive delivery capability by using routes to split traffic between different services, but this typically requires manual intervention and management.
16+
17+
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.
18+
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.
20+
21+
[id="prerequisites_using-argo-rollouts-for-progressive-deployment-delivery"]
22+
== Prerequisites
23+
* You have access to the cluster with `cluster-admin` privileges.
24+
* You have access to the {product-title} web console.
25+
* {gitops-title} 1.9.0 or a newer version is installed in your cluster.
26+
27+
include::modules/gitops-benefits-of-argo-rollouts.adoc[leveloffset=+1]
28+
29+
include::modules/gitops-about-argo-rollout-manager-custom-resources-and-spec.adoc[leveloffset=+1]
30+
31+
include::modules/gitops-creating-rolloutmanager-custom-resource.adoc[leveloffset=+1]
32+
33+
include::modules/gitops-deleting-rolloutmanager-custom-resource.adoc[leveloffset=+1]
34+
35+
[role="_additional-resources"]
36+
[id="additional-resources_argo-rollouts-in-gitops"]
37+
== Additional resources
38+
* xref:../../cicd/gitops/installing-openshift-gitops.adoc#installing-gitops-operator-in-web-console_installing-openshift-gitops[Installing {gitops-title}]
39+
* xref:../../cicd/gitops/uninstalling-openshift-gitops.adoc#go-uninstalling-gitops-operator_uninstalling-openshift-gitops[Uninstalling {gitops-title}]
40+
* xref:../../applications/deployments/deployment-strategies.adoc#deployments-canary-deployments_deployment-strategies[Canary deployments]
41+
* xref:../../applications/deployments/route-based-deployment-strategies.adoc#deployments-blue-green_route-based-deployment-strategies[Blue-green deployments]
42+
* link:https://argo-rollouts-manager.readthedocs.io/en/latest/crd_reference/[`RolloutManager` Custom Resource specification]
43+
* link:https://www.redhat.com/architect/blue-green-canary-argo-rollouts[Blue-green and canary deployments with Argo Rollouts]
44+
* link:https://cloud.redhat.com/blog/trying-out-argo-rollouts-in-openshift-gitops-1.9/[Argo Rollouts tech preview limitations]
Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * cicd/gitops/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
5+
:_content-type: CONCEPT
6+
[id="gitops-about-argo-rollout-manager-custom-resources-and-spec_{context}"]
7+
= About RolloutManager custom resources and specification
8+
9+
To use Argo Rollouts, you must install {gitops-title} Operator on the cluster, and then create and submit a `RolloutManager` custom resource (CR) to the Operator in the namespace of your choice. You can scope the `RolloutManager` CR for single or multiple namespaces. The Operator creates an `argo-rollouts` instance with the following namespace-scoped supporting resources:
10+
11+
* Argo Rollouts controller
12+
* Argo Rollouts metrics service
13+
* Argo Rollouts service account
14+
* Argo Rollouts roles
15+
* Argo Rollouts role bindings
16+
* Argo Rollouts secret
17+
18+
You can specify the command arguments, environment variables, a custom image name, and so on for the Argo Rollouts controller resource in the spec of the `RolloutsManager` CR. The `RolloutManager` CR spec defines the desired state of Argo Rollouts.
19+
20+
.Example: `RolloutManager` CR
21+
[source,yaml]
22+
----
23+
apiVersion: argoproj.io/v1alpha1
24+
kind: RolloutManager
25+
metadata:
26+
name: argo-rollout
27+
labels:
28+
example: basic
29+
spec: {}
30+
----
31+
32+
[id="argo-rollouts-controller_{context}"]
33+
== Argo Rollouts controller
34+
35+
With the Argo Rollouts controller resource, you can manage the progressive application delivery in your namespace. The Argo Rollouts controller resource monitors the cluster for events, and reacts whenever there is a change in any resource related to Argo Rollouts. The controller reads all the rollout details and brings the cluster to the same state as described in the rollout definition.
36+
37+
.Additional Resources
38+
link:https://argo-rollouts-manager.readthedocs.io/en/latest/crd_reference/[`RolloutManager` Custom Resource specification]
Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * cicd/gitops/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
5+
:_content-type: CONCEPT
6+
[id="gitops-benefits-of-argo-rollouts_{context}"]
7+
= Benefits of Argo Rollouts
8+
9+
Managing and coordinating advanced deployment strategies in traditional infrastructure often involves long maintenance windows. Automation with tools like {product-title} and {gitops-title} can reduce these windows, but setting up these strategies can still be challenging. With Argo Rollouts, you simplify this process by allowing application teams to define their rollout strategy declaratively. Teams no longer need to define multiple deployments and services or create automation for traffic shaping and integration of tests. Using Argo Rollouts, you can encapsulate all the required definitions for a declarative rollout strategy, automate and manage the process.
10+
11+
Using Argo Rollouts as a default workload in {gitops-title} provides the following benefits:
12+
13+
* Automated progressive delivery as part of the {gitops-shortname} workflow
14+
* Advanced deployment capabilities
15+
* Optimize the existing advanced deployment strategies such as blue-green or canary
16+
* Zero downtime updates for deployments
17+
* Fine-grained, weighted traffic shifting
18+
* Able to test without any new traffic hitting the production environment
19+
* Automated rollbacks and promotions
20+
* Manual judgment
21+
* Customizable metric queries and analysis of business key performance indicators (KPIs)
22+
* Integration with ingress controller and {SMProductName} for advanced traffic routing
23+
* Integration with metric providers for deployment strategy analysis
24+
* Usage of multiple providers
25+
26+
With Argo Rollouts, users can more easily adopt progressive delivery in end-user environments. This provides structure and guidelines without requiring teams to learn about traffic managers and complex infrastructure. With automated rollouts, the {gitops-title} Operator provides security to your end-user environments and helps manage the resources, cost, and time effectively. Existing users who use Argo CD with security and automated deployments get feedback early in the process and avoid problems that impact them.
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * cicd/gitops/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="gitops-creating-rolloutmanager-custom-resource_{context}"]
7+
= Creating a RolloutManager custom resource
8+
9+
To manage progressive delivery of deployments by using Argo Rollouts in {gitops-title}, you must create and configure a `RolloutManager` custom resource (CR) in the namespace of your choice. By default, any new `argo-rollouts` instance has permission to manage resources only in the namespace where it is deployed, but you can use Argo Rollouts in multiple namespaces as required.
10+
11+
.Prerequisites
12+
13+
* {gitops-title} 1.9.0 or a newer version is installed in your cluster.
14+
15+
.Procedure
16+
17+
. Log in to the {product-title} web console as a cluster administrator.
18+
19+
. In the *Administrator* perspective, click *Operators* -> *Installed Operators*.
20+
21+
. Create or select the project where you want to create and configure a `RolloutManager` custom resource (CR) from the *Project* drop-down menu.
22+
23+
. Select *OpenShift GitOps Operator* from the installed operators.
24+
25+
. In the *Details* tab, under the *Provided APIs* section, click *Create instance* in the *RolloutManager* pane.
26+
27+
. On the *Create RolloutManager* page, select the *YAML view* and use the default YAML or edit it according to your requirements:
28+
+
29+
.Example: `RolloutManager` CR
30+
[source,yaml]
31+
----
32+
apiVersion: argoproj.io/v1alpha1
33+
kind: RolloutManager
34+
metadata:
35+
name: argo-rollout
36+
labels:
37+
example: basic
38+
spec: {}
39+
----
40+
41+
. Click *Create*.
42+
43+
. In the *RolloutManager* tab, under the *RolloutManagers* section, verify that the *Status* field of the RolloutManager instance shows as *Phase: Available*.
44+
45+
. In the left navigation pane, verify the creation of the namespace-scoped supporting resources:
46+
+
47+
* Click *Workloads* -> *Deployments* to verify that the `argo-rollouts` deployment is available with the *Status* showing as `1 of 1 pods` running.
48+
* Click *Workloads* -> *Secrets* to verify that the `argo-rollouts-notification-secret` secret is available.
49+
* Click *Networking* -> *Services* to verify that the `argo-rollouts-metrics` service is available.
50+
* Click *User Management* -> *Roles* to verify that the `argo-rollouts` role and `argo-rollouts-aggregate-to-admin`, `argo-rollouts-aggregate-to-edit`, and `argo-rollouts-aggregate-to-view` cluster roles are available.
51+
* Click *User Management* -> *RoleBindings* to verify that the `argo-rollouts` role binding is available.
52+
53+
.Additional resources
54+
* link:https://argo-rollouts-manager.readthedocs.io/en/latest/crd_reference/[`RolloutManager` Custom Resource specification]
Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * cicd/gitops/using-argo-rollouts-for-progressive-deployment-delivery.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="gitops-deleting-rolloutmanager-custom-resource_{context}"]
7+
= Deleting a RolloutManager custom resource
8+
9+
Uninstalling the {gitops-title} Operator does not remove the resources that were created during installation. You must manually delete the `RolloutManager` custom resource (CR) before you uninstall the {gitops-title} Operator.
10+
11+
.Prerequisites
12+
13+
* {gitops-title} 1.9.0 or a newer version is installed in your cluster.
14+
* A `RolloutManager` CR exists in your namespace.
15+
16+
.Procedure
17+
18+
. Log in to the {product-title} web console as a cluster administrator.
19+
20+
. In the *Administrator* perspective, click *Operators* -> *Installed Operators*.
21+
22+
. Click the *Project* drop-down menu and select the project that contains the `RolloutManager` CR.
23+
24+
. Select *OpenShift GitOps Operator* from the installed operators.
25+
26+
. Click the *RolloutManager* tab to find RolloutManager instances under the *RolloutManagers* section.
27+
28+
. Click the instance.
29+
30+
. Click *Actions* -> *Delete RolloutManager* from the drop-down menu, and click *Delete* to confirm in the dialog box.
31+
32+
. In the *RolloutManager* tab, under the *RolloutManagers* section, verify that the RolloutManager instance is not available anymore.
33+
34+
. In the left navigation pane, verify the deletion of the namespace-scoped supporting resources:
35+
+
36+
* Click *Workloads* -> *Deployments* to verify that the `argo-rollouts` deployment is deleted.
37+
* Click *Workloads* -> *Secrets* to verify that the `argo-rollouts-notification-secret` secret is deleted.
38+
* Click *Networking* -> *Services* to verify that the `argo-rollouts-metrics` service is deleted.
39+
* Click *User Management* -> *Roles* to verify that the `argo-rollouts` role and `argo-rollouts-aggregate-to-admin`, `argo-rollouts-aggregate-to-edit`, and `argo-rollouts-aggregate-to-view` cluster roles are deleted.
40+
* Click *User Management* -> *RoleBindings* to verify that the `argo-rollouts` role binding is deleted.
41+
42+

0 commit comments

Comments
 (0)