Skip to content

Commit 1701e70

Browse files
kquinn1204kquinn1204
committed
TELCODOCS-2229 updating retail pattern docs
1 parent c4b0f8a commit 1701e70

File tree

8 files changed

+484
-0
lines changed

8 files changed

+484
-0
lines changed

‎content/patterns/retail/_index.adoc‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
---
2+
title: Retail
3+
date: 2022-12-08
4+
tier: tested
5+
summary: This pattern demonstrates a pattern that models the store side of a retail application.
6+
rh_products:
7+
- Red Hat OpenShift Container Platform
8+
- Red Hat Advanced Cluster Management
9+
- Red Hat AMQ
10+
industries:
11+
- Retail
12+
aliases: /retail/
13+
# uncomment once this exists
14+
# pattern_logo: retail.png
15+
links:
16+
install: getting-started
17+
help: https://groups.google.com/g/validatedpatterns
18+
bugs: https://github.com/validatedpatterns/retail/issues
19+
# uncomment once this exists
20+
ci: retail
21+
---
22+
23+
:toc:
24+
:imagesdir: /images
25+
:_content-type: ASSEMBLY
26+
include::modules/comm-attributes.adoc[]
27+
28+
include::modules/retail-about.adoc[leveloffset=+1]
29+
30+
include::modules/retail-architecture.adoc[leveloffset=+1]
31+
32+
33+

‎content/patterns/retail/application.adoc‎

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
== Demonstrating Retail example applications
2+
3+
=== Background
4+
5+
Up until now the Retail validated pattern has focused primarily on
6+
successfully deploying the architectural pattern. Now it is time to see
7+
the actual applications running as we have deployed them.
8+
9+
If you have already deployed the hub cluster, then you have already seen
10+
several applications deployed in the OpenShift GitOps console. If you
11+
haven’t done this then we recommend you deploy the hub after you have
12+
setup the Quay repositories described below.
13+
14+
=== Ordering Items at the Coffeeshop
15+
16+
The easiest way to get to the coffeeshop store page is from the
17+
OpenShift Console Menu Landing Page entry:
18+
19+
link:/images/retail/retail-v1-console-menu.png[image:/images/retail/retail-v1-console-menu.png[retail-v1-console-menu]]
20+
21+
Clicking on the Quarkus Coffeeshop Landing Page link will bring you to
22+
this page:
23+
24+
link:/images/retail/retail-v1-landing-page.png[image:/images/retail/retail-v1-landing-page.png[retail-v1-landing-page]]
25+
26+
And clicking on either the "`Store Web Page`" or "`TEST Store Web Page`"
27+
links will bring you to a screen that looks like this:
28+
29+
link:/images/retail/retail-v1-store-page.png[image:/images/retail/retail-v1-store-page.png[retail-v1-store-page]]
30+
31+
_NOTE_: The applications are initially identical. The "`TEST`" site is
32+
deployed to the `+quarkuscoffeeshop-demo+` namespace; the regular Store
33+
site is deployed to the `+quarkuscoffeeshop-store+` namespace.
34+
35+
Each store requires supporting services, in PostgreSQL and Kafka. In our
36+
pattern, PostgreSQL is provided by the Crunchy PostgreSQL operator, and
37+
Kafka is provided by the Red Hat AMQ Streams operator. Each instance,
38+
the regular instance and the TEST instance, has its own instance of each
39+
of these supporting services it uses.
40+
41+
To order, click on the "`Place an Order`" button on the front page. The
42+
menu should look like this:
43+
44+
link:/images/retail/retail-v1-store-web-menu.png[image:/images/retail/retail-v1-store-web-menu.png[retail-v1-store-web-menu]]
45+
46+
Click the "`Add`" button next to a menu item; the item name will appear.
47+
Add a name for the order:
48+
49+
link:/images/retail/retail-v1-order-p1.png[image:/images/retail/retail-v1-order-p1.png[retail-v1-order-p1]]
50+
51+
You can add as many orders as you want. On your last item, click the
52+
"`Place Order`" button on the item dialog:
53+
54+
link:/images/retail/retail-v1-place-order.png[image:/images/retail/retail-v1-place-order.png[retail-v1-place-order]]
55+
56+
As the orders are serviced by the barista and kitchen services, you can
57+
see their status in the "`Orders`" section of the page:
58+
59+
link:/images/retail/retail-v1-orders-status.png[image:/images/retail/retail-v1-orders-status.png[retail-v1-orders-status]]

‎content/patterns/retail/cluster-sizing.adoc‎

