mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 00:48:01 +01:00
132 lines
4.1 KiB
Plaintext
132 lines
4.1 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * serverless/develop/serverless-traffic-management.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="serverless-blue-green-deploy_{context}"]
|
|
= Routing and managing traffic by using a blue-green deployment strategy
|
|
|
|
.Prerequisites
|
|
|
|
* The {ServerlessOperatorName} and Knative Serving are installed on the cluster.
|
|
* Install the OpenShift CLI (`oc`).
|
|
|
|
.Procedure
|
|
|
|
. Create and deploy an app as a Knative service.
|
|
|
|
. Find the name of the first revision that was created when you deployed the service, by viewing the output from the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
|
|
----
|
|
+
|
|
.Example command
|
|
[source,terminal]
|
|
----
|
|
$ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
$ example-service-00001
|
|
----
|
|
|
|
. Add the following YAML to the service `spec` to send inbound traffic to the revision:
|
|
+
|
|
[source,yaml]
|
|
----
|
|
...
|
|
spec:
|
|
traffic:
|
|
- revisionName: <first_revision_name>
|
|
percent: 100 # All traffic goes to this revision
|
|
...
|
|
----
|
|
|
|
. Verify that you can view your app at the URL output you get from running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get ksvc <service_name>
|
|
----
|
|
|
|
. Deploy a second revision of your app by modifying at least one field in the `template` spec of the service and redeploying it. For example, you can modify the `image` of the service, or an `env` environment variable. You can redeploy the service by applying the service YAML file, or by using the `kn service update` command if you have installed the Knative (`kn`) CLI.
|
|
|
|
. Find the name of the second, latest revision that was created when you redeployed the service, by running the command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
|
|
----
|
|
+
|
|
At this point, both the first and second revisions of the service are deployed and running.
|
|
|
|
. Update your existing service to create a new, test endpoint for the second revision, while still sending all other traffic to the first revision:
|
|
+
|
|
.Example of updated service spec with test endpoint
|
|
[source,yaml]
|
|
----
|
|
...
|
|
spec:
|
|
traffic:
|
|
- revisionName: <first_revision_name>
|
|
percent: 100 # All traffic is still being routed to the first revision
|
|
- revisionName: <second_revision_name>
|
|
percent: 0 # No traffic is routed to the second revision
|
|
tag: v2 # A named route
|
|
...
|
|
----
|
|
+
|
|
After you redeploy this service by reapplying the YAML resource, the second revision of the app is now staged. No traffic is routed to the second revision at the main URL, and Knative creates a new service named `v2` for testing the newly deployed revision.
|
|
|
|
. Get the URL of the new service for the second revision, by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"
|
|
----
|
|
+
|
|
You can use this URL to validate that the new version of the app is behaving as expected before you route any traffic to it.
|
|
|
|
. Update your existing service again, so that 50% of traffic is sent to the first revision, and 50% is sent to the second revision:
|
|
+
|
|
.Example of updated service spec splitting traffic 50/50 between revisions
|
|
[source,yaml]
|
|
----
|
|
...
|
|
spec:
|
|
traffic:
|
|
- revisionName: <first_revision_name>
|
|
percent: 50
|
|
- revisionName: <second_revision_name>
|
|
percent: 50
|
|
tag: v2
|
|
...
|
|
----
|
|
|
|
. When you are ready to route all traffic to the new version of the app, update the service again to send 100% of traffic to the second revision:
|
|
+
|
|
.Example of updated service spec sending all traffic to the second revision
|
|
[source,yaml]
|
|
----
|
|
...
|
|
spec:
|
|
traffic:
|
|
- revisionName: <first_revision_name>
|
|
percent: 0
|
|
- revisionName: <second_revision_name>
|
|
percent: 100
|
|
tag: v2
|
|
...
|
|
----
|
|
+
|
|
[TIP]
|
|
====
|
|
You can remove the first revision instead of setting it to 0% of traffic if you do not plan to roll back the revision. Non-routeable revision objects are then garbage-collected.
|
|
====
|
|
|
|
. Visit the URL of the first revision to verify that no more traffic is being sent to the old version of the app.
|