diff --git a/argo-rollouts-workshop/main/02-workshop-overview.html b/argo-rollouts-workshop/main/02-workshop-overview.html index ff4922c..5b04ce9 100644 --- a/argo-rollouts-workshop/main/02-workshop-overview.html +++ b/argo-rollouts-workshop/main/02-workshop-overview.html @@ -273,7 +273,7 @@

-Argo Rollouts can be deployed as ether a namespace or cluster scope, the OpenShift GitOps operator +Argo Rollouts can be deployed as either a namespace or cluster scope, the OpenShift GitOps operator currently only supports namespace scope. @@ -294,7 +294,8 @@

-We are using a kubectl plugin called kubectl-neat +The oc CLI tool is a superset of kubectl with some additional Openshift specific features. We will use oc in this tutorial but if you prefer you can use kubectl as well. +In the previous command we are using a kubectl plugin called kubectl-neat in order to tidy the yaml by removing additional fields, labels and annotations added automatically by Kubernetes. @@ -558,7 +559,7 @@

D

Copy the URL into a browser and confirm that the application is running, you should see a grid of -blue squares appearing and disappearing periodically as the application makes requests to it’s back-end +blue squares appearing and disappearing periodically as the application makes requests to its back-end from the browser.

diff --git a/argo-rollouts-workshop/main/03-bluegreen-rollout.html b/argo-rollouts-workshop/main/03-bluegreen-rollout.html index c1c2235..890cdc2 100644 --- a/argo-rollouts-workshop/main/03-bluegreen-rollout.html +++ b/argo-rollouts-workshop/main/03-bluegreen-rollout.html @@ -246,12 +246,11 @@

B

-

In traditional infrastructure this approach can be very challenging. While Kubernetes is simpler due to it’s declarative nature the process still tends to be cumbersome to manage since bespoke automation needs to be created to manage the separate stacks, +

In traditional infrastructure this approach can be very challenging. While Kubernetes is simpler due to its declarative nature, the process still tends to be cumbersome to manage. Bespoke automation would still need to be created to manage the separate stacks, and for testing and traffic management between versions.

-

This is where Argo Rollouts comes in, it greatly reduces the complexity by providing these capabilities with a simple, declarative approach. In this module -we will deploy a simple blue-green Rollout and explore it’s basic capabilities.

+

This is where Argo Rollouts comes in. It greatly reduces the complexity by providing these capabilities with a simple, declarative approach. In this module we will deploy a simple blue-green Rollout and explore its basic capabilities.

@@ -317,11 +316,11 @@

-

Under the blueGreen strategy we have identified the active and preview Kubernetes services for the rollout which will be covered +

Under the blueGreen strategy we have identified the active and preview Kubernetes services for the rollout. This will be covered in more detail when services are discussed next.

-

As well as services the field autoPromotionEnabled is set to false which means the rollout will require manual intervention to promote. Manual promotion +

The field autoPromotionEnabled is set to false. This means the rollout will require manual intervention to promote. Manual promotion is enabled so the behavior of the rollout can be observed in-depth in subsequent sections of this module.

@@ -432,7 +431,7 @@

-We are getting pods using the label app=rollouts-demo to specifically select pods from the rollout, remember +We are getting pods using the label app=rollouts-demo to specifically select pods from the rollout. Remember the RolloutManager pod is also deployed in the user%USERNUM%-prod namespace. Using the label enables us to exclude that pod. @@ -515,12 +514,12 @@

Notice that the selector now has an additional key, rollouts-pod-template-hash, with a hashed value. This is how the rollout manages traffic -between the active and preview versions. Since we have not deployed a new image, if you check the preview service you will see the same +between the active and preview versions. Since we have not deployed a new image, the preview service will have the same selector used there as well.

Similar to Kubernetes deployments, each revision, i.e. version, of the Rollout is backed by a ReplicaSet. -This ReplicaSet will have a rollouts-pod-template-hash label in it’s PodTemplate with a value unique to the revision. Argo Rollouts will automatically ensure that +This ReplicaSet will have a rollouts-pod-template-hash label in its PodTemplate with a value unique to the revision. Argo Rollouts will automatically ensure that the selector in the service is pointing to the appropriate revision.

