It would be useful to be able to proxy API requests to the various backend components through the frontend for demonstration purposes.

For example http://frontend/proxy/carts/customer1 should be forwarded to the carts service.

This should be possible by using Spring Cloud Gateway and the ProxyExchange mechanism to transparently proxy requests to each backend endpoint.

https://docs.spring.io/spring-cloud-gateway/reference/spring-cloud-gateway-proxy-exchange.html

Both Oracle and MariaDB JDBC drivers have licenses that are not preferable (for example LGPL). It would also be nice to have something that uses PostgreSQL instead of MySQL as a persistence store.

Add a README for each helm chart. For now this should focus on documenting the values.

Example for inspiration https://github.com/aws/karpenter-provider-aws/tree/main/charts/karpenter

Hi! I work on the DevRel team at Pulumi, and we've been using your application (referred to us by a friend of mine at AWS) in a fictional series of blog posts. So, thank you for all your efforts in putting this together!

Along the way, we've developed Pulumi code to both:

a) deploy the application to EKS
b) deploy the application locally via Docker

I'm curious if folks would be interested in accepting a PR to add one or both of these to your repository?

When running the docker-compose file from the Catalog src directory, I'm supplying a password as described in the Readme and the MySQL container loads up fine.
I'm getting the following from the catalog container:

catalog-catalog-1     | 2023/02/23 14:50:40 Running database migration...
catalog-catalog-1     | 2023/02/23 14:50:40 Error: Failed to apply migration <nil>
catalog-catalog-1     | 2023/02/23 14:50:40 Connecting to catalog-db:3306/sampledb?timeout=5s
catalog-catalog-1     | 2023/02/23 14:50:40 invalid connection config: missing required peer IP or hostname

The container keeps running and is working, but the logging is misleading...

There are multiple components allows data persist option:

• MySQL in orders and catalog
• RabbitMQ in orders

Add data persist options on helm charts and manifest to allow users play with storage options.

The Helm charts should be published to ECR Public along with the container images. A new set of repositories should be created, one for each component. For example the UI chart should be published to:

https://gallery.ecr.aws/aws-containers/retail-store-sample-ui-chart

The current repositories could be used but that would result in odd version tags like 0.8.0-chart

Any time a component is updated is should be subject to a Trivy scan to ensure that no issues are being introduced.

Can likely leverage: https://github.com/aquasecurity/trivy-action

Hi,

The LoadBalancer is defined twice in the deploy.yaml

By default Spring Data JPA uses Hibernate, which uses licenses that cause extra toil like LGPL.

There are two perceived options:

1. Move to EclipseLink or OpenJPA as the JPA provider
2. Migrate to jOOQ over Spring Data JPA

Currently theres a kustomize component that enables OpenTelemetry support, but this isn't enabled when using the EKS Terraform configuration. This should be enabled by default, limited to X-Ray for the moment.

Work required:

• Modify EKS cluster install to enable ADOT operator managed addon via EKS blueprints
• Add Terraform to create IRSA constructs for the OTel collector, inject IAM role ARN as an environment variable when invoking kustomize
• Install the opentelemetry helm chart with appropriate configuration passed in

Use the IAM policy suggested here https://github.com/aws-observability/aws-otel-collector/blob/main/docs/developers/eks-demo.md#create-eks-awsotel-iam-policy

Add ability to install the Cilium CNI with the blueprints addon and add sample network policies that lock down communication between the components.

General rules:

• UI can communicate with all services
• Checkout can communicate with orders
• Components that have dependencies like MySQL must be able to communicate with them

The Terraform should be behind a flag called something like network_policies_enabled

With the migration to Spring Boot 3 its possible to take advantage of the improved native image story which provides better application startup time.

https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html

We should publish a set of parallel images that uses a native executable to provide a way to experiment with this developing method for building Java applications.

This will require several threads of work:

• Investigate if all/some of the components work as native executables
• Work to understand limitations (for example: OpenTelemetry Java agent is no longer usable)
• Figure out minimal Dockerfile that can be used for native executables
• Re-work image build scripts to account for building multiple images for the same component, where currently it is 1-to-1

Each application component in the architecture exports Prometheus metrics. Create a Grafana dashboard for each component that shows relevant metrics (for example: heap metrics in Java). These should be stored with each respective component as a JSON file.

