Red Hat OpenShift Application Runtimes 0.1 Eclipse Vert.x ... · PDF fileWhy Circuit Breaker...

Red Hat OpenShift ApplicationRuntimes 0.1

Eclipse Vert.x Runtime Guide

For Use with Red Hat OpenShift Application Runtimes

Last Updated: 2017-09-29

Red Hat OpenShift Application Runtimes 0.1 Eclipse Vert.x Runtime Guide

For Use with Red Hat OpenShift Application Runtimes

Legal Notice

Copyright © 2017 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinitylogo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and othercountries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related toor endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and other countriesand are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed orsponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Abstract

This guide provides details on using the Eclipse Vert.x runtime with Red Hat OpenShift ApplicationRuntimes.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table of Contents

PREFACE

CHAPTER 1. RUNTIME DETAILS

CHAPTER 2. MISSIONS2.1. REST API LEVEL 0 MISSION - ECLIPSE VERT.X BOOSTER

2.1.1. Building and Deploying the Booster2.1.1.1. Deploying the Booster to a Single-node OpenShift Cluster

2.1.1.1.1. Deploying Using developers.redhat.com/launch2.1.1.1.2. Deploying Using the oc CLI Client

2.1.1.2. Deploying your Booster to OpenShift Online2.1.2. Interacting with the Unmodified Eclipse Vert.x Booster2.1.3. REST Resources

2.2. CONFIGMAP MISSION - ECLIPSE VERT.X BOOSTER2.2.1. About ConfigMap2.2.2. Why ConfigMap is Important2.2.3. Building and Deploying the Booster

2.2.3.1. Deploying the Booster to a Single-node OpenShift Cluster2.2.3.1.1. Deploying Using developers.redhat.com/launch2.2.3.1.2. Deploying Using the oc CLI Client

2.2.3.2. Deploying your Booster to OpenShift Online2.2.4. Interacting with the Unmodified Eclipse Vert.x Booster2.2.5. Running Integration Tests2.2.6. ConfigMap Resources

2.3. RELATIONAL DATABASE BACKEND MISSION - ECLIPSE VERT.X BOOSTER2.3.1. Building and Deploying the Booster


2.3.1.2. Deploying your Booster to OpenShift Online2.3.2. Interacting with the Application API2.3.3. Running Integration Tests2.3.4. Relational Database Resources

2.4. HEALTH CHECK MISSION - ECLIPSE VERT.X BOOSTER2.4.1. Building and Deploying the Booster


2.4.1.2. Deploying your Booster to OpenShift Online2.4.2. Interacting with the Unmodified Eclipse Vert.x Booster2.4.3. Running Integration Tests2.4.4. Health Check Resources

2.5. CIRCUIT BREAKER MISSION - ECLIPSE VERT.X BOOSTER2.5.1. About Circuit Breaker2.5.2. Why Circuit Breaker is Important2.5.3. Building and Deploying the Booster


2.5.3.2. Deploying your Booster to OpenShift Online2.5.4. Interacting with the Unmodified Eclipse Vert.x Booster2.5.5. Running Integration Tests

4

5

667777999

101010111111111313141414161616161818192020212122222323252526262627272727292931

Table of Contents

1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.6. Using Hystrix Dashboard to Monitor the Circuit Breaker2.5.7. Circuit Breaker Resources

APPENDIX A. THE SOURCE-TO-IMAGE (S2I) BUILD PROCESS

APPENDIX B. BREAKDOWN OF POM COMPONENTS

APPENDIX C. ADDITIONAL RESOURCES

APPENDIX D. PROFICIENCY LEVELSFoundationalAdvancedExpert

APPENDIX E. GLOSSARYE.1. PRODUCT AND PROJECT NAMESE.2. TERMS SPECIFIC TO DEVELOPERS.REDHAT.COM/LAUNCH

3132

33

34

39

40404040

414141


2

Table of Contents

3

PREFACEThis guide covers concepts as well as practical details needed by developers to use the Eclipse Vert.xruntime.


4

CHAPTER 1. RUNTIME DETAILSEclipse Vert.x is a toolkit for writing reactive, non-blocking, asynchronous applications that run on theJVM. Eclipse Vert.x provides an unopinionated and flexible way to write polyglot applications that are fastand lightweight. Eclipse Vert.x is also designed to be truly cloud-native by efficiently allowing manyprocesses to switch between one or very few threads. This allows Eclipse Vert.x applications andservices to more effectively use their CPU quotas in cloud environments and avoids the unnecessaryoverhead caused when creating new threads. Check out Additional Resources for further reading onEclipse Vert.x.

Using the Eclipse Vert.x runtime in OpenShift makes it simpler and easier to build reactive systems withEclipse Vert.x. The Eclipse Vert.x runtime enables you to run Eclipse Vert.x applications and services inOpenShift while providing all the advantages and conveniences of the OpenShift platform such as rollingupdates, service discovery, and canary deployments. OpenShift also makes it easier for yourapplications to implement common microservice patterns such as ConfigMap, HealthCheck, CircuitBreaker, and Failover.

Eclipse Vert.x has a product version of its runtime that runs on OpenShift and is provided as part of aRed Hat subscription.

IMPORTANT

Eclipse Vert.x has a community version of its runtime that runs on OpenShift and isprovided outside of a Red Hat subscription.

CHAPTER 1. RUNTIME DETAILS

5

CHAPTER 2. MISSIONSMissions are working applications that showcase different fundamental pieces of building cloud nativeapplications and services, such as creating HTTP APIs, interoperating with a database, or implementingthe health check pattern. A booster is the implementation of a mission in a specific runtime. Boosters arepreconfigured, functioning applications based on a mission that demonstrate a fundamental aspect ofmodern application development running in an environment similar to production. Missions and boosterscan be used as a proof of technology demonstration, a teaching tool, or even a sandbox forunderstanding how to develop applications. They can also be updated or extended for your own usecase.

NOTE

Each mission has different boosters that show how to implement the same mission indifferent runtimes. For example, the REST API Level 0 mission has a Spring Boot Tomcatbooster, a Eclipse Vert.x booster, and a WildFly Swarm booster.

2.1. REST API LEVEL 0 MISSION - ECLIPSE VERT.X BOOSTER

Mission proficiency level: Foundational.