@@ -657,7 +656,7 @@

-

In the dashboard each rollout will show in it’s own tile on the overview screen. The tile will provide some +

In the dashboard each rollout will show in its own tile on the overview screen. The tile will provide some basic information about the rollout as shown here:

@@ -716,7 +715,7 @@

Promote Image This pipeline is not meant to be a comprehensive example of how to manage image promotion, rather we are using it provide a simple way in the workshop to drive image changes. This pipeline uses OpenShift -Pipelines however any Continuous Integration(CI) tool can be used with Argo Rollouts including Argo Workflows, +Pipelines, an implementation of the Tekton project, however any Continuous Integration(CI) tool can be used with Argo Rollouts including Argo Workflows, GitHub Actions, GitLab, etc. @@ -768,7 +767,7 @@

Promote Image

Now let’s see what the application looks like in production where we are using Rollouts. First, let’s check the preview service by -retrieving it’s URL and viewing it in the browser:

+retrieving its URL and viewing it in the browser:

diff --git a/argo-rollouts-workshop/main/04-analysis.html b/argo-rollouts-workshop/main/04-analysis.html index dcaa2c0..eb3250f 100644 --- a/argo-rollouts-workshop/main/04-analysis.html +++ b/argo-rollouts-workshop/main/04-analysis.html @@ -240,7 +240,7 @@

Analy new version of the application.

-

In addition to collecting data, an Analysis can include a Job to drive more advanced use cases. For example +

In addition to collecting data, an Analysis can include a Job to drive more advanced use cases. For example, a Job could be used to run load against an application in order to generate the metrics needed to validate the revision.

@@ -248,7 +248,7 @@

Analy

To deploy an Analysis, first an AnalysisTemplate is created that defines the analysis that is required and then is associated with one or more rollouts. The way an analysis is associated with a rollout is dependent on the rollout strategy used. In this module we will look at it from the perspective of the Blue-Green -strategy we have deployed previously however in the next module we delve into it for the Canary strategy as well.

+strategy we have deployed previously. In the next module we will delve into using an Analysis with the Canary strategy as well.

In the blue-green strategy, an Analysis can be added as either pre-promotion or post-promotion. Pre-promotion @@ -347,14 +347,13 @@

A

-

In the metrics provider section we can see we have two providers defined, one that uses the prometheus metric provider to pull -metrics from Thanos, an aggregator for Prometheus data, and a job that runs Apache Siege +

In the metrics provider section we can see that we have two providers defined. The first one, named success-rate, uses the prometheus metric provider to pull metrics from Thanos, an aggregator for Prometheus data. The second one, run-load is a job that runs Apache Siege to drive some load on the application.

The count and interval fields in the success-rate metric powered by the prometheus provider indicate that the metric will be checked four times with a thirty second interval between each check. The failureLimit determines how many failures are permitted for the rollout to be considered -a success, here we set a failure limit of 0.

+a success. Here we set a failure limit of 0.

Finally, remember we are running this Analysis in the pre-promotion phase of the blue-green strategy so the application will not @@ -377,7 +376,7 @@

A

Finally a third parameter, api-token, is provided by a secret. This secret provides the token needed -to access the OpenShift monitoring stack, it was created by the GitOps process which provisioned this workshop.

+to access the OpenShift monitoring stack. It was created by the GitOps process which provisioned this workshop.

Next let’s look at the rollout and see how the AnalysisTemplate is wired into the rollout.

@@ -431,7 +430,7 @@

A template.

-

Next to deploy this new version of the blue-green rollout, execute the following command:

+

To deploy this new version of the blue-green rollout, execute the following command:

@@ -456,7 +455,7 @@

A

-

Next confirm that the application is displaying blue squares by opening the active route URL in your browser:

+

Confirm that the application is displaying blue squares by opening the active route URL in your browser:

@@ -507,9 +506,9 @@

Analysi

When a promotion of a rollout with an analysis is executed the controller will generate an analysis run for each template execution. Since we only have one template -being used in pre-promotion we will only see one analysis run being created however -it is possible for a promotion to have multiple analysis runs dependent on the -rollout configuration, i.e. in blue-green defining both pre and post promotion analysis.

