{"id":18429128,"url":"https://github.com/openliberty/guide-cloud-openshift-operator","last_synced_at":"2025-04-07T17:32:47.286Z","repository":{"id":40380417,"uuid":"257316523","full_name":"OpenLiberty/guide-cloud-openshift-operator","owner":"OpenLiberty","description":"A guide on how to deploy microservices to Red Hat OpenShift by using Kubernetes Operators.","archived":false,"fork":false,"pushed_at":"2025-03-03T19:07:38.000Z","size":637,"stargazers_count":2,"open_issues_count":1,"forks_count":3,"subscribers_count":5,"default_branch":"prod","last_synced_at":"2025-03-22T21:51:12.692Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://openliberty.io/guides/cloud-openshift-operator.html","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/OpenLiberty.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-04-20T15:02:15.000Z","updated_at":"2025-03-03T19:07:43.000Z","dependencies_parsed_at":"2024-04-01T22:23:34.767Z","dependency_job_id":"7ea2f7e3-8428-485f-9f3d-a366d5b1521f","html_url":"https://github.com/OpenLiberty/guide-cloud-openshift-operator","commit_stats":null,"previous_names":[],"tags_count":6,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-openshift-operator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-openshift-operator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-openshift-operator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenLiberty%2Fguide-cloud-openshift-operator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/OpenLiberty","download_url":"https://codeload.github.com/OpenLiberty/guide-cloud-openshift-operator/tar.gz/refs/heads/prod","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247697945,"owners_count":20981277,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-06T05:15:56.934Z","updated_at":"2025-04-07T17:32:47.273Z","avatar_url":"https://github.com/OpenLiberty.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"// Copyright (c) 2020, 2025 IBM Corporation and others.\n// Licensed under Creative Commons Attribution-NoDerivatives\n// 4.0 International (CC BY-ND 4.0)\n//   https://creativecommons.org/licenses/by-nd/4.0/\n//\n// Contributors:\n//     IBM Corporation\n//\n:projectid: cloud-openshift-operator\n:page-layout: guide-multipane\n:page-duration: 30 minutes\n:page-releasedate: 2020-10-30\n:page-majorupdateddate: 2024-04-04\n:page-description: Explore how to deploy microservices to Red Hat OpenShift 4 using Kubernetes Operators like the Open Liberty Operator.\n:page-tags: ['kubernetes', 'docker', 'cloud'] \n:page-permalink: /guides/{projectid}\n:page-related-guides: ['cloud-openshift', 'okd']\n:common-includes: https://raw.githubusercontent.com/OpenLiberty/guides-common/prod\n:imagesdir: /img/guide/{projectid}\n:source-highlighter: prettify\n:page-seo-title: Deploying microservices to Red Hat OpenShift 4 using Kubernetes Operators\n:page-seo-description: A getting started tutorial with examples on how to deploy cloud-native Java applications and microservices to Red Hat OpenShift cluster by using Kubernetes Operators like the Open Liberty Operator.\n:guide-author: Open Liberty\n= Deploying microservices to OpenShift 4 using Kubernetes Operators\n\n[.hidden]\nNOTE: This repository contains the guide documentation source. To view the guide in published form, view it on the https://openliberty.io/guides/{projectid}.html[Open Liberty website^].\n\nExplore how to deploy microservices to Red Hat OpenShift 4 using Kubernetes Operators.\n\n== What you'll learn \n\nYou will learn how to deploy a cloud-native application with 2 microservices to Red Hat OpenShift 4 using Kubernetes Operators like the Open Liberty Operator. \nYou will install two operators into an OpenShift cluster and use them to deploy and scale sample microservices. \n\nhttps://www.openshift.com/[OpenShift^] is a Kubernetes-based platform with added functions. It streamlines the DevOps\nprocess by providing an intuitive development pipeline. It also provides integration with multiple tools to make the\ndeployment and management of cloud applications easier.\nYou can learn more about Kubernetes by checking out the https://openliberty.io/guides/kubernetes-intro.html[Deploying microservices to Kubernetes^] guide.\n\nhttps://kubernetes.io/docs/concepts/extend-kubernetes/operator/#operators-in-kubernetes[Kubernetes operators]\nprovide an easy way to automate the management and updating of applications by abstracting away some of the details of cloud application management.\nTo learn more about operators, check out this https://www.openshift.com/learn/topics/operators[Operators tech topic article^]. \n\nThe application in this guide consists of two microservices, `system` and `inventory`. Every 15 seconds, the `system`\nmicroservice calculates and publishes events that contain its current average system load. The `inventory` microservice\nsubscribes to that information so that it can keep an updated list of all the system microservices and their current system loads.\n\nThe following figure shows the application that you deploy, which consists of two microservices, `system` and `inventory`, connected by a message broker:\n\nimage::reactive-messaging-system-inventory-rest.png[Reactive system inventory,align=\"center\"]\n\nYou will deploy the two Open Liberty microservices by using the Open Liberty Operator, and deploy Kafka using the Strimzi Operator. \nThe https://github.com/OpenLiberty/open-liberty-operator[Open Liberty Operator^] provides a method of packaging,\ndeploying, and managing Open Liberty applications on Kubernetes-based clusters. \nThe Open Liberty Operator watches Open Liberty resources and creates various Kubernetes resources,\nincluding `Deployments`, `Services`, and `Routes`, depending on the configurations. \nThe Operator then continuously compares the current state of the resources, the desired state\nof application deployment, and reconciles them when necessary.\nTo learn more about the Strimzi Operator, visit their https://strimzi.io/[official website^].\nYou can learn more about how the reactive Java services used in this guide work by checking out the\nhttps://openliberty.io/guides/microprofile-reactive-messaging.html[Creating reactive Java microservices^] guide.\n\n== Additional prerequisites\n\nBefore you can deploy your microservices, you must gain access to a cluster on OpenShift and have an OpenShift client installed. \nFor client installation instructions, refer to https://docs.openshift.com/container-platform/latest/cli_reference/openshift_cli/getting-started-cli.html[the official OpenShift Online documentation^].\n\nThere are various OpenShift offerings. You can gain access to an OpenShift cluster that is hosted on\nhttps://www.openshift.com/products/openshift-ibm-cloud[IBM Cloud^], or check out other offerings\nhttps://www.openshift.com/products[from OpenShift^]. \n\nAfter you get access to a cluster, make sure you are logged in to the cluster\nas a cluster administrator by running the following command:\n\n[role='command']\n```\noc version\n```\n\nLook for output similar to the following example:\n\n[role='no_copy']\n```\nClient Version: 4.17.6\nServer Version: 4.17.3\nKubernetes Version: v1.30.5\n```\n\nBefore you install any resources, you need to create a project on your OpenShift cluster.\nCreate a project named `guide` by running the following command:\n\n[role='command']\n```\noc new-project guide\n```\n\nEnsure that you are working within the project `guide` by running the following command:\n\n[role='command']\n```\noc projects\n```\n\nLook for an asterisk (*) with the `guide` project in the list of projects to confirm that you are in the `guide` project, as shown in the following example:\n\n[role='no_copy']\n```\nYou have access to the following projects and can switch between them with 'oc project \u003cprojectname\u003e':\n\n    default\n  * guide\n```\n\nIf the https://cert-manager.io[cert-manager^]  is not installed on your cluster yet, install it by running the following command:\n[role='command']\n```\noc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.3/cert-manager.yaml\n```\nFor more information, see the https://cert-manager.io/docs/installation[cert-manager installation] documentation.\n\n// Getting Started block\n\n== Getting started\n\nThe fastest way to work through this guide is to clone the https://github.com/openliberty/guide-{projectid}.git[Git repository^]\ninto your cluster and use the projects that are provided inside:\n\n[source, role=\"command\", subs=\"attributes\"]\n----\ngit clone https://github.com/openliberty/guide-{projectid}.git\ncd guide-{projectid}\ncd start\n----\n\nThe `start` directory contains the starting project that you will build upon.\n\nThe `finish` directory contains the finished project that you will build.\n\n// no \"try what you'll build\" section in this guide because it would be too long due to all setup the user will have to do.\n\n== Installing the Operators\n\nWhen you obtained your OpenShift cluster, you received login information for the\nhttps://docs.openshift.com/container-platform/latest/web_console/web-console.html[OpenShift web console^].\nThe web console provides an interface to interact with your OpenShift cluster through your web browser.\n\nTo install the two Operators, navigate to the web console and select *Operators \u003e OperatorHub* from the sidebar menu.\nSearch for and install the *Open Liberty Operator* and the *Strimzi Operator*. For the Strimzi Operator, install the latest version, not the stable version.\nMake sure you install the Operators into the `guide` namespace. \n\nRun the following command to view all the supported API resources that are available through the Open Liberty Operator:\n\n[role='command']\n```\noc api-resources --api-group=apps.openliberty.io\n```\n\nLook for the following output, which shows the https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/[custom resource definitions^] (CRDs) that can be used by the Open Liberty Operator:\n\n[role='no_copy']\n```\nNAME                      SHORTNAMES         APIGROUP              NAMESPACED   KIND\nopenlibertyapplications   olapp,olapps       apps.openliberty.io   true         OpenLibertyApplication\nopenlibertydumps          oldump,oldumps     apps.openliberty.io   true         OpenLibertyDump\nopenlibertytraces         oltrace,oltraces   apps.openliberty.io   true         OpenLibertyTrace\n```\n\nEach CRD defines a kind of object that can be used, which is specified in the previous example by the `KIND` value.\nThe `SHORTNAME` value specifies alternative names that you can substitute in the configuration to refer to an object kind. \nFor example, you can refer to the `OpenLibertyApplication` object kind by one of its specified shortnames, such as `olapps`. \n\nThe `openlibertyapplications` CRD defines a set of configurations for\ndeploying an Open Liberty-based application, including the application image, number of instances, and storage settings.\nThe Open Liberty Operator watches for changes to instances of the `OpenLibertyApplication` object kind and creates Kubernetes resources that are based on the configuration that is defined in the CRD.\n\nRun the following command to all CRDs that the Strimzi Operator uses:\n\n[role='command']\n```\noc api-resources --api-group=kafka.strimzi.io\n```\n\nLook for the following output, which lists the CRDs that the Strimzi Operator uses, along with object kinds and shortnames.\n\n[role='no_copy']\n```\nNAME                 SHORTNAMES   APIGROUP           NAMESPACED   KIND\nkafkabridges         kb           kafka.strimzi.io   true         KafkaBridge\nkafkaconnectors      kctr         kafka.strimzi.io   true         KafkaConnector\nkafkaconnects        kc           kafka.strimzi.io   true         KafkaConnect\nkafkaconnects2is     kcs2i        kafka.strimzi.io   true         KafkaConnectS2I\nkafkamirrormaker2s   kmm2         kafka.strimzi.io   true         KafkaMirrorMaker2\nkafkamirrormakers    kmm          kafka.strimzi.io   true         KafkaMirrorMaker\nkafkarebalances      kr           kafka.strimzi.io   true         KafkaRebalance\nkafkas               k            kafka.strimzi.io   true         Kafka\nkafkatopics          kt           kafka.strimzi.io   true         KafkaTopic\nkafkausers           ku           kafka.strimzi.io   true         KafkaUser\n```\n\nYou can also confirm the installation of the operators from the web console.\nNavigate to the OperatorHub.\nFrom the categories on the left, you can filter to see only installed operators. \n\n\n== Deploying the Kafka cluster to OpenShift\n\n//File 0\nkafka.yaml\n[source, yaml, linenums, role='code_column']\n----\ninclude::finish/kafka.yaml[]\n----\n\nApache Kafka is the messaging broker that is used in this application. The Strimzi Operator simplifies the deployment\nand management of Kafka clusters. \n\nYou can configure the specifics of the Strimzi Operator-controlled Kafka deployment with a YAML configuration file.\n\nEnsure that you are in the `start` directory.\n\n[role=\"code_command hotspot file=0\", subs=\"quotes\"]\n----\n#Create the `kafka.yaml` configuration file in the `start` directory.#\n`kafka.yaml`\n----\n\nThe provided Kafka cluster configuration is based on the\nhttps://github.com/strimzi/strimzi-kafka-operator/blob/main/examples/kafka/kafka-ephemeral-single.yaml[Strimzi Kafka ephemeral single example^].\nFor more information about the Kafka configuration file, check out the\nhttps://strimzi.io/docs/operators/master/using.html#assembly-deployment-configuration-kafka-str[official Strimzi documentation^]\n\nRun the following command to deploy Kafka by using the newly created configuration file:\n\n[role='command']\n```\noc apply -f kafka.yaml\n```\n\nRun the following command to view the details of the deployment:\n\n[role='command']\n```\noc get kafka/kafka-cluster -o yaml\n```\n\nIn the `status` section under `conditions` you can see a report similar to the following example when the cluster is ready:\n\n[role='no_copy']\n```\n- lastTransitionTime: 2024-03-28T19:27:00+0000\n  status: \"True\"\n  type: Ready\n```\n\n== Deploying the system and inventory microservices to OpenShift\n\n//File 0\nbuild.yaml\n[source, yaml, linenums, role='code_column']\n----\ninclude::finish/build.yaml[]\n----\n\nTo deploy the `system` and `inventory` microservices, you must first package the microservices, then create and\nrun an OpenShift build to produce runnable container images of the packaged microservices.\n\n=== Packaging the microservices\n\nEnsure that you are in the `start` directory and run the following commands to package the `system` and `inventory`\nmicroservices:\n\n[role='command']\n```\nmvn -pl models clean install\nmvn clean package\n```\n\n=== Building and pushing the images\n\nCreate a build template to configure how to build your container images.\n\n[role=\"code_command hotspot file=0\", subs=\"quotes\"]\n----\n#Create the `build.yaml` template file in the `start` directory.#\n`build.yaml`\n----\n\nThe [hotspot file=0]`build.yaml` template includes two objects. \nThe [hotspot=imageStream file=0]`ImageStream` object provides an abstraction from the image in the image registry. \nThis allows you to reference and tag the image. \nThe image registry used is the integrated internal OpenShift Container Registry.\n\nThe [hotspot=buildConfig file=0]`BuildConfig` object defines a single\nbuild definition and any triggers that kickstart the build. The [hotspot=source file=0]`source` spec defines the build input. In this case,\nthe build inputs are your [hotspot=binary file=0]`binary` (local) files, which are streamed to OpenShift for the build.\nThe uploaded files need to include the packaged `WAR` application binaries, which is why you needed to run the Maven commands. The template specifies\na [hotspot=docker file=0]`Docker` strategy build, which invokes the `docker build` command, and creates a runnable container image of the microservice\nfrom the build input. The template is parameterized with the [hotspot=appname file=0]`APP_NAME` parameter so that you can use the same\ntemplate to create the objects for the `system` and `inventory` microservices separately.\n\nRun the following commands to create the objects for the `system` and `inventory` microservices:\n\n[role='command']\n```\noc process -f build.yaml -p APP_NAME=system | oc create -f -\noc process -f build.yaml -p APP_NAME=inventory | oc create -f -\n```\n\nNext, run the following commands to view the newly created `ImageStream` objects and the build configurations for each microservice:\n\n[role='command']\n```\noc get all -l name=system\noc get all -l name=inventory\n```\n\nLook for the following resources:\n\n[role='no_copy']\n```\nNAME                                                TYPE     FROM     LATEST\nbuildconfig.build.openshift.io/system-buildconfig   Docker   Binary   0\n\nNAME                                                IMAGE REPOSITORY                                                            TAGS           UPDATED\nimagestream.image.openshift.io/system-imagestream   image-registry.openshift-image-registry.svc:5000/guide/system-imagestream   1.0-SNAPSHOT   2 days ago\n\n...\n\nNAME                                                   TYPE     FROM     LATEST\nbuildconfig.build.openshift.io/inventory-buildconfig   Docker   Binary   2\n\nNAME                                                   IMAGE REPOSITORY                                                               TAGS           UPDATED\nimagestream.image.openshift.io/inventory-imagestream   image-registry.openshift-image-registry.svc:5000/guide/inventory-imagestream   1.0-SNAPSHOT   2 days ago\n```\n\nEnsure that you are in the `start` directory and trigger the builds by running the following commands:\n\n[role='command']\n```\noc start-build system-buildconfig --from-dir=system/.\noc start-build inventory-buildconfig --from-dir=inventory/.\n```\n\nThe local `system` and `inventory` directories are uploaded to OpenShift to be built into the Docker images. Run the\nfollowing command to list the builds and track their status:\n\n[role='command']\n```\noc get builds\n```\n\nLook for the output that is similar to the following example:\n\n[role='no_copy']\n```\nNAME                      TYPE     FROM             STATUS     STARTED\nsystem-buildconfig-1      Docker   Binary@f24cb58   Running    45 seconds ago\ninventory-buildconfig-1   Docker   Binary@f24cb58   Running    13 seconds ago\n```\n\nYou may need to wait some time until the build is complete. To check whether the build is complete, run the following\ncommands to view the build logs until the `Push successful` message appears:\n\n[role='command']\n```\noc logs build/system-buildconfig-1\noc logs build/inventory-buildconfig-1\n```\n\n=== Checking the images\n\nDuring the build process, the images associated with the `ImageStream` objects that you created earlier\nwere pushed to the image registry and tagged. Run the following command to view the newly updated `ImageStream` objects:\n\n[role='command']\n```\noc get imagestreams\n```\n\nRun the following commands to get more details on the newly pushed images within the streams:\n\n[role='command']\n```\noc describe imagestream/system-imagestream\noc describe imagestream/inventory-imagestream\n```\n\nThe following example shows part of the `system-imagestream` output:\n\n[role='no_copy']\n```\nName:                     system-imagestream\nNamespace:                guide\nCreated:                  2 minutes ago\nLabels:                   name=system\nAnnotations:              \u003cnone\u003e\nImage Repository:         image-registry.openshift-image-registry.svc:5000/guide/system-imagestream\nImage Lookup:             local=false\nUnique Images:            1\nTags:                     1\n\n...\n```\nLook for similar output for `inventory-imagestream`.\n\nNow you're ready to deploy the images.\n\n=== Deploying the images\n//File 0\ndeploy.yaml\n[source, yaml, linenums, role='code_column hide_tags=replicas']\n----\ninclude::finish/deploy.yaml[]\n----\n\nYou can configure the specifics of the Open Liberty Operator-controlled deployment with a YAML configuration file.\n\n[role=\"code_command hotspot file=0\", subs=\"quotes\"]\n----\n#Create the `deploy.yaml` configuration file in the `start` directory.#\n`deploy.yaml`\n----\n\nThe [hotspot file=0]`deploy.yaml` file is configured to deploy two [hotspot=olapp1 hotspot=olapp2 file=0]`OpenLibertyApplication`\nresources, [hotspot=system file=0]`system` and [hotspot=inventory file=0]`inventory`, which are controlled by\nthe Open Liberty Operator.\n\nThe [hotspot=sysImage hotspot=invImage file=0]`applicationImage` parameter defines what container image is deployed as part of the `OpenLibertyApplication` CRD. \nThis parameter follows the `\u003cproject-name\u003e/\u003cimage-stream-name\u003e[:tag]` format.\nThe parameter can also point to an image hosted on an external registry, such as Docker Hub. \nThe [hotspot=system file=0]`system` microservice is configured to use the [hotspot=sysImage file=0]`image` created from the earlier build. \n\nOne of the benefits of using `ImageStream` objects is that the operator redeploys the application when it detects a new image is pushed.\nThe [hotspot=systemEnv file=0]`env` parameter is used to specify environment variables that are passed to the container at runtime.\nYou need to specify the bootstrap address required to communicate with the deployed Kafka cluster as an environment variable.\n\nUpdate the [hotspot=bootstrap hotspot=bootstrapInv file=0]`[kafka-bootstrap-address]` variable to the\nbootstrap address found by running the following command:\n\n[role='command']\n```\noc describe kafka kafka-cluster | grep -B1 \"Name:\\s*plain\" | grep \"Bootstrap Servers:\" | awk '{print $3}'\n```\n\nYou will see output similar to the following example:\n\n[role='no_copy']\n```\nkafka-cluster-kafka-bootstrap.guide.svc:9092\n```\n\nThe [hotspot=inventory file=0]`inventory` microservice is configured\nsimilarly to the [hotspot=system file=0]`system` microservice.\nAdditionally, the `inventory` microservice includes the [hotspot=service file=0]`service`\nand [hotspot=expose file=0]`expose` parameters.\nThe [hotspot=servicePort file=0]`service.port` parameter specifies which port is exposed by the container,\nallowing the microservice to be accessed from outside the container.\nTo access the microservice from outside of the cluster,\nit must be exposed by setting the [hotspot=expose file=0]`expose` parameter to `true`.\nAfter you expose the microservice, the Operator automatically creates and configures routes for external access to your microservice.\n\nRun the following command to deploy the `system` and `inventory` microservices with the previously explained configurations:\n\n[role='command']\n```\noc apply -f deploy.yaml\n```\n\nNext, run the following command to view your newly created `OpenLibertyApplications` resources:\n\n[role='command']\n```\noc get OpenLibertyApplications\n```\n\nYou can also replace `OpenLibertyApplications` with the shortname `olapps`.\n\nLook for output that is similar to the following example:\n\n[role='no_copy']\n```\nNAME        IMAGE                                      EXPOSED   RECONCILED   AGE\ninventory   guide/inventory-imagestream:1.0-SNAPSHOT   true      True         10s\nsystem      guide/system-imagestream:1.0-SNAPSHOT                True         10s\n```\n\nA `RECONCILED` state value of `True` indicates that the operator was able to successfully process the `OpenLibertyApplications` instances. \nRun the following commands to view details of your microservices:\n\n[role='command']\n```\noc describe olapps/system\noc describe olapps/inventory\n```\n\nThis example shows part of the `olapps/system` output:\n\n[role='no_copy']\n```\nName:         system\nNamespace:    guide\nLabels:       app.kubernetes.io/part-of=system\n              name=system\nAnnotations:  kubectl.kubernetes.io/last-applied-configuration:\n                {\"apiVersion\":\"apps.openliberty.io/v1\",\"kind\":\"OpenLibertyApplication\",\"metadata\":{\"annotations\":{},\"labels\":{\"name\":\"system\"},\"name\":\"sys...\nAPI Version:  apps.openliberty.io/v1\nKind:         OpenLibertyApplication\n\n...\n```\n\nLook for a similar output for `olapps/inventory`.\n\n== Accessing the inventory microservice\n\nTo access the exposed `inventory` microservice, run the following command and make note of the `HOST`:\n\n[role='command']\n```\noc get routes\n```\n\nLook for an output that is similar to the following example:\n\n[role='no_copy']\n```\nNAME        HOST/PORT                                    PATH   SERVICES    PORT       TERMINATION   WILDCARD\ninventory   inventory-guide.apps.lights.os.fyre.ibm.com         inventory   9448-tcp                 None\n```\n\n\nVisit the `inventory` microservice by going to the following URL: \n`https://[HOST]/inventory/systems`\n\nMake sure to substitute the appropriate `HOST` value.\nFor example, using the output from the command above, `inventory-guide.apps.lights.os.fyre.ibm.com` is the `HOST`.\nThe following example shows this value substituted for `HOST` in the URL:\n`\\https://inventory-guide.apps.lights.os.fyre.ibm.com/inventory/systems`.\n\nLook for a JSON response that is similar to the following example: \n\n[role='no_copy']\n```\n[\n    {\n        \"hostname\": \"system-7cbc47455c-664wh\",\n        \"systemLoad\": 1.15\n    }\n]\n```\nThis sample output was formatted for readability. Your output might not be formatted.\n\n== Scaling up the system microservices\n\n//File 0\ndeploy.yaml\n[source, yaml, linenums, role='code_column']\n----\ninclude::finish/deploy.yaml[]\n----\n\nThe `inventory` microservice displays the `hostname` and `systemLoad` of all `system` microservices that are publishing\nmessages to the Kafka broker. Because only one `system` pod is running, only one element displays in the `inventory` microservice.\nScaling up microservices is easy with Operators. Simply update the `deploy.yaml` file with the `replica: n` parameter,\nwhere `n` is the number of instances that you want.\n\n[role=\"code_command hotspot file=0\", subs=\"quotes\"]\n----\n#Update the `deploy.yaml` configuration file in the `start` directory.#\n`deploy.yaml`\n----\n[role=\"edit_command_text\"]\nAdd the [hotspot=replicas file=0]`replicas` parameter to the `system` configuration.\n\nRun the following command to update the `system` resource:\n\n[role='command']\n```\noc apply -f deploy.yaml\n```\n\nLook for the following output:\n\n[role='no_copy']\n```\nopenlibertyapplications.apps.openliberty.io/system configured\nopenlibertyapplications.apps.openliberty.io/inventory unchanged\n```\n\nNotice that only the `system` resource was updated because there was a change in its specification. The `inventory`\nresource was left unchanged.\n\nRun the following command to see the newly scaled up `system` pods:\n\n[role='command']\n```\noc get pods\n```\n\nWhen you see a status of `Running` on all of the `system` pods, your application is ready. \nRevisit the `inventory` microservice and you can now see three instances of the `system` microservice listed in the `inventory` endpoint:\n\n[role='no_copy']\n```\n[\n    {\n        \"hostname\": \"system-5bb7b86fd5-b5plz\",\n        \"systemLoad\": 2.73\n    },\n    {\n        \"hostname\": \"system-5bb7b86fd5-fkd5j\",\n        \"systemLoad\": 2.95\n    },\n    {\n        \"hostname\": \"system-5bb7b86fd5-pgcbf\",\n        \"systemLoad\": 2.73\n    }\n]\n```\n\n== Tearing down the environment\n\nWhen you no longer need your project, switch to another project and delete the project `guide` by running the following command:\n\n[role='command']\n```\noc delete project guide\n```\n\nThis command deletes all the applications and resources.\n\n== Great work! You're done!\n\nYou just deployed two microservices running in Open Liberty to OpenShift by using the Open Liberty Operator.\n\n== Related Links\n\n// Multipane\ninclude::{common-includes}/attribution.adoc[subs=\"attributes\"]\n\n// DO NO CREATE ANYMORE SECTIONS AT THIS POINT\n// Related guides will be added in automatically here if you included them in \":page-related-guides\"\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenliberty%2Fguide-cloud-openshift-operator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenliberty%2Fguide-cloud-openshift-operator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenliberty%2Fguide-cloud-openshift-operator/lists"}