The REST API Level 0 Mission provides a basic example of mapping business operations to a remoteprocedure call endpoint over HTTP using a REST framework. This corresponds to Level 0 in theRichardson Maturity Model. Creating an HTTP endpoint using REST and its underlying principals todefine your API enables you to quickly prototype and design your API in a flexible manner. Morebackground information on REST is available in Section 2.1.3, “REST Resources”.

This is an introduction to the mechanics of opening a service that is called remotely. Specifically, thisbooster is an application that allows a user to:

Execute an HTTP GET request on the api/greeting endpoint.

Receive a response in JSON format with a payload consisting of the Hello, World! String.

Execute an HTTP GET request on the api/greeting endpoint while passing in a Stringargument. This uses the name request parameter in the query string.

Receive a response in JSON format with a payload of Hello, $name! with $name replaced bythe value of the name parameter passed into the request.

NOTE

To view the source code and README file of this booster, download and extract the ZIPfile with the booster. To get the download link of the ZIP file, follow the instructions in theUsing OpenShift to Create a Booster chapter of the Getting Started Guide.

Table 2.1. Design Tradeoffs


6

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-http-api-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/eclipse_vert.x_runtime_guide/#mission-http-api-vertx

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-http-api-wf-swarm

https://martinfowler.com/articles/richardsonMaturityModel.html#level0

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/getting_started_guide/#oso-create-booster

Pros Cons

Fast prototyping

Flexible API Design

HTTP endpoints allow clients to belanguage agnostic

As an application or service matures, theREST API Level 0 approach may not scalewell to properly support a clean API designor use cases involving databaseinteractions. Any operations involvingshared, mutable state must be integratedwith an appropriate backing datastore. Allrequests handled by an API designed in thismanner will be scoped only to the containerservicing the request. Therefore there is noguarantee that subsequent requests will beserved by the same container.

2.1.1. Building and Deploying the Booster

2.1.1.1. Deploying the Booster to a Single-node OpenShift Cluster

1. Before you can use a Single-node OpenShift Cluster, you need to have it installed, configured,and running. You can find more details in Install and Configure a Single-node OpenShift Cluster.

2. Once you have a Single-node OpenShift Cluster running, check the console output for the URLyou can use to access it.

Example Console Output from a Single-node OpenShift Cluster Startup

2.1.1.1.1. Deploying Using developers.redhat.com/launch

Once you have the developers.redhat.com/launch application installed and configured, navigate to it inyour Single-node OpenShift Cluster and use it to create and launch your booster.

2.1.1.1.2. Deploying Using the oc CLI Client

...-- Removing temporary directory ... OK-- Server Information ... OpenShift server started. The server is accessible via web console at: https://192.168.42.152:8443

You are logged in as: User: developer Password: developer

To login as administrator: oc login -u system:admin

CHAPTER 2. MISSIONS

7

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/install_and_configure_the_developers.redhat.comlaunch_application_on_a_single-node_openshift_cluster/#install-local-cloud

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/install_and_configure_the_developers.redhat.comlaunch_application_on_a_single-node_openshift_cluster/

IMPORTANT

You must still create a booster using the developers.redhat.com/launch application beforeyou can deploy it using the oc CLI client.

If you choose I will build and run locally, unzip the ZIP file you downloaded. If you choseUse OpenShift Online to build and deploy you need to clone the GitHub repository createdby developers.redhat.com/launch.

1. Get the command containing your authentication token for using the oc CLI client with yourSingle-node OpenShift Cluster account:

a. Click on the question mark icon in the top right-hand corner of the Web console, next to youruser name.

b. Select Command Line Tools in the drop-down menu.

c. Find the text box that contains the oc login … command with the hidden token, and clickthe button next to it to copy its content to your clipboard.

2. Paste the command you copied in the previous step into a terminal to authenticate your oc CLIclient with your Single-node OpenShift Cluster account by using your authentication token.

3. Create a new project in Single-node OpenShift Cluster.

4. Navigate to the root directory of your booster.

5. Use maven to start the deployment to Single-node OpenShift Cluster.

This command uses the Fabric8 Maven Plugin to launch the S2I process on Single-nodeOpenShift Cluster and to start the pod.

6. Check the status of your booster and ensure your pod is running.

You MY_APP_NAME-1-aaaaa pod should have a status of Running once its fully deployed andstarted.

7. Once your booster is deployed and started, determine its route.

Example Route Information

$ oc login OPENSHIFT_URL --token=MYTOKEN

$ oc new-project MY_PROJECT_NAME

$ mvn clean fabric8:deploy -Popenshift

$ oc get pods -wNAME READY STATUS RESTARTS AGEMY_APP_NAME-1-aaaaa 1/1 Running 0 58sMY_APP_NAME-s2i-1-build 0/1 Completed 0 2m


8

A pod’s route information gives you the base URL which you use to access it. In the exampleabove, you would use http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME as the base URL to access theapplication.

2.1.1.2. Deploying your Booster to OpenShift Online

Navigate to developers.redhat.com/launch and use it to create and launch your booster. You can alsouse the oc CLI Client to deploy a booster to OpenShift Online. To use the oc CLI Client with OpenShiftOnline, you follow the same steps as with your Single-node OpenShift Cluster but use the authenticationtoken and URL from the OpenShift Online Web Console.

2.1.2. Interacting with the Unmodified Eclipse Vert.x Booster

The booster provides a default HTTP endpoint that accepts GET requests.

1. Use curl to execute a GET request against the booster. You can also use a browser to do this.

2. Use curl to execute a GET request with the name URL parameter against the booster. You canalso use a browser to do this.

NOTE

From a browser you can also use a form provided by the booster to perform these sameinteractions. The form is located at the root of the project http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME.

2.1.3. REST Resources

More background and related information on REST can be found here:

Architectural Styles and the Design of Network-based Software Architectures - RepresentationalState Transfer (REST)

Richardson Maturity Model

$ oc get routesNAME HOST/PORT PATH SERVICES PORT TERMINATIONMY_APP_NAME MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME MY_APP_NAME 8080

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{ "content" : "Hello, World!"}

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting?name=Sarah{ "content" : "Hello, Sarah!"}

CHAPTER 2. MISSIONS

9

http://my_app_name-my_project_name.local_openshift_hostname

https://developers.redhat.com/launch


https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

https://martinfowler.com/articles/richardsonMaturityModel.html

JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

