diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml index f25ba18..94ab196 100644 --- a/.github/workflows/docs.yml +++ b/.github/workflows/docs.yml @@ -6,6 +6,7 @@ on: - "rhds" - "6.5" - "6.7" + - "6.8" env: SITE_DIR: "gh-pages" jobs: diff --git a/documentation/modules/ROOT/assets/images/che-login.png b/documentation/modules/ROOT/assets/images/che-login.png index 4d0cd41..d79303f 100644 Binary files a/documentation/modules/ROOT/assets/images/che-login.png and b/documentation/modules/ROOT/assets/images/che-login.png differ diff --git a/documentation/modules/ROOT/assets/images/config-psql-secret.png b/documentation/modules/ROOT/assets/images/config-psql-secret.png index ee20616..c488468 100644 Binary files a/documentation/modules/ROOT/assets/images/config-psql-secret.png and b/documentation/modules/ROOT/assets/images/config-psql-secret.png differ diff --git a/documentation/modules/ROOT/assets/images/developer-console-button.png b/documentation/modules/ROOT/assets/images/developer-console-button.png index 2b76f8f..a64854a 100644 Binary files a/documentation/modules/ROOT/assets/images/developer-console-button.png and b/documentation/modules/ROOT/assets/images/developer-console-button.png differ diff --git a/documentation/modules/ROOT/assets/images/login-with-openshift.png b/documentation/modules/ROOT/assets/images/login-with-openshift.png index d270983..770b364 100644 Binary files a/documentation/modules/ROOT/assets/images/login-with-openshift.png and b/documentation/modules/ROOT/assets/images/login-with-openshift.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-add-database.png b/documentation/modules/ROOT/assets/images/openshift-add-database.png index e635f62..8c616d1 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-add-database.png and b/documentation/modules/ROOT/assets/images/openshift-add-database.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-add-from-git.png b/documentation/modules/ROOT/assets/images/openshift-add-from-git.png index e6fbefc..8e08e15 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-add-from-git.png and b/documentation/modules/ROOT/assets/images/openshift-add-from-git.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-create-configmap.png b/documentation/modules/ROOT/assets/images/openshift-create-configmap.png index 2997626..0ce2d73 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-create-configmap.png and b/documentation/modules/ROOT/assets/images/openshift-create-configmap.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-empty-project.png b/documentation/modules/ROOT/assets/images/openshift-empty-project.png index 7c87fd5..4dfa659 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-empty-project.png and b/documentation/modules/ROOT/assets/images/openshift-empty-project.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-inventory-delete-pod.png b/documentation/modules/ROOT/assets/images/openshift-inventory-delete-pod.png index 7a05c1e..8314ee7 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-inventory-delete-pod.png and b/documentation/modules/ROOT/assets/images/openshift-inventory-delete-pod.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-inventory-topology.png b/documentation/modules/ROOT/assets/images/openshift-inventory-topology.png index 62a9926..250a0e1 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-inventory-topology.png and b/documentation/modules/ROOT/assets/images/openshift-inventory-topology.png differ diff --git a/documentation/modules/ROOT/assets/images/openshift-pod-details.png b/documentation/modules/ROOT/assets/images/openshift-pod-details.png index 6828624..ba922e6 100644 Binary files a/documentation/modules/ROOT/assets/images/openshift-pod-details.png and b/documentation/modules/ROOT/assets/images/openshift-pod-details.png differ diff --git a/documentation/modules/ROOT/pages/app-config.adoc b/documentation/modules/ROOT/pages/app-config.adoc index 3d6a74a..bf381ff 100644 --- a/documentation/modules/ROOT/pages/app-config.adoc +++ b/documentation/modules/ROOT/pages/app-config.adoc @@ -25,7 +25,7 @@ configuration files and command line arguments. These configuration artifacts should be externalized from the application and the container image content in order to keep the image portable across environments. -OpenShift provides a mechanism called https://docs.openshift.com/container-platform/4.12/welcome/index.html[**ConfigMaps**^] +OpenShift provides a mechanism called https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/nodes/working-with-pods#configmaps[**ConfigMaps**^] in order to externalize configurations from the applications deployed within containers and provide them to the containers in a unified way as files and environment variables. OpenShift also offers a way to @@ -51,26 +51,27 @@ a persistent storage that survives the container itself. You can deploy database regardless of what happens to the container itself, the data is safe and can be used by the next database container. -Let's create a https://docs.openshift.com/container-platform/4.12/welcome/index.html[MariaDB database^] +Let's create a https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/creating-applications[MariaDB database^] for the **Inventory Service** using the MariaDB template that is provided out-of-the-box: [TIP] ==== -https://docs.openshift.com/container-platform/4.12/openshift_images/using-templates.html[OpenShift Templates^] use YAML/JSON to compose +https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/creating-applications[OpenShift Templates^] use YAML/JSON to compose multiple containers and their configurations as a list of objects to be created and deployed at once, making it simple to re-create complex deployments by just deploying a single template. Templates can be parameterized to get input for fields like service names and generate values for fields like passwords. ==== -In the OpenShift Web Console, `*click on '+Add' and select 'Database'*` +In the OpenShift Web Console `*click on the 'Home' menu, and choose 'Software Catalog'*` +and then select `*Databases*` within the catalog. -image::openshift-add-database.png[OpenShift - Add database, 700] +image::openshift-add-database.png[OpenShift - Add database, 800] `*Select 'MariaDB (Ephemeral)' and click on 'Instantiate Template'*` Then, enter the following information: -.Inventory Database +.Inventory Database - MariaDB (Ephemeral) [%header,cols=2*] |=== |Parameter @@ -109,12 +110,12 @@ Then, enter the following information: image::openshift-inventory-mariadb-topology.png[OpenShift - Inventory MariaDB, 700] -`*Now click again on '+Add' and select 'Database', select 'PostgreSQL (Ephemeral)' and click on 'Instantiate Template'*` +Now select again from the `*'Software Catalog'*`, this time choose `*'PostgreSQL (Ephemeral)' and click on 'Instantiate Template'*` to create the Catalog Database as follows: Then, enter the following information: -.Catalog Database +.Catalog Database - PostgreSQL (Ephemeral) [%header,cols=2*] |=== |Parameter @@ -215,7 +216,7 @@ parameters unchanged. They will be overridden later. Now, let's create the Quarkus configuration content using the database credentials. -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console from the `*Workloads*` menu `*click on 'Config Maps' then click on the 'Create Config Map' button*`. image::openshift-create-configmap.png[Che - OpenShift Create Config Map, 900] @@ -317,7 +318,7 @@ configuration using an alternative **application.properties** backed by a config Let's create the Spring Boot configuration content using the database credentials and create the Config Map. -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console, from the `*Workloads*` menu, `*click on 'Config Maps' then click on the 'Create Config Map' button*`. image::openshift-create-configmap.png[Che - OpenShift Create Config Map, 900] @@ -429,7 +430,7 @@ credentials to simplify the steps; however, for production environments, you sho secure way to handle sensitive data. Fortunately, OpenShift already provides a secure mechanism for handling sensitive data which is -called https://docs.openshift.com/container-platform/4.12/welcome/index.html[**Secrets**^]. Secret objects act and are used +called https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/nodes/working-with-pods#nodes-pods-secrets[**Secrets**^]. Secret objects act and are used similarly to config maps however with the difference that they are encrypted as they travel over the wire and also at rest when kept on a persistent disk. Like config maps, secrets can be injected into containers as environment variables or files on the filesystem using a temporary file-storage @@ -471,9 +472,9 @@ This secret has three encrypted properties defined as **database-name**, **datab the PostgreSQL database name, username and password values. These values are injected in the PostgreSQL container as environment variables and used to initialize the database. -In the OpenShift Web Console, from the **Developer view**, +In the {OPENSHIFT_CONSOLE_URL}[OpenShift Web Console^, role='params-link'], from the `*Workloads*` `*Topology*` menu, `*click on 'DC catalog-postgresql' -> 'DC catalog-postgresql' -> 'Environment'*`. Notice the values -from the secret are defined as env vars on the deployment: +from the secret are defined as environment variables on the deployment: image::config-psql-secret.png[Secrets as Env Vars,900] @@ -484,7 +485,7 @@ Having made all those changes with adding databases and the application configur test that the Coolstore application still works. Just like you did a couple of chapters ago you need to use the topology display in the web console. -In the OpenShift Web Console, from the **Developer view**, +In the {OPENSHIFT_CONSOLE_URL}[OpenShift Web Console^, role='params-link'] from the `*Workloads*` `*Topology*` menu, `*click on the 'Open URL' icon of the Web Service*` image::openshift-web-topology.png[OpenShift - Web Topology, 700] diff --git a/documentation/modules/ROOT/pages/app-health.adoc b/documentation/modules/ROOT/pages/app-health.adoc index 1728a23..738964d 100644 --- a/documentation/modules/ROOT/pages/app-health.adoc +++ b/documentation/modules/ROOT/pages/app-health.adoc @@ -26,7 +26,7 @@ Furthermore, there are of course a category of issues that can't be resolved by In those scenarios, OpenShift would remove the faulty container from the built-in load-balancer and send traffic only to the healthy containers that remain. -There are three types of health probes available in OpenShift: https://docs.openshift.com/container-platform/4.12/applications/application-health.html#application-health-about_application-health[startup, readiness and liveness probes^]. +There are three types of health probes available in OpenShift: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/application-health[startup, readiness and liveness probes^]. * **Startup probes** determine if the container in which it is scheduled is started * **Readiness probes** determine if the container in which it is scheduled is ready to service requests @@ -38,7 +38,7 @@ order to remove downtime during deployments. A readiness health probe would sign traffic from the old version of the container to the new version so that the users don't get affected during deployments. -There are https://docs.openshift.com/container-platform/4.12/applications/application-health.html#application-health-about_types_application-health[three ways to define a health probe^] for a container: +There are three ways to define a health probe for a container: * **HTTP Checks:** healthiness of the container is determined based on the response code of an HTTP endpoint. Anything between 200 and 399 is considered success. A HTTP check is ideal for applications @@ -60,7 +60,7 @@ start listening until initialization is complete. By default Pods are designed to be resilient, if a pod dies it will get restarted. Let's see this happening. -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console under the Workloads menu `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Resources' -> 'P inventory-coolstore-x-xxxxx'*` image::openshift-inventory-pod.png[OpenShift Inventory Pod, 700] @@ -129,7 +129,7 @@ image::che-inventory-traffic.png[Che - Catalog Traffic OK, 500] Now let's scale out your _Inventory Service_ to 2 instances. -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console under the Workloads menu, `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Details' then click once on the up arrows on the right side of the pod blue circle*`. @@ -147,7 +147,7 @@ In order to prevent this behaviour, a **Readiness check** is needed. It determin If the readiness probe fails, the endpoints controller ensures the container has its IP address removed from the endpoints of all services. A readiness probe can be used to signal to the endpoints controller that even though a container is running, it should not receive any traffic from a proxy. -First, scale down your _Inventory Service_ to 1 instance. In the OpenShift Web Console, from the **Developer view**, +First, scale down your _Inventory Service_ to 1 instance. In the OpenShift Web Console, under the Workloads menu, `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Details' then click once on the down arrows on the right side of the pod blue circle*`. @@ -236,7 +236,7 @@ You should have the following output: } ---- -In the OpenShift Web Console, from the **Developer view**, +In the In the OpenShift Web Console under the Workloads menu, `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Add Health Checks'*`. image::openshift-inventory-add-health-check.png[Che - Inventory Add Health Check, 700] @@ -330,8 +330,7 @@ Now repeat the same task for the *Inventory* service, but this time set the *Rea |=== -Finally `*click on the check icon and the 'Add' button*`. OpenShift automates deployments using -https://docs.openshift.com/container-platform/4.12/welcome/index.html[deployment triggers^] +Finally `*click on the check icon and the 'Add' button*`. OpenShift automates deployments using *deployment triggers* that react to changes to the container image or configuration. Therefore, as soon as you define the probe, OpenShift automatically redeploys the pod using the new configuration including the liveness probe. @@ -378,7 +377,7 @@ You should have the following output: Liveness and Readiness health checks values have already been set for this service as part of the build and deploying using Eclipse JKube in combination with the Spring Boot actuator. -You can check this in the OpenShift Web Console, from the **Developer view**, +You can check this in the OpenShift Web Console, under the Workloads menu, `*click on 'Topology' -> '(D) catalog-coolstore' -> 'Actions' -> 'Edit Health Checks'*`. image::openshift-catalog-edit-health.png[Che - Catalog Add Health Check, 700] @@ -490,18 +489,19 @@ gain visibility into how the application behaves and particularly in identifying OpenShift provides container metrics out-of-the-box and displays how much memory, cpu and network each container has been consuming over time. +// +//In the OpenShift Web Console +//`*click on 'Observe' then select your 'my-project{USER_ID}' project*`. +// +//In the project overview, you can see the different **Resource Usage** sections. +//`*click on one graph to get more details*`. +// +//image::openshift-monitoring.png[OpenShift Monitoring,740] +// +From the Workloads menu, `*click on 'Topology' -> any Deployment (D) and click on the associated Pod (P)*` + +In the pod `*Metrics*` tab, you can see a more detailed view of the pod consumption. -In the OpenShift Web Console, from the **Developer view**, -`*click on 'Observe' then select your project*`. - -In the project overview, you can see the different **Resource Usage** sections. -`*click on one graph to get more details*`. - -image::openshift-monitoring.png[OpenShift Monitoring,740] - -From the **Developer view**, `*click on 'Topology' -> any Deployment (D) and click on the associated Pod (P)*` - -In the pod overview, you can see a more detailed view of the pod consumption. The graphs can be found under the Metrics heading, or Details in earlier versions of the OpenShift console. image::openshift-pod-details.png[OpenShift Pod Details,740] diff --git a/documentation/modules/ROOT/pages/catalog-spring-boot.adoc b/documentation/modules/ROOT/pages/catalog-spring-boot.adoc index 57c3035..d95ac1c 100644 --- a/documentation/modules/ROOT/pages/catalog-spring-boot.adoc +++ b/documentation/modules/ROOT/pages/catalog-spring-boot.adoc @@ -445,7 +445,7 @@ containers for the project. [#test_your_service] == Test your Service -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console, `*click on the 'Open URL' icon of the Catalog Service*` image::openshift-catalog-topology.png[OpenShift - Catalog Topology, 700] diff --git a/documentation/modules/ROOT/pages/developer-workspace.adoc b/documentation/modules/ROOT/pages/developer-workspace.adoc index 8846d12..77196f0 100644 --- a/documentation/modules/ROOT/pages/developer-workspace.adoc +++ b/documentation/modules/ROOT/pages/developer-workspace.adoc @@ -153,7 +153,7 @@ web proxies etc. If you are using a corporate device you may need to switch to a === I've been timed out or need to restart the workspace -The workshop will take a few hours to complete all the way through, if you use the system continuosly throughout +The workshop will take a few hours to complete all the way through, if you use the system continously throughout that period you will not see this issue. *Timed-out and wont reconnect* diff --git a/documentation/modules/ROOT/pages/inventory-quarkus.adoc b/documentation/modules/ROOT/pages/inventory-quarkus.adoc index f0c0d2d..d1d4f71 100644 --- a/documentation/modules/ROOT/pages/inventory-quarkus.adoc +++ b/documentation/modules/ROOT/pages/inventory-quarkus.adoc @@ -471,7 +471,7 @@ it’s time to deploy your service on OpenShift using all that information in th we saw earlier. In this section you will locally build a .jar file, then *create* the OpenShift build and deployment components -and *push* the .jar it to OpenShift. The OpenShift https://docs.openshift.com/container-platform/4.12/cicd/builds/understanding-image-builds.html[Source-to-Image (S2I)^] builder +and *push* the .jar it to OpenShift. The OpenShift https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/builds_using_buildconfig/understanding-image-builds.html[Source-to-Image (S2I)^] builder will then package the .jar file into a container and run it. [source,java,subs="{markup-in-source}"] @@ -625,7 +625,7 @@ in one or more pods. A pod is the unit of runtime deployment and consists of the [#test_your_service] == Test your Service -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console, `*click on the 'Open URL' icon of the Inventory Service*` image::openshift-inventory-topology.png[OpenShift - Inventory Topology, 700] diff --git a/documentation/modules/ROOT/pages/webui-deployment.adoc b/documentation/modules/ROOT/pages/webui-deployment.adoc index 48b19a0..2d4c254 100644 --- a/documentation/modules/ROOT/pages/webui-deployment.adoc +++ b/documentation/modules/ROOT/pages/webui-deployment.adoc @@ -39,16 +39,16 @@ The Web UI is built using Node.js for server-side JavaScript and AngularJS for c JavaScript. Let's deploy it on OpenShift using the certified Node.js container image available in OpenShift. -In this lab, again you will use OpenShift https://docs.openshift.com/container-platform/4.12/cicd/builds/understanding-image-builds.html[Source-to-Image (S2I)^]. +In this lab, again you will use OpenShift https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/builds_using_buildconfig/understanding-image-builds.html[Source-to-Image (S2I)^]. OpenShift will obtain the application code directly from the source repository then build and deploy a container image of it. For a change, rather than using the CLI option you will start this process from the web console. -In the OpenShift Web Console, from the **Developer view**, -`*click on '+Add' and select 'Import from Git'*` +In the OpenShift Web Console, +`*click on '(+)' and select 'Import from Git'*` -image::openshift-add-from-git.png[OpenShift - Add from Git, 700] +image::openshift-add-from-git.png[OpenShift - Add from Git, 800] Then, enter the following information: @@ -100,7 +100,7 @@ the web application pod will not be ready until the blue ring goes dark blue. [#test_your_service] == Test your Service -In the OpenShift Web Console, from the **Developer view**, +In the OpenShift Web Console, `*click on the 'Open URL' icon of the Web Service*` image::openshift-web-topology.png[OpenShift - Web Topology, 700] diff --git a/site.yml b/site.yml index d894670..cfc12f3 100644 --- a/site.yml +++ b/site.yml @@ -10,7 +10,7 @@ content: sources: - url: git@github.com:redhat-scholars/inner-loop-guide.git tags: [] - branches: ["rhds", "6.5", "6.7"] + branches: ["rhds", "6.5", "6.7", "6.8"] start_path: documentation asciidoc: