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
A store ("`ATLANTA`") is installed on the hub cluster by default. This feature is interesting if you want to see how ACM can manage a remote
17
17
cluster to install the same application on a different cluster.
18
18
19
-
The way we apply this is through the managedClusterGroups block in `values-hub.yaml`:
19
+
The way we apply this is through the `managedClusterGroups` block in `values-hub.yaml`:
20
20
+
21
21
[source,yaml]
22
22
----
@@ -37,16 +37,16 @@ The way we apply this is through the managedClusterGroups block in `values-hub.y
37
37
- OpenShift
38
38
----
39
39
40
-
Any cluster joined with the label `clusterGroup=store-raleigh` will be assigned the policies that deploy the store app to them.
40
+
Any cluster joined with the label `clusterGroup=store-raleigh` is assigned the policies that deploy the store app to them.
41
41
42
42
[id="attach-managed-cluster"]
43
-
= Attach a managed cluster (edge) to the management hub
43
+
=== Attaching a managed cluster (edge) to the management hub
44
44
45
-
The use of this Multicloud GitOps pattern depends on having at least one running Red Hat OpenShift cluster.
45
+
The use of this pattern depends on having at least one running Red Hat OpenShift cluster.
46
46
47
-
When you install the multi-cloud GitOps pattern, a hub cluster is setup. The hub cluster serves as the central point for managing and deploying applications across multiple clusters.
47
+
When you install the retail GitOps pattern, a hub cluster is setup. The hub cluster serves as the central point for managing and deploying applications across multiple clusters.
Copy file name to clipboardExpand all lines: modules/retail-about.adoc
+2-5Lines changed: 2 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,15 +10,12 @@ It is derived from the https://quarkuscoffeeshop.github.io[Quarkus Coffeeshop De
10
10
11
11
This demo pulls together several different strands of the demo and allows for multiple stores to be installed on remote clusters via ACM if the user desires.
12
12
13
-
The demo allows users to go to the store’s web page, order drinks and food items, and see those items `made` and served by the microservices in real time.
14
-
15
-
The pattern includes build pipelines and a demo space, so that changes to the applications can be tested prior to `production` deployments.
13
+
The demo allows users to go to the store’s web page, order drinks and food items, and see those items `made` and served by the microservices in real time. The pattern includes build pipelines and a demo space, so that changes to the applications can be tested prior to `production` deployments.
16
14
17
15
[id="solution-elements"]
18
16
== Solution elements
19
17
20
-
* How to use a GitOps approach to keep in control of configuration and
21
-
operations
18
+
* How to use a GitOps approach to keep in control of configuration and operations
22
19
* How to centrally manage multiple clusters, including workloads
23
20
* How to build and deploy workloads across clusters using modern CI/CD
24
21
* How to architect a modern application using microservices and Kafka in Java
** The cluster must have a dynamic `StorageClass` to provision `PersistentVolumes`. See link:../../multicloud-gitops/mcg-cluster-sizing[sizing your cluster].
11
+
** Select *OpenShift \-> Red Hat OpenShift Container Platform \-> Create cluster*.
12
+
** The cluster must have a dynamic `StorageClass` to provision `PersistentVolumes`. Verify that a dynamic StorageClass exists before creating one by running the following command:
13
+
+
14
+
[source,terminal]
15
+
----
16
+
$ oc get storageclass -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner,DEFAULT:.metadata.annotations."storageclass\.kubernetes\.io/is-default-class"
17
+
----
18
+
+
19
+
.Example output
20
+
+
21
+
[source,terminal]
22
+
----
23
+
NAME PROVISIONER DEFAULT
24
+
gp2-csi ebs.csi.aws.com <none>
25
+
gp3-csi ebs.csi.aws.com true
26
+
----
27
+
+
28
+
For more information about creating a dynamic `StorageClass`, see the https://docs.openshift.com/container-platform/latest/storage/dynamic-provisioning.html[Dynamic provisioning] documentation.
29
+
13
30
* Optional: A second OpenShift cluster for multicloud demonstration.
14
31
//Replaced git and podman prereqs with the tooling dependencies page
32
+
* Optional: A quay account that can update images; this is if you want to use the pipelines to customize the applications.
33
+
* Optional: A quay account with the following repositories set as public, and which you can write to:
These repos contain the demo's microservices. The public repos (`quay.io/hybridcloudpatterns/*`) provide pre-built images used by default, allowing the demo to run without rebuilding the apps. Creating your own quay copies offers transparency and lets you reproduce results or customize the apps.
46
+
====
47
+
15
48
* https://validatedpatterns.io/learn/quickstart/[Install the tooling dependencies].
16
49
17
50
The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
@@ -26,20 +59,20 @@ If you do not have a running Red Hat OpenShift cluster, you can start one on a p
. Edit `values-secret.yaml` populating with your quay `username` and `password`.
40
73
+
41
74
[source,yaml]
42
-
---
75
+
----
43
76
# NEVER COMMIT THESE VALUES TO GIT
44
77
version: "2.0"
45
78
secrets:
@@ -53,7 +86,7 @@ secrets:
53
86
value: "my-quay-password"
54
87
----
55
88
+
56
-
[WARNING]
89
+
[NOTE]
57
90
====
58
91
Do not commit this file. You do not want to push personal credentials to GitHub.
59
92
====
@@ -74,9 +107,9 @@ $ git switch -c my-branch
74
107
$ vi values-global.yaml
75
108
----
76
109
+
77
-
The values that you need to change are under the `imageregistry` key, to use your own account and hostname. If you like, you can change the `git` settings of `account`, `email` and `hostname` to reflect your own account settings.
78
-
79
-
If you plan to customize the build of the applications themselves, there are `revision` and `imageTag` settings for each of them. The defaults should suffice if you just want to see the apps running.
110
+
The defaults should suffice if you just want to see the apps running. The values that you might change are under the `imageregistry`, if you copied the images to your own quay account and hostname. If you like, you can change the `git` settings of `account`, `email` and `hostname` to reflect your own account settings.
111
+
+
112
+
If you plan to customize the build of the applications themselves, there are `revision` and `imageTag` settings for each of them.
80
113
81
114
.. Stage the changes to the `values-hub.yaml` file by running the following commands:
82
115
+
@@ -140,30 +173,30 @@ $ ./pattern.sh make install
140
173
141
174
.. Set your project to `All Projects` and verify the operators are installed and have a status of `Succeeded`.
0 commit comments