Exploring Alternate Configuration Options

8 Exploring Alternate Configuration Options

The ASAP cloud native toolkit provides samples and documentation for setting up your ASAP cloud native environment using standard configuration options. However, you can choose to explore alternate configuration options for setting up your environment, based on your requirements. This chapter describes alternate configurations you can explore, allowing you to decide how best to configure your ASAP cloud native environment to suit your needs.

You can choose alternate configuration options for the following:

The sections that follow provide instructions for working with these configuration options.

Choosing Worker Nodes for Running ASAP Cloud Native

By default, ASAP cloud native has its pods scheduled on all worker nodes in the Kubernetes cluster in which it is installed. However, in some situations, you may want to choose a subset of nodes where pods are scheduled.

For example, these situations include:

Non-license restrictions: Limitation on the deployment of ASAP on specific worker nodes per each team for reasons such as capacity management, chargeback, budgetary reasons, and so on.

To choose a subset of nodes where pods are scheduled, you can use the configuration in the asap-cntk/charts/asap/values.yaml file.

# If ASAP cloud native instances must be targeted to a subset of worker nodes in the
# Kubernetes cluster, tag those nodes with a label name and value, and choose
# that label+value here.
#   key    : any node label key
#   values : list of values to choose the node.
#            If any of the values is found for the above label key, then that
#            node is included in the pod scheduling algorithm.
#
# This can be overriden in instance specification if required.
nodeSelector: {} # This empty declaration should be removed if adding items here.
#asapcnTargetNodes:
#  nodeLabel:
##   oracle.com/licensed-for-coherence is just an indicative example, any label and its values can be used for choosing nodes.
#    key: oracle.com/licensed-for-coherence
#    values:
#      - true

Consider the following when you update the configuration:

There is no restriction on the node label key. Any valid node label can be used.
There can be multiple valid values for a key.

Working with Ingress, Ingress Controller, and External Load Balancer

A Kubernetes ingress is responsible for establishing access to back-end services. However, creating an ingress is not sufficient. An Ingress controller connects the back-end services with the front-end services based on Ingress rules. In ASAP cloud native, you can configure an ingress controller in the asap-cntk/charts/asap/values.yaml file. For example,

# valid values are TRAEFIK, GENERIC, OTHER
ingressController: "TRAEFIK"

The Traefik ingress controller works by creating an operator in its own "traefik" name space and exposing a NodePort service. However, all ingress controllers do not behave the same way. To accommodate all types of ingress controllers, by default, the values.yaml file provides the loadBalancerPort parameter.

If an external load balancer is used, it needs to be connected to the NodePort service of the Ingress controller. Hence, externalLoadBalancerIP also needs to be present in the values.yaml file.

For the Traefik ingress controller, do the following:

If an external load balancer is not configured, fetch loadBalancerPort by running the following command:
```
$kubectl -n $TRAEFIK_NS get service traefik-operator --output=jsonpath="{..spec.ports[?(@.name=='http')].nodePort}"
```
If an external load balancer is used, fetch loadBalancerPort by running the following command:
```
kubectl -n $TRAEFIK_NS get service traefik-operator --output=jsonpath="{..spec.ports[?(@.name=='http')].port}"
```

Populate the values in the values.yaml file before invoking create-instance.sh command to create an instance:

# If external hardware or software load balancer is used, set this value to that frontend host IP.
# If OCI load balancer is used, then set externalLoadBalancerIP from OCI LBaaS
#externalLoadBalancerIP: ""
 
# For Traefik Ingress Controller:
# If external load balancer is used, then this would be 80, else traefik pod's Nodeport (30305)
loadBalancerPort: 80

Note:

If you choose Traefik or any other ingress controller such as GENERIC or OTHER you can update the ingress: section in the asap_cntk/charts/asap/values.yaml file.

Using an Alternate Ingress Controller

By default, ASAP cloud native supports Traefik and provides sample files for integration. However, you can use any Ingress controller that supports host-based routing and session stickiness with cookies. ASAP cloud native uses the term "generic" ingress for scenarios where you want to leverage the Ingress capabilities that the Kubernetes platform may provide.

To use a generic ingress controller, you must create the ingress object and configure your ASAP instance to use it. The toolkit uses an ingress Helm chart ($ASAP_CNTK/samples/charts/asap/templates/traefik-ingress.yaml) and scripts for creating the ingress objects. If you want to use a generic ingress controller, these samples can be used as a reference and customized as necessary.

If your ASAP cloud native instance needs to secure incoming communications, then look at the $ASAP_CNTK/samples/charts/asap/templates/traefik-ingress.yaml file. This file demonstrates the configuration for a TLS-enabled Traefik ingress that can be used as a sample.

The host-based rules and the corresponding back-end Kubernetes service mapping are provided using the following definition:

asapUID: Combination of project-instance. For example, sr-quick.

The following table lists the service name and service ports for Ingress rules:

Table 8-1 Service Name and Service Ports for Ingress Rules

Rule	Service Name	Service Port	Purpose
instance.project.loadBalancerDomainName	domainUID-cluster-clusterName	8001	For access to ASAP through UI, XMLAPI, Web Services, and so on.
t3.instance.project.loadBalancerDomainName	t3.instance.project.loadBalancerDomainName	30303	ASAP T3 Channel access for WLST, JMS, and SAF clients.
admin.instance.project.loadBalancerDomainName	domainUID-admin	7001	For access to ASAP WebLogic Admin Console UI.

You must update the value of the ingressController parameter in the $ASAP_CNTK/charts/asap/values.yaml file. For example,

#valid values are TRAEFIK, GENERIC, OTHER
ingressController: "GENERIC"

If any of the supported Ingress controllers or even a generic ingress does not meet your requirements, you can choose "OTHER".

