Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 5. Setting up HawtIO on OpenShift 4

Note

While HawtIO Online should be able to discover Fuse 7 apps, the Camel plugin that is included only supports Camel 4.x models. It is most likely unusable to manage Fuse 7 Camel routes with the HawtIO 4.

On OpenShift 4.x, setting up HawtIO involves installing and deploying it. The preferred mechanism for this installation is using the HawtIO Operator available from the OperatorHub (see Section 5.1, “Installing and deploying HawtIO on OpenShift 4.x by using the OperatorHub”). Optionally, you can customize role-based access control (RBAC) for HawtIO as described in Section 2.3, “Role-based access control for HawtIO on OpenShift 4.x”.

5.1. Installing and deploying HawtIO on OpenShift 4 by using the OperatorHub

The HawtIO Operator is provided in the OpenShift OperatorHub for the installation of HawtIO. To deploy HawtIO you will have to deploy an instance of the installed operator as well as a HawtIO Custom Resource (CR).

To install and deploy HawtIO:

  1. Log in to the OpenShift console in the web browser as a user with cluster admin access.
  2. Click Operators and then click OperatorHub.
  3. In the search field window, type HawtIO to filter the list of operators. Click HawtIO Operator.

  4. In the HawtIO Operator install window, click Install. The Create Operator Subscription form opens:

    1. For Update Channel, select stable-v1.

    2. For Installation Mode, accept the default (a specific namespace on the cluster).

      Note

      This mode determines what namespaces the operator will monitor for HawtIO CRs. This is different to what namespaces HawtIO will monitor when it is fully deployed. The latter can be configured via the HawtIO CR.

    3. For Installed Namespace, select the namespace in which you want to install HawtIO Operator.

    4. For the Update Approval, select Automatic or Manual to configure how OpenShift handles updates to HawtIO Operator.

      1. If the Automatic updates option is selected and a new version of HawtIO Operator is available, the OpenShift Operator Lifecycle Manager (OLM) automatically upgrades the running instance of HawtIO without human intervention;
      2. If the Manual updates option is selected and a newer version of an Operator is available, the OLM only creates an update request. A Cluster Administrator must then manually approve the update request to have HawtIO Operator updated to the new version.
  5. Click Install and OpenShift installs HawtIO Operator into the current namespace.
  6. To verify the installation, click Operators and then click Installed Operators. HawtIO should be visible in the list of operators.

  7. To deploy HawtIO by using the OpenShift web console:

    1. In the list of Installed Operators, under the Name column, click HawtIO Operator.
    2. On the Operator Details page under Provided APIs, click Create HawtIO.

    3. Accept the configuration default values or optionally edit them.

      1. For Replicas, to increase HawtIO performance (for example, in a high availability environment), the number of pods allocated to HawtIO can be increased;
      2. For RBAC (role-based access control), only specify a value in the Config Map field if you want to customize the default RBAC behaviour and if the ConfigMap file already exists in the namespace in which you installed HawtIO Operator
      3. For Nginx, see Performance tuning for HawtIO Operator installation

      4. For Type, specify either:

        1. Cluster: for HawtIO to monitor all namespaces on the OpenShift cluster for any HawtIO-enabled applications;
        2. Namespace: for HawtIO to monitor only the HawtIO-enabled applications that have been deployed in the same namespace.
    4. Click Create. The HawtIO Operator Details page opens and shows the status of the deployment.

  8. To open HawtIO:

    1. For a namespace deployment: In the OpenShift web console, open the project in which the HawtIO operator is installed, and then select Overview. In the Project Overview page, scroll down to the Launcher section and click the HawtIO link.
    2. For a cluster deployment, in the OpenShift web console’s title bar, click the grid icon. In the popup menu, under Red Hat Applications, click the HawtIO URL link.
    3. Log into HawtIO. An Authorize Access page opens in the browser listing the required permissions.
    4. Click Allow selected permissions. HawtIO opens in the browser and shows any HawtIO-enabled application pods that are authorized for access.
  9. Click Connect to view the monitored application. A new browser window opens showing the application in HawtIO.

