構築・運用: WebOTX Application Server Manual

WebOTX Manual V10.3 (第4版)

目次を表示

2. Operator

WebOTX Operator for Kubernetes の運用管理に関して説明します。以降、WebOTX Operator for Kubernetes を Operator と表記します。

2.1. Operator の展開・設定変更・更新・削除

2.1.1. Operator の展開

Operator を Kubernetes 上に展開するまでの流れは次の図のようなイメージとなります。

この展開の手順は次の通りとなります。

Operator インストールディレクトリに移動
```
cd <Operator インストールディレクトリ>
```

Operator イメージを作成

docker build -t <Docker レジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.3 docker

Operator イメージを Docker レジストリに登録

Docker レジストリ認証

プライベート Docker レジストリを使用している場合、認証情報を Secret として、 operator.yaml とカスタムリソース内の imagePullSecrets に設定する必要があります。

Secret 情報を kubectl で作成

ここでは、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 アドレス>

作成した Secret を operator.yaml の 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

Docker レジストリに登録
以下のコマンドを実行して、Operator イメージを Docker レジストリに登録します。
```
docker push <Docker レジストリのホスト名>:<ポート番号>/<任意のリポジトリ名>/webotx-operator:10.3
```

カスタムリソース定義（CRD）を作成

カスタムリソース定義とは、WebOTX Application Container のカスタムリソースをどのように記述するかを定義したものです。カスタムリソースを登録するために、予めカスタムリソース定義を登録しておく必要があります。
```
kubectl apply -f manifest/webotx_crd.yaml
```
サービスアカウントと権限の作成

Operator が動作するために必要な権限を付与します。
```
kubectl apply -f manifest/servie_account.yaml -n <Namespace 名>
```
ConfigMap の登録

WebOTX AS コンテナの起動に必要なスクリプトや logstash でのログ収集に必要な定義ファイルを管理する ConfigMap を登録します。
```
kubectl apply -f manifest/configmap.yaml -n <Namespace 名>
```

Operator の展開

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 の設定は operator.yaml 内の ConfigMap にて設定します。 ConfigMap に設定できる値については、 [リファレンス] > [設定] > [WebOTX Operator for Kubernetes] を参照してください。

設定の反映方法について、説明します。
1. operator.yaml 内に定義している ConfigMap の設定
  
  次の設定例では、太字の箇所を変更しています。
  
  設定例）
```
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:
  ：
```
2. ConfigMap の変更の適用
```
kubectl apply -f manifest/operator.yaml -n <Namespace名>
```
3. Operator への設定変更の反映
  
  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 が起動時に出力される次のようなログを確認してください。
1. Pod 名の確認
```
kubectl get pod -n <Namespace名>
```
  Namespace 名が不明瞭なときの Pod 名の確認方法 :
```
kubectl get pod --all-namespaces
```
2. Operator のログ確認
  
  次に、取得した 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"}}
```

2.1.2. Operator の削除

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 から削除されるので、注意が必要です。

2.2. WebOTX Application Server の展開・更新・削除

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 を作成します。

2.2.1. WebOTX Application Server の展開

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 を生成するまでの流れを次に示します。

Operator が WebOTX Application Server 用カスタムリソースの登録を検知します。
Operator は WebOTX Application Server の Deployment リソースが既に登録済みか確認します。
未登録の場合は、カスタムリソースに指定された定義をもとに Deployment マニフェストを作成し、適用します。
登録済みの場合は、カスタムリソースに定義された設定値と登録されている Deployment リソースの設定値を比較し、差異があればカスタムリソースの設定値で Deployment リソースを更新します。
Operator は WebOTX Application Server の Service リソースが既に登録済みか確認します。
未登録の場合は、カスタムリソースに指定された定義をもとに Service マニフェストを作成し、適用します。
登録済みの場合は、カスタムリソースに定義された設定値と登録されている Service リソースの設定値を比較し、差異があればカスタムリソースの設定値で Service リソースを更新します。

2.2.2. WebOTX Application Server の更新

WebOTX Application Server を更新する場合は、変更を行った WebOTX Application Server の Docker イメージを作成した後、カスタムリソースのマニフェストファイルを編集して再度適用すします。

WebOTX Application Server の設定変更の流れを次に示します。

更新した WebOTX Application Server の Docker イメージを作成
作成した Docker イメージを Docker レジストリに登録

作成した Docker イメージは予め Docker レジストリ登録しておく必要があります。次のコマンドで登録先の Docker レジストリに Docker のイメージ名を書き換えてから、登録を行います。
```
docker tag <イメージ名> <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:10.3
```
次のコマンドで Docker レジストリに Docker イメージを登録します。
```
docker push <Dockerレジストリのホスト名>:<ポート>/webotx/webotx-for-container:10.3
```
カスタムリソースを編集（イメージ名のタグなど）
カスタムリソースを Kubernetes に適用

kubectl apply -f webotx_cr.yaml -n <Namespace名>

2.2.3. WebOTX Application Server の削除

展開に使用したカスタムリソースを削除することで WebOTX Server が削除されます。

カスタムリソースを削除するには、次のコマンドを実行します。

kubectl ApplicationServer <カスタムリソース名> -n <Namespace名>

Caution カスタムリソースとそれにより展開された WebOTX Application Server の Deployment、Service は関連付けがされています。そのため、カスタムリソースを削除すると、そのカスタムリソースに紐づいている Deployment と Service も削除されます。

2.2.4. WebOTX Application Server の運用管理

2.3. 周辺の OSS ソフトウェアとの連携

2.3.1. Elasticsearch との連携

Logstash で収集したログを Elasticsearch に送信するための設定方法について説明します。 Operator から起動した WebOTX Application Server の Pod では、自動的に Logstash コンテナが起動し、WebOTX Application Server コンテナのログをリアルタイムで収集します。このログを Elasticsearch に送信しておくことで、Pod が削除された後もログを確認することができ、障害解析などに役立てることができます。

Elasticsearch との連携設定は次のように行います。

logstash.conf の output 定義に送信先の Elasticsearch を設定

logstash.conf で定義している次の環境変数に対して、送信先の Elasticsearch のホスト名とポート番号を指定します。既定値では、ホスト名は unknown となっており、Logstash のコンテナの標準出力に　ログは出力されます。
```
output {
  elasticsearch {
     hosts => ["${ELASTICSEARCH_HOST:unknown}:${ELASTICSEARCH_PORT:9200}"]
     index => "webotx"
  }
}
```

2.3.2. Promethues との連携

では、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 との連携設定
設定項目	説明
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"}

2.4. Infinispan を用いたセッションレプリケーション

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 名>
```

2.5. Amazon EKS 環境への展開

2.5.1. Amazon EKS 接続環境の構築

Amazon EKS クラスタの作成と管理に必要なバイナリのインストールと設定の手順は次の通りです。

Python のインストール

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 以降のバージョンが必要です。
AWS CLI のインストール
```
pip install awscli --upgrade --user
```
環境変数 PATH の編集

環境変数 PATH に、インストールした AWS CLI を追加します。

Memo
通常、以下の場所へインストールされます。
Windows 10 の場合：%USERPROFILE%\AppData\Roaming\Python\Python37\Scripts
Windows 10 以前の場合：%USERPROFILE%\AppData\Local\Programs\Python\Python37\Scripts
Linux の場合：~/.local/bin

AWS CLI 認証情報の設定

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 CLI 認証情報設定
設定項目	説明
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 からのコマンド出力の制御」をご参照ください。

eksctl のインストール

<Windows の場合>
1. Chocolatey をインストールします。
  
  下記のサイトを参考に、Chocolatey をインストールしてください。
  
  https://chocolatey.org/install
2. eksctl と aws-iam-authenticator をインストールします。
```
chocolatey install -y eksctl aws-iam-authenticator
```
<Linux の場合>
1. 以下のコマンドを実行して、eksctl をダウンロードして解凍します。
```
curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
```
2. 解凍したバイナリを /usr/local/bin に移動します。
```
sudo mv /tmp/eksctl /usr/local/bin
```

2.5.2. Amazon EKS クラスタの作成

Amazon EKS 上に、Kubernetes クラスタとワーカーノードを作成する手順は次の通りです。

Amazon EKS クラスタとワーカーノードの作成

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

kubectl のインストール

作成したKubernetes クラスタの操作に必要な kubectl をインストールします。

<Windows の場合>
1. PowerShell ターミナルを開きます。
2. 作成したクラスタの Kubernetes バージョンに応じて、Amazon EKS 提供の kubectl バイナリファイルをダウンロードします。
  　Kubernetes 1.14:
```
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.sha256
```
  　Kubernetes 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.sha256
```
  　Kubernetes 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
```
3. ダウンロードしたバイナリファイルを SHA-256 チェックサムを確認します。
```
Get-FileHash kubectl.exe
```
  上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
  
  Caution PowerShell のコマンド実行結果は大文字で出力されます。
4. ダウンロードした kubectl.exe を、任意のディレクトリへ移動します。
5. ユーザーまたは、システムの環境変数 PATH に、kubectl.exe を移動したディレクトリを追加します。
<Linux の場合>
1. 作成したクラスタの Kubernetes バージョンに応じて、Amazon EKS 提供の kubectl バイナリファイルをダウンロードします。
  　Kubernetes 1.14:
```
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.sha256
```
  　Kubernetes 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.sha256
```
  　Kubernetes 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
```
2. ダウンロードしたバイナリファイルを SHA-256 チェックサムを確認します。
```
openssl sha1 -sha256 kubectl
```
  上記コマンドで出力された SHA-256 チェックサムとダウンロードした SHA-256 ファイルに記載された内容が一致することを確認してください。
3. ダウンロードしたバイナリファイルへ実行アクセス権限を設定します。
```
chmod +x ./kubectl
```
4. ダウンロードした kubectl を、任意のディレクトリへ移動します。
5. 環境変数 PATH に、kubectl を移動したディレクトリを追加します。

2.5.3. Amazon ECR への Operator イメージ登録

Amazon ECR 上に、Operator の Docker イメージを登録する手順は次の通りです。

Amazon ECR へ認証コマンドの取得
```
aws ecr get-login --no-include-email --region <AWS リージョン>
```
上記コマンドを実行すると、Amazon ECR へログインするためのコマンドが出力されます。
Amazon ECR へログイン

取得した認証コマンドを実行します。
```
docker login -u AWS -p <省略>== https://<レジストリID>.dkr.ecr.<AWS リージョン>.amazonaws.com
```
「Login Succeeded」と表示されれば、ログインの成功です。

Amazon ECR リポジトリの作成

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 リポジトリを作成した際のコマンド結果に出力された値を設定。

Operator イメージの登録

docker push <registryId>/dkr.ecr.<AWS リージョン>.amazonaws.com/webotx/webotx-operator:10.3

2.5.4. Amazon EKS クラスタへの WebOTX Operator の展開

Amazon EKS 上に作成した、Kubernetes クラスタに WebOTX Operator を展開する手順は「Operator の展開・設定変更・更新・削除」を参照してください。

2.5.5. Amazon EKS クラスタへの WebOTX Application Server の展開

Amazon EKS 上に作成した、Kubernetes クラスタに WebOTX Application Server を展開する手順は「WebOTX Application Server の展開・更新・削除」を参照してください。

2.5.6. Amazon EKS クラスタの削除

Amazon EKS 上に作成した、Kubernetes クラスタを削除する手順は次の通りです。

Amazon EKS クラスタとワーカーノードの作成
```
eksctl delete cluster --name <クラスタ名> --wait
```
--wait オプションを指定することで、クラスタの削除が完了してからコマンドが終了します。

2.5.7. Amazon ECR から Operator イメージ削除

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 リポジトリを削除すると、リポジトリ内のイメージもすべて削除されますので、注意が必要です。

2.6. OpenShift 環境への展開

2.6.1. WebOTX Operator コンテナイメージ生成

OpenShift では、クラスタ内部にコンテナレジストリを持っています。この内部レジストリに、ソースコード（Dockerfile）からビルドされたコンテナイメージを登録して、 OpenShift 上へ配備することができます。

ここでは、WebOTX Operator のコンテナイメージの生成とレジストリへの登録方法を説明します。

OpenShift へのログイン

oc login -u <ユーザー名> -p <パスワード>

対象プロジェクトの切り替え
```
oc project <プロジェクト名>
```
新規にプロジェクトを作成する場合は、次のコマンドを実行します。
```
oc new-project <プロジェクト名>
```
BuildConfig の作成

次のコマンドで、バイナリソースによる 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」となります。

2.6.2. OpenShift への WebOTX Operator の展開

OpenShift へ WebOTX Operator を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

カスタムリソース定義（CRD）を作成
```
oc apply -f manifest/webotx_crd.yaml
```
サービスアカウントと権限の作成
```
oc apply -f manifest/service_account.yaml
```
ConfigMap の登録
```
oc apply -f manifest/configmap.yaml
```
WebOTX Operator の展開
```
oc apply -f manifest/operator.yaml
```

2.6.3. OpenShift への WebOTX Application Server の展開

OpenShift へ WebOTX Application Server を展開する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

SCC (Security Context Constraints) の設定

WebOTX Application Server を OpenShift 上で動作させるには、nonroot (WebOTX運用管理ユーザが非rootの場合) または anyuid (WebOTX運用管理ユーザがrootの場合) の SCC が必要です。以下のコマンドで、対象のサービスアカウントに SCC を付与します。この設定は各プロジェクトで 1 回実行すれば十分です。
<WebOTX運用管理ユーザが非root の場合>
```
oc patch scc nonroot --type=merge -p 'priority: 5'
oc adm policy add-scc-to-user nonroot -z <サービスアカウント名>
```
<WebOTX運用管理ユーザが root の場合>
```
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 名を指定します。

2.6.4. OpenShift から WebOTX Application Server を削除

OpenShift から WebOTX Application Server を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

Route の確認

次のコマンドで、サービスを公開する為に作成した 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

Route の削除
```
oc expose svc/<カスタムリソース名> --name <Route名> --port <公開するポート番号>
```
複数のポートを公開する場合は、公開するポート番号毎に異なる Route 名を指定します。
カスタムリソースの削除
```
oc delete -f manifest/webotx_cr.yaml
```

2.6.5. OpenShift から WebOTX Operator を削除

OpenShift から WebOTX Operator を削除する手順を説明します。oc コマンドは OpenShift にログインし、対象のプロジェクトに切り替えた状態で実行してください。

WebOTX Operator の削除

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 が全てのプロジェクトから削除されるので、注意が必要です。