redhat-middleware-workshops/dg8-workshop

Source for the Red Hat Data Grid 8.0 workshop content repository

This is the Data Grid 8.2 workshop

The workshop can be deployed on Openshift 4.3+ cluster. It requires the DataGrid, CodeReady operators.

Contributing

Incase you find an issue; use the issues; Incase you want to fix an issue; create a PR to the development branch

Docs/Instructions

After you have cloned this repo. Head off to the docs directory and run the runFile.sh and head of to localhost:4000 to view the documentation.

Deployment

If you are looking to deploy this workshop on Openshift 4.3:

git clone https://github.com/redhat-cop/agnosticd

Request an Openshift 4.3 Workshop from rhpds. Once the environment is provisioned, you should receive an email with credentials and links to your environment.

If you have generated a password less private key, you might want to do something like this:

cat ~/.ssh/id_ansible.pub | ssh  [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Review the defaults variable file

• This file link:./defaults/main.yml[./defaults/main.yml] contains all the variables you need to define to control the deployment of your workload.
• The variable ocp_username is mandatory to assign the workload to the correct OpenShift user.
• A variable silent=True can be passed to suppress debug messages.
• You can modify any of these default values by adding -e "variable_name=variable_value" to the command line

Deploy a Workload with the ocp-workload playbook [Mostly for testing]

TARGET_HOST="bastion.cph-05c1.openshiftworkshop.com"
OCP_USERNAME="username"
WORKLOAD="ocp4-workload-jdg-workshop"
GUID=05c1
SSH_KEY=~/.ssh/id_rsa
AWS_REGION=us-east-1

# a TARGET_HOST is specified in the command line, without using an inventory file
ansible-playbook -i ${TARGET_HOST}, ./configs/ocp-workloads/ocp-workload.yml \
    -e"ansible_ssh_private_key_file=${SSH_KEY}" \
    -e"ansible_user=${OCP_USERNAME}" \
    -e"ocp_username=${OCP_USERNAME}" \
    -e"ocp_workload=${WORKLOAD}" \
    -e"silent=False" \
    -e"guid=${GUID}" \
    -e"aws_region=${AWS_REGION}" \
    -e"num_users=50" \
    -e"subdomain_base=${TARGET_HOST}" \
    -e"ACTION=create"

What does the installer do?

• Install CodeReady Workspace Operator in namespace codeready
• Creates project for each user e.g. user1-cache
• Creates codeready workspaces for each user and sets it with a Quarkus ready devfile.
• Installs DataGrid Operator and subscribes each user project to it.
• Create a guides project with the latest instruction guides for attendees

dg8-workshop's Issues

RFE: write more session data in session externalization lab

We should add a scenario e.g. shopping cart, to show case the Spring session support.
Also we should have an remote cache scenario so replicated sessions can be showcased. @danieloh30

Upgrade infra cluster to 4.7 and DG to 8.2

The underlying cluster needs to be updated to the latest 4.7 and use the latest Data Grid 8.2 (when it arrives)

New lab: Infinispan server tutorial

The server tutorial covers aspects like client listeners and queries which we should add to the labs.
https://infinispan.org/infinispan-server-tutorial/

Update CodeReady Operator Installation

Need to update the CodeReady Operator to use SSL by default.
This is due to issues e.g. cloning of repositories etc.

Add a section about appropriate use cases

Is your feature request related to a problem? Please describe.
Different modes of operation for caches have better or worse performance implications. For example, using Spring Session Remote Cache works best when the data being cached is minimal and comprised of simple data types. Conversely, for complex data types is often better to use JPA 2nd-layer caching or JCache APIs for larger or more complex object graphs.

Describe the solution you'd like
I would like to see a section which makes general recommendations on where and when to use different cache modes/implementations to maximize performance and resilience for different example use cases.

Describe alternatives you've considered
No other alternatives currently exist

Additional context
I have worked with a number of clients/customers in recent months who are using Remote Caches for Sessions and storing extremely large and complex object graphs in those session caches. This often leads to less than desirable performance outcomes for those use cases where if they had uses Remote Session Caching in conjunction with JPA 2nd-level caches and/or JCache it would have led to better outcomes.

Update workshop guides to RHDG 8.4

New lab: Add SQLCachestores

Add SQLStore into workshop labs from @karesti demo at infinispan-sqlstore-demo

RFE: Add Prometheus to Operator lab

We need to add Prometheus to showcase the new 8.0 capabilities.

Fix Typos in DG in 10 mins section

RFE: In the RemoteCache lab add section for looking at cache metrics in the console

In the remote cache lab we have the user open up the application and add games, but we never explore where the games are getting stored. In the previous lab we have the user open the data grid console but never walk them through it. Maybe we tie these together here and after adding some games via the UI, we bring the user to the Data Grid console and look at the caches/metrics/etc?

Stack trace in console

Describe the bug
Exposing stack traces in console could be problematic

Greetings,

We are security researchers and we are looking for insecure coding patterns and configurations in the microservice architecture repositories. In your repository, we have found instances of improper exception handling.

According to CWE, stack traces due to exception handling should not be printed. See https://cwe.mitre.org/

Source: https://github.com/RedHat-Middleware-Workshops/dg8-workshop/blob/master/dg8-quarkus-client-example/.mvn/wrapper/MavenWrapperDownloader.java

Fix: #19

I am interested to know if you agree with the findings. Any feedback is appreciated.

Showcase active/active deployment

This is a RFE to add an exercise to demonstrate DG's ability to do active/active deployments (possibly simulated on a single cluster since multi-cluster is difficult to setup). @sshaaf

Embedded Cache Lab - onStart method instantiates cache even though it has been Injected earlier

In ScoreService.java instructions ask to add

    @Inject
    EmbeddedCacheManager cacheManager; 

but in the onStart method, it is initialized to DefaultCacheManager

    void onStart(@Observes @Priority(value = 1) StartupEvent ev){
       cacheManager = new DefaultCacheManager(); // is this necessary? already injected the embedded cache