5.2. Role-based access control for HawtIO on OpenShift 4

HawtIO offers role-based access control (RBAC) that infers access according to the user authorization provided by OpenShift. In HawtIO, RBAC determines a user’s ability to perform MBean operations on a pod.

For information on OpenShift authorization, see the Using RBAC to define and apply permissions section of the OpenShift documentation.

Role-based access is enabled by default when you use the Operator to install HawtIO on OpenShift. HawtIO RBAC leverages the user’s verb access on a pod resource in OpenShift to determine the user’s access to a pod’s MBean operations in HawtIO. By default, there are two user roles for HawtIO:

  1. admin: if a user can update a pod in OpenShift, then the user is conferred the admin role for HawtIO. The user can perform write MBean operations in HawtIO for the pod.
  2. viewer: if a user can get a pod in OpenShift, then the user is conferred the viewer role for HawtIO. The user can perform read-only MBean operations in HawtIO for the pod.

5.2.1. Determining access roles for HawtIO on OpenShift 4

HawtIO role-based access control is inferred from a user’s OpenShift permissions for a pod. To determine HawtIO access role granted to a particular user, obtain the OpenShift permissions granted to the user for a pod.

Prerequisites:

  • The user’s name
  • The pod’s name

Procedure:

  1. To determine whether a user has HawtIO admin role for the pod, run the following command to see whether the user can update the pod on OpenShift: 

    oc auth can-i update pods/<pod> --as <user>
  2. If the response is yes, the user has the admin role for the pod. The user can perform write operations in HawtIO for the pod.

  3. To determine whether a user has HawtIO viewer role for the pod, run the following command to see whether the user can get a pod on OpenShift: 

    oc auth can-i get pods/<pod> --as <user>
  4. If the response is yes, the user has the viewer role for the pod. The user can perform read-only operations in HawtIO for the pod. Depending on the context, HawtIO prevents the user with the viewer role from performing a write MBean operation, by disabling an option or by displaying an operation not allowed for this user message when the user attempts a write MBean operation.
  5. If the response is no, the user is not bound to any HawtIO roles and the user cannot view the pod in HawtIO.

5.2.2. Customizing role-based access to HawtIO on OpenShift 4

If you use the OperatorHub to install HawtIO, role-based access control (RBAC) is enabled by default. To customize HawtIO RBAC behaviour, before deployment of HawtIO, a ConfigMap resource (that defines the custom RBAC behaviour) must be provided. The name of this ConfigMap should be entered in the rbac configuration section of the HawtIO Custom Resource (CR).

The custom ConfigMap resource must be added in the same namespace in which the HawtIO Operator has been installed.

Prerequisite:

  • The HawtIO Operator has been installed from the OperatorHub.

Procedure:

To customize HawtIO RBAC roles:

  1. Create an RBAC ConfigMap:

    1. Make sure the current OpenShift project is the project to which you want to install HawtIO. For example, to install HawtIO in the hawtio-test project, run this command: 

      oc project hawtio-test

    2. Create a HawtIO RBAC ConfigMap file from the template, and run this command: 

      oc process -f https://raw.githubusercontent.com/hawtio/hawtio-online/2.x/docker/ACL.yaml -p APP_NAME=custom-hawtio | oc create -f -

    3. Edit the new custom ConfigMap, using the command: 

      oc edit ConfigMap custom-hawtio-rbac
    4. By saving the edits, the ConfigMap resource will be updated
  2. Create a new HawtIO CR, as described above, and edit the rbac section by adding the name of the new ConfigMap under the property configMap.
  3. Click Create. The operator should deploy a new version of HawtIO making use of the custom ConfigMap

5.3. Migrating from Fuse Console

The version of the HawtIO Custom Resource Definition (CRD) has been upgraded in HawtIO from v1alpha1 to v1. This means that upon install of the HawtIO operator, all existing Fuse-Console Custom Resources (CRs) will be upgraded to this new version. The current schema properties of the CRD remain unchanged.

