fix images
@@ -24,7 +24,7 @@ This will tell Che that the project is a Maven-based project, and be able to res
|
||||
|
||||
The structure of the project can be seen in the project browser to the left of the code editor:
|
||||
|
||||
image::structure.png[structure,800]
|
||||
image::structure.png[structure,600]
|
||||
|
||||
The project has
|
||||
|
||||
@@ -78,9 +78,11 @@ It’s a very simple REST endpoint, returning "hello" to requests on `/hello`.
|
||||
Compared to vanilla JAX-RS, with Quarkus there is no need to create an `Application` class. It’s supported but not required. In addition, only one instance of the resource is created and not one per request. You can configure this using the different `*Scoped` annotations (`ApplicationScoped`, `RequestScoped`, etc).
|
||||
====
|
||||
|
||||
## Running the Application
|
||||
## Running the Application in Live Coding Mode
|
||||
|
||||
Now we are ready to run our application. In Che, select the _Command Palette_ by clicking on its icon in the upper right, and double-click on **Start Live Coding**:
|
||||
**Live Coding** (also referred to as _dev mode_) allows us to run the app and make changes on the fly. Quarkus will automatically re-compile and reload the app when changes are made. This is a powerful and effecient style of developing that you will use throughout the lab.
|
||||
|
||||
In Che, select the _Command Palette_ by clicking on its icon in the upper right, and double-click on **Start Live Coding**:
|
||||
|
||||
image::runlocally.png[runlocal,800]
|
||||
|
||||
@@ -101,9 +103,9 @@ You should see:
|
||||
2019-02-28 17:05:22,771 INFO [io.quarkus] (main) Installed features: [cdi, resteasy]
|
||||
----
|
||||
|
||||
Note the amazingly fast startup time! The app is now running "locally" (within the Che container in which the workspace is also running). Che also makes the app accessible from outside the container by creating a Route (ingress) that is displayed at the top of the Terminal window. Look for _Preview URL_:
|
||||
Note the amazingly fast startup time! The app is now running "locally" (within the Che container in which the workspace is also running). `localhost` refers to the Kubernetes pod, not "your" laptop (so therefore opening localhost:8080 in your browser will not do anything). To access applications from your laptop broweser, Che creates an Ingress (referred to as a _Route_ in OpenShift) that is displayed at the top of the Terminal window. Look for _Preview URL_:
|
||||
|
||||
image::previewurl.png[preview,800]
|
||||
image::previewurl.png[preview,900]
|
||||
|
||||
Click on this Preview link to open the link in a new tab, which will access the default Quarkus HTML page included in this app:
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ This will cause our new `GreetingResource` class to be instantiated and injected
|
||||
|
||||
You will get red error squigglies when you paste this code due to missing import statements:
|
||||
|
||||
image::importerror.png[error,500]
|
||||
image::importerror.png[error,800]
|
||||
|
||||
Use the _Assistant_ > _Organize Imports_ menu option to fix this and import the right classes. You may need to choose from multiple matches, e.g. make sure you choose to import `javax.ws.rs.PathParam` when fixing the missing `PathParam` import. In general, look for `javax` or other well-known names to import. If you get it wrong you'll find out soon enough.
|
||||
|
||||
|
||||
@@ -33,11 +33,11 @@ This will add the extension below to your `pom.xml`:
|
||||
</dependency>
|
||||
----
|
||||
|
||||
Next, Run the app once more by using the command palette and select **Start Live Coding** to start the app up in dev local mode. With no code, Quarkus still provides a default health check which may be enough for you if all you need is to know the app started. Try to access the `/health` endpoint on the Terminal:
|
||||
Next, Run the app once more by using the command palette and select **Start Live Coding** to start the app up in dev local mode. With no code, Quarkus still provides a default health check which may be enough for you if all you need is to know the app started. Try to access the `/health/ready` endpoint on the Terminal:
|
||||
|
||||
[source, sh, role="copypaste"]
|
||||
----
|
||||
curl http://localhost:8080/health
|
||||
curl http://localhost:8080/health/ready
|
||||
----
|
||||
|
||||
You'll see:
|
||||
@@ -51,7 +51,7 @@ You'll see:
|
||||
}
|
||||
----
|
||||
|
||||
This default health check will return success as long as the app is running - if it crashes, the health check will fail.
|
||||
This default health check will return success as long as the app is running - if it crashes, the health check will of course fail.
|
||||
|
||||
=== Add a probe
|
||||
|
||||
@@ -90,11 +90,11 @@ There are two types of probes in Quarkus apps (and Kubernetes):
|
||||
Readiness and liveness probes can be used in parallel for the same container. Using both can ensure that traffic does not reach a container that is not ready for it, and that containers are restarted when they fail.
|
||||
====
|
||||
|
||||
As we have started our Quarkus application in dev mode simply open a Terminal window and run:
|
||||
THanks to Live Coding mode, simply open a Terminal window and run:
|
||||
|
||||
[source, sh, role="copypaste"]
|
||||
----
|
||||
curl http://localhost:8080/health
|
||||
curl http://localhost:8080/health/ready
|
||||
----
|
||||
|
||||
The new health check procedure is now present in the `checks` array:
|
||||
@@ -147,13 +147,20 @@ public class DataHealthCheck implements HealthCheck {
|
||||
}
|
||||
----
|
||||
|
||||
If you rerun the health check procedure again by accessing the `/health` endpoint with `curl` you can see that the new health check Health check with data is present in the `checks` array. This check contains a new attribute called `data` which is a JSON object consisting of the properties we have defined in our health check procedure above.
|
||||
Access the liveness health checks:
|
||||
|
||||
[source, sh, role="copypaste"]
|
||||
----
|
||||
curl http://localhost:8080/health/live
|
||||
----
|
||||
|
||||
You can see that the new health check with data is present in the `checks` array. This check contains a new attribute called `data` which is a JSON object consisting of the properties we have defined in our health check procedure above.
|
||||
|
||||
== Negative Health Checks
|
||||
|
||||
In this section we create another health check which simulates a connection to an external service provider such as a database. For simplicity reasons, we only determine whether the database is accessible or not by a configuration property.
|
||||
In this section we create another health check which simulates a connection to an external service provider such as a database. For simplicity reasons, we'll use an `application.properties` setting to toggle the health check from `DOWN` to `UP`.
|
||||
|
||||
Let’s create our final health check procedure (another Liveness probe). Create another Java class `org.acme.people.health.DatabaseConnectionHealthCheck` with the following code:
|
||||
Create another Java class in the same package called `DatabaseConnectionHealthCheck` with the following code:
|
||||
|
||||
[source, java, role="copypaste"]
|
||||
----
|
||||
@@ -199,7 +206,14 @@ public class DatabaseConnectionHealthCheck implements HealthCheck {
|
||||
}
|
||||
----
|
||||
|
||||
If you now rerun the health check (by running the same `curl` command from before) the overall outcome should be `DOWN` and you should see in the `checks` array the newly added Database connection health check which is down and the error message explaining why it failed:
|
||||
Re-run the health check test:
|
||||
|
||||
[source, sh, role="copypaste"]
|
||||
----
|
||||
curl http://localhost:8080/health/live
|
||||
----
|
||||
|
||||
The overall outcome should be `DOWN` and you should see in the `checks` array the newly added Database connection health check which is down and the error message explaining why it failed:
|
||||
|
||||
[source,json]
|
||||
----
|
||||
@@ -212,11 +226,11 @@ If you now rerun the health check (by running the same `curl` command from befor
|
||||
},
|
||||
----
|
||||
|
||||
We shouldn’t leave this application with a health check in DOWN state. Because we are running Quarkus dev mode, add `database.up=true` to the end of the `src/main/resources/application.properties` file and rerun the health check again — it should be up again.
|
||||
We shouldn’t leave this application with a health check in DOWN state. Because we are running Quarkus dev mode, add `database.up=true` to the end of the `src/main/resources/application.properties` file and rerun the health check test again — it should be `UP`!
|
||||
|
||||
== Accessing liveness and readiness separately
|
||||
|
||||
Quarkus apps can access the two different types using two different endpoints. This is useful when configuring Kubernetes with probes which we'll do later, as it can access each separately (and configure each with different timeouts, periods, failure thresholds, etc). For example, You may want your Readiness probe to wait 30 seconds before starting, but Liveness should wait 2 minutes and only wait 10 seconds between retries.
|
||||
Quarkus apps can access the two different types using two different endpoints (`/health/live` and `/health/ready`). This is useful when configuring Kubernetes with probes which we'll do later, as it can access each separately (and configure each with different timeouts, periods, failure thresholds, etc). For example, You may want your Readiness probe to wait 30 seconds before starting, but Liveness should wait 2 minutes and only wait 10 seconds between retries.
|
||||
|
||||
Access the two endpoints. Each endpoint will only report on its specific type of probe:
|
||||
|
||||
|
||||
@@ -9,9 +9,7 @@ OpenShift is a commercially supported distribution of Kubernetes from Red Hat. T
|
||||
|
||||
Let's rebuild our native image with all our changes thus far. Using the Command Palette, select **Build Native Quarkus App** and wait 3-4 minutes for it to finish (this runs `mvn clean package -Pnative` under the hood).
|
||||
|
||||
As you recall, the output of this process is a native Linux binary. To package it as a Linux container, and store it in OpenShift's internal image registry, run the following command:
|
||||
|
||||
Now that we have our app built as a container, let's deploy it to our cluster.
|
||||
As you recall, the output of this process is a native Linux binary. Let's deploy it to our cluster.
|
||||
|
||||
== Login to OpenShift
|
||||
|
||||
@@ -46,6 +44,11 @@ Welcome! See 'oc help' to get started.
|
||||
|
||||
Congratulations, you are now authenticated to the OpenShift server.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
The login session might timeout after long periods of inactivity. If this happens, you'll get messages like `Error from server (Forbidden): xxxxx is forbidden: User "system:anonymous" cannot xxxxx`. Simply re-issue the above login command to re-establish a session.
|
||||
====
|
||||
|
||||
https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/[Namespaces]
|
||||
are a top level concept to help you organize your deployments and teams of developers. A
|
||||
namespace allows a community of users (or a user) to organize and manage
|
||||
|
||||
@@ -16,7 +16,17 @@ Retrieve the list of possible extensions using the Maven plugin. Run this in the
|
||||
mvn quarkus:list-extensions
|
||||
----
|
||||
|
||||
You can see the list of ~50 different extensions available to you.
|
||||
You can see the list of ~50 different extensions available to you in the output:
|
||||
|
||||
[source,none]
|
||||
----
|
||||
Current Quarkus extensions available:
|
||||
Agroal - Database connection pool quarkus-agroal
|
||||
Amazon DynamoDB quarkus-amazon-dynamodb
|
||||
Apache Kafka Client quarkus-kafka-client
|
||||
Apache Kafka Streams quarkus-kafka-streams
|
||||
Apache Tika quarkus-tika
|
||||
----
|
||||
|
||||
Adding an extension is simiarly easy. With Maven, you can add extensions using `mvn quarkus:add-extension -Dextensions="extension1,extension2,..."`. The extension name can be the maven groupId/artifactId name of the extension: e.g. `io.quarkus:quarkus-agroal`. But you can pass a partial name and Quarkus will do its best to find the right extension. For example, `agroal`, `Agroal` or `agro` will expand to `io.quarkus:quarkus-agroal`. If no extension is found or if more than one extensions match, you will see a warning and a list of possible matches in the command result.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 150 KiB After Width: | Height: | Size: 150 KiB |
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 290 KiB After Width: | Height: | Size: 254 KiB |
|
Before Width: | Height: | Size: 188 KiB After Width: | Height: | Size: 110 KiB |
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 77 KiB |