Lines changed: 199 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,199 @@
1+
== OpenShift Cluster Sizing for the Retail Pattern
2+
3+
=== Tested Platforms
4+
5+
The *retail* pattern has been tested in the following Certified Cloud
6+
Providers.
7+
8+
[cols="<,<",options="header",]
9+
|===
10+
|*Certified Cloud Providers* |4.10
11+
|Amazon Web Services |:heavy_check_mark:
12+
|Microsoft Azure |
13+
|Google Cloud Platform |
14+
|===
15+
16+
=== General OpenShift Minimum Requirements
17+
18+
OpenShift 4 has the following minimum requirements for sizing of nodes:
19+
20+
* *Minimum 4 vCPU* (additional are strongly recommended).
21+
* *Minimum 16 GB RAM* (additional memory is strongly recommended,
22+
especially if etcd is colocated on masters).
23+
* *Minimum 40 GB* hard disk space for the file system containing /var/.
24+
* *Minimum 1 GB* hard disk space for the file system containing
25+
/usr/local/bin/.
26+
27+
There are several applications that comprise the *retail* pattern. In
28+
addition, the *retail* pattern also includes a number of supporting
29+
operators that are installed by *OpenShift GitOps* using ArgoCD.
30+
31+
==== Retail Pattern OpenShift Datacenter HUB Cluster Size
32+
33+
The retail pattern has been tested with a defined set of specifically
34+
tested configurations that represent the most common combinations that
35+
Red Hat OpenShift Container Platform (OCP) customers are using or
36+
deploying for the x86_64 architecture.
37+
38+
The Datacenter HUB OpenShift Cluster is made up of the the following on
39+
the AWS deployment tested:
40+
41+
[cols="<,^,<,<",options="header",]
42+
|===
43+
|Node Type |Number of nodes |Cloud Provider |Instance Type
44+
|Master |3 |Amazon Web Services |m5.xlarge
45+
|Worker |3 |Amazon Web Services |m5.xlarge
46+
|===
47+
48+
The Datacenter HUB OpenShift cluster needs to be a bit bigger than the
49+
Factory/Edge clusters because this is where the developers will be
50+
running pipelines to build and deploy the *Industrial Edge* pattern on
51+
the cluster. The above cluster sizing is close to a *minimum* size for a
52+
Datacenter HUB cluster. In the next few sections we take some snapshots
53+
of the cluster utilization while the *Industrial Edge* pattern is
54+
running. Keep in mind that resources will have to be added as more
55+
developers are working building their applications.
56+
57+
==== Retail Pattern OpenShift Store Edge Cluster Size
58+
59+
The OpenShift cluster is made of 3 Nodes combining Master/Workers for
60+
the Edge/Factory cluster.
61+
62+
[cols="^,^,^,^",options="header",]
63+
|===
64+
|Node Type |Number of nodes |Cloud Provider |Instance Type
65+
|Master/Worker |3 |Google Cloud |n1-standard-8
66+
|Master/Worker |3 |Amazon Cloud Services |m5.2xlarge
67+
|Master/Worker |3 |Microsoft Azure |Standard_D8s_v3
68+
|===
69+
70+
==== AWS Instance Types
71+
72+
The *retail* pattern was tested with the highlighted AWS instances in
73+
*bold*. The OpenShift installer will let you know if the instance type
74+
meets the minimum requirements for a cluster.
75+
76+
The message that the openshift installer will give you will be similar
77+
to this message
78+
79+
[source,text]
80+
----
81+
INFO Credentials loaded from default AWS environment variables
82+
FATAL failed to fetch Metadata: failed to load asset "Install Config": [controlPlane.platform.aws.type: Invalid value: "m4.large": instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: "m4.large": instance type does not meet minimum resource requirements of 16384 MiB Memory]
83+
----
84+
85+
Below you can find a list of the AWS instance types that can be used to
86+
deploy the *retail* pattern.
87+
88+
[width="100%",cols="^26%,^20%,^20%,^17%,^17%",options="header",]
89+
|===
90+
|Instance type |Default vCPUs |Memory (GiB) |Datacenter |Factory/Edge
91+
| | | |3x3 OCP Cluster |3 Node OCP Cluster
92+
|m4.xlarge |4 |16 |N |N
93+
|m4.2xlarge |8 |32 |Y |Y
94+
|m4.4xlarge |16 |64 |Y |Y
95+
|m4.10xlarge |40 |160 |Y |Y
96+
|m4.16xlarge |64 |256 |Y |Y
97+
|*m5.xlarge* |4 |16 |Y |N
98+
|m5.2xlarge |8 |32 |Y |Y
99+
|m5.4xlarge |16 |64 |Y |Y
100+
|m5.8xlarge |32 |128 |Y |Y
101+
|m5.12xlarge |48 |192 |Y |Y
102+
|m5.16xlarge |64 |256 |Y |Y
103+
|m5.24xlarge |96 |384 |Y |Y
104+
|===
105+
106+
The OpenShift cluster is made of 3 Masters and 3 Workers for the
107+
Datacenter and the Edge/Factory cluster are made of 3 Master/Worker
108+
nodes. For the node sizes we used the *m5.xlarge* on AWS and this
109+
instance type met the minimum requirements to deploy the *retail*
110+
pattern successfully on the Datacenter hub. On the Factory/Edge cluster
111+
we used the *m5.2xlarge* since the minimum cluster was comprised of 3
112+
nodes. .
113+
114+
To understand better what types of nodes you can use on other Cloud
115+
Providers we provide some of the details below.
116+
117+
==== Azure Instance Types
118+
119+
The *retail* pattern was also deployed on Azure using the
120+
*Standard_D8s_v3* VM size. Below is a table of different VM sizes
121+
available for Azure. Keep in mind that due to limited access to Azure we
122+
only used the *Standard_D8s_v3* VM size.
123+
124+
The OpenShift cluster is made of 3 Master and 3 Workers for the
125+
Datacenter cluster.
126+
127+
The OpenShift cluster is made of 3 Nodes combining Master/Workers for
128+
the Edge/Factory cluster.
129+
130+
[width="100%",cols="<34%,<33%,<33%",options="header",]
131+
|===
132+
|Type |Sizes |Description
133+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-general[General
134+
purpose] |B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4,
135+
Dsv4, Ddv4, Ddsv4 |Balanced CPU-to-memory ratio. Ideal for testing and
136+
development, small to medium databases, and low to medium traffic web
137+
servers.
138+
139+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-compute[Compute
140+
optimized] |F, Fs, Fsv2, FX |High CPU-to-memory ratio. Good for medium
141+
traffic web servers, network appliances, batch processes, and
142+
application servers.
143+
144+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-memory[Memory
145+
optimized] |Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M,
146+
DSv2, Dv2 |High memory-to-CPU ratio. Great for relational database
147+
servers, medium to large caches, and in-memory analytics.
148+
149+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-storage[Storage
150+
optimized] |Lsv2 |High disk throughput and IO ideal for Big Data, SQL,
151+
NoSQL databases, data warehousing and large transactional databases.
152+
153+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-gpu[GPU]
154+
|NC, NCv2, NCv3, NCasT4_v3, ND, NDv2, NV, NVv3, NVv4 |Specialized
155+
virtual machines targeted for heavy graphic rendering and video editing,
156+
as well as model training and inferencing (ND) with deep learning.
157+
Available with single or multiple GPUs.
158+
159+
|https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-hpc[High
160+
performance compute] |HB, HBv2, HBv3, HC, H |Our fastest and most
161+
powerful CPU virtual machines with optional high-throughput network
162+
interfaces (RDMA).
163+
|===
164+
165+
For more information please refer to the
166+
https://docs.microsoft.com/en-us/azure/virtual-machines/sizes[Azure VM
167+
Size Page].
168+
169+
==== Google Cloud (GCP) Instance Types
170+
171+
The *retail* pattern was also deployed on GCP using the *n1-standard-8*
172+
VM size. Below is a table of different VM sizes available for GCP. Keep
173+
in mind that due to limited access to GCP we only used the
174+
*n1-standard-8* VM size.
175+
176+
The OpenShift cluster is made of 3 Master and 3 Workers for the
177+
Datacenter cluster.
178+
179+
The OpenShift cluster is made of 3 Nodes combining Master/Workers for
180+
the Edge/Factory cluster.
181+
182+
The following table provides VM recommendations for different workloads.
183+
184+
[verse]
185+
--
186+
*General purpose* | *Workload optimized*
187+
Cost-optimized | Balanced | Scale-out optimized | Memory-optimized |Compute-optimized | Accelerator-optimized
188+
:—- | :—- | :—- | :—- | :—- | :—-
189+
E2 | N2, N2D, N1 | T2D | M2, M1 | C2 | A2
190+
--
191+
192+
Day-to-day computing at a lower cost | Balanced price/performance across
193+
a wide range of VM shapes | Best performance/cost for scale-out
194+
workloads | Ultra high-memory workloads | Ultra high performance for
195+
compute-intensive workloads | Optimized for high performance computing
196+
workloads
197+
198+
For more information please refer to the
199+
https://cloud.google.com/compute/docs/machine-types[GCP VM Size Page].

