update storefront usecase (#475)

* Update container-image-security-enforcement.md

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* adding storefront usecase

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* adding storefront usecase

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* spell check fixes

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* spell fixes

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* update docs

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* resolving conflicts

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* rm package lock

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* update docs

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* revert the lock file

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

* fixing spells

Signed-off-by: Hemankita Perabathini <phemankita@gmail.com>

Co-authored-by: Andrew Trice <amtrice@us.ibm.com>

Author: phemankita

docs/adopting/use-cases/applying.md

@@ -4,9 +4,7 @@
     Add additional use cases
 
 - [Create an operator](operator/operator.md) : Shows how the toolkit can be used to create an operator
-- Quarkus :
-    - [Deploy StoreFront - Quarkus Version](https://cloudnativereference.dev/deployments/quarkus)
-    - [Git tracking for StoreFront Quarkus](https://github.com/ibm-garage-cloud/planning/issues/705)
+- [StoreFront - Quarkus Version](storefront/storefront.md): Exemplar application for developers to understand the cloud native toolkit and use cases on Red Hat OpenShift.
 - [App Connect REST API Workflow](ace-pipeline/ace-pipeline.md)
 
 If you have requirements not supported by the Toolkit you can extend the toolkit by [adding a new use case](add-use-case.md)

docs/adopting/use-cases/storefront/images/sf_pipelines.png

@@ -0,0 +1,49 @@
+# Storefront - Cloud Native Exemplar
+
+<!--- cSpell:ignore CICD cntk pipelinerun Omni Frontends cloudnative -->
+
+Exemplar application for developers to understand the cloud native toolkit and use cases on Red Hat OpenShift.
+
+## Build and deploy a cloudnative reference implementation using Cloud native toolkit
+
+This provides a working example of a Tekton based CICD pipeline to build and deploy a [StoreFront](https://cloudnativereference.dev/). The Pipeline and Task resources available in [Cloud Native Toolkit](https://cloudnativetoolkit.dev/) can be used to deploy different microservices that are part of this application.
+
+### Prerequisites
+
+| Task                             | Instructions                             |
+| ---------------------------------| -----------------------------------------|
+| Active OpenShift 4.x Cluster     |                                          |
+| Set up accounts and tools        | [Instructions](../../../overview/prerequisites.md) |
+| Install the Cloud Native Toolkit | [Install the Cloud Native Toolkit](../../../setup/setup-options.md) |
+
+### Deploy the StoreFront
+
+Get started with deploying a simple retail application, Storefront using Cloud Native Toolkit. The Storefront application implements a simple shopping application that displays a catalog of antique computing devices. People can search for and buy products from the application’s web interface.
+
+The logical architecture for this reference implementation is shown in the picture below.
+
+![Architecture](images/storefront.png)
+
+This application has a web interface that relies on separate BFF (Backend for Frontend) services to interact with the backend data.
+
+These are several components of this architecture.
+
+- This OmniChannel application contains an [AngularJS](https://angularjs.org/) based web application.
+- The Web app invokes its own backend Microservice to fetch data, we call this component BFFs following the [Backend for Frontends](http://samnewman.io/patterns/architectural/bff/) pattern. The Web BFF is implemented using the Node.js Express Framework.
+- The BFFs invokes another layer of reusable Java Microservices. The reusable microservices are written in Java using [Quarkus](https://quarkus.io/) framework.
+- The Java Microservices are as follows:
+  - The [Inventory Service](https://cloudnativereference.dev/related-repositories/inventory) uses an instance of [MySQL](https://www.mysql.com/) to store the inventory items.
+  - The [Catalog service](https://cloudnativereference.dev/related-repositories/catalog) retrieves items from a searchable JSON data source using [ElasticSearch](https://www.elastic.co/).
+  - [Keycloak](https://cloudnativereference.dev/related-repositories/keycloak) delegates authentication and authorization.
+  - The [Customer service](https://cloudnativereference.dev/related-repositories/customer) stores and retrieves Customer data from a searchable JSON data source using [CouchDB](http://couchdb.apache.org/).
+  - The [Orders Service](https://cloudnativereference.dev/related-repositories/orders) uses an instance of [MariaDB](https://mariadb.org/) to store order information.
+
+### Deploy the Storefront using Cloud native toolkit
+
+Follow the below guide for instructions on how to deploy all the microservices of StoreFront onto Openshift using Cloud native toolkit.
+
+[Cloud native toolkit - StoreFront Quarkus version](https://cloudnativereference.dev/deployments/cntk-quarkus)
+
+To get an idea, here is a view of a completed and successful pipeline runs for all the microservices.
+
+![Pipeline run](images/sf_pipelines.png)

docs/adopting/use-cases/storefront/images/storefront.png

@@ -130,7 +130,7 @@ skopeo --sign-by <KEY_FINGERPRINT> copy ${IMAGE_FROM_CREDS} docker://${IMAGE_FRO
 ```
 
 !!!note
-    On Linux® and macOS: The default configuration for the signing tools is to store the signatures locally. Storing signatures locally can lead to signature verification failure because the signature is not in the registry. To fix this problem, you can modify or delete the configuration file. On Linux®, the configuration is saved in /etc/containers/registries.d/default.yaml. On macOS, the configuration file is saved in /usr/local/etc/containers/registries.d/default.yaml.  If you sign images in your container registry, yet your deployments are failing with the message `policy denied the request: A signature was required, but no signature exists`, then the default configuration is likely saving your image signatures locally instead of pushing the signature to the registry API server and you need to modify the tools configuration. 
+    On Linux® and macOS: The default configuration for the signing tools is to store the signatures locally. Storing signatures locally can lead to signature verification failure because the signature is not in the registry. To fix this problem, you can modify or delete the configuration file. On Linux®, the configuration is saved in /etc/containers/registries.d/default.yaml. On macOS, the configuration file is saved in /usr/local/etc/containers/registries.d/default.yaml.  If you sign images in your container registry, yet your deployments are failing with the message `policy denied the request: A signature was required, but no signature exists`, then the default configuration is likely saving your image signatures locally instead of pushing the signature to the registry API server and you need to modify the tools configuration.
 
 
 
@@ -170,7 +170,7 @@ The [toolkit's 8-image-release.yaml](https://github.com/IBM/ibm-garage-tekton-ta
 
 ## Impact to Kubernetes yaml or helm charts
 
-The Portieris image signing tools require an explicit specifcation which image pull secrets should be used to retrieve the signature/trust data.  You deployment must specify an `imagePullSecret` value, or else the trust/verification will fail.
+The Portieris image signing tools require an explicit specification which image pull secrets should be used to retrieve the signature/trust data.  You deployment must specify an `imagePullSecret` value, or else the trust/verification will fail.
 
 
 ## Additional Information

docs/adopting/use-cases/storefront/storefront.md

@@ -177,6 +177,7 @@ nav:
       - App Connect REST API workflow: adopting/use-cases/ace-pipeline/ace-pipeline.md
       - GitOps with Toolkit: adopting/use-cases/gitops/gitops-toolkit.md
       - GitOps with App Connect: adopting/use-cases/gitops/gitops-ace.md
+      - Storefront - Cloud Native Exemplar: adopting/use-cases/storefront/storefront.md
   - Reference:
     - Reference: reference/reference.md
     - Command Line Tool: reference/cli.md