By choosing this option, ASAP cloud native does not create or manage any ingress required for accessing the ASAP cloud native services. However, you may choose to create your own ingress objects based on the service and port details mentioned in the above table.

Note:

Regardless of the choice of Ingress controller, it is mandatory to provide the value of loadBalancerPort in one of the specification files. This is used for establishing a front-end cluster.

Managing Logs

ASAP cloud native generates traditional textual logs. By default, these log files are generated in the managed server pod but can be re-directed to a Persistent Volume Claim (PVC) supported by the underlying technology that you choose. See "Setting Up Persistent Storage" for details.

When you update the staging container, update the LOGDIR attribute in the $ASAP_BASE/Environment_Profile file:

# LOGDIR=/asaplogs

The ASAP application logs can be found at: pv-directory/asapinstance/logs

Update the WebLogic logs path to the PVC mounted path.

Managing ASAP Cloud Native Metrics

ASAP WebLogic Server exposes the work order metrics deployed in ASAP cloud native. The following is the work order metrics path:

asapcn.metricspath: /ENV_ID/OrderMetrics

ASAP cloud native metrics expose the Order Balancer metrics along with the work order metrics. The following is the Order Balancer metrics path:

metrics_path: /ASAPOB/metrics

Configuring Prometheus for ASAP Cloud Native Metrics

ASAP provides the following metrics for monitoring based on the work order status:

Completed
Completed in last interval
Loading Work Orders
Failed
Canceled
In progress

Work order metrics can be queried with different parameter values. To query the work order metrics, use the following URL in the browser:

http://host:port/env_id/OrderMetrics?query=parameter

The supported parameter values are:

total: Provides total work order count. This is the the default parameter used.
today: Provides todays total work order count.
last_interval: Provides total work order count in the last interval.
all: Provides all the three work order counts (total + today + last_interval).

The Order Balancer metrics provided are:

ASAP Count: Provides the number of ASAP instances that are registered with Order Balancer.
ASAP instance status: Provides the status of each ASAP instance that is registered in Order Balancer.
Order Distribution: Provides the order distribution between the ASAP instances.

Configure the scrape job in Prometheus by updating the prometheus.yml file as follows:

- job_name: 'asapmetrics'
    scrape_interval: 120s
    scrape_timeout: 60s
    metrics_path: /ENV_ID/OrderMetrics
    scheme: http/https
    basic_auth:
      username: WebLogic user name
      password: WebLogic password
    static_configs:
      - targets: ['hostname:port number']
    params:
         query: [all]

  - job_name: 'obmetrics'
    scrape_interval: 120s
    scrape_timeout: 60s
    metrics_path: /ASAPOB/metrics
    scheme: http/https
    basic_auth:
      username: WebLogic user name
      password: WebLogic password
    static_configs:
      - targets: ['hostname:port number']

Where

WebLogic user name is the user name of WebLogic Server.
WebLogic password is the password of WebLogic Server.
hostname is the configured host name in the values.yaml file.
- ASAP: $asap_cntk/charts/asap/values.yaml
- Order Balancer: $ob-cntk/charts/ob/values.yaml
port number is the traefik node port number.

Note:

The filter options are: all, today, and total.

If you use a filter, update query: [filter] in the prometheus.yml file.

If you do not use a filter, comment out params: query: [filter] in the prometheus.yml file.

If multiple ASAP instances are added, add the respective jobs in prometheus.yml file

Viewing ASAP Cloud Native Metrics Without Using Prometheus

You can view the ASAP cloud native metrics, such as the work order metrics and the Order Balancer metrics using the following URLs:

Work order metrics:

http://hostname:traefik_Port/ENV_ID/OrderMetrics

Order Balancer metrics:

http://hostname:traefik_Port/ASAPOB/metrics

Where

hostname is the configured host name in the values.yaml file
- ASAP: $asap_cntk/charts/asap/values.yaml
- Order Balancer: $ob-cntk/charts/ob/values.yaml
traefik_Port is the traefik node port number.

These only provide metrics of the WebLogic Server that is serving the request. They does not provide consolidated metrics for the entire cluster. Prometheus Query and Grafana dashboards provide consolidated metrics.

Viewing ASAP Cloud Native Metrics in Grafana

ASAP cloud native metrics and Order Balancer metrics scraped by Prometheus can be made available for further processing and visualization. The ASAP cloud native toolkit comes with sample Grafana dashboards to get you started with visualizations.

Import the dashboard JSON files from $ASAP_CNTK/samples/grafana into your Grafana environment.

The sample dashboard displays the following:

ASAP Count
ASAP Instance Status
Order Distribution
Work order count by order state
Completed work order count in a configured interval

Exposed ASAP Order Metrics

The following ASAP metrics are exposed via ASAP Servlet APIs.

Order Metrics

The following table lists the order metrics exposed.

Table 8-2 Order Metrics Exposed via ASAP Servlet APIs

Name	Notes
asap_wo_complete_total	The total work orders in the completed state.
asap_wo_loading_total	The total work orders in the loading state.
asap_wo_failed_total	The total work orders in the failed state.
asap_wo_cancelled_total	The total work orders in the canceled state.
asap_wo_inprogress_total	The total work orders in the in progress state.
asap_wo_complete_last_interval	The total work orders that are in the completed state in the last interval.
asap_wo_complete_today	The total work orders that are in the completed state as of the current date.
asap_wo_loading_today	The total work orders that are in the loading state as of the current date.
asap_wo_failed_today	The total work orders that are in the failed state as of the current date.
asap_wo_cancelled_today	The total work orders that are in the canceled state as of the current date.
asap_wo_inprogress_today	The total work orders that are in the in-progress state as of the current date.