|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
|
|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
WebOTX Operator for Kubernetes の運用管理に関して説明します。
以降、WebOTX Operator for Kubernetes を Operator と表記します。
以降の手順は、Operator をインストールした際に展開されるファイルを使用します。インストールの詳細は、以下のインストールガイド（Linux）を参照してください。
Operator を Kubernetes 上に展開するまでの流れは次の図のようなイメージとなります。
コンテナイメージ生成の手順は次の通りとなります。
cd <Operatorインストールディレクトリ>
docker build -t <Dockerレジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:11.1 docker
次のコマンドを実行して、Operator イメージを Docker レジストリに登録します。
docker push <Dockerレジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:11.1
Operator の展開は、マニフェストファイル (YAML) を編集して、Kubernetes クラスタへ登録することで行います。 マニフェストファイルは、Operator をインストールしたディレクトリの manifest 配下に格納されています。
Operator の展開の手順は次の通りとなります。
必要に応じて Operator を動作させたい Namespace を作成してください。
kubectl create namespace <Namespace名>
カスタムリソース定義とは、WebOTX Application Container のカスタムリソースをどのように記述するかを 定義したものです。 カスタムリソースを登録するために、予めカスタムリソース定義を登録しておく必要があります。
kubectl apply -f manifest/webotx_crd.yaml
WebOTX AS コンテナの起動に必要なスクリプトや Logstash でのログ収集に必要な定義ファイルを管理する ConfigMap を登録します。
kubectl apply -f manifest/configmap.yaml -n <Namespace名>
license.yaml にある下記の設定項目を変更してください。
| 設定項目 | 置換文字 |
|---|---|
| Operator ライセンスキー（Base64エンコード後） | REPLACE_BASE64_ENCODED_LICENSE_KEY |
次のコマンドを実行してライセンスを登録します。
kubectl apply -f manifest/license.yaml -n <Namespace名>
operator.yaml にある下記の設定項目を変更してください。
| 設定項目 | 置換文字 |
|---|---|
| Operator イメージ名 | REPLACE_WEBOTX_OPERATOR_IMAGE |
apiVersion: apps/v1
kind: Deployment
metadata:
name: webotx-operator
spec:
：
replicas: 1
template:
spec:
container:
name: webotx-operator
image: REPLACE_WEBOTX_OPERATOR_IMAGE # この設定値を Operator のコンテナイメージ名に変更してください。
：
Docker プライベートレジストリを利用する場合
Operator のコンテナイメージを Docker プライベートレジストリに登録している場合、認証情報を登録した Secret を作成して、
operator.yaml で imagePullSecrets の設定を追加する必要があります。
kubectl create secret docker-registry <Secret名> \
--docker-server=<レジストリサーバーのホスト名またはIPアドレス>:<ポート番号> \
--docker-username=<ユーザー名> \
--docker-password=<パスワード> \
--docker-email=<Emailアドレス> \
-n <Namespace名>
imagePullSecrets に設定
operator.yaml の次の太字の 2 行のコメントを解除して、REPLACE_REGISTRY_AUTH_SECRET_NAME を上記で作成した Secret の名前に変更します。
spec:
# Set when pulling an image from the private registry.
#imagePullSecrets:
# - name: REPLACE_REGISTRY_AUTH_SECRET_NAME
serviceAccountName: webotx-operator
volumes:
- name: share-volume
emptyDir: {}
設定例 :
ここでは、docker-registry-auth という名前の Secret を作成しています。
spec:
# Set when pulling an image from the private registry.
imagePullSecrets:
- name: docker-registry-auth
serviceAccountName: webotx-operator
volumes:
- name: share-volume
emptyDir: {}
次のコマンドを実行して Operator を展開します。
kubectl apply -f manifest/operator.yaml -n <Namespace名>
次のコマンドを実行して Operator の Pod の STATUS が「Running」、READY が「1/1」となることを確認します。
kubectl get pod -n <Namespace名>
出力例 :
NAME READY STATUS RESTARTS AGE webotx-operator-controller-manager-9fb75f759-fjf5s 1/1 Running 0 40s
Operator の設定は operator.yaml 内の ConfigMap にて設定します。 ConfigMap に設定できる値については、 [リファレンス] > [設定] > [WebOTX Operator for Kubernetes] > [Operator 設定項目] を参照してください。
設定の反映方法について、説明します。
次の設定例では、太字の箇所を変更しています。
設定例 :
apiVersion: v1 kind: ConfigMap metadata: name: webotx-operator-config data: LOG_LEVEL: "ERROR" LOG_ROTATION: "5" LOG_FILESIZE: "10" PPROF_ENABLED: "FALSE" PPROF_INTERVAL: "10" PPROF_ROTATION: "144" METERING_ENABLED: "TRUE" METERING_INTERVAL: "1" METERING_TIMEOUT_SCRAPE: "10" METERING_TIMEOUT_READ: "60" METERING_TIMEOUT_WRITE: "30" --- apiVersion: apps/v1 kind: Deployment metadata: name: webotx-operator-controller-manager spec: ：
kubectl apply -f manifest/operator.yaml -n <Namespace名>
変更した設定を Operator に反映するには、Operator を再起動する必要があります。
次のコマンドを実行して Operator を再起動します。
kubectl set env deployment/webotx-operator-controller-manager RELOAD_DATE="$(date)" -n <Namespace名>
Operator 設定の確認手順
設定の変更を反映するには Pod の再起動が必要です。
このため、ConfigMap の設定と展開済の Operator の設定は一致するとは限りません。
展開済の Operator の設定を確認したい場合は、次のコマンドで、ログに出力されている設定の内容を確認します。
kubectl get pod -n <Namespace名>
Namespace 名が不明瞭なときの Pod 名の確認方法 :
kubectl get pod --all-namespaces
次に、取得した Pod 名を指定して次のように kubectl logs を実行します。 設定情報は Operator 起動時に出力されるので、パイプ（|）で head コマンドで出力を渡すと見やすくなります。
kubectl logs <Pod名> -n <Namespace名> | head -n <表示行数>
出力例 :
2020-03-27 01:03:04 UTC INFO launcherOTX33050002: WebOTX Operator Settings.
LOG:
LOG_LEVEL: INFO
LOG_ROTATION: "5"
LOG_FILESIZE: "1"
PPROF:
PPROF_ENABLED: "FALSE"
PPROF_INTERVAL: "10"
PPROF_ROTATION: "144"
METERING:
METERING_ENABLED: "TRUE"
METERING_INTERVAL: "1"
TIMEOUT:
METERING_TIMEOUT_SCRAPE: "10"
METERING_TIMEOUT_READ: "60"
METERING_TIMEOUT_WRITE: "30"
Operator を Kubernetes 上から削除するためには、次のコマンドを実行します。
kubectl delete -f manifest/operator.yaml -n <Namespace 名>
kubectl delete -f manifest/license.yaml -n <Namespace名>
kubectl delete -f manifest/configmap.yaml -n <Namespace 名>
kubectl delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義(CRD)は、Namespace 毎ではなく、Kubernetes Cluster 全体で 1 つ登録します。 このため、カスタムリソース定義(CRD)を削除すると、 全ての Namespace で展開されている WebOTX Application Server が削除されますので、注意してください。
メータリング機能とは、Operator を利用して展開した WebOTX Server にて公開されているメトリックスを収集して、REST-API として公開する機能です。
メータリング機能を利用するには、以下の設定を行う必要があります。
operator.yaml 内の、以下の設定を修正し、Operator の展開を行います。
METERING_ENABLED ・・・ メータリング機能の有効/無効の設定（TRUE: 有効, FALSE: 無効）
METERING_INTERVAL ・・・ WebOTX Server からメトリックスを収集する間隔（分）
設定例 :
METERING_ENABLED: "TRUE" METERING_INTERVAL: "1"
カスタムリソース単位に、メトリックスを収集を収集するかどうかを設定します。
カスタムリソースのマニフェストファイル（webotx_cr.yaml）に、以下の設定を行い、WebOTX Server の展開を行います。WebOTX Server を展開する手順は「WebOTX Application Server の展開」を参照してください。
enabled ・・・ WebOTX Server からメトリックスを収集の有無の設定（true: する, false: しない）
scheme ・・・ WebOTX Server でメトリックスを公開しているエンドポイントの URI スキーム
port ・・・ WebOTX Server でメトリックスを公開しているエンドポイントのポート番号
※scheme、port については、Operator で展開する WebOTX Server コンテナの設定に合わせてください。
設定例 :
：
spec:
# WebOTX related settings
webotx:
# Metering related settings
metering:
# Enable / disable metric collection.
enabled: true
# Set the URL scheme for retrieving metrics.
scheme: https
# Set the port number when retrieving metrics.
port: 8443
：
REST-API のエンドポイントは以下の通りです。
| エンドポイント | パラメータ | 説明 |
|---|---|---|
| https://<pod-ip>:8989/metrics | なし | 全てのカスタムリソースで展開された WebOTX Server から収集したメトリックスを出力します。 |
| https://<pod-ip>:8989/metrics/<パラメータ> | カスタムリソース名 | パラメータにカスタムリソース名を指定することで、特定のカスタムリソースで展開された WebOTX Server から収集したメトリックスのみ出力します。 |
REST-API では、JSON フォーマットと Prometheus フォーマットをサポートしています。
JSON フォーマット
Accept ヘッダに、「application/json」を指定した場合、JSON フォーマットで応答します。
{
""<カスタムリソース名>": [
{
"name": "<メトリックス名>",
"help": "<メトリックスの説明>",
"type": "<メトリックスタイプ>",
"metrics": [
{
"labels": {
"applicationserver": "<ラベル：カスタムリソース名>",
"pod": "<ラベル：Pod名>"
},
"value": "<メトリックス値>"
},
{
"labels": {
"applicationserver": "<ラベル：カスタムリソース名>",
"pod": "<ラベル：Pod名>"
},
"value": "<メトリックス値>"
},
：
]
},
：
"<カスタムリソース名>": [
{
：
}
Prometheus フォーマット
Accept ヘッダに、「application/json」以外を指定した場合、Prometheus フォーマットで応答します。
# TYPE <メトリックス名> <メトリックスタイプ>
# HELP <メトリックス名> <メトリックスの説明>
<メトリックス名>{applicationserver="<ラベル：カスタムリソース名>", pod="<ラベル：Pod名>"} <メトリックス値>
Operator の監視を Prometheus で行うことができます。
Prometheus と連携を有効にするには、operator.yaml のアノテーションの設定を行います。
| 設定項目 | 説明 | 既定値 |
|---|---|---|
| prometheus.io/scrape | Prometheus で監視を行うかどうかを設定します。 設定値は true または false で設定し、true を設定した場合は有効となります。 |
true |
| prometheus.io/scheme | 監視する URI スキームを指定します。 | http |
| prometheus.io/path | 監視するパスを指定します。 | /metrics |
| prometheus.io/port | 監視するポート番号を設定します。 | 8383 |
例えば、メータリング機能で出力するメトリックスを Prometheus で監視したい場合は、以下のように設定します。
設定例 :
apiVersion: apps/v1
kind: Deployment
：
template:
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/scheme: "https"
prometheus.io/path: "/metrics"
prometheus.io/port: "8989"
spec:
：
<補足>
Prometheus の Service Discovery の機能を使用することで、Kubernetes クラスタ上で 動作している Operator の Prometheus 情報を自動的に収集することができます。
次に Service Discovery 機能を利用して動的に監視する場合の Prometheus の設定例を示します。
Prometheus の設定例 :
global:
：
scrape_configs:
：
- job_name: 'kubernetes-pods'
tls_config:
insecure_skip_verify: true
kubernetes_sd_configs:
- role: pod
api_server: "https://kubernetes.default.svc.cluster.local:443"
tls_config:
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: ${1}:${2}
target_label: __address__
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
Prometheus で収集したメトリックスを確認する場合は、Prometheus の管理コンソールから、クエリを実行することで確認できます。
Operator では、WebOTX Application Server を Kubernetes 上に展開するために、 Docker レジストリからそのイメージを取得します。 このため、予め WebOTX Application Server のイメージを作成し、Docker レジストリに 登録しておく必要があります。
次の図に、Operator が WebOTX Application Server を展開するまでの流れを示します。
上図のように WebOTX Application Server のカスタムリソースのマニフェストファイル（webotx_cr.yaml）を編集して、 kubectl コマンドにて Kubernetes Cluster 上に適用します。 Operator ではカスタムリソースの作成、または変更を検知して設定を読み込みます。 読み込んだ後、指定された WebOTX Application Server イメージを Docker レジストリより取得して、 WebOTX Application Server の Pod と公開用の Service を作成します。
カスタムリソースのマニフェストファイル（webotx_cr.yaml）を修正し、カスタムリソースを登録します。webotx_cr.yaml は Operator をインストールしたディレクトリに展開されます。
マニフェストファイル内に記載している次の置換文字を実際の値に修正してください。
| 設定項目 | 置換文字 |
|---|---|
| カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
| WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
Operator は、WebOTX Server に配備したアプリケーションを公開するための Service を作成します。
webotx_cr.yaml では、NodePort タイプの Service を作成して、WebOTX Server コンテナの 8080、8443 ポートを Kubernetes ワーカーノードの 30080、30443 へポートフォワードするように設定されています。WebOTX Server に配備したアプリケーションの設定やサービスの公開方法などに合わせて、設定を編集してください。（設定項目については、
[リファレンス]
> [設定]
> [WebOTX Operator for Kubernetes]
> [カスタムリソース設定項目]
を参照してください。）
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: NodePort
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
nodePort: 30080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
nodePort: 30443
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800
externalTrafficPolicy: Cluster
次のコマンドを実行し、WebOTX Server 用のカスタムリソースを適用します。
kubectl apply -f manifest/webotx_cr.yaml -n <Namespace名>
次のコマンドを実行し、WebOTX Server の Pod の STATUS が「Running」、READY が「2/2」となることを確認します。
kubectl get pod -n <Namespace名>
出力例 :
NAME READY STATUS RESTARTS AGE webotx-for-container-57964fffbc-bsldj 2/2 Running 0 3m21s
Operator の動作
WebOTX Application Server 用のカスタムリソースを kubectl コマンドで適用すると、
Operator が検知し、WebOTX Application Server の Pod を生成します。
このとき Pod 内には「図 WebOTX Application Server イメージの展開」のように、ログ収集のためのサイドカーとして Logstash コンテナが含まれます。
WebOTX Application Server の Pod を生成するまでの流れを次に示します。
WebOTX Application Server を更新する場合は、変更を行った WebOTX Application Server の Docker イメージを作成した後、 カスタムリソースのマニフェストファイルを編集して再度、適用します。
WebOTX Application Server の設定変更の流れを次に示します。
作成した Docker イメージは予め Docker レジストリ登録しておく必要があります。 次のコマンドで登録先の Docker レジストリに Docker のイメージ名を書き換えてから、 登録を行います。
docker tag <イメージ名> <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:11.1
次のコマンドで Docker レジストリに Docker イメージを登録します。
docker push <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:11.1
kubectl apply -f webotx_cr.yaml -n <Namespace名>
展開に使用したカスタムリソースを削除することで WebOTX Server が削除されます。
カスタムリソースを削除するには、次のコマンドを実行します。
kubectl ApplicationServer <カスタムリソース名> -n <Namespace名>
展開された WebOTX Application Server の Pod には、サイドカーとして Logstash コンテナが起動しており、この Logstash から WebOTX Application Server および、アプリケーションログを任意の Elasticsearch へ送信することができます。
Elasticsearch に送信しておくことで、Pod が削除された後もログを確認することができ、障害解析などに役立てることができます。
ログの収集する場合、以下の設定を行います。
webotx_cr.yaml の spec.webotx 配下に、以下の設定を追加します。
spec:
# WebOTX related settings
webotx:
：
application:
logs:
- <収集対象とするログファイルの絶対パス>
- <収集対象とするログファイルの絶対パス>
：
webotx_cr.yaml の spec.deployment: 配下に、以下の設定を追加します。
spec:
：
deployment:
：
logstash:
elasticsearch:
host: <Elasticsearch のホスト名 or IPアドレス>
port: <Elasticsearch のポート番号>
tls:
enabled: true
cacert:
secret:
name: <Logstash に配置する CA 証明書を定義した Secret 名>
key: <Logstash に配置する CA 証明書を定義した Secret の data 部のキー名>
verification: true
auth:
enabled: true
secretName: <認証用のユーザー名、パスワードを定義した Secret 名>
：
Memo
上記の設定を行わない（Elasticsearchへ送信しない）場合は、Logstash コンテナの標準出力に出力されます。
以下のように設定することで、WebOTX Application Server コンテナに環境変数を設定することが出来ます。
以下の形式で環境変数を定義したファイルを作成します。
環境変数名=値 環境変数名=値 環境変数名=値 ：
次のコマンドを実行して ConfigMap または、Secret を作成します。
# ConfigMap の場合 kubectl create configmap <ConfigMap名> --from-env-file=<環境変数を定義したファイルパス> -n <Namespace名> # Secret の場合 kubectl create secret generic <Secret名> --from-env-file=<環境変数を定義したファイルパス> -n <Namespace名>
webotx_cr.yaml に作成した ConfigMap(Secret) の設定を追加します。
spec:
# WebOTX related settings
webotx:
：
envFrom:
# ConfigMap の場合
configMaps:
- <ConfigMap名>
- <ConfigMap名>
：
# Secret の場合
secrets:
- <Secret名>
- <Secret名>
：
Kubernetes 上で動作する WebOTX Application Server コンテナでは、ホスト名や IP アドレスが
変動的であるため、ホスト名や IP アドレスを指定したセッションレプリケーションをすることが
できません。
この場合に利用できるのが、Infinispan のデータグリッド連携機能（※）による
セッションレプリケーションです。
Caution Infinispan のデータグリッド連携機能は WebOTX Application Server V10 の Standard でのみ サポートしています。
次の図に WebOTX Application Server をセッションレプリケーションした際のイメージを示します。
Infinispan は、WebOTX Application Server が動作している各 Pod に配置され、 Kubernetes の Pod Network 上にある Infinispan が自動的に連携します。
Operator では、この Infinispan を利用したセッションレプリケーションが容易にできるよう 設計されており、カスタムリソース内で次のように sessionReplication の enabled、useJmxAgent、 useAllProcessGroups の設定を行うだけで、複数の Pod 間で自動的にセッションレプリケーションが 行われます。
カスタムリソースの設定例 :
spec:
# WebOTX related settings
webotx:
:
# Session replication related settings
sessionReplication:
# Enable / disable session replication.
# optional
enabled: true
# Sets whether the data grid is loaded by the agent process.
# optional
useJmxAgent: true
# Set whether the data grid is loaded in all process groups.
# optional
useAllProcessGroups: true
# Deployment manifest definition settings
deployment:
# Setting pod multiplicity.
replicas: 1
# WebOTX AS container image name setting.
image: <WebOTX AS コンテナイメージ名>
# The name of the ServiceAccount used to run this pod.
# Default to default.
# optional
serviceAccountName: <サービスアカウント名（※）>
# Indicates whether the service account token should be automatically
# mounted.
# optional
automountServiceAccountToken: true
:
※Infinispan を利用してセッションレプリケーションを行うには、Kubernetes API へのアクセス権限を付与されたサービスアカウントで WebOTX AS コンテナを起動する必要があります。
任意のサービスアカウントへ Kubernetes API へのアクセス権限を付与する手順は次の通りです。
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: webotx-infinispan-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: webotx-infinispan-binding
subjects:
- kind: ServiceAccount
name: <サービスアカウント名>
roleRef:
kind: Role
name: webotx-infinispan-role
apiGroup: rbac.authorization.k8s.io
kubectl apply -f <作成したマニフェストファイルパス> -n <Namespace 名>
kubectl delete -f <作成したマニフェストファイルパス> -n <Namespace 名>
OpenShift では、クラスタ内部にコンテナレジストリを持っています。この内部レジストリに、ソースコード（Dockerfile）からビルドされたコンテナイメージを登録して、 OpenShift 上へ配備することができます。
ここでは、WebOTX Operator のコンテナイメージの生成とレジストリへの登録方法を説明します。
oc login -u <ユーザー名> -p <パスワード>
oc project <プロジェクト名>
新規にプロジェクトを作成する場合は、次のコマンドを実行します。
oc new-project <プロジェクト名>
次のコマンドで、バイナリソースによる Docker ビルドストラテジーの BuildConfig を作成します。
oc new-build --strategy=docker --binary --name=<任意の BuildConfig 名>
プロキシ環境下では、必要に応じて --build-arg オプションで環境変数 http_proxy, https_proxy, no_proxy を指定してください。
次のコマンドで、WebOTX Operator のインストールで展開した資材を使用して、ビルドを開始します。
oc start-build <任意の BuildConfig 名> --from-dir=<Operator インストールディレクトリ>/docker
実行結果はOpenShiftの管理コンソールか oc get is コマンドで確認できます。 また、oc start-build コマンドに --follow オプションを追加すると、コンテナイメージ生成の実行状況が表示されます。
生成されたコンテナイメージのタグは latest として生成されます。次のコマンドでコンテナイメージのタグを変更できます。
oc tag <任意の BuildConfig 名>:latest <任意の BuildConfig 名>:<タグ>
次のコマンドで、生成されたコンテナイメージを確認します。
oc get is
出力例 :
> oc get is NAME IMAGE REPOSITORY TAGS UPDATED webotx-operator image-registry.openshift-image-registry.svc:5000/example/webotx-operator 11.1,latest 42 seconds ago
上記は、example という名前のプロジェクト上で生成した場合の例です。
この場合、operator.yaml に設定する Operator イメージ名は、「image-registry.openshift-image-registry.svc:5000/example/webotx-operator:11.1」となります。
OpenShift へ WebOTX Operator を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
oc apply -f manifest/webotx_crd.yaml
oc apply -f manifest/configmap.yaml
マニフェストファイル（operator.yaml、license.yaml）に Operator コンテナイメージ名とライセンスキーを設定します。
詳細は、「Operator の展開」を参照してください。
oc apply -f manifest/license.yaml
oc apply -f manifest/operator.yaml
OpenShift へ WebOTX Application Server を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
「OpenShift を使ったコンテナ(Pod)の起動」を参照して、SCC (Security Context Constraints) の設定を行ってください。
| 設定項目 | 置換文字 |
|---|---|
| カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
| WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
OpenShift では、サービスの公開を Route を作成して行うため、ワーカーノードにポートフォワードする必要がないため、NodePort ではなく ClusterIP で作成します。
設定例 :
：
# Service manifest definition settings
service:
# Configure NodePort service.
type: ClusterIP
ports:
- name: http
protocol: TCP
targetPort: 8080
port: 8080
- name: https
protocol: TCP
targetPort: 8443
port: 8443
oc apply -f manifest/webotx_cr.yaml
OpeShift へ展開した WebOTX Application Server のコンテナ（Pod）に外部からアクセスする場合、次のコマンドを実行します。
oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>
複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。
OpenShift から WebOTX Application Server を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
次のコマンドで、サービスを公開する為に作成した Route を確認します。
oc get route
出力例 :
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD webotx-as-http webotx-as-http-example.apps.otx4k.smileninja.net webotx-as-container 8080 None webotx-as-https webotx-as-https-example.apps.otx4k.smileninja.net webotx-as-container 8443 None
oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>
複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。
oc delete -f manifest/webotx_cr.yaml
OpenShift から WebOTX Operator を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
oc delete -f manifest/operator.yaml oc delete -f manifest/license.yaml
OpenShift 上に展開した全ての WebOTX Operator および、WebOTX Application Server を削除する場合のみ実施します。
oc delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義は、プロジェクト毎ではなく、OpenShift 全体で 1 つ登録します。 このため、カスタムリソース定義を削除すると、 カスタムリソース定義に紐づいている WebOTX Application Server が全てのプロジェクトから 削除されるので、注意が必要です。