‎content/patterns/retail/components.adoc‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
== Component Details
2+
3+
=== The Quarkus Coffeeshop Store https://github.com/validatedpatterns/retail/tree/main/charts/store/quarkuscoffeeshop-charts[Chart]
4+
5+
This chart is responsible for deploying the applications, services and
6+
routes for the Quarkus Coffeeshop demo. It models a set of microservices
7+
that would make sense for a coffeeshop retail operation. The detail of
8+
what the microservices do is
9+
https://quarkuscoffeeshop.github.io/coffeeshop/[here].
10+
11+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-web[quarkuscoffeeshop-web]
12+
13+
Serves as the "`front end`" for ordering food and drinks.
14+
15+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-counter[quarkuscoffeeshop-counter]
16+
17+
The counter service receives the orders, persists them in the database,
18+
and notifies when they are ready.
19+
20+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-barista[quarkuscoffeeshop-barista]
21+
22+
The barista service is responsible for preparing items from the
23+
"`drink`" side of the menu.
24+
25+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-kitchen[quarkuscoffeeshop-kitchen]
26+
27+
The kitchen service is responsible for preparing items from the "`food`"
28+
side of the menu.
29+
30+
* https://github.com/quarkuscoffeeshop/customerloyalty[quarkuscoffeeshop-customerloyalty]
31+
32+
The customerloyalty service is responsible for generating customer
33+
loyalty events, when a customer enters the "`rewards`" email. This data
34+
is not persisted or tracked anywhere.
35+
36+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-inventory[quarkuscoffeeshop-inventory]
37+
38+
The inventory service is responsible for tracking food and drink
39+
inventory.
40+
41+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-customermocker[quarkuscoffeeshop-customermocker]
42+
43+
The customermocker can be used to generate test traffic.
44+
45+
* https://github.com/quarkuscoffeeshop/quarkuscoffeeshop-majestic-monolith[quarkuscoffeeshop-majestic-monolith]
46+
47+
The "`majestic monolith`" builds all the apps into a single bundle, to
48+
simplify the process of deploying this app on single node systems.
49+
50+
All the components look like this in ArgoCD when deployed:
51+
52+
link:/images/retail/retail-v1-argo-coffeeshop-store.png[image:/images/retail/retail-v1-argo-coffeeshop-store.png[retail-v1-argo-coffeeshop-store]]
53+
54+
The chart is designed such that the same chart can be deployed in the
55+
hub cluster as the "`production`" store, the "`demo`" or TEST store, and
56+
on a remote cluster.
57+
58+
=== The Quarkus Coffeeshop Database https://github.com/validatedpatterns/retail/tree/main/charts/all/crunchy-pgcluster[Chart]
59+
60+
This installs a database instance suitable for use in the Retail
61+
pattern. It uses the Crunchy PostgreSQL
62+
https://github.com/CrunchyData/postgres-operator[Operator] to provide
63+
PostgreSQL services, which includes high availability and backup
64+
services by default, and other features available.
65+
66+
Like the store chart, the Database chart can be deployed in the same
67+
different scenarios.
68+
69+
In ArgoCD, it looks like this:
70+
71+
link:/images/retail/retail-v1-argo-coffeeshopdb.png[image:/images/retail/retail-v1-argo-coffeeshopdb.png[retail-v1-argo-coffeeshopdb]]
72+
73+
=== The Quarkus Coffeeshop Kafka https://github.com/validatedpatterns/retail/tree/main/charts/all/quarkuscoffeeshop-kafka[Chart]
74+
75+
This chart installs Kafka for use in the Retail pattern. It uses the Red
76+
Hat AMQ Streams
77+
https://access.redhat.com/documentation/en-us/red_hat_amq/7.2/html/using_amq_streams_on_openshift_container_platform/index[operator].
78+
79+
=== The Quarkus Coffeeshop Pipelines https://github.com/validatedpatterns/retail/tree/main/charts/hub/quarkuscoffeeshop-pipelines[Chart]
80+
81+
The pipelines chart defines build pipelines using the Red Hat OpenShift
82+
Pipelines
83+
https://catalog.redhat.com/software/operators/detail/5ec54a4628834587a6b85ca5[Operator]
84+
(tektoncd). Pipelines are provided for all of the application images
85+
that ship with the pattern; the pipelines all build the app from source,
86+
deploy them to the "`demo`" namespace, and push them to the configured
87+
image registry.
88+
89+
Like the store and database charts, the kafka chart supports all three
90+
modes of deployment.
91+
92+
link:/images/retail/retail-v1-argo-pipelines.png[image:/images/retail/retail-v1-argo-pipelines.png[retail-v1-argo-pipelines]]
93+
94+
=== The Quarkus Coffeeshop Landing Page https://github.com/validatedpatterns/retail/tree/main/charts/all/landing-page[Chart]
95+
96+
The Landing Page chart builds the page that presents the links for the
97+
demos in the pattern.
98+
99+
link:/images/retail/retail-v1-argo-landing-page.png[image:/images/retail/retail-v1-argo-landing-page.png[retail-v1-landing-page]]

0 commit comments

Comments
 (0)