+being used in pre-promotion we will only see one analysis run being created. +It is however possible for a promotion to have multiple analysis runs, dependent on the +rollout configuration. i.e. in blue-green defining both pre and post promotion analysis.

Clicking on the analysis button will expand the view to show the in-progress analysis @@ -634,9 +633,9 @@

Analysis This section should not be overly timing sensitive since we are cheating a bit by pre-generating errors. However when we promote the new image the error -setting will be reset back to 0 for the preview service. After the promotion pipeline completes, +setting will be reset back to 0 for the preview service. After the promotion pipeline completes, immediately switch back to the tab with the preview service and push the error bar -back to 100%. +back to 100%. @@ -671,7 +670,7 @@

Analysis If the timing did not work out for you, you can try again by promoting with a different color. -You can see the list of available colors .here +You can see the list of available colors here where each color is simply a tag in our quay.io registry. diff --git a/argo-rollouts-workshop/main/05-canary-rollout.html b/argo-rollouts-workshop/main/05-canary-rollout.html index e8b83da..6e5844e 100644 --- a/argo-rollouts-workshop/main/05-canary-rollout.html +++ b/argo-rollouts-workshop/main/05-canary-rollout.html @@ -234,8 +234,8 @@

Canary St

Canary can be -thought of as an advanced version of blue-green where instead of an abrupt cut-over -of live traffic between a current and new revision traffic is instead gradually increased to the new +thought of as an advanced version of blue-green. Instead of an abrupt cut-over +of live traffic between a current and new revision, traffic is instead gradually increased to the new version in increments, or steps, while simultaneously decreasing the current revision. Like the proverbial canary in the coal mine, the intent is to allow users to access the new version over time and if unexpected problems occur revert back to the @@ -337,8 +337,8 @@

<

-

In the rollout we have changed our strategy from blue-green to canary. In the canary strategy, like the blue-green strategy, we specify -the services to use however here they are stable and canary services. Unlike blue-green we explicitly define the promotion process by +

In the rollout manifest we have changed our strategy from blue-green to canary. In the canary strategy, like the blue-green strategy, we specify +the services to use however here they are stable and canary services. Unlike blue-green we explicitly define the promotion process by specifying a series of discrete steps. At each step we can set the traffic weight between the services, pause or perform an inline analysis.

@@ -704,7 +704,7 @@

Promote Image

-

Observe the dashboard once it has been promoted, the dashboard will show the progression +

Observe the dashboard once it has been promoted. The dashboard will show the progression of the steps by highlighting each step as it is being executed. Also note how pods are being drained from one service to the other as traffic weighting changes.

@@ -740,13 +740,13 @@

Inline An or as an inline analysis.

-

A background analysis happens asynchronously and does not block the progression of steps, however +

A Background Analysis happens asynchronously and does not block the progression of steps, however if the analysis fails it will abort the rollout similar to what we saw in the previous module with -the blue-green strategy. In the case of an inline analysis, the analysis is performed as a discrete step +the blue-green strategy. In the case of an Inline Analysis, the analysis is performed as a discrete step and will block the progression of the rollout until it completes.

-

The files for this example are in the ./canary-analysis/base folder, to view the list of files +

In the following example we will implement an Inline Analysis. The files for this example are in the ./canary-analysis/base folder, to view the list of files perform an ls as follows:

@@ -755,7 +755,7 @@

Inline An

-

Note that the files are identical to the previous example other then the rollout.yaml and the +

Note that the files are identical to the previous example other than the rollout.yaml and the analysistemplate.yaml file. The AnalysisTemplate being used here is identical to the one we used in the blue-green example so we will not cover it again here.

diff --git a/sitemap.xml b/sitemap.xml index 41c299b..c9a0e38 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,30 +2,30 @@ https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/01-getting-started.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/02-workshop-overview.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/03-bluegreen-rollout.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/04-analysis.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/05-canary-rollout.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/06-conclusion.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/index.html -2024-01-09T20:42:39.776Z +2024-03-08T15:41:35.581Z