Some Rest with Eclipse Vert.x

REST API Level 0 Mission - Spring Boot Tomcat Booster

REST API Level 0 Mission - WildFly Swarm Booster

2.2. CONFIGMAP MISSION - ECLIPSE VERT.X BOOSTER


The ConfigMap Mission provides a basic example of using ConfigMap to take advantage of externalconfiguration sources. This mission shows you how to:

Setup and configuration of ConfigMap.

Use the configuration provided by ConfigMap within an application.

Deploy changes to ConfigMap to applications that are already running.

2.2.1. About ConfigMap

ConfigMap is an object used by OpenShift to inject configuration data as simple key and value pairs intoone or more Linux containers while keeping the containers agnostic of OpenShift. You can create aConfigMap object in a variety of different ways, including using a YAML file, and inject it into the Linuxcontainer. You can find more information about ConfigMap in the OpenShift documentation.

2.2.2. Why ConfigMap is Important

It is important for an application’s configuration to be externalized and separate from it’s code. Thisallows for the application’s configuration to change as it moves through different environments whileleaving the code unchanged. This also keeps sensitive or internal information out of your codebase andversion control. Many languages and application servers provide environment variables to supportexternalizing an application’s configuration. Microservices and Linux containers increase the complexityof this by adding pods, or groups of containers representing a deployment, and polyglot environments.ConfigMap enables application configuration to be externalized and used in individual Linux containersand pods in a language agnostic way. ConfigMap also allows sets of configuration data to be easilygrouped and scaled, which enables you to configure an arbitrarily large number of environments beyondthe basic Dev, Stage, and Production.

NOTE




10

https://www.jcp.org/en/jsr/detail?id=311

http://vertx.io/blog/some-rest-with-vert-x/

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-http-api-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-http-api-wf-swarm

https://docs.openshift.org/latest/dev_guide/configmaps.html


Pros Cons

Configuration is separate from deployments

Can be updated independently

Can be shared across services

Configuration is separate from deployments

Has to be maintained separately

Requires coordination beyond the scope ofa service









IMPORTANT






CHAPTER 2. MISSIONS

11








3. Create a new project in your Single-node OpenShift Cluster.

4. Assign view access rights to the service account before deploying your booster, so that thebooster can access the OpenShift API in order to read the contents of the ConfigMap.


6. Deploy your ConfigMap configuration to your Single-node OpenShift Cluster using app-config.yml.

7. Verify your ConfigMap configuration has been deployed.

8. Use Maven to start the deployment to your Single-node OpenShift Cluster.

This command uses the Fabric8 Maven Plugin to launch the S2I process on your Single-nodeOpenShift Cluster and to start the pod.




$ oc policy add-role-to-user view -n $(oc project -q) -z default

$ oc create configmap app-config --from-file=app-config.yml

$ oc get configmap app-config -o yaml

apiVersion: v1data: app-config.yml: |- message : "Hello, %s from a ConfigMap !" level : INFO...


$ oc get pods -wNAME READY STATUS


12

Your MY_APP_NAME-1-aaaaa pod should have a status of Running once its fully deployed andstarted. You should also wait for your pod to be ready before proceeding, which is shown in the READY column. For example, MY_APP_NAME-1-aaaaa is ready when the READY column is 1/1.







The booster provides a default HTTP endpoint that accepts GET requests.

1. Use curl to execute a GET request against the booster. You can also use a browser to do this.

2. Update the deployed ConfigMap configuration.

Change the value for the message key to Bonjour, %s from a ConfigMap ! and save thefile.

3. Update of the config map should be read by the application within an acceptable time (a fewseconds) without requiring a restart of the application.

RESTARTS AGEMY_APP_NAME-1-aaaaa 1/1 Running 0 58sMY_APP_NAME-s2i-1-build 0/1 Completed 0 2m


$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Hello, World from a ConfigMap !"}

$ oc edit configmap app-config

CHAPTER 2. MISSIONS

13



4. Use curl to execute a GET request against the booster with the updated ConfigMapconfiguration. You can also use a browser to do this.

You should see your updated greeting.

2.2.5. Running Integration Tests

This booster contains a set of integration tests. To run them, you must be connected to an OpenShiftinstance and select the project that will be used for testing.

To run the integration tests, execute the following command:

WARNING

Be sure that view access rights for service account are added before executingtests.

2.2.6. ConfigMap Resources

More background and related information on ConfigMap can be found here:

OpenShift ConfigMap Documentation

Blog Post about ConfigMap in OpenShift

External Configuration with Eclipse Vert.x

ConfigMap - Spring Boot Tomcat Booster

ConfigMap - WildFly Swarm Booster

2.3. RELATIONAL DATABASE BACKEND MISSION - ECLIPSE VERT.XBOOSTER

IMPORTANT

This booster is not currently available on OpenShift Online but you can still run it using aSingle-node OpenShift Cluster.

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Bonjour, World from a ConfigMap !"}

$ mvn clean verify -Popenshift,openshift-it

$ oc policy add-role-to-user view -n $(oc project -q) -z default


14

https://docs.openshift.org/latest/dev_guide/configmaps.html

https://blog.openshift.com/configuring-your-application-part-1/

http://vertx.io/docs/vertx-config/js/

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-configmap-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-configmap-wf-swarm


The Relational Database Backend booster expands on the REST API Level 0 booster to provide a basicexample of performing create, read, update and delete (CRUD) operations on a PostgreSQL databaseusing a simple HTTP API. CRUD operations are the four basic functions of persistent storage, widelyused when developing an HTTP API dealing with a database.

The booster also demonstrates the ability of the HTTP application to locate and connect to a database inOpenShift. Each runtime determines in an opinionated manner how to implement the connectivitysolution that is best suited in the given case. The runtime can choose between using JDBC, JPA, oraccess ORM APIs directly.

The booster application exposes an HTTP API, which provides endpoints that allow you to manipulatedata by performing CRUD operations over HTTP. The CRUD operations are mapped to HTTP Verbs.The API uses JSON formatting to receive requests and return responses to the user. The user can alsouse an UI provided by the booster to use the application. Specifically, this booster provides anapplication that allows you to:

Navigate to the application web interface in your browser. This exposes a simple websiteallowing you to perform CRUD operations on the data in the my_data database.

Execute an HTTP GET request on the api/fruits endpoint.

