![]() |
![]() |
WebOTX Manual V10.3 (第4版) 目次を表示 |
WebOTX Operator for Kubernetes の運用管理に関して説明します。 以降、WebOTX Operator for Kubernetes を Operator と表記します。
Operator を Kubernetes 上に展開するまでの流れは次の図のようなイメージとなります。
この展開の手順は次の通りとなります。
cd <Operator インストールディレクトリ>
docker build -t <Docker レジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.3 docker
Docker レジストリ認証
プライベート Docker レジストリを使用している場合、認証情報を Secret として、
operator.yaml とカスタムリソース内の imagePullSecrets
に設定する必要があります。
ここでは、docker-registry-auth という Secret を作成しています。この Secret の名前は任意です。
kubectl create secret --save-config docker registry docker-registry-auth \ --docker-server=<レジストリサーバーのホスト名またはIPアドレス>:<ポート番号> \ --docker-username=<ユーザー名> \ --docker-password=<パスワード> \ --docker-email=<Email アドレス>
imagePullSecrets
に設定
operator.yaml に次の太字の 2 行を追加します。
containers:
- name: webotx-operator
# Replace this with the built image name
image: REPLACE_WEBOTX_OPERATOR_IMAGE
command:
- /opt/WebOTX/bin/entrypoint
imagePullPolicy: Always
imagePullSecrets:
- name: docker-registry-auth
以下のコマンドを実行して、Operator イメージを Docker レジストリに登録します。
docker push <Docker レジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.3
カスタムリソース定義とは、WebOTX Application Container のカスタムリソースをどのように記述するかを 定義したものです。 カスタムリソースを登録するために、予めカスタムリソース定義を登録しておく必要があります。
kubectl apply -f manifest/webotx_crd.yaml
Operator が動作するために必要な権限を付与します。
kubectl apply -f manifest/servie_account.yaml -n <Namespace 名>
WebOTX AS コンテナの起動に必要なスクリプトや logstash でのログ収集に必要な定義ファイルを管理する ConfigMap を登録します。
kubectl apply -f manifest/configmap.yaml -n <Namespace 名>
Operator マニフェストの変更
operator.yaml にある下記の設定変更してください。
設定項目 | 置換文字 |
---|---|
Operator イメージ名 | REPLACE_WEBOTX_OPERATOR_IMAGE |
Operator ライセンスキー | REPLACE_LICENSE_KEY |
operator.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: webotx-operator spec: : replicas: 1 template: spec: container: name: webotx-operator image: REPLACE_WEBOTX_OPERATOR_IMAGE # この設定値に任意のイメージ名を設定してください。 : env: - name: LICENSE_KEY Value: REPLACE_LICENSE_KEY # この設定値に Operator のライセンスキーを設定してください。 :
次のコマンドを実行して Operator を展開します。
kubectl apply -f manifest/operator.yaml -n <Namespace 名>
Operator の設定変更
Operator の設定は operator.yaml 内の ConfigMap にて設定します。 ConfigMap に設定できる値については、 [リファレンス] > [設定] > [WebOTX Operator for Kubernetes] を参照してください。
設定の反映方法について、説明します。
次の設定例では、太字の箇所を変更しています。
設定例)
apiVersion: v1 kind: ConfigMap metadata: name: webotx-operator-config data: LOG_LEVEL: ERROR LOG_ROTATION: 5 LOG_FILESIZE: 200 : --- apiVersion: apps/v1 kind: Deployment metadata: name: webotx-operator spec: :
kubectl apply -f manifest/operator.yaml -n <Namespace名>
operator.yaml 内の Deployment に変更がない場合は反映されないため、次のコマンドで operator.yaml 内の REALOAD_DATE 値を更新日時に変更します。 このコマンドを実行することで、配備済の Pod が再起動されます。
kubectl set env deployment/webotx-operator RELOAD_DATE="$(date)" -n <Namespace名>
Operator の設定内容確認
Operator の設定は ConfigMap で管理していますが、ConfigMap の設定変更を 反映するには Pod の再起動が必要です。 このため、ConfigMap の設定と配備済の Operator の設定は一致するとは限りません。 配備済の 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
実行例 :
kubectl logs webotx-operator-684c7976cc-kcxtl -n webotx | head
出力例 :
OTX33050002: WebOTX Operator Settings. {"LOG": {"LOG_LEVEL":"INFO","LOG_ROTATION":"5","LOG_FILESIZE":"1"}, "PPROF": {"PPROF_ENABLED":"FALSE","PPROF_INTERVAL":"10","PPROF_ROTATION":"144"}}
Operator を Kubernetes 上から削除するためには、次のように kubectl delete を実行します。
Operator の削除 :
kubectl delete -f manifest/operator.yaml -n <Namespace 名> kubectl delete -f manifest/service_account.yaml -n <Namespace 名>
カスタムリソース定義を削除する場合は、次のコマンドを実行します。
カスタムリソース定義の削除 :
kubectl delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義は、Namespace 毎ではなく、Kubernetes Cluster 全体で 1 つ登録します。 このため、カスタムリソース定義を削除すると、 カスタムリソース定義に紐づいている WebOTX Application Server が全ての Namespace から 削除されるので、注意が必要です。
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 インストール時に展開されます。
webotx_cr.yaml 中に記載している次の置換文字を実際の値に修正してください。
設定項目 | 置換文字 |
---|---|
カスタムリソース名 | REPLACE_APPLICATIONSERVER_NAME |
WebOTX Application Server の Docker イメージ名 | REPLACE_WEBOTX_AS_IMAGE |
次のコマンドを実行し、WebOTX Application Server 用のカスタムリソースを適用します。
kubectl apply -f webotx_cr.yaml -n <Namespace名>
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:10.3
次のコマンドで Docker レジストリに Docker イメージを登録します。
docker push <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:10.3
kubectl apply -f webotx_cr.yaml -n <Namespace名>
展開に使用したカスタムリソースを削除することで WebOTX Server が削除されます。
カスタムリソースを削除するには、次のコマンドを実行します。
kubectl ApplicationServer <カスタムリソース名> -n <Namespace名>
Logstash で収集したログを Elasticsearch に送信するための設定方法について説明します。 Operator から起動した WebOTX Application Server の Pod では、自動的に Logstash コンテナが起動し、WebOTX Application Server コンテナのログを リアルタイムで収集します。 このログを Elasticsearch に送信しておくことで、Pod が削除された後もログを確認することができ、 障害解析などに役立てることができます。
Elasticsearch との連携設定は次のように行います。
logstash.conf で定義している次の環境変数に対して、 送信先の Elasticsearch のホスト名とポート番号を指定します。 既定値では、ホスト名は unknown となっており、Logstash のコンテナの標準出力に ログは出力されます。
output { elasticsearch { hosts => ["${ELASTICSEARCH_HOST:unknown}:${ELASTICSEARCH_PORT:9200}"] index => "webotx" } }
では、Prometheus と連携して監視するための URL を有効にして、 Operator の監視を Prometheus で行うことができます。
Prometheus と連携を有効にするには、operator.yaml の spec.template.metadata.annotation に 次の設定を行います。
Prometheus と連携する場合の operator.yaml の設定例 :
apiVersion: apps/v1 kind: Deployment : : template: metadata: annotations: prometheus.io/scrape: "true" prometheus.io/path: "/metrics" prometheus.io/port: "8383" spec: containers: - name: webotx-as
設定項目 | 説明 |
---|---|
prometheus.io/scrape | Prometheus で監視を行うかどうかを設定します。 設定値は true または false で設定し、true を設定した場合は有効となります。 |
prometheus.io/path | 監視する URI を指定します。 |
prometheus.io/port | 監視するポート番号を設定します。 |
<補足>
Prometheus の Service Discovery の機能を使用することで、Kubernetes Cluster 上で 動作している Operator の Prometheus 情報を自動的に収集することができます。
次に Service Discovery 機能を利用して動的に監視する場合の Prometheus の設定例を示します。
Prometheus の設定例 :
global: : scrape_configs: : - job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true - 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_(.+) replacement: $1 - source_labels: [__meta_kubernetes_namespace] action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: kubernetes_pod_name
例えば、Prometheus で収集した Operator の常駐メモリ(process_resident_memory_bytes)を 確認する場合は、Prometheus にて次のように Metrics を指定してグラフを表示します。
process_resident_memory_bytes{name="webotx-operator"}
Kubernetes 上で動作する WebOTX Application Server コンテナでは、ホスト名や IP アドレスが
変動的であるため、ホスト名や IP アドレスを指定したセッションレプリケーションをすることが
できません。
この場合に利用できるのが、Infinispan のデータグリッド連携機能(※)による
セッションレプリケーションです。
Caution Infinispan のデータグリッド連携機能は WebOTX Application Server の 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 名>
Amazon EKS クラスタの作成と管理に必要なバイナリのインストールと設定の手順は次の通りです。
AWS サービスを管理を行う AWS Command Line Interface(以降、AWS CLI と表記します)のインストールは、Python に含まれる pip を使用してインストールします。
下記のサイトを参考に、Python をインストールしてください。
https://www.python.jp/install/install.html
Caution AWS CLI を使用するには、Python 2.7 以降または Python 3.4 以降のバージョンが必要です。
pip install awscli --upgrade --user
環境変数 PATH に、インストールした AWS CLI を追加します。
Memo
通常、以下の場所へインストールされます。
Windows 10 の場合:%USERPROFILE%\AppData\Roaming\Python\Python37\Scripts
Windows 10 以前の場合:%USERPROFILE%\AppData\Local\Programs\Python\Python37\Scripts
Linux の場合:~/.local/bin
Amazon EKS へ接続する為の 認証情報の設定を行います。
aws configure AWS Access Key ID [None]: <IAM ユーザーのアクセスキー> AWS Secret Access Key [None]: <IAM ユーザーのシークレットアクセスキー> Default region name [None]: <リージョンコード> Default output format [None]: <出力形式>
設定項目 | 説明 |
---|---|
AWS Access Key ID | IAM ユーザーまたはロールに関連付けられる AWS アクセスキーを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI の設定」をご参照ください。 |
AWS Secret Access Key | アクセスキーに関連付けられるシークレットキーを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI の設定」をご参照ください。 |
Default region name | リクエストを送信する AWS リージョンを指定します。 詳細については、AWS リファレンスガイドの「AWS サービスエンドポイント」をご参照ください。 |
Default output format | AWS CLI コマンド実行結果の出力形式を指定します。 json 、text 、 table の何れかを指定します。 詳細については、AWS ユーザーガイドの「AWS CLI からのコマンド出力の制御」をご参照ください。 |
<Windows の場合>
下記のサイトを参考に、Chocolatey をインストールしてください。
chocolatey install -y eksctl aws-iam-authenticator
<Linux の場合>
curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
Amazon EKS 上に、Kubernetes クラスタとワーカーノードを作成する手順は次の通りです。
eksctl create cluster \ --name <クラスタ名> \ --region <AWS リージョン> \ --version <Kubernetes バージョン番号> \ --nodegroup-name <ノードグループ名> \ --node-type <ワーカーノードのEC2インスタンスタイプ> \ --nodes <ワーカーノードのノード数> \ --nodes-min <ワーカーノードのスケーリング最小サイズ> \ --nodes-max <ワーカーノードのスケーリング最大サイズ> \ --node-ami <ワーカーノード起動 AMI>
コマンド例 :
eksctl create cluster \ --name prod \ --region ap-northeast-1 \ --version 1.14 \ --nodegroup-name standard-workers \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --node-ami auto
オプション名 | 説明 |
---|---|
--name | Amazon EKS クラスタの名前を指定します。 |
--region | Amazon EKS クラスタを作成するリージョンを指定します。 詳細については、AWS リファレンスガイドの「AWS サービスエンドポイント」をご参照ください。 |
--version | Kubernetes バージョン番号を指定します。(1.12, 1.13, 1.14 の何れかを設定) |
--nodegroup-name | ノードグループの名前を指定します。 |
--node-type | ワーカーノードのEC2インスタンスタイプを指定します。 詳細については、「Amazon EC2 インスタンスタイプ」をご参照ください。 |
--nodes | ワーカーノードのノード数を指定します。 |
--nodes-min | ワーカーノードのスケーリングの最小サイズを指定します。 |
--nodes-max | ワーカーノードのスケーリングの最大サイズを指定します。 |
--node-ami | ワーカーノードの起動に用いる Amazon マシンイメージ (AMI) を指定します。 「auto」が指定されている場合、Kubernetes バージョン/リージョン/インスタンスタイプに基づいて AMI を自動的に設定されます。 |
上記以外にも指定可能なオプションがあります。
詳細については、下記のコマンドでヘルプページを参照し、構築する環境に合わせて指定してください。
eksctl create cluster --help
作成したKubernetes クラスタの操作に必要な kubectl をインストールします。
<Windows の場合>
curl -o kubectl.exe https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/windows/amd64/kubectl.exe.sha256Kubernetes 1.13:
curl -o kubectl.exe https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.8/2019-08-14/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.8/2019-08-14/bin/windows/amd64/kubectl.exe.sha256Kubernetes 1.12:
curl -o kubectl.exe https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.10/2019-08-14/bin/windows/amd64/kubectl.exe curl -o kubectl.exe.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.10/2019-08-14/bin/windows/amd64/kubectl.exe.sha256
Get-FileHash kubectl.exe
上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
Caution PowerShell のコマンド実行結果は大文字で出力されます。
<Linux の場合>
curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/linux/amd64/kubectl.sha256Kubernetes 1.13:
curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.8/2019-08-14/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.8/2019-08-14/bin/linux/amd64/kubectl.sha256Kubernetes 1.12:
curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.10/2019-08-14/bin/linux/amd64/kubectl curl -o kubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.10/2019-08-14/bin/linux/amd64/kubectl.sha256
openssl sha1 -sha256 kubectl
上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
chmod +x ./kubectl
Amazon ECR 上に、Operator の Docker イメージを登録する手順は次の通りです。
aws ecr get-login --no-include-email --region <AWS リージョン>
上記コマンドを実行すると、Amazon ECR へログインするためのコマンドが出力されます。
取得した認証コマンドを実行します。
docker login -u AWS -p <省略>== https://<レジストリID>.dkr.ecr.<AWS リージョン>.amazonaws.com
「Login Succeeded」と表示されれば、ログインの成功です。
aws ecr create-repository --region <AWS リージョン> --repository-name webotx/webotx-operator
出力例 :
> aws ecr create-repository --region ap-northeast-1 --repository-name webotx/webotx-operator
{
"repository": {
"repositoryArn": "arn:aws:ecr:ap-northeast-1:123456789012:repository/webotx/webotx-operator",
"registryId": "123456789012",
"repositoryName": "webotx/webotx-operator",
"repositoryUri": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/webotx/webotx-operator",
"createdAt": 1581908263.0,
"imageTagMutability": "MUTABLE",
"imageScanningConfiguration": {
"scanOnPush": false
}
}
}
registryId は、次の手順にて使用する為、出力内容を控えてください。
Operator の Docker イメージを、Amazon ECR のリポジトリへ登録するために、イメージ名のタグを修正します。
docker tag <Operator イメージ名> <registryId>/dkr.ecr.<AWS リージョン>.amazonaws.com/webotx/webotx-operator:10.3
<registryId> は、Amazon ECR リポジトリを作成した際のコマンド結果に出力された値を設定。
docker push <registryId>/dkr.ecr.<AWS リージョン>.amazonaws.com/webotx/webotx-operator:10.3
Amazon EKS 上に作成した、Kubernetes クラスタに WebOTX Operator を展開する手順は「Operator の展開・設定変更・更新・削除」を参照してください。
Amazon EKS 上に作成した、Kubernetes クラスタに WebOTX Application Server を展開する手順は「WebOTX Application Server の展開・更新・削除」を参照してください。
Amazon EKS 上に作成した、Kubernetes クラスタを削除する手順は次の通りです。
eksctl delete cluster --name <クラスタ名> --wait
--wait
オプションを指定することで、クラスタの削除が完了してからコマンドが終了します。
Amazon ECR 上に登録した、Operator の Docker イメージを削除する手順は次の通りです。
aws ecr list-images --repository-name webotx/webotx-operator
出力例 :
> aws ecr list-images --repository-name webotx/webotx-operator
{
"imageIds": [
{
"imageDigest": "sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646",
"imageTag": "10.3"
}
]
}
削除するイメージの imageDigest を控えてください。
aws ecr batch-delete-image --repository-name webotx/webotx-operator --image-ids imageDigest=<imageDigest の出力値>
出力例 :
> aws ecr batch-delete-image --repository-name webotx/webotx-operator --image-ids imageDigest=sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646 { "imageIds": [ { "imageDigest": "sha256:27fb54237f6dbcd45e976e56b4cf6ef14be57bd16292c3b43a8d91b39faed646", "imageTag": "10.3" } ], "failures": [] }
作成したリポジトリも削除する場合は、次のコマンドを実行します。
aws ecr delete-repository --repository-name webotx/webotx-operator
Caution リポジトリを削除すると、リポジトリ内のイメージもすべて削除されますので、注意が必要です。
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 10.3,latest 42 seconds ago
上記は、example という名前のプロジェクト上で生成した場合の例です。
この場合、operator.yaml に設定する Operator イメージ名は、「image-registry.openshift-image-registry.svc:5000/example/webotx-operator:10.3」となります。
OpenShift へ WebOTX Operator を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
oc apply -f manifest/webotx_crd.yaml
oc apply -f manifest/service_account.yaml
oc apply -f manifest/configmap.yaml
oc apply -f manifest/operator.yaml
OpenShift へ WebOTX Application Server を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。
WebOTX Application Server を OpenShift 上で動作させるには、nonroot (WebOTX運用管理ユーザが非rootの場合) または anyuid (WebOTX運用管理ユーザがrootの場合) の SCC が必要です。 以下のコマンドで、対象のサービスアカウントに SCC を付与します。 この設定は各プロジェクトで 1 回実行すれば十分です。
oc patch scc nonroot --type=merge -p 'priority: 5' oc adm policy add-scc-to-user nonroot -z <サービスアカウント名>
oc adm policy add-scc-to-user anyuid -z <サービスアカウント名>
デフォルトのサービスアカウントに SCC を付与する場合は、サービスアカウント名に「default」を指定します。
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/service_account.yaml
OpenShift 上に展開した全ての WebOTX Operator および、WebOTX Application Server を削除する場合のみ実施します。
oc delete -f manifest/webotx_crd.yaml
Caution カスタムリソースの定義は、プロジェクト毎ではなく、OpenShift 全体で 1 つ登録します。 このため、カスタムリソース定義を削除すると、 カスタムリソース定義に紐づいている WebOTX Application Server が全てのプロジェクトから 削除されるので、注意が必要です。