The CRD version property remains in the CRD but is no longer used by the HawtIO operator for installing HawtIO; it remains so that the Fuse-Console operator is still able to install Fuse-Console correctly.

HawtIO and Fuse-Console should perform as separate and independent applications.

5.4. Upgrading HawtIO on OpenShift 4

Red Hat OpenShift 4.x handles updates to operators, including HawtIO operators. For more information see the Operators OpenShift documentation. In turn, the operator updates will trigger application upgrades, depending on how the application is configured.

5.5. Tuning the performance of HawtIO on OpenShift 4

By default, HawtIO uses the following Nginx settings:

  • clientBodyBufferSize: 256k
  • proxyBuffers: 16 128k
  • subrequestOutputBufferSize: 10m
Note

For descriptions of these settings, see the Nginx documentation.

To tune the performance of HawtIO, you can set any of the clientBodyBufferSize, proxyBuffers, and subrequestOutputBufferSize environment variables. For example, if you are using HawtIO to monitor numerous pods and routes (for instance, 100 routes in total), you can resolve a loading timeout issue by setting HawtIO’s subrequestOutputBufferSize environment variable between 60m to 100m.

5.5.1. Performance tuning for HawtIO Operator installation

On Openshift 4.x, you can set the Nginx performance tuning environment variables before or after you deploy HawtIO. If you do so afterwards, OpenShift redeploys HawtIO.

Prerequisite:

  • You must have cluster admin access to the OpenShift cluster.

Procedure:

You can set the environment variables before or after you deploy HawtIO.

  1. To set the environment variables before deploying HawtIO:

    1. In the OpenShift web console, in a project that has HawtIO Operator installed, select Operators> Installed Operators> HawtIO Operator.
    2. Click the HawtIO tab, and then click Create HawtIO.
    3. On the Create HawtIO page, in the Form view, scroll down to the Config> Nginx section.

    4. Expand the Nginx section and then set the environment variables. For example:

      1. clientBodyBufferSize: 256k
      2. proxyBuffers: 16 128k
      3. subrequestOutputBufferSize: 100m
    5. Click Create to deploy HawtIO.
    6. After the deployment completes, open the Deployments> HawtIO-console page, and then click Environment to verify that the environment variables are in the list.

  2. To set the environment variables after you deploy HawtIO:

    1. In the OpenShift web console, open the project in which HawtIO is deployed.
    2. Select Operators> Installed Operators> HawtIO Operator.
    3. Click the HawtIO tab, and then click HawtIO.
    4. Select Actions> Edit HawtIO.
    5. In the Editor window, scroll down to the spec section.

    6. Under the spec section, add a new nginx section and specify one or more environment variables, for example: 

      apiVersion: hawt.io/v1
kind: Hawtio
metadata:
  name: hawtio-console
spec:
  type: Namespace
  nginx:
    clientBodyBufferSize: 256k
    proxyBuffers: 16 128k
    subrequestOutputBufferSize: 100m
    7. Click Save. OpenShift redeploys HawtIO.
    8. After the redeployment completes, open the Workloads> Deployments> HawtIO-console page, and then click Environment to see the environment variables in the list.

5.5.2. Performance tuning for viewing applications on HawtIO

Enhanced performance tuning capability of HawtIO allows viewing of the applications with a large number of MBeans. To use this capability perform the following steps.

Prerequisite:

  • You must have cluster admin access to the OpenShift cluster.

Procedure:

Increase the memory limit for the applications.

  1. To increase the memory limits after deploying HawtIO:

    1. In the OpenShift web console, open the project in which HawtIO is deployed.
    2. Select Operators> Installed Operators> HawtIO Operator.
    3. Click the HawtIO tab, and then click HawtIO.
    4. Select Actions> Edit HawtIO.
    5. In the Editor window, scroll down to the spec.resources section.
    6. Update the values for both requests and limits to preferred amounts
    7. Click Save
    8. HawtIO should re-deploy using the new resource specification.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.