Receive a response formatted as a JSON array containing the list of all fruits in the database.

Execute an HTTP GET request on the api/fruits/* endpoint while passing in a valid item IDas an argument.

Receive a response in JSON format containing the name of the fruit with the given ID. If no itemmatches the specified ID, the call results in an HTTP error 404.

Execute an HTTP POST request on the api/fruits endpoint passing in a valid name value tocreate a new entry in the database.

Execute an HTTP PUT request on the api/fruits/* endpoint passing in a valid ID and aname as an argument. This updates the name of the item with the given ID to match the namespecified in your request.

Execute an HTTP DELETE request on the api/fruits/* endpoint, passing in a valid ID as anargument. This removes the item with the specified ID from the database and returns an HTTPcode 204 (No Content) as a response. If you pass in an invalid ID, the call results in an HTTPerror 404.

This booster also contains a set of automated integration test that can be used to verify that theapplication is fully integrated with the database.

This booster does not showcase a fully matured RESTful model (level 3), but it does use compatibleHTTP verbs and status, following the recommended HTTP API practices.

NOTE



CHAPTER 2. MISSIONS

15


Pros Cons

Each runtime decides how the databaseinteractions are implemented. One can useJDBC while others can use JPA or accessORM APIs directly. Each runtime decideswhat would be the best way.

Each runtime decides how the schema isgoing to be created.

The example PostgreSQL databaseprovided with the Relational DatabaseBackend Missions is not backed up withpersistent storage. Changes to the databaseare lost if you stop or redeploy the databaseapplication.









IMPORTANT







16










5. Deploy the PostgreSQL database to your Single-node OpenShift Cluster.

6. Check the status of your database and ensure the pod is running.

Your my-database-1-aaaaa pod should have a status of Running and should be indicated asready once it is fully deployed and started.




Your MY_APP_NAME-1-aaaaa pod should have a status of Running and should be indicated asready once it is fully deployed and started.



$ oc new-app -e POSTGRESQL_USER=luke -ePOSTGRESQL_PASSWORD=secret -ePOSTGRESQL_DATABASE=my_data openshift/postgresql-92-centos7 --name=my-database

$ oc get pods -wmy-database-1-aaaaa 1/1 Running 0 45smy-database-1-deploy 0/1 Completed 0 53s


$ oc get pods -wNAME READY STATUS RESTARTS AGEMY_APP_NAME-1-aaaaa 1/1 Running 0 58sMY_APP_NAME-s2i-1-build 0/1 Completed 0 2m

CHAPTER 2. MISSIONS

17






2.3.2. Interacting with the Application API

1. Once the application is running, you can access it using the application URL. To obtain the URL,execute the following command:

2. To access the web interface of the database application, navigate to the application URL in yourbrowser:

Alternatively, you can make requests directly on the api/fruits/* endpoint using curl:

List all entries in the database:

[ { "id" : 1, "name" : "Apple",}, { "id" : 2, "name" : "Orange",


oc get route MY_APP_NAME

NAME HOST/PORT PATH SERVICES PORT TERMINATIONMY_APP_NAME MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME MY_APP_NAME 8080

http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME

curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/fruits


18



}, { "id" : 3, "name" : "Pear",} ]

Retrieve an entry with a specific ID

{ "id" : 3, "name" : "Pear",}

Create a new entry:

{ "id" : 4, "name" : "apple",}

Update an Entry

{ "id" : 1, "name" : "pineapple",}

Delete an Entry:

If you receive an HTTP Error code 503 as a response after executing these commands, it means thatthe application is not ready yet.


This booster includes a self-contained set of integration tests. When you run the tests inside an emptyOpenShift project, they:

deploy a test instance of the application to the project,

curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/fruits/3

curl -H "Content-Type: application/json" -X POST -d '{"name":"apple"}' http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/fruits

curl -H "Content-Type: application/json" -X PUT -d '{"name":"pineapple"}' http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/fruits/1

curl -X DELETE http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/fruits/1

CHAPTER 2. MISSIONS

19

execute the individual tests on that instance,

remove the test instance of the application from the project when the testing is done.

Before running the tests, ensure that you:

are logged into your OpenShift account,

have selected a project within that account.

WARNING

Running the integration tests in an OpenShift project already containing an instanceof the tested application removes the pre-existing instance of the application fromthe project when the testing finishes.


2.3.4. Relational Database Resources

More background and related information on running relational databases in OpenShift, CRUD, HTTPAPI and REST can be found here:

HTTP Verbs

Architectural Styles and the Design of Network-based Software Architectures - RepresentationalState Transfer (REST)

The never ending REST API design debase

REST APIs must be Hypertext driven

Richardson Maturity Model

JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

Some Rest with Eclipse Vert.x

Using the Eclipse Vert.x asynchronous SQL client

Relational Database Backend Mission - Spring Boot Tomcat Booster

Relational Database Backend Mission - WildFly Swarm Booster

2.4. HEALTH CHECK MISSION - ECLIPSE VERT.X BOOSTER


mvn clean verify -Popenshift,openshift-it


20

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

https://speakerdeck.com/glaforge/the-never-ending-rest-api-design-debate

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

https://martinfowler.com/articles/richardsonMaturityModel.html

https://www.jcp.org/en/jsr/detail?id=311

http://vertx.io/blog/some-rest-with-vert-x/

http://vertx.io/blog/using-the-asynchronous-sql-client/

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-crud-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-crud-wf-swarm

When you deploy an application, its important to know if it is available and if it can start handlingincoming requests. Implementing the health check pattern allows you to monitor the health of anapplication, which includes if an application is available and whether it is able to service requests.

In order to understand the health check pattern, you need to first understand the following concepts:

Liveness

Liveness defines whether an application is running or not. Sometimes a running application movesinto an unresponsive or stopped state and needs to be restarted. Checking for liveness helpsdetermine whether or not an application needs to be restarted.

Readiness

Readiness defines whether a running application can service requests. Sometimes a runningapplication moves into an error or broken state where it can no longer service requests. Checkingreadiness helps determine whether or not requests should continue to be routed to that application.

Fail-over

Fail-over enables failures in servicing requests to be handled gracefully. If an application fails toservice a request, that request and future requests can then fail-over or be routed to anotherapplication, which is usually a redundant copy of that same application.

Resilience and Stability

Resilience and Stability enable failures in servicing requests to be handled gracefully. If an applicationfails to service a request due to connection loss, in a resilient system that request can be retried afterthe connection is re-established.

Probe

A probe is a Kubernetes action that periodically performs diagnostics on a running container.

The purpose of this use case is to demonstrate the health check pattern through the use of probing.Probing is used to report the liveness and readiness of an application. In this use case, you configure anapplication which exposes an HTTP health endpoint to issue HTTP requests. If the container is alive,according to the liveness probe on the health HTTP endpoint, the management platform receives 200as return code and no further action is required. If the health HTTP endpoint does not return aresponse, for example if the JVM is no longer running or a thread is blocked, then the application is notconsidered alive according to the liveness probe. In that case, the platform kills the pod corresponding tothat application and recreates a new pod to restart the application.

This use case also allows you to demonstrate and use a readiness probe. In cases where the applicationis running but is unable to handle requests, such as when the application returns an HTTP 503 responsecode during restart, this application is not considered ready according to the readiness probe. If theapplication is not considered ready by the readiness probe, requests are not routed to that applicationuntil it is considered ready according to the readiness probe.

NOTE





CHAPTER 2. MISSIONS

21








IMPORTANT















22




This command uses the Fabric8 Maven Plugin to launch the S2I process on Single-nodeOpenShift Cluster and to start the pod.


Your MY_APP_NAME-1-aaaaa pod should have a status of Running once it’s fully deployedand started. You should also wait for your pod to be ready before proceeding, which is shown inthe READY column. For example, PROJECT_NAME-1-aaaaa is ready when the READY columnis 1/1.



A pod’s route information gives you the base URL which you use to access it. In the exampleabove, you would use http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME as the base URL to access theapplications.




Once you have the Eclipse Vert.x booster deployed, you will have a service called MY_APP_NAMErunning that exposes the following REST endpoints:

/api/greeting

This endpoint returns a JSON containing greeting of name parameter (or World as default value).

/api/killme


$ oc get pods -wNAME READY STATUS RESTARTS AGEMY_APP_NAME-1-aaaaa 1/1 Running 0 14sMY_APP_NAME-1-deploy 0/1 Completed 0 22s

$ oc get routesNAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARDMY_APP_NAME MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME MY_APP_NAME 8080 None

CHAPTER 2. MISSIONS

23



This endpoint forces the service to become unresponsive which is meant to simulate a failure in theservice.

The following steps demonstrate how to verify the service availability and simulate a failure. This failureof an available service causes the OpenShift self-healing capabilities to be trigger on the service.

NOTE

The below steps use the command line to interact with the service. Alternatively, you canuse the web interface to perform the same steps (See #4).

1. Use curl to execute a GET request against the MY_APP_NAME service. You can also use abrowser to do this.

2. Invoke the /api/killme endpoint and verify the availability of the /api/greeting endpointshortly after that.Invoking the /api/killme endpoint simulates an internal service failure and triggers theOpenShift self-healing capabilities. When invoking /api/greeting after simulating the failure,the service should return a HTTP status 503.

3. Use oc get pods -w to continuously watch the self-healing capabilities in action.While invoking the service failure, you can watch the self-healing capabilities in action onOpenShift console, or with the oc client tools. You should see the number pods in a READY statemove to zero (0/1) and after a short period (less than one minute) move back up to one (1/1).In addition the RESTARTS count increases every time you you invoke the service failure.

4. Optional: Use the web interface to invoke the service.Alternatively to the interaction using the terminal window, you can use the web interfaceprovided by the service to invoke the different methods and watch the service move through thelife cycle phases.

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Hello, World!"}

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/killmeStopping HTTP server, Bye bye world !

(followed by)

$ curl http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greetingNot online

$ oc get pods -wNAME READY STATUS RESTARTS AGEMY_APP_NAME-1-26iy7 0/1 Running 5 18mMY_APP_NAME-1-26iy7 1/1 Running 5 19m

http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME


24

1. Optional: Use the web console to view the log output generated by the application at each stageof the self-healing process.

1. Navigate to your project.

2. On the sidebar, click on Monitoring.

3. In the upper right-hand corner of the screen, click on Events to display the log messages.

4. Optional: Click View Details to display a detailed view of the Event log.

The health check application generates the following messages:

Message Status

Unhealthy Readiness probe failed. This message is expectedand indicates that the simulated failure of the /api/greeting endpoint has been detected andthe self-healing process starts.

Killing The unavailable Docker container running the serviceis being killed before being re-created.

Pulling Downloading the latest version of docker image to re-create the container.

Pulled Docker image downloaded successfully.

Created Docker container has been successfully created

Started Docker container is ready to handle requests




2.4.4. Health Check Resources

More background and related information on health checking can be found here:

Overview of Application Health in OpenShift

Health Checking in Kubernetes

Kubernetes Liveness and Readiness Probes

Kubernetes Probes


CHAPTER 2. MISSIONS

25

https://docs.openshift.com/container-platform/latest/dev_guide/application_health.html

https://kubernetes.io/docs/user-guide/walkthrough/k8s201/#health-checking

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

https://kubernetes.io/docs/api-reference/v1/definitions/#_v1_probe

Health Check - Spring Boot Tomcat Booster

Health Check - WildFly Swarm Booster

2.5. CIRCUIT BREAKER MISSION - ECLIPSE VERT.X BOOSTER

IMPORTANT

This booster is not currently available on OpenShift Online but you can still run it using aSingle-node OpenShift Cluster.


The Circuit Breaker Mission demonstrates a generic pattern for reporting the failure of a service and thenlimiting access to the failed service until it becomes available to handle requests. This helps preventcascading failure in other services that depend on the failed services for functionality.

This mission shows you how to implement a Circuit Breaker and Fallback pattern in your services.

2.5.1. About Circuit Breaker

The Circuit Breaker is a pattern intended to mitigate the impact of network failure and high latency onservice architectures where services synchronously invoke other services. In such cases, if one of theservices becomes unavailable due to network failure or incurs unusually high latency values due tooverwhelming traffic, other services attempting to call its endpoint may end up exhausting criticalresources in an attempt to reach it, rendering themselves unusable. This condition is also known ascascading failure and can render the entire microservice architecture unusable.

Essentially, the Circuit Breaker acts as a proxy between a protected function and a remote function,which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and allfurther calls to the circuit breaker return with an error or a predefined fallback response, without theprotected call being made at all. The Circuit Breaker usually also contain an error reporting mechanismthat notifies you when the Circuit Breaker trips.

2.5.2. Why Circuit Breaker is Important

In an architecture where multiple services depend on each other for functionality, a failure in one servicecan rapidly propagate to its dependent services, causing the entire architecture to collapse.Implementing a Circuit Breaker pattern helps prevent this. With the Circuit Breaker pattern implemented,a service client invokes a remote service endpoint via a proxy at regular intervals. If the calls to theremote service endpoint fail repeatedly and consistently, the Circuit Breaker trips, making all calls to theservice fail immediately over a set timeout period and returns a predefined fallback response. When thetimeout period expires, a limited number of test calls are allowed to pass through to the remote service todetermine whether it has healed, or remains unavailable. If these test calls fail, the Circuit Breaker keepsthe service unavailable and keeps returning the fallback responses to incoming calls. If the test callssucceed, the Circuit Breaker closes, fully enabling traffic to reach the remote service again.

NOTE



26

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-health-check-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-health-check-wf-swarm



Pros Cons

Enables a service to handle the failure ofother services it invokes.

Optimizing the timeout values can bechallenging

Larger-than-necessary timeout valuesmay generate excessive latency.

Smaller-than-necessary timeout valuesmay introduce false positives.












CHAPTER 2. MISSIONS

27



IMPORTANT










5. Use Maven to start the deployment to your Single-node OpenShift Cluster.



Both the MY_APP_NAME-greeting-1-aaaaa and MY_APP_NAME-name-1-aaaaa podsshould have a status of Running once they are fully deployed and started. You should also waitfor your pods to be ready before proceeding, which is shown in the READY column. For example,




$ oc get pods -wNAME READY STATUS RESTARTS AGEMY_APP_NAME-greeting-1-aaaaa 1/1 Running 0 17sMY_APP_NAME-greeting-1-deploy 0/1 Completed 0 22sMY_APP_NAME-name-1-aaaaa 1/1 Running 0 14sMY_APP_NAME-name-1-deploy 0/1 Completed 0 28s


28

PROJECT_NAME-1-aaaaa is ready when the READY column is 1/1.



A pod’s route information gives you the base URL which you use to access it. In the exampleabove, you would use http://MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME as the base URL to access theapplications.




Once you have the Eclipse Vert.x booster deployed, you have the following services running:

MY_APP_NAME-name

Exposes the following endpoints:

the /api/name endpoint, which returns a name when this service is working, and an errorwhen this service is set up to demonstrate failure.

the /api/state endpoint, which controls the behavior of the /api/name endpoint anddetermines whether the service works correctly or demonstrates failure.

MY_APP_NAME-greeting

Exposes the following endpoints:

the /api/greeting endpoint that you can call to get a personalized greeting response.When you call the /api/greeting endpoint, it issues a call against the /api/nameendpoint of the MY_APP_NAME-name service as part of processing your request. The callmade against the /api/name endpoint is protected by the Circuit Breaker.

If the remote endpoint is available, it responds with an HTTP code 200 and you receive thefollowing greeting:

{"content":"Hello, World!"}

$ oc get routesNAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARDMY_APP_NAME-greeting MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME MY_APP_NAME-greeting 8080 NoneMY_APP_NAME-name MY_APP_NAME-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME MY_APP_NAME-name 8080 None

CHAPTER 2. MISSIONS

29



If the remote endpoint is unavailable, it responds with an HTTP code 500 and you receive apredefined fallback response:

{"content":"Hello, Fallback!"}

the /api/cb-state endpoint, which returns the state of the Circuit Breaker. The state canbe open or closed.

The following steps demonstrate how to verify the service availability, simulate a failure and receive afallback response.

NOTE

The following steps use the command line to interact with the service. Alternatively, youcan use the web interface to perform the same steps.

1. Use curl to execute a GET request against the MY_APP_NAME-greeting service. You canalso use the Invoke button in the web interface to do this.

2. To simulate the failure of the MY_APP_NAME-name service you can:

use the Toggle button in the web interface.

scale the number of replicas of the pod running the MY_APP_NAME-name service down to 0.

execute an HTTP PUT request against the /api/state endpoint of the MY_APP_NAME-name service to set its state to fail.

3. The Circuit Breaker state indicator in the web interface changes from CLOSED to OPEN and theCircuit Breaker issues the fallback response when you invoke the /api/greeting endpoint.

4. Restore the name MY_APP_NAME-name service to availability. To do this you can:

use the Toggle button in the web interface.

scale the number of replicas of the pod running the MY_APP_NAME-name service back up to1.

execute an HTTP PUT request against the /api/state endpoint of the MY_APP_NAME-name service to set its state back to ok.

$ curl http://MY_APP_NAME-greeting-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Hello, World!"}

$ curl -X PUT -H "Content-Type: application/json" -d '{"state": "fail"}' http://MY_APP_NAME-name-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/state

$ curl http://MY_APP_NAME-greeting-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Hello, Fallback!"}


30

5. Invoke the /api/greeting endpoint again. If the MY_APP_NAME-name service is available,you should receive the Hello World! greeting as the response:




2.5.6. Using Hystrix Dashboard to Monitor the Circuit Breaker

Hystrix Dashboard lets you easily monitor the health of your services in real time by aggregating Hystrixmetrics data from an event stream and displaying them on one screen. For more detail, see the HystrixDashboard wiki page.

NOTE

You must have the Circuit Breaker booster application deployed before proceeding withthe steps below.

1. Log in to your Single-node OpenShift Cluster cluster.

2. To access the Web console, use your browser to navigate to your Single-node OpenShift ClusterURL.

3. Navigate to the project that contains your Circuit Breaker application.

4. Import the YAML template for the Hystrix Dashboard application. You can do this by clickingAdd to Project, then selecting the Import YAML / JSON tab, and copying the contents of theYAML file into the text box. Alternatively, you can execute the following command.

5. Click the Create button to create the Hystrix Dashboard application based on the template.Alternatively, you can execute the following command.

$ curl -X PUT -H "Content-Type: application/json" -d '{"state": "ok"}' http://MY_APP_NAME-name-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/state

$ curl http://MY_APP_NAME-greeting-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME/api/greeting{"content":"Hello, World!"}



$ oc project MY_PROJECT_NAME

oc create -f https://raw.githubusercontent.com/snowdrop/openshift-templates/master/hystrix-dashboard/hystrix-dashboard.yml

CHAPTER 2. MISSIONS

31

https://github.com/Netflix/Hystrix/wiki/Dashboard

https://raw.githubusercontent.com/snowdrop/openshift-templates/master/hystrix-dashboard/hystrix-dashboard.yml

6. Wait for the pod containing Hystrix Dashboard to deploy.

7. Obtain the route of your Hystrix Dashboard application.

8. To access the Dashboard, open the Dashboard application route URL in your browser.Alternatively, you can navigate to the Overview screen in the Web console and click the routeURL in the header above the pod containing your Hystrix Dashboard application.

9. To use the Dashboard to monitor the MY_APP_NAME-greeting service, replace the defaultevent stream address with the following address and click the Monitor Stream button.

2.5.7. Circuit Breaker Resources

Follow the links below for more background information on the design principles behind the CircuitBreaker pattern

microservices.io: Microservice Patterns: Circuit Breaker

Martin Fowler: CircuitBreaker

Circuit Breaker Mission - Spring Boot Tomcat Booster

Circuit Breaker Mission - WildFly Swarm Booster

oc new-app --template=hystrix-dashboard

oc get route hystrix-dashboardNAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARDhystrix-dashboard hystrix-dashboard-MY_PROJECT_NAME.LOCAL_OPENSHIFT_HOSTNAME hystrix-dashboard <all> None

http://MY_APP_NAME-greeting/hystrix.stream


32

http://microservices.io/patterns/reliability/circuit-breaker.html

https://martinfowler.com/bliki/CircuitBreaker.html

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/spring_boot_tomcat_runtime_guide/#mission-circuit-breaker-spring-boot-tomcat

https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/0.1/html-single/wildfly_swarm_runtime_guide/#mission-circuit-breaker-wf-swarm

APPENDIX A. THE SOURCE-TO-IMAGE (S2I) BUILD PROCESSSource-to-Image (S2I) is a build tool that allows you to generate reproducible Docker-formatted containerimages from application sources hosted in an online SCM repository. With S2I builds you can easilydeliver the latest version of your application into production while achieving shorter build times,decreased resource and network usage, improved security and a number of advantages.

You need to provide three key elements as the input to the S2I process:

application sources (hosted in an online SCM repository, such as a Git Hub repo)

S2I scripts

the Builder image, which serves as the foundation for the assembled image and provides theecosystem within which your application is running

The process combines these inputs by injecting your application source and dependencies into theBuilder image according to instructions specified in the S2I script and generates a Docker-formattedcontainer image that runs the assembled application. For more detail, check the S2I build requirementsand build options sections of the OpenShift Container Platform documentation.

APPENDIX A. THE SOURCE-TO-IMAGE (S2I) BUILD PROCESS

33

https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/builds_and_image_streams.html#source-build

https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/builds_and_image_streams.html#source-build

https://docs.openshift.com/container-platform/3.4/creating_images/s2i.html#s2i-scripts

https://docs.openshift.com/container-platform/3.4/creating_images/s2i.html

https://docs.openshift.com/enterprise/3.0/dev_guide/builds.html#source-to-image-strategy-options

https://docs.openshift.com/container-platform/3.4/welcome/index.html

vertx-http-booster/pom.xml

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion>

<parent> 1 <groupId>io.openshift</groupId> <artifactId>booster-parent</artifactId> <version>4</version> </parent> <groupId>io.openshift.booster</groupId> <artifactId>http-vertx</artifactId> <version>7-SNAPSHOT</version> <packaging>jar</packaging>

<name>Vert.x - HTTP</name> <description>Exposes an HTTP API using Vert.x</description>

<properties> 2 <vertx.version>3.4.1</vertx.version> <vertx-maven-plugin.version>1.0.8</vertx-maven-plugin.version> <vertx.verticle>io.openshift.booster.HttpApplication</vertx.verticle> </properties>

<dependencyManagement> <dependencies> <dependency> <groupId>io.vertx</groupId>

<artifactId>vertx-dependencies</artifactId> 3 <version>${vertx.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

<dependencies> <dependency> <groupId>io.vertx</groupId>

<artifactId>vertx-core</artifactId> 4 </dependency> <dependency> <groupId>io.vertx</groupId>

<artifactId>vertx-web</artifactId> 5 </dependency>



<dependency> 6 <groupId>io.vertx</groupId> <artifactId>vertx-web-client</artifactId>


34

https://github.com/openshiftio-vertx-boosters/vertx-http-booster/blob/master/pom.xml

<scope>test</scope> </dependency> <dependency> <groupId>io.vertx</groupId> <artifactId>vertx-unit</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <dependency> <groupId>org.assertj</groupId> <artifactId>assertj-core</artifactId> <version>3.6.2</version> <scope>test</scope> </dependency> <dependency> <groupId>com.jayway.restassured</groupId> <artifactId>rest-assured</artifactId> <version>2.9.0</version> <scope>test</scope> </dependency> <dependency> <groupId>com.jayway.awaitility</groupId> <artifactId>awaitility</artifactId> <version>1.7.0</version> <scope>test</scope> </dependency> </dependencies>

<build> <plugins> <plugin> <groupId>io.fabric8</groupId>

<artifactId>vertx-maven-plugin</artifactId> 7 <version>${vertx-maven-plugin.version}</version> <executions> <execution> <id>vmp</id> <goals> <goal>initialize</goal> <goal>package</goal> </goals> </execution> </executions> <configuration> <redeploy>true</redeploy> </configuration> </plugin> </plugins>

<pluginManagement>


35

<plugins> <plugin> <groupId>org.eclipse.m2e</groupId>

<artifactId>lifecycle-mapping</artifactId> 8 <version>1.0.0</version> <configuration> <lifecycleMappingMetadata> <pluginExecutions> <pluginExecution> <pluginExecutionFilter> <groupId>io.fabric8</groupId> <artifactId>vertx-maven-plugin</artifactId> <versionRange>[1.0.6,)</versionRange> <goals> <goal>initialize</goal> </goals> </pluginExecutionFilter> <action> <ignore/> </action> </pluginExecution> </pluginExecutions> </lifecycleMappingMetadata> </configuration> </plugin> </plugins> </pluginManagement> </build>

<profiles> <profile>

<id>openshift</id> 9 <build> <plugins> <plugin> <groupId>io.fabric8</groupId> <artifactId>fabric8-maven-plugin</artifactId> <version>3.2.28</version> <executions> <execution> <id>fmp</id> <goals> <goal>resource</goal> <goal>build</goal> </goals> </execution> </executions> <configuration> <enricher> <includes> <include>vertx-health-check</include> </includes> <config> <vertx-health-check> <path>/</path> </vertx-health-check>


36

1

2

3

4

5

6

7

8

9

Parent POM which contains the necessary dependencies and the required versions for the boosterprojects.

Properties for setting the Eclipse Vert.x and Eclipse Vert.x Maven plugin version to use as well asthe name of the Eclipse Vert.x verticle.

BOM for building Eclipse Vert.x applications with Maven.

POM containing core functionality of Eclipse Vert.x. More details on the core components of EclipseVert.x are avialble in the Eclipse Vert.x documentation.

POM containing the components for building web applications with Eclipse Vert.x.

Various dependencies needed for testing the application. This includes several Eclipse Vert.xcomponents such as vertx-web-client and vertx-unit as well as other projects such as assertj forassertions, rest-assured for testing REST services, and awaitility for doing asynchronousoperations.

Vert.x Maven Plugin used for packaging and deploying Eclipse Vert.x applications

Lifecycle metadata that works with the Vert.x Maven Plugin for building and deploying theapplication.

The profile for building and deploying the booster to OpenShift. It uses the Fabric8 Maven Plugin(FMP) to build and deploy the application with the S2I Build Process.

</config> </enricher> </configuration> </plugin> </plugins> </build> </profile>

<profile>

<id>openshift-it</id> 10 <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles></project>


37

https://github.com/openshiftio/booster-parent/blob/master/pom.xml

https://github.com/vert-x3/vertx-dependencies/blob/master/pom.xml

https://github.com/eclipse/vert.x/blob/master/pom.xml

http://vertx.io/docs/vertx-core/java/

https://github.com/vert-x3/vertx-web/blob/master/pom.xml

http://vertx.io/docs/vertx-web-client/java/

http://vertx.io/docs/vertx-unit/java/

https://joel-costigliola.github.io/assertj/

https://github.com/rest-assured/rest-assured

https://github.com/awaitility/awaitility

https://vmp.fabric8.io

https://wiki.eclipse.org/M2E_compatible_maven_plugins

http://fabric8.io/gitbook/mavenPlugin.html

10 The profile for running integration tests when the application is deployed on OpenShift. Forexample, a test can require a database pod or a ConfigMap value.


38

APPENDIX C. ADDITIONAL RESOURCESEclipse Vert.x project

Eclipse Vert.x for Reactive Programming in Red Hat OpenShift Application Runtimes

Building Reactive Microservices in Java

Eclipse Vert.x Cheat Sheet for Developers

Eclipse Vert.x - From zero to (micro)-hero

Red Hat Summit 2017 Talk - Reactive Programming with Eclipse Vert.x

Red Hat Summit 2017 Breakout Session - Reactive Systems with Eclipse Vert.x and Red HatOpenShift

Live Coding Reactive Systems with Eclipse Vert.x and OpenShift

APPENDIX C. ADDITIONAL RESOURCES

39

http://vertx.io

http://middlewareblog.redhat.com/2017/05/04/vert-x-for-reactive-programming-in-red-hat-openshift-application-runtimes/

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

https://developers.redhat.com/promotions/vertx-cheatsheet/

http://escoffier.me/vertx-hol/#_vert_x

https://github.com/cescoffier/rhsummit17-reactive-programming-with-vertx/blob/master/reactive-programming-with-vertx.pdf

https://www.redhat.com/en/about/videos/reactive-systems-eclipse-vertx-and-red-hat-openshift

https://developers.redhat.com/blog/2017/06/21/live-coding-reactive-systems-weclipse-vert-x-and-openshift/

APPENDIX D. PROFICIENCY LEVELSEach mission available on developers.redhat.com/launch teaches you about certain topics, but requirescertain minimum knowledge, which varies by mission. For clarity, the minimum requirements andconcepts are organized in several proficiency levels. In addition to the levels described in this chapter,there can be additional requirements with each mission, specific to its aim or the technologies it uses.

FoundationalThe missions rated at Foundational proficiency generally require no prior knowledge of the subjectmatter; they provide general awareness and demonstration of key elements, concepts, and terminology.There are no special requirements except those directly mentioned in the description of the mission.

AdvancedWhen using Advanced missions, the assumption is that you are familiar with the common concepts andterminology of the subject area of the mission in addition to Kubernetes and OpenShift. You must also beable to perform basic tasks on your own, for example configure services and applications, or administernetworks. If a service is needed by the mission, but configuring it is not in the scope of the mission, theassumption is that you have the knowledge to to properly configure it, and only the resulting state of theservice is described in the documentation.

ExpertExpert missions require the highest level of knowledge of the subject matter. You are expected toperform many tasks based on feature-based documentation and manuals, and the documentation isaimed at most complex scenarios.


40

APPENDIX E. GLOSSARY

E.1. PRODUCT AND PROJECT NAMES

developers.redhat.com/launch

The web application you launch boosters with.

Single-node OpenShift Cluster

An OpenShift cluster running on your machine using Minishift.

E.2. TERMS SPECIFIC TO DEVELOPERS.REDHAT.COM/LAUNCH

Booster

An language-specific implementation of a particular mission on a particular runtime. Boosters arelisted in a booster catalog.For example, a booster is a web service with a REST API implemented using the WildFly Swarmruntime.

Booster Catalog

A Git repository that contains information about boosters.

Mission

An application specification, for example a web service with a REST API.Missions generally do not specify which language or platform they should run on; the description onlycontains the intended functionality.

Runtime

A platform that executes boosters. For example, WildFly Swarm or Eclipse Vert.x.

APPENDIX E. GLOSSARY

41

Red Hat OpenShift Application Runtimes 0.1 Eclipse Vert.x ... · PDF fileWhy Circuit Breaker...

Documents

Transcript of Red Hat OpenShift Application Runtimes 0.1 Eclipse Vert.x ... · PDF fileWhy Circuit Breaker...