Currently the Kubernetes manifests are expressed as kustomize configuration. Although this is simple to read and understand it is becoming increasingly difficult to express optionality, especially via mechanisms like Terraform.

Migrate the kustomize configuration to helm charts.

Hello,
https://catalog.workshops.aws/ecs-immersion-day/en-US
doesn't work on the retail-store-sample-app latest 0.8.1 release on step "Automation" as the change made on src/ui/script, build.source deleted in this release.

codebuild log:
Failed
Start time: 3 minutes agoChange 3 minutes ago to UTC+2:00 time formatChange 3 minutes ago to UTC+2:00 time format
Current phase: COMPLETED
Showing the last 90 lines of the build log. View entire log
[Container] 2024/07/20 19:09:48.938218 Running on CodeBuild On-demand
[Container] 2024/07/20 19:09:48.938241 Waiting for agent ping
[Container] 2024/07/20 19:09:49.039139 Waiting for DOWNLOAD_SOURCE
[Container] 2024/07/20 19:09:50.716375 Phase is DOWNLOAD_SOURCE
[Container] 2024/07/20 19:09:50.721026 CODEBUILD_SRC_DIR=/codebuild/output/src2366024653/src
[Container] 2024/07/20 19:09:50.721467 YAML location is /codebuild/output/src2366024653/src/buildspec.yml
[Container] 2024/07/20 19:09:50.723023 Setting HTTP client timeout to higher timeout for S3 source
[Container] 2024/07/20 19:09:50.723102 Processing environment variables
[Container] 2024/07/20 19:09:50.930309 No runtime version selected in buildspec.
[Container] 2024/07/20 19:09:50.958173 Moving to directory /codebuild/output/src2366024653/src
[Container] 2024/07/20 19:09:50.961244 Unable to initialize cache download: no paths specified to be cached
[Container] 2024/07/20 19:09:50.983489 Configuring ssm agent with target id: codebuild:7ebd4c8b-98ff-4430-928b-87ffd78552aa
[Container] 2024/07/20 19:09:51.044600 Successfully updated ssm agent configuration
[Container] 2024/07/20 19:09:51.044903 Registering with agent
[Container] 2024/07/20 19:09:51.073371 Phases found in YAML: 4
[Container] 2024/07/20 19:09:51.073396 BUILD: 8 commands
[Container] 2024/07/20 19:09:51.073399 POST_BUILD: 8 commands
[Container] 2024/07/20 19:09:51.073402 INSTALL: 1 commands
[Container] 2024/07/20 19:09:51.073405 PRE_BUILD: 8 commands
[Container] 2024/07/20 19:09:51.073676 Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED
[Container] 2024/07/20 19:09:51.073689 Phase context status code: Message:
[Container] 2024/07/20 19:09:51.128895 Entering phase INSTALL
[Container] 2024/07/20 19:09:51.129236 Running command echo Build started on date
Build started on Sat Jul 20 19:09:51 UTC 2024
[Container] 2024/07/20 19:09:51.173601 Phase complete: INSTALL State: SUCCEEDED
[Container] 2024/07/20 19:09:51.173617 Phase context status code: Message:
[Container] 2024/07/20 19:09:51.205847 Entering phase PRE_BUILD
[Container] 2024/07/20 19:09:51.206263 Running command ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
[Container] 2024/07/20 19:10:04.720590 Running command echo Logging in to Amazon ECR in $AWS_REGION
Logging in to Amazon ECR in us-west-2
[Container] 2024/07/20 19:10:04.727328 Running command COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-8)
[Container] 2024/07/20 19:10:04.735473 Running command IMAGE_TAG_I=i$(date +%Y%m%d%H%M%S)-${COMMIT_HASH:=latest}
[Container] 2024/07/20 19:10:04.742631 Running command echo ECR_URI=$ECR_URI
ECR_URI=071385330200.dkr.ecr.us-west-2.amazonaws.com/retail-store-sample-ui
[Container] 2024/07/20 19:10:04.748830 Running command echo IMAGE_TAG=$IMAGE_TAG
IMAGE_TAG=latest-amd64
[Container] 2024/07/20 19:10:04.754908 Running command echo IMAGE_TAG_I=$IMAGE_TAG_I
IMAGE_TAG_I=i20240720191004-c8bf4e36
[Container] 2024/07/20 19:10:04.761075 Running command aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $ECR_URI
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
[Container] 2024/07/20 19:10:05.433477 Phase complete: PRE_BUILD State: SUCCEEDED
[Container] 2024/07/20 19:10:05.433496 Phase context status code: Message:
[Container] 2024/07/20 19:10:05.469612 Entering phase BUILD
[Container] 2024/07/20 19:10:05.470049 Running command echo Building a container image ...
Building a container image ...
[Container] 2024/07/20 19:10:05.476635 Running command component=ui
[Container] 2024/07/20 19:10:05.483175 Running command component_dir="./src/$component"
[Container] 2024/07/20 19:10:05.489132 Running command source "$component_dir/scripts/build.source"
/codebuild/output/tmp/script.sh: line 4: ./src/ui/scripts/build.source: No such file or directory
[Container] 2024/07/20 19:10:05.494795 Command did not exit successfully source "$component_dir/scripts/build.source" exit status 1
[Container] 2024/07/20 19:10:05.499639 Phase complete: BUILD State: FAILED
[Container] 2024/07/20 19:10:05.499654 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: source "$component_dir/scripts/build.source". Reason: exit status 1
[Container] 2024/07/20 19:10:05.537714 Entering phase POST_BUILD
[Container] 2024/07/20 19:10:05.538105 Running command docker push $ECR_URI:$IMAGE_TAG_I
The push refers to repository [071385330200.dkr.ecr.us-west-2.amazonaws.com/retail-store-sample-ui]
An image does not exist locally with the tag: 071385330200.dkr.ecr.us-west-2.amazonaws.com/retail-store-sample-ui
[Container] 2024/07/20 19:10:05.556526 Command did not exit successfully docker push $ECR_URI:$IMAGE_TAG_I exit status 1
[Container] 2024/07/20 19:10:05.561689 Phase complete: POST_BUILD State: FAILED
[Container] 2024/07/20 19:10:05.561705 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker push $ECR_URI:$IMAGE_TAG_I. Reason: exit status 1
[Container] 2024/07/20 19:10:05.659925 Expanding base directory path: .
[Container] 2024/07/20 19:10:05.663375 Assembling file list
[Container] 2024/07/20 19:10:05.663391 Expanding .
[Container] 2024/07/20 19:10:05.666592 Expanding file paths for base directory .
[Container] 2024/07/20 19:10:05.666605 Assembling file list
[Container] 2024/07/20 19:10:05.666608 Expanding imagedefinitions.json
[Container] 2024/07/20 19:10:05.669782 Skipping invalid file path imagedefinitions.json
[Container] 2024/07/20 19:10:05.669795 Expanding imageDetail.json
[Container] 2024/07/20 19:10:05.672909 Skipping invalid file path imageDetail.json
[Container] 2024/07/20 19:10:05.672918 Expanding taskdef.json
[Container] 2024/07/20 19:10:05.675954 Found 1 file(s)
[Container] 2024/07/20 19:10:05.678077 Phase complete: UPLOAD_ARTIFACTS State: SUCCEEDED
[Container] 2024/07/20 19:10:05.678094 Phase context status code: Message:

In the root Readme file, the instruction to run Docker Compose produces an error:

$ docker-compose MYSQL_PASSWORD='pass@word1' docker compose up -f dist/docker-compose/docker-compose.yml

unknown shorthand flag: 'f' in -f

There should be Terraform to create all the AWS infrastructure required to deploy the application on EKS.

Initial thoughts were:

• Use EKS blueprints as a starting point to create the EKS cluster
• Create RDS, RabbitMQ and other infrastructure required by the application components
• Use null_resource to run kubectl apply -k and deploy the application

All application component should be instrumented with OpenTelemetry SDKs to allow metrics and traces to be shipped to a collector. Each component will need to be instrumented with its respective library/middleware.

Using Redis with TLS results in the checkout component never responding to queries.

The component should work with and without TLS.

working eks workshop:
https://www.eksworkshop.com/docs/fundamentals/exposing/loadbalancer/adding-lb
when deploying loadbalancer services it showing "pending" status.

Error from ui-nlb serivces:

couldn't get current server API group list: Get "http://ervice/api?timeout=32s": dial tcp: lookup ervice on 172.31.0.2:53: no such host.
it seems like somewhere in code its mention as "ervice" instead of "services" ?
I have looked the ui app code but unable to find URL.

https://github.com/aws-containers/retail-store-sample-app/tree/main/src/ui

Its expected that additional components will be added to this application over time. Document the expectations of an application component such as:

• OpenAPI spec
• Automated test expectations
• Must be able to run on ARM64
• Must be instrumented with OpenTelemetry

The UI should provide a page that outputs information about the environment the container is deployed in. This is useful for demonstrations where it is necessary to show aspects such as cross-AZ load balancing and many others.

This component should automatically determine where it is running by checking for things like the EC2 metadata endpoint, ECS metadata endpoint etc. It should likely be possible for multiple "contributors" to add to the metadata, for example one to provide Kubernetes metadata and another to provide EC2 metadata.

Examples of information that could be shown:

• Availability zone/region
• EC2 instance type
• ECS task family, revision
• Environment variables with a specific prefix, for example METADATA_CUSTOM_FIELD, which would allow use of Kubernetes downwards API

Create kustomize component and recipe for using Istio service mesh. This should mostly be creating a VirtualService for the ui component:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ui
spec:
  hosts:
  - "*"
  gateways:
  - watchn
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: ui
        port:
          number: 80

And then a gateway:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: retail-store-sample
spec:
  selector:
    istio: ingressgateway 
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - [...]

Also turn on Istio automatic sidecar injection by adding istio-injection=enabled to all the application namespaces.

Establish an initial set of utility functions in the UI component to enable demonstrations. The podinfo application provides lots of these.

Suggested functions:

• GET /headers Print the heads of the inbound request
• GET /status/{code} Return the given HTTP status code
• GET /panic Shutdown the application with an error code
• POST /echo Write back the payload sent to it
• POST /store Write the payload to a file and return a hash
• GET /store/{hash} Return the payload from the file system previously stored

The catalog component has no automated tests which makes it difficult to assess changes and package upgrades. Implement integration tests that can be run as part of CI and locally.

Potential approaches:

• Use TestContainers for Go to run MySQL
• Use apitest to start server and run tests

Currently the catalog component does not have database connection timeouts implemented, which means that if it cannot connect to the MySQL database there will be no output or indication of the error before something like a Kubernetes readiness probe fails.

Add a configuration setting DB_CONNECTION_TIMEOUT with has a default value of 10.

Each component should have consistency documentation addressing:

• Nature of the component and its use-cases
• How to build and run the component locally
• Configuration values like environment variables

Components:

• UI
• Cart
• Checkout
• Catalog
• Orders
• Assets

Currently Bootstrap is used to build the store UI. Migrate to Tailwind CSS to provide a fresher look.

The challenge with this is that Tailwind is not "natively" integrated in to Spring Boot so it would need an approach that either uses the Tailwind CLI to generate the final CSS or use something like the maven frontend plugin.

I have deployed this application on aws eks cluster, after some time I am getting below error in UI microservice pod

2023-08-24T22:59:04.921238623Z 2023-08-24T22:59:04.920Z ERROR 1 --- [tor-tcp-epoll-4] a.w.r.e.AbstractErrorWebExceptionHandler : [5acd6824-159902] 500 Server Error for HTTP GET "/home" 2023-08-24T22:59:04.921290963Z 2023-08-24T22:59:04.921297614Z org.springframework.web.reactive.function.client.WebClientResponseException$InternalServerError: 500 Internal Server Error from GET http://carts/carts/73763495-a13d-4269-879b-338c7d46c9f7 2023-08-24T22:59:04.921301724Z at org.springframework.web.reactive.function.client.WebClientResponseException.create(WebClientResponseException.java:330) ~[spring-webflux-6.0.11.jar!/:6.0.11] 2023-08-24T22:59:04.921307774Z Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 2023-08-24T22:59:04.921310804Z Error has been observed at the following site(s): 2023-08-24T22:59:04.921314094Z *__checkpoint ⇢ 500 INTERNAL_SERVER_ERROR from GET http://carts/carts/73763495-a13d-4269-879b-338c7d46c9f7 [DefaultWebClient] 2023-08-24T22:59:04.921316924Z *__checkpoint ⇢ Handler com.amazon.sample.ui.web.HomeController#home(Model, ServerHttpRequest) [DispatcherHandler] 2023-08-24T22:59:04.921319864Z *__checkpoint ⇢ com.amazon.sample.ui.web.util.SessionIDWebFilter [DefaultWebFilterChain] 2023-08-24T22:59:04.921323074Z *__checkpoint ⇢ org.springframework.web.filter.reactive.ServerHttpObservationFilter [DefaultWebFilterChain] 2023-08-24T22:59:04.921325664Z *__checkpoint ⇢ HTTP GET "/home" [ExceptionHandlingWebHandler]

There should be Terraform to create all the AWS infrastructure required to deploy the application on AWS App Runner.

This includes:

• An App Runner service per component
• The UI component as a public server
• The rest of the components as private services
• Initially using a single VPC as a "hub" to route traffic between the services as well as their dependencies

Architecture image

https://github.com/aws-containers/retail-store-sample-app/blob/main/docs/images/architecture.png

The Orders service is using PostgreSQL but not MySQL database.

To reduce the number of Java components in the architecture migrate the carts service to .NET Core.

Currently the NodeJs image uses the root user in the container.

https://github.com/aws-containers/retail-store-sample-app/blob/main/images/nodejs/Dockerfile

Update this to follow the other images which create an app user:

https://github.com/aws-containers/retail-store-sample-app/blob/main/images/java17/Dockerfile

There should be a terraform to create all the AWS infrastructure required to deploy applications on ECS.

Initial tasks:

• Potentially use ECS blueprints as a starting point to create the cluster
• Create RDS, RabbitMQ and other infrastructure required by the application components (re-use the existing EKS terraform library)
• Create IAM Roles, Task Definitions and Services for each component
• Choice between EC2/Fargate deployment models for services.

The Java components should be upgraded to Spring Boot 3, which provides better support for building native executables.

• UI
• Orders
• Cart

Migration guide: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide

Currently the catalog is immutable unless directly updating the SQL database. There are use-cases where it is valuable to be able to update the catalog, for example to show changes are persisted over database restarts.

Add API calls to the catalog API that allows products to be created and modified. This does not involve any UI work.

These are the steps I have followed:

• started a minikube cluster (checked it's running)
• applied the deploy.yaml file by running

kubectl apply -f https://raw.githubusercontent.com/aws-containers/retail-store-sample-app/main/dist/kubernetes/deploy.yaml
kubectl wait --for=condition=available deployments --all

• started the load generator pod by following the steps here

apiVersion: v1
kind: Pod
metadata:
  name: load-generator
spec:
  containers:
  - name: artillery
    image: artilleryio/artillery:2.0.0-31
    args:
    - "run"
    - "-t"
    - "http://ui.ui.svc"
    - "/scripts/scenario.yml"
    volumeMounts:
    - name: scripts
      mountPath: /scripts
  initContainers:
  - name: setup
    image: public.ecr.aws/aws-containers/retail-store-sample-utils:load-gen.0.3.0
    command:
    - bash
    args:
    - -c
    - "cp /artillery/* /scripts"
    volumeMounts:
    - name: scripts
      mountPath: "/scripts"
  volumes:
  - name: scripts
    emptyDir: {}
EOF

• ran the bash script bash src/load-generator/scripts/run.sh

It seems that the load is not being generated as I have run the micro-service (also the load-generator pod) for more than 5 hours now and the ui deployment log file has only ~70 lines with timestamps of the lines corresponding to the deployment start time.

Could someone tell me what files I have to edit to generate the load using the load generator pod that I created?
@niallthomson

Currently the load generator has no automated tests, which makes it difficult to verify changes and dependency updates.

Add automated tests to the load generator that can be run in CI. The tests should verify that:

1. Artillery runs and exits with an error code
2. A certain % of synthetic requests succeed with HTTP 200. This can likely start at 100% and then be adjusted based on how stable the scenarios are.

So far the ability to use anything from just the UI component all the way through to a fully distributed architecture with as many component as are necessary is largely undocumented. This feature makes the application useful for situations where simpler architecture are necessary and the full architecture may be over-complicated.

Create a tutorial that walks the user through:

1. Deploying just the UI component
2. Add the separate carts service (in-memory storage)
3. Add the catalog service with database

This should be done in Docker Compose to make it accessible to the most people.