Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

クラスターの設定

OpenShift Container Platform 3.10

OpenShift Container Platform 3.10 のインストールおよび設定

Red Hat OpenShift Documentation Team

概要

『OpenShift のインストールと設定』では、ご使用の環境で OpenShift をインストールし、設定するための基本事項を説明します。扱われるトピックを参照して、OpenShift の稼働に必要な一度だけ実行するタスク (one-time task) を実行してください。

第1章 概要

本書では、OpenShift Container Platform クラスターのインストール後に利用できる追加の設定オプションについて説明します。

第2章 レジストリーのセットアップ

2.1. レジストリーの概要

2.1.1. レジストリーについて

OpenShift Container Platform は、ソースコードからコンテナーイメージをビルドし、デプロイし、そのライフサイクルを管理することができます。これを可能にするために、OpenShift Container Platform は、内部の統合 Docker レジストリーを提供します。このレジストリーは、ローカルでイメージを管理するために OpenShift Container Platform 環境にデプロイすることができます。

2.1.2. 統合レジストリーまたはスタンドアロンレジストリー

完全な OpenShift Container Platform クラスターの初回インストール時に、レジストリーはインストールプロセスで自動的にデプロイされている可能性があります。自動的にデプロイされていなかった場合やレジストリー設定のカスタマイズが追加で必要になる場合には、「既存クラスターへのレジストリーのデプロイ」を参照してください。

OpenShift Container Platform のレジストリーは、完全な OpenShift Container Platform クラスターの統合部分として実行されるようにデプロイできる一方で、スタンドアロンのコンテナーイメージレジストリーとして個別にインストールすることも可能です。

スタンドアロンレジストリーをインストールするには、「スタンドアロンレジストリーのインストール」の手順に従ってください。このインストールパスは、レジストリーと専用の Web コンソールを実行するオールインワンのクラスターをデプロイします。

2.1.3. Red Hat Quay レジストリー

エンタープライズ向けの高品質なコンテナーイメージレジストリーを必要とされる場合、Red Hat Quay をホストされたサービスおよびソフトウェアのどちらとしてもご利用いただけます。これは独自のデータセンターやクラウド環境にインストールしてご利用いただけます。Red Hat Quay の高度なレジストリーには、geo レプリケーション、イメージのスキャニング、およびイメージのロールバック機能が含まれます。

Quay.io サイトにアクセスして独自のホストレベルの Quay レジストリーのアカウントをセットアップできます。その後は、Quay チュートリアルをご利用いただき、Quay レジストリーにログインしてからイメージの管理を開始できます。または、独自の Red Hat Quay レジストリーをセットアップする方法についての詳細は、「Getting Started with Red Hat Quay」を参照してください。

現時点では、リモートのコンテナーイメージレジストリーにアクセスするのと同じ方法で Red Hat Quay レジストリーに OpenShift からアクセスできます。Red Hat Quay にアクセスするための認証情報をセキュリティー保護されたレジストリーとしてセットアップする方法については、「Allowing Pods to Reference Images from Other Secured Registries」を参照してください。

2.2. 既存クラスターへのレジストリーのデプロイ

2.2.1. 概要

OpenShift Container Platform クラスターの初回インストール時に統合レジストリーが事前に自動的にデプロイされなかった場合や、正常に実行されず、既存のクラスターに再デプロイする必要がある場合は、以下のセクションで新規レジストリーをデプロイするためのオプションを参照してください。

注記

スタンドアロンレジストリーをインストールしていない場合、このトピックは不要になります。

2.2.2. レジストリーのデプロイ

統合 Docker レジストリーをデプロイするには、クラスター管理者権限を持つユーザーとして oc adm registry コマンドを使用します。以下は例になります。

$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \1
    --service-account=registry \2
    --images='registry.access.redhat.com/openshift3/ose-${component}:${version}' 3
1
--config は、クラスター管理者用の CLI 設定ファイルへのパスです。
2
--service-account は、レジストリーの Pod の実行に使用されるサービスアカウントです。
3
OpenShift Container Platform の適切なイメージをプルするために必要です。

これでサービスとデプロイメント設定が作成されます。これらは共に docker-registry と呼ばれます。正常にデプロイされると、Pod が docker-registry-1-cpty9 などの名前で作成されます。

レジストリーの作成時に指定できるオプションの詳細の一覧を表示するには、以下を実行します。

$ oc adm registry --help

--fs-group の値は、レジストリーが使用している SCC (通常は制限付き SCC) によって許可されている必要があります。

2.2.3. レジストリーの DaemonSet としてのデプロイ

レジストリーを --daemonset オプションを使用して DaemonSetとしてデプロイするには、 oc adm registry コマンドを使用します。

DaemonSet は、ノードの作成時に、指定した Pod のコピーがノードに含まれていることを確認します。ノードが削除されると、Pod はガベージコレクションされます。

DaemonSetに関する詳細は、「Daemonset の使用」を参照してください。

2.2.4. レジストリーのコンピュートリソース

デフォルトで、レジストリーはコンピュートリソースの要求や制限に関する設定がない状態で作成されます。実稼働環境では、レジストリーのデプロイメント設定を更新してレジストリー Pod のリソース要求や制限を設定しておくことが強く推奨されます。設定しない場合、レジストリー Pod は BestEffort Pod と判断されます。

要求や制限の設定に関する詳細は、「コンピュートリソース」を参照してください。

2.2.5. レジストリーのストレージ

レジストリーには、コンテナーのイメージとメタデータが格納されています。Pod をレジストリーと共に単純にデプロイする場合、Pod がすでに存在する場合に破棄される一時ボリュームが使用されます。この場合、誰かがビルドしたりレジストリーにプッシュしたりしたイメージは消えてしまいます。

以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下の一覧には、レジストリーの設定ファイルで設定を行う必要があるストレージドライバーが含まれます。

レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。

注記

サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。

2.2.5.1. 実稼働環境での使用

実稼働環境での使用の場合には、リモートボリュームを割り当てるか、または各自が選択した永続ストレージ方法を定義して使用します

たとえば、既存の Persistent Volume Claim (永続ボリューム要求) を使用するには、以下を実行します。

$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
     --claim-name=<pvc_name> --overwrite
重要

テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

2.2.5.1.1. Amazon S3 のストレージのバックエンドとしての使用

Amazon Simple Storage Service のストレージを内部 Docker レジストリーと共に使用する方法もあります。Amazon Simple Storage Service は AWS マネジメントコンソールで管理できるセキュアなクラウドストレージです。これを使用するには、レジストリーの設定ファイルを手動で編集し、レジストリー Pod にマウントする必要があります。ただし、設定を開始する前にアップストリームの推奨手順を確認してください。

デフォルトの YAML 設定ファイルをベースとして取得し、storage セクションの filesystem エントリーを、以下のように s3 エントリーに置き換えます。これにより、ストレージのセクションは以下のようになります。

storage:
  cache:
    layerinfo: inmemory
  delete:
    enabled: true
  s3:
    accesskey: awsaccesskey 1
    secretkey: awssecretkey 2
    region: us-west-1
    regionendpoint: http://myobjects.local
    bucket: bucketname
    encrypt: true
    keyid: mykeyid
    secure: true
    v4auth: false
    chunksize: 5242880
    rootdirectory: /s3/object/name/prefix
1
Amazon のアクセスキーに置き換えてください。
2
Amazon のシークレットキーに置き換えてください。

s3 のすべての設定オプションは、アップストリームのドライバー参照ドキュメントに記載されています。

レジストリー設定を上書きすると、設定ファイルを Pod にマウントするための追加の手順に進みます。

警告

レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます

使用している統合レジストリーでサポートされていない S3 リージョンを使用する必要がある場合は、「S3 ドライバー設定」を参照してください。

2.2.5.2. 非実稼働環境での使用

非実稼働環境の場合、--mount-host=<path> オプションを使って、永続ストレージに使用するレジストリーのディレクトリーを指定します。次に、レジストリーのボリュームがホストのマウントとして、指定された <path> に作成されます。

重要

--mount-host オプションは、レジストリーのコンテナーが実行されているノードからディレクトリーをマウントします。docker-registry デプロイメント設定をスケールアップすると、レジストリー Pod とコンテナーが別々のノードで実行されので、それぞれ独自のローカルストレージを使用したレジストリーコンテナーが 2 つ以上作成される可能性があります。これは予期しない動作を生じさせます。その後に繰り返される同一イメージのプル要求が最終的に到達するコンテナーによっては必ずしも成功しない場合があるためです。

--mount-host オプションを使用する場合には、レジストリーコンテナーを特権モードで実行する必要があります。--mount-host を指定すると、自動的に特権モードが有効になります。ただしデフォルトでは、すべての Pod が特権付きコンテナー をデフォルトで実行できる訳ではありません。それでもこのオプションを使用する必要がある場合は、レジストリーを作成してから、レジストリーがインストール時に作成された registry サービスアカウントを使用するように指定してください。

$ oc adm registry --service-account=registry \
    --config=/etc/origin/master/admin.kubeconfig \
    --images='registry.access.redhat.com/openshift3/ose-${component}:${version}' \
    --mount-host=<path>
重要

Docker レジストリー Pod は、ユーザー 1001 として実行されます。このユーザーは、ホストのディレクトリーへの書き込みができなければなりません。したがって、以下のコマンドでディレクトリーの所有権をユーザー ID 1001 に変更する必要がある場合があります。

$ sudo chown 1001:root <path>

2.2.6. レジストリーコンソールの有効化

OpenShift Container Platform は、統合レジストリーへの Web ベースのインターフェースを提供します。このレジストリーコンソールは、イメージの参照と管理を行うためのオプションのコンポーネントであり、Pod として実行されるステートレスサービスとしてデプロイされます。

注記

OpenShift Container Platform をスタンドアロンレジストリーとしてインストールした場合、レジストリーコンソールはインストール時にすでにデプロイされ、そのセキュリティーが自動的に保護されています。

重要

Cockpit がすでに実行されている場合、レジストリーコンソールとのポート競合 (デフォルトでは9090) を避けるために、次に進む前にこれをシャットダウンする必要があります。

2.2.6.1. レジストリーコンソールのデプロイ

重要

最初にレジストリーを公開しておく必要があります。

  1. デフォルトのプロジェクトにパススルールートを作成します。このルートは、以下の手順でレジストリーコンソールのアプリケーションを作成する際に必要になります。

    $ oc create route passthrough --service registry-console \
        --port registry-console \
        -n default
  2. レジストリーコンソールのアプリケーションをデプロイします。<openshift_oauth_url> は、OpenShift Container Platform OAuth プロバイダー の URL に置き換えます。通常これはマスターになります。

    $ oc new-app -n default --template=registry-console \
        -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \
        -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \
        -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')
    注記

    レジストリーコンソールへのログインの試行時にリダイレクト URL が間違っていた場合は、oc get oauthclients で OAuth クライアントを確認してください。

  3. 最後に、Web ブラウザーでこのルート URI を使用しているコンソールを表示します。

2.2.6.2. レジストリーコンソールのセキュリティー保護

デフォルトでは、レジストリーコンソールは、レジストリーコンソールのデプロイの手順ごとに手動でデプロイされる場合に自己署名 TLS 証明書を生成します。詳細は、「レジストリーコンソールのトラブルシューティング」を参照してください。

組織の署名済み証明書をシークレットボリュームとして追加する際には、以下の手順に従ってください。ここでは、証明書が oc クライアントホストで利用可能であることを前提としています。

  1. 証明書とキーを含む .cert ファイルを作成します。以下を使用してファイルをフォーマットします。

    • サーバー証明書と中間証明機関用の BEGIN CERTIFICATE ブロック 1 つまたは複数。
    • キーの BEGIN PRIVATE KEY または同種のものを含むブロック。キーは暗号化することができません。

      以下は例を示しています。

      -----BEGIN CERTIFICATE-----
      MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV
      BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls
      ...
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV
      BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls
      ...
      -----END CERTIFICATE-----
      -----BEGIN PRIVATE KEY-----
      MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCyOJ5garOYw0sm
      8TBCDSqQ/H1awGMzDYdB11xuHHsxYS2VepPMzMzryHR137I4dGFLhvdTvJUH8lUS
      ...
      -----END PRIVATE KEY-----
    • セキュリティーの保護されたレジストリーには、以下の SAN (サブジェクトの別名: Subject Alternative Names) 一覧が含まれているはずです。

      • 2 つのサービスのホスト名。

        以下は例を示しています。

        docker-registry.default.svc.cluster.local
        docker-registry.default.svc
      • サービス IP アドレス。

        以下は例を示しています。

        172.30.124.220

        以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。

        oc get service docker-registry --template='{{.spec.clusterIP}}'
      • パブリックホスト名。

        以下は例を示しています。

        docker-registry-default.apps.example.com

        以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。

        oc get route docker-registry --template '{{.spec.host}}'

        たとえば、サーバー証明書には以下のような SAN の詳細が記載されるはずです。

        X509v3 Subject Alternative Name:
                       DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98

        レジストリーコンソールは、証明書を /etc/cockpit/ws-certs.d ディレクトリーから読み込み、拡張子 .cert が付いたファイルをアルファベット順で (最後から) 使用します。したがって .cert ファイルには、 OpenSSL スタイルでフォーマットされた PEM ブロックが少なくとも 2 つ含まれている必要があります。

        証明書がない場合には、 openssl コマンドで自己署名証明書を作成し、0-self-signed.cert ファイルに保存します。

  2. シークレットを作成します。

    $ oc create secret generic console-secret \
        /path/to/console.cert
  3. このシークレットを registry-console デプロイメント設定に追加します。

    $ oc volume dc/registry-console --add --type=secret \
        --secret-name=console-secret -m /etc/cockpit/ws-certs.d

    これにより、レジストリーコンソールの新規デプロイメントがトリガーされ、署名済み証明書が組み込まれます。

2.2.6.3. レジストリーコンソールのトラブルシューティング

2.2.6.3.1. デバッグモード

レジストリーコンソールのデバッグモードは環境変数を使用して有効にされます。以下のコマンドは、レジストリーコンソールをデバッグモードで再デプロイします。

$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper

デバッグモードを有効にすると、より詳細なログがレジストリコンソールの Pod ログに表示されます。

2.2.6.3.2. SSL 証明書パスの表示

レジストリーコンソールが使用している証明書を確認するには、コマンドをコンソール Pod から実行します。

  1. デフォルト のプロジェクトに Pod を一覧表示して、レジストリーコンソールの Pod 名を検索します。

    $ oc get pods -n default
    NAME                       READY     STATUS    RESTARTS   AGE
    registry-console-1-rssrw   1/1       Running   0          1d
  2. 直前のコマンドで取得した Pod 名を使って、cockpit-ws プロセスが使用している証明書パスを取得します。以下は、自動生成された証明書を使用しているコンソールの例です。

    $ oc exec registry-console-1-rssrw remotectl certificate
    certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert

2.3. レジストリーへのアクセス

2.3.1. ログの表示

Docker レジストリーのログを表示するには、デプロイメント設定で oc logs コマンドを使用します。

$ oc logs dc/docker-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

2.3.2. ファイルストレージ

タグとイメージメタデータは OpenShift Container Platform に格納されますが、レジストリーは、レイヤーと署名データを /registry にあるレジストリーコンテナーにマウントされているボリュームに格納します。oc exec は特権付きコンテナーでは機能しないため、レジストリーの内容を確認するには、レジストリー Pod のコンテナーを格納しているノードに対して SSH を手動で実行し、コンテナー自体で docker exec を実行します。

  1. 現在の Pod を一覧表示し、Docker レジストリーの Pod 名を検索します。

    # oc get pods

    次に、oc describe を使用して、コンテナーを実行しているノードのホスト名を検索します。

    # oc describe pod <pod_name>
  2. 必要なノードにログインします。

    #ssh node.example.com
  3. ノードホストのデフォルトプロジェクトから実行中のコンテナーを一覧表示し、Docker レジストリーのコンテナー ID を特定します。

    #docker ps --filter = name = registry_docker-registry。* _ default_
  4. oc rsh コマンドを使用してレジストリーの内容を一覧表示します。

    # oc rsh dc/docker-registry find /registry
    /registry/docker
    /registry/docker/registry
    /registry/docker/registry/v2
    /registry/docker/registry/v2/blobs 1
    /registry/docker/registry/v2/blobs/sha256
    /registry/docker/registry/v2/blobs/sha256/ed
    /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810
    /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/data 2
    /registry/docker/registry/v2/blobs/sha256/a3
    /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/data
    /registry/docker/registry/v2/blobs/sha256/f7
    /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845
    /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/data
    /registry/docker/registry/v2/repositories 3
    /registry/docker/registry/v2/repositories/p1
    /registry/docker/registry/v2/repositories/p1/pause 4
    /registry/docker/registry/v2/repositories/p1/pause/_manifests
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures 5
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/link 6
    /registry/docker/registry/v2/repositories/p1/pause/_uploads 7
    /registry/docker/registry/v2/repositories/p1/pause/_layers 8
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/link 9
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/link
    1
    このディレクトリーには、すべてのレイヤーと署名が Blob として格納されます。
    2
    このファイルには、Blob の内容が含まれます。
    3
    このディレクトリーには、すべてのイメージリポジトリーが格納されます。
    4
    このディレクトリーは単一イメージリポジトリーの p1/pause 用です。
    5
    このディレクトリーには、特定のイメージマニフェストリビジョンの署名が含まれます。
    6
    このファイルには、Blob (署名データを含む) への参照が含まれます。
    7
    このディレクトリーには、指定されたリポジトリーに対して現在アップロードされステージングされているすべてのレイヤーが含まれます。
    8
    このディレクトリーには、このリポジトリーが参照するすべてのレイヤーへのリンクが含まれます。
    9
    このファイルには、イメージを介してこのリポジトリーにリンクされている特定のレイヤーへの参照が含まれます。

2.3.3. レジストリーへの直接アクセス

さらに高度な使用方法として、レジストリーに直接アクセスし、docker コマンドを起動することが可能です。これにより、docker pushdocker pull などの操作で直接イメージをプッシュするか、または統合レジストリーからイメージをプルすることができます。これを実行するには、docker login コマンドを使ってレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つ権限によって異なります。

2.3.3.1. ユーザーの前提条件

レジストリーに直接アクセスするには、使用するユーザーが、使用目的に応じて以下の前提条件を満たしている必要があります。

  • 直接アクセスするには、ユーザーは選択するアイデンティティープロバイダー通常ユーザーである必要があります。通常ユーザーは、レジストリーへのログインに必要なアクセストークンを生成できます。system:admin などのシステムユーザーはアクセストークンを取得できないため、レジストリーに直接アクセスすることはできません。

    たとえば HTPASSWD 認証を使用している場合は、以下のコマンドを使用してこれを作成することができます。

    # htpasswd /etc/origin/openshift-htpasswd <user_name>
  • docker pull コマンドを使用する場合などにイメージをプルするには、ユーザーに registry-viewer ロールがなければなりません。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-viewer <user_name>
  • イメージの書き出しやプッシュを実行するには (docker push コマンドを使用する場合など)、ユーザーに registry-editor ロールが必要です。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-editor <user_name>

ユーザーパーミッションに関する詳細は、「ロールバインディングの管理」を参照してください。

2.3.3.2. レジストリーへのログイン

注記

ユーザーが、レジストリーに直接アクセスできるための前提条件を満たしていることを確認してください。

レジストリーに直接ログインするには、以下を実行します。

  1. OpenShift Container Platform に通常ユーザーとしてログインしていることを確認します。

    $ oc login
  2. アクセストークンを使用して Docker レジストリーにログインします。

    docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
注記

ユーザー名には、任意の値を指定でき、トークンには必要な情報が全て含まれます。コロンが含まれるユーザー名を指定すると、ログインに失敗します。

2.3.3.3. イメージのプッシュとプル

レジストリーにログインすると、レジストリーに docker pull および docker push 操作を実行できます。

重要

任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。

以下の例では、以下を使用します。

コンポーネント

<registry_ip>

172.30.124.220

<port>

5000

<project>

openshift

<image>

busybox

<tag>

省略 (デフォルトは latest)

  1. 任意のイメージをプルします。

    $ docker pull docker.io/busybox
  2. 新規イメージに <registry_ip>:<port>/<project>/<image> 形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするには OpenShift Container Platform のプル仕様必ず表示されている必要があります。

    $ docker tag docker.io/busybox 172.30.124.220:5000/openshift/busybox
    注記

    通常ユーザーには、指定されたプロジェクトの system:image-builder ロールが必要です。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。このロールが設定されていない場合には以下の手順の docker push が失敗します。新規プロジェクトを作成して busybox イメージをプッシュしてテストすることができます。

  3. 新しくタグ付けされたイメージをレジストリーにプッシュします。

    $ docker push 172.30.124.220:5000/openshift/busybox
    ...
    cf2616975b4a: Image successfully pushed
    Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55

2.3.4. レジストリーメトリクスへのアクセス

OpenShift Container レジストリーは、Prometheus メトリクス のエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースシステムのモニタリングおよびアラートツールキットです。

メトリクスはレジストリーのエンドポイントの /extensions/v2/metrics パスに公開されます。ただし、このルートは最初に有効にされている必要があります。有効化の方法についてはレジストリー設定の拡張を参照してください。

以下は、メトリクスクエリーの簡単な例です。

$ curl -s -u <user>:<secret> \ 1
    http://172.30.30.30:5000/extensions/v2/metrics | grep openshift | head -n 10

# HELP openshift_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which OpenShift was built.
# TYPE openshift_build_info gauge
openshift_build_info{gitCommit="67275e1",gitVersion="v3.6.0-alpha.1+67275e1-803",major="3",minor="6+"} 1
# HELP openshift_registry_request_duration_seconds Request latency summary in microseconds for each operation
# TYPE openshift_registry_request_duration_seconds summary
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.5"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.9"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.99"} 0
openshift_registry_request_duration_seconds_sum{name="test/origin-pod",operation="blobstore.create"} 0
openshift_registry_request_duration_seconds_count{name="test/origin-pod",operation="blobstore.create"} 5
1
<user> は任意ですが、<secret>レジストリー設定で指定された値と一致していなければなりません。

メトリクスにアクセスするための別の方法は、クラスターロールの使用です。エンドポイントはここでも有効にする必要がありますが、<secret> を指定する必要はありません。設定ファイルのメトリクスに対応する部分は以下のようになります。

openshift:
  version: 1.0
  metrics:
    enabled: true
...

メトリクスにアクセスするために必要なクラスターロールがない場合、これを作成する必要があります。

$ cat <<EOF |
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-scraper
rules:
- apiGroups:
  - image.openshift.io
  resources:
  - registry/metrics
  verbs:
  - get
EOF
oc create -f -

このロールをユーザーに追加するには、以下のコマンドを実行します。

$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>

高度なクエリーと推奨されるビジュアライザーについては、アップストリームの Prometheus ドキュメントを参照してください。

2.4. レジストリーのセキュリティー保護および公開

2.4.1. 概要

デフォルトでは、OpenShift Container Platform レジストリーは、TLS 経由でトラフィックを提供できるようクラスターのインストール時にセキュリティー保護されます。サービスを外部に公開するために、パススルールートもデフォルトで作成されます。

何らかの理由でレジストリーが保護されていないか、または公開されていない場合は、これらを手動で実行する方法について以下のセクションを参照してください。

2.4.2. レジストリーを手動でセキュリティー保護する

レジストリーを手動でセキュリティー保護して TLS 経由でトラフィックを処理するには、以下を実行します。

  1. レジストリーをデプロイします
  2. レジストリーのサービス IP とポートを取得します。

    $ oc get svc/docker-registry
    NAME              LABELS                                    SELECTOR                  IP(S)            PORT(S)
    docker-registry   docker-registry=default                   docker-registry=default   172.30.124.220   5000/TCP
  3. 既存のサーバー証明書を使用するか、指定の IP およびホスト名で有効で、指定の CA により署名されたサーバー証明書およびキーを作成します。レジストリーのサービス IP と docker-registry.default.svc.cluster.local ホスト名のサーバー証明書を作成するには、Ansible ホストインベントリーファイル (デフォルトでは /etc/ansible/hosts) に一覧表示されている最初のマスターから以下のコマンドを実行します。

    $ oc adm ca create-server-cert \
        --signer-cert=/etc/origin/master/ca.crt \
        --signer-key=/etc/origin/master/ca.key \
        --signer-serial=/etc/origin/master/ca.serial.txt \
        --hostnames='docker-registry.default.svc.cluster.local,docker-registry.default.svc,172.30.124.220' \
        --cert=/etc/secrets/registry.crt \
        --key=/etc/secrets/registry.key

    ルーターを外部に公開する場合、公開ルートのホスト名を --hostnames フラグに追加します。

    --hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \

    ルートを外部にアクセス可能にするためにデフォルトの証明書を更新する際のその他詳細については、「レジストリーとルーター証明書の再デプロイ」を参照してください。

    注記

    oc adm ca create-server-cert コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。

  4. レジストリー証明書のシークレットを作成します。

    $ oc create secret generic registry-certificates \
        --from-file=/etc/secrets/registry.crt \
        --from-file=/etc/secrets/registry.key
  5. シークレットをレジストリー Pod のサービスアカウント (デフォルトのサービスアカウントなど) に追加します。

    $ oc secrets link registry registry-certificates
    $ oc secrets link default  registry-certificates
    注記

    デフォルトでは、対象のシークレットを参照するサービスアカウントだけに、そのシークレットを制限する動作は無効になっています。つまり、マスターの設定ファイルで serviceAccountConfig.limitSecretReferencesfalse (デフォルトの設定) に設定されている場合、シークレットをサービスにリンクさせる必要はありません。

  6. docker-registry サービスを一時停止します。

    $ oc rollout pause dc / docker-registry
  7. シークレットボリュームをレジストリーのデプロイメント設定に追加します。

    $ oc volume dc/docker-registry --add --type=secret \
        --secret-name=registry-certificates -m /etc/secrets
  8. 以下の環境変数をレジストリーのデプロイメント設定に追加して TLS を有効にします。

    $ oc set env dc/docker-registry \
        REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \
        REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key

    詳細は、Docker ドキュメントのレジストリーの設定のセクションを参照してください。

  9. レジストリーの liveness probe に使用されているスキームを HTTP から HTTPS に更新します。

    $ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{
        "name":"registry",
        "livenessProbe":  {"httpGet": {"scheme":"HTTPS"}}
      }]}}}}'
  10. レジストリーを OpenShift Container Platform 3.2 以降に初めてデプロイした場合は、レジストリーの readiness probe として使用されているスキームを HTTP から HTTPS に更新します。

    $ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{
        "name":"registry",
        "readinessProbe":  {"httpGet": {"scheme":"HTTPS"}}
      }]}}}}'
  11. docker-registry サービスを再開します。

    $ oc rollout resume dc/docker-registry
  12. レジストリーが TLS モードで実行されていることを検証します。最後の docker-registry のデプロイメントが完了するまで待機し、Docker ログでレジストリーコンテナーを確認します。listening on :5000, tls のエントリーが見つかるはずです。

    $ oc logs dc/docker-registry | grep tls
    time="2015-05-27T05:05:53Z" level=info msg="listening on :5000, tls" instance.id=deeba528-c478-41f5-b751-dc48e4935fc2
  13. CA 証明書を Docker 証明書ディレクトリーにコピーします。これはクラスター内のすべてのノードで実行する必要があります。

    $ dcertsdir=/etc/docker/certs.d
    $ destdir_addr=$dcertsdir/172.30.124.220:5000
    $ destdir_name=$dcertsdir/docker-registry.default.svc.cluster.local:5000
    
    $ sudo mkdir -p $destdir_addr $destdir_name
    $ sudo cp ca.crt $destdir_addr    1
    $ sudo cp ca.crt $destdir_name
    1
    ca.crt ファイルは、マスター上の /etc/origin/master/ca.crt のコピーです。
  14. 認証を使用している場合、docker のバージョンによっては、OS レベルで証明書を信頼するようにクラスターを設定することも必要になります。

    1. 証明書をコピーします。

      $ cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
    2. 以下を実行します。

      $ update-ca-trust enable
  15. /etc/sysconfig/docker ファイルのこの特定のレジストリーに対してのみ、--insecure-registry オプションを削除します。次にデーモンを再度読み込み、 docker サービスを再起動して設定の変更を反映させます。

    $ sudo systemctl daemon-reload
    $ sudo systemctl restart docker
  16. docker クライアント接続を検証します。レジストリーに対する docker push、またはレジストリーからの docker pull が正常に実行されるはずです。必ずこのレジストリーにログインしていることを確認してください。

    $ docker tag|push <registry/image> <internal_registry/project/image>

    以下は例を示しています。

    $ docker pull busybox
    $ docker tag docker.io/busybox 172.30.124.220:5000/openshift/busybox
    $ docker push 172.30.124.220:5000/openshift/busybox
    ...
    cf2616975b4a: Image successfully pushed
    Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55

2.4.3. セキュアなレジストリーの手動による公開

OpenShift Container Platform クラスター内から、OpenShift Container Platform レジストリーにログインするのではなく、外部からレジストリーにアクセスできるようにするには、先にレジストリーのセキュリティーを確保してから、このレジストリーをルートに公開します。この方法を使うと、ルートアドレスを使ってクラスターの外部からレジストリーにログインし、ルートのホストを使ってイメージにタグ付けしたり、イメージをプッシュしたりできます。

  1. 以下の前提条件に関するそれぞれの手順は、標準的なクラスターのインストール時にデフォルトで実行されます。これが実行されていない場合は、手動で実行してください。

  2. パススルールートは、クラスターの初回インストール時にこのレジストリーについてデフォルトで作成されている必要があります。

    1. ルートが存在するかどうかを確認します。

      $ oc get route/docker-registry -o yaml
      apiVersion: v1
      kind: Route
      metadata:
        name: docker-registry
      spec:
        host: <host> 1
        to:
          kind: Service
          name: docker-registry 2
        tls:
          termination: passthrough 3
      1
      ルートのホスト。この名前は、外部から DNS 経由でルーターの IP アドレスに解決できる必要があります。
      2
      レジストリーのサービス名。
      3
      このルートをパススルールートとして指定します。
      注記

      Re-encrypt ルートはセキュアなレジストリーを公開するためにもサポートされています。

    2. ルートが存在していない場合、oc create route passthrough コマンドで、レジストリーをルートのサービスとして指定してルートを作成します。デフォルトでは、作成したルートの名前はサービス名と同じです。

      1. docker-registry サービスの詳細を取得します。

        $ oc get svc
        NAME              CLUSTER_IP       EXTERNAL_IP   PORT(S)                 SELECTOR                  AGE
        docker-registry   172.30.69.167    <none>        5000/TCP                docker-registry=default   4h
        kubernetes        172.30.0.1       <none>        443/TCP,53/UDP,53/TCP   <none>                    4h
        router            172.30.172.132   <none>        80/TCP                  router=router             4h
      2. ルートを作成します。

        $ oc create route passthrough    \
            --service=docker-registry    \1
            --hostname=<host>
        route "docker-registry" created     2
        1
        レジストリーをルートのサービスとして指定します。
        2
        ルート名はサービス名と同じです。
  3. 次に、ホストシステム上のレジストリーに使用されている証明書を信頼し、ホストによるイメージのプッシュおよびプルを許可する必要があります。参照される証明書は、レジストリーのセキュリティー保護を実行したときに作成されたものです。

    $ sudo mkdir -p /etc/docker/certs.d/<host>
    $ sudo cp <ca_certificate_file> /etc/docker/certs.d/<host>
    $ sudo systemctl restart docker
  4. レジストリーのセキュリティー保護の実行時に得られた情報を使ってレジストリーにログインします。ただし、ここではサービス IP ではなくルートで使用されているホスト名を指定します。セキュリティーが保護され、公開されているレジストリーにログインする際は、必ず docker login コマンドのレジストリーを指定してください。

    # docker login -e user@company.com \
        -u f83j5h6 \
        -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
        <host>
  5. これでルートのホストを使ってイメージのタグ付けとプッシュを実行できます。たとえば、test という名前のプロジェクトにある busybox イメージをタグ付けし、プッシュするには、以下を実行します。

    $ oc get imagestreams -n test
    NAME      DOCKER REPO   TAGS      UPDATED
    
    $ docker pull busybox
    $ docker tag busybox <host>/test/busybox
    $ docker push <host>/test/busybox
    The push refers to a repository [<host>/test/busybox] (len: 1)
    8c2e06607696: Image already exists
    6ce2e90b0bc7: Image successfully pushed
    cf2616975b4a: Image successfully pushed
    Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31
    
    $ docker pull <host>/test/busybox
    latest: Pulling from <host>/test/busybox
    cf2616975b4a: Already exists
    6ce2e90b0bc7: Already exists
    8c2e06607696: Already exists
    Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31
    Status: Image is up to date for <host>/test/busybox:latest
    
    $ oc get imagestreams -n test
    NAME      DOCKER REPO                       TAGS      UPDATED
    busybox   172.30.11.215:5000/test/busybox   latest    2 seconds ago
    注記

    イメージストリームにはルート名とポートではなく、レジストリーサービスの IP アドレスとポートが設定されます。詳細は oc get imagestreams を参照してください。

2.4.4. 非セキュアなレジストリーの手動での公開

レジストリーのセキュリティーを確保してレジストリーを公開する代わりに、OpenShift Container Platform の非稼働環境に、セキュアでないレジストリーを簡単に公開できます。これにより、SSL 証明書を使用せずにレジストリーへの外部ルートを作成することができます。

警告

非実稼働環境以外では、非セキュアなレジストリーを外部アクセスに公開すべきではありません。

非セキュアなレジストリーを公開するには、以下を実行します。

  1. レジストリーを公開します。

    # oc expose service docker-registry --hostname=<hostname> -n default

    以下の JSON ファイルが作成されます。

    apiVersion: v1
    kind: Route
    metadata:
      creationTimestamp: null
      labels:
        docker-registry: default
      name: docker-registry
    spec:
      host: registry.example.com
      port:
        targetPort: "5000"
      to:
        kind: Service
        name: docker-registry
    status: {}
  2. ルートが正常に作成されたことを確認します。

    # oc get route
    NAME              HOST/PORT                    PATH      SERVICE           LABELS                    INSECURE POLICY   TLS TERMINATION
    docker-registry   registry.example.com            docker-registry   docker-registry=default
  3. レジストリーの健全性を確認します。

    $ curl -v http://registry.example.com/healthz

    HTTP 200 / OK メッセージが表示されるはずです。

    レジストリーを公開したら、ポート番号を OPTIONS エントリーに追加して /etc/sysconfig/docker ファイルを更新します。以下は例になります。

    OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'
    重要

    上記のオプションは、ログインしようとしているクライアントに追加してください。

    また、Docker がクライアント上で実行されていることも確認してください。

公開されている非セキュアなレジストリーにログインする際に、docker login コマンドでレジストリーを指定していることを確認します。以下は例になります。

# docker login -e user@company.com \
    -u f83j5h6 \
    -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
    <host>

2.5. レジストリー設定の拡張

2.5.1. レジストリー IP アドレスの維持

OpenShift Container Platform はサービス IP アドレスによって統合レジストリーを参照します。したがって docker-registry サービスを削除し、再作成しようとする場合、古い IP アドレスを新しいサービスで再利用するように調整すると、完全に透過的な移行が可能になります。新規 IP アドレスを取得することが避けられない場合は、マスターのみを再起動してクラスターの中断を最小限に抑えられます。

アドレスの再利用
IP アドレスを再利用するには、古い docker-registry サービスの IP アドレスを削除する前に保存し、新たに割り当てられた IP アドレスを、新しい docker-registry サービスに保存されているアドレスに置き換えるように調整します。
  1. サービスの clusterIP を書き留めておきます。

    $ oc get svc/docker-registry -o yaml | grep clusterIP:
  2. サービスを削除します。

    $ oc delete svc / docker-registry dc / docker-registry
  3. レジストリーの定義を registry.yaml に作成し、<options> を、たとえば「非実稼働環境での使用」のセクションの手順 3 で使用されているものなどに置き換えます。

    $ oc adm registry <options> -o yaml > registry.yaml
  4. registry.yaml を編集し、そこで Service を検索して、clusterIP を手順 1 で書き留めたアドレスに変更します。
  5. 変更した registry.yaml を使ってレジストリーを作成します。

    $ oc create -f registry.yaml
マスターの再起動
IP アドレスを再利用できない場合、古い IP アドレスを含むプル仕様を使った操作は失敗します。クラスターの中断を最小限に抑えるには、マスターを再起動する必要があります。
# master-restart api
# master-restart controllers

これで、古い IP アドレスを含む古いレジストリー URL がキャッシュからクリアされます。

注記

クラスター全体を再起動すると、Pod に不要なダウンタイムが発生し、実質、キャッシュのクリアが行われないので、これは推奨していません。

2.5.2. Docker レジストリーのホワイトリスト化

Docker レジストリーのホワイトリストを指定すると、OpenShift Container Platform ユーザーがダウンロードして入手できるイメージやテンプレートのセットをキュレートできます。このキュレートされたセットは、1 つまたは複数の Docker レジストリーに保管され、その後ホワイトリストに追加されます。ホワイトリストを使用する場合、OpenShift Container Platform からアクセスできるのは指定されたレジストリーのみで、その他すべてのレジストリーはデフォルトでアクセスが拒否されます。

ホワイトリストを設定するには、以下を実行します。

  1. /etc/sysconfig/docker ファイルを編集し、すべてのレジストリーをブロックします。

    BLOCK_REGISTRY='--block-registry=all'

    BLOCK_REGISTRY 行のコメント解除が必要となる場合があります。

  2. 同じファイルで、アクセスを許可するレジストリーを追加します。

    ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'

    レジストリーへのアクセスの許可

    ADD_REGISTRY = ' -  add-registry = registry.access.redhat.com'

    上記の例では、Red Hat カスタマーポータルで入手できるイメージへのアクセスを制限しています。

ホワイトリストが設定されると、ホワイトリストにない Docker レジストリーからプルしようとすると、許可されていないレジストリーであることを示すエラーメッセージが表示されます。

2.5.3. レジストリーのホスト名の設定

内部参照と外部参照の両方でレジストリーを認識するために使用するホスト名とポートを設定できます。これを実行すると、イメージストリームはイメージのホスト名ベースのプッシュおよびプル仕様を提供することができ、これによってイメージのコンシューマーがレジストリーのサービス IP の変更の影響を受けないようにし、イメージストリームとその参照をクラスター間で移植できる可能性があります。

クラスター内でレジストリーを参照するために使用されるホスト名を設定するには、マスター設定ファイルの imagePolicyConfig セクションで internalRegistryHostname を設定します。外部のホスト名は、同じ場所で externalRegistryHostname の値を設定することで管理されます。

イメージポリシーの設定

imagePolicyConfig:
  internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
  externalRegistryHostname: docker-registry.mycompany.com

レジストリー自体は、同じ内部ホスト名の値で設定する必要があります。これは、レジストリーのデプロイメント設定で REGISTRY_OPENSHIFT_SERVER_ADDR 環境変数を設定するか、またはレジストリー設定の OpenShift セクションで値を設定することで実行できます。

注記

レジストリーで TLS を有効にしている場合、サーバー証明書にはレジストリーの参照に使用されるホスト名が含まれている必要があります。ホスト名をサーバー証明書に追加する方法については、「レジストリーのセキュリティー保護」を参照してください。

2.5.4. レジストリー設定の上書き

統合レジストリーのデフォルトの設定 (デフォルトでは実行中のレジストリーコンテナーの /config.yml にあります) は、独自の カスタム設定で上書きできます。

注記

このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ミドルウェアのセクションは、環境変数を使って上書きできるオプションがごく少数であるため例外とします。特定の設定オプションを上書きする方法についてこちらを参照してください。

レジストリー設定ファイルの直接的な管理を可能にし、ConfigMap を使って更新された設定をデプロイするには、以下を実行します。

  1. レジストリーをデプロイします
  2. 必要に応じて、レジストリー設定ファイルをローカルで編集します。以下は、レジストリーにデプロイされている初期 YAML ファイルです。サポートされているオプションを確認してください。

    レジストリー設定ファイル

    version: 0.1
    log:
      level: debug
    http:
      addr: :5000
    storage:
      cache:
        blobdescriptor: inmemory
      filesystem:
        rootdirectory: /registry
      delete:
        enabled: true
    auth:
      openshift:
        realm: openshift
    middleware:
      registry:
        - name: openshift
      repository:
        - name: openshift
          options:
            acceptschema2: true
            pullthrough: true
            enforcequota: false
            projectcachettl: 1m
            blobrepositorycachettl: 10m
      storage:
        - name: openshift
    openshift:
      version: 1.0
      metrics:
        enabled: false
        secret: <secret>

  3. 各ファイルの内容を保持する ConfigMap をこのディレクトリーに作成します。

    $ oc create configmap registry-config \
        --from-file=</path/to/custom/registry/config.yml>/
  4. registry-config ConfigMap をボリュームとしてレジストリーのデプロイメント設定に追加し、カスタム設定ファイルを /etc/docker/registry/ にマウントします。

    $ oc volume dc/docker-registry --add --type=configmap \
        --configmap-name=registry-config -m /etc/docker/registry/
  5. 以下の環境変数をレジストリーのデプロイメント設定に追加して、直前の手順の設定パスを参照するようにレジストリーを更新します。

    $ oc set env dc/docker-registry \
        REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yml

上記の手順は、反復プロセスとして実行し、希望の設定を実現することができます。たとえば、トラブルシューティング時に、デバッグ モードに切り換えるよう設定が一時的に更新される場合があります。

既存の設定を更新するには、以下を実行します。

警告

この手順を実行すると、現在デプロイされているレジストリー設定が上書きされます。

  1. ローカルのレジストリー設定ファイル config.yml を編集します。
  2. registry-config configmap を削除します。

    $ oc delete configmap registry-config
  3. 更新された設定ファイルを参照するよう configmap を再作成します。

    $ oc create configmap registry-config\
        --from-file=</path/to/custom/registry/config.yml>/
  4. 更新された設定を読み取るためにレジストリーを再デプロイします。

    $ oc rollout latest docker-registry
ヒント

設定ファイルをソース管理リポジトリーに保持します。

2.5.5. レジストリー設定の参照

アップストリームの docker ディストリビューションライブラリーでは、多数の設定オプションを利用できます。ただし、すべての設定オプションがサポートされているか、または有効にされているわけではありません。このセクションは、レジストリー設定を上書きする際の参考としてご利用ください。

注記

このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ただし、ミドルウェアのセクションは、環境変数を使って上書きすることはできません特定の設定オプションを上書きする方法についてこちらを参照してください。

2.5.5.1. ログ

アップストリームのオプションはサポートされています。

例:

log:
  level: debug
  formatter: text
  fields:
    service: registry
    environment: staging

2.5.5.2. フック

メールフックはサポートされていません。

2.5.5.3. ストレージ

以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下の一覧には、レジストリーの設定ファイルで設定を行う必要があるストレージドライバーが含まれます。

レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。

注記

サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。

一般的なストレージ設定オプション

storage:
  delete:
    enabled: true 1
  redirect:
    disable: false
  cache:
    blobdescriptor: inmemory
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
    readonly:
      enabled: false

1
このエントリーは、イメージのプルーニングが正常に機能するために必須です。

2.5.5.4. 認証

認証オプションは変更することができません。openshift の拡張がサポートされている唯一のオプションです。

auth:
  openshift:
    realm: openshift

2.5.5.5. ミドルウェア

リポジトリーのミドルウェアの拡張を使用して、OpenShift Container Platform やイメージプロキシーとの対話を行う OpenShift Container Platform ミドルウェアの設定を行うことができます。

middleware:
  registry:
    - name: openshift 1
  repository:
    - name: openshift 2
      options:
        acceptschema2: true 3
        pullthrough: true 4
        mirrorpullthrough: true 5
        enforcequota: false 6
        projectcachettl: 1m 7
        blobrepositorycachettl: 10m 8
  storage:
    - name: openshift 9
1 2 9
これらの入力は必須です。これらの入力によって必要なコンポーネントが読み込まれていることを確認できます。これらの値は変更しないでください。
3
レジストリーへのプッシュ時に manifest schema v2 を格納できます。詳細は、こちらを参照してください。
4
レジストリーがリモート Blob のプロキシーとして機能できるようにします。詳細は、 こちらを参照してください。
5
レジストリーキャッシュの Blob がリモートレジストリーから提供されるようにし、その後の迅速なアクセスを可能にします。Blob の初回アクセス時にミラーリングが開始されます。このオプションは、プルスルーが無効にされている場合は機能しません。
6
ターゲットに設定されているプロジェクトで定義されているサイズ制限を超える Blob のアップロードを防止します。
7
レジストリーにキャッシュされている制限の有効期限のタイムアウト。値が小さいほど、制限の変更がレジストリーに伝搬するまでの時間が短くなります。ただし、レジストリーは制限をサーバーからより頻繁に照会するため、結果としてプッシュは遅くなります。
8
Blob とリポジトリー間の記憶されている関連付けの有効期限のタイムアウト。値が高いほどルックアップが高速になり、レジストリー操作がより効率的になる可能性が高くなります。一方、アクセスできなくなったユーザーにイメージレイヤーを提供するリスクと同様にメモリー使用量も上昇します。
2.5.5.5.1. S3 ドライバー設定

使用している統合レジストリーでサポートされていない S3 リージョンを使用する必要がある場合は、regionendpoint を指定して region 検証エラーを防ぐことができます。

Amazon Simple Storage Service ストレージの使用についての詳細は、「ストレージバックエンドとしての Amazon S3」を参照してください。

以下は例を示しています。

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3:
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    bucket: docker.myregistry.com
    region: eu-west-3
    regionendpoint: https://s3.eu-west-3.amazonaws.com
 auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: openshift
注記

region および regionendpoint フィールドの間に整合性があることを確認します。そうでない場合、統合レジストリーは開始されますが、S3 ストレージに対する読み取りまたは書き込みを行うことはできません。

また、Amazon S3 とは異なる S3 ストレージを使用する場合に、regionendpoint が役に立ちます。

2.5.5.5.2. CloudFront ミドルウェア

CloudFront ミドルウェア拡張は、CloudFront CDN ストレージプロバイダーである AWS をサポートするために追加することができます。CloudFront ミドルウェアは、イメージコンテンツの海外への配信を高速化します。Blob は世界中の複数のエッジロケーションに配信されます。クライアントは常に最小の待機時間でエッジにアクセスできます。

注記

CloudFront ミドルウェア拡張を使用できるストレージは S3 ストレージのみです。また、使用できるのは Blob が提供されている間のみです。したがって、高速化できるのは Blob のダウンロードのみで、アップロードは高速化しません。

以下は、CloudFront ミドルウェアを含む S3 ストレージドライバーの最小限の設定例です。

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3: 1
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    region: us-east-1
    bucket: docker.myregistry.com
auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: cloudfront 2
      options:
        baseurl: https://jrpbyn0k5k88bi.cloudfront.net/ 3
        privatekey: /etc/docker/cloudfront-ABCEDFGHIJKLMNOPQRST.pem 4
        keypairid: ABCEDFGHIJKLMNOPQRST 5
    - name: openshift
1
S3 ストレージは、CloudFront ミドルウェアに関係なく同じ方法で設定する必要があります。
2
CloudFront ストレージミドルウェアは、OpenShift ミドルウェアより前に一覧表示される必要があります。
3
CloudFront ベースの URL。AWS マネジメントコンソールでは、これは CloudFront ディストリビューションの Domain Name として一覧表示されます。
4
AWS のプライベートキーが格納されているファイルシステムの場所。Amazon EC2 のキーペアと混同しないよう注意してください。信頼される署名者の CloudFront キーペアの作成については、AWS ドキュメントを参照してください。このファイルは、レジストリー Pod にシークレットとしてマウントする必要があります。
5
Cloudfront キーペアの ID。
2.5.5.5.3. ミドルウェア設定オプションの上書き

middleware セクションは、環境変数を使って上書きできません。ただし例外がいくつかあります。以下は例になります。

middleware:
  repository:
    - name: openshift
      options:
        acceptschema2: true 1
        pullthrough: true 2
        mirrorpullthrough: true 3
        enforcequota: false 4
        projectcachettl: 1m 5
        blobrepositorycachettl: 10m 6
1
ブール環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2 で上書きできる設定オプション。manifest schema v2 をマニフェストの Put 要求で 受け入れる機能を有効にします。認識される値は truefalse (以下の他のすべてのブール変数に適用されます) になります。
2
ブール環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PULLTHROUGH で上書きできる設定オプション。リモートレジストリーのプロキシーモードを有効にします。
3
ブール環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_MIRRORPULLTHROUGH で上書きできる設定オプション。リモート Blob が提供されている場合、レジストリーに対して Blob をローカルにミラーリングするように指示します。
4
ブール環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA で上書きできる設定オプション。クォータ実施をオンまたはオフにする機能を有効にします。デフォルトでは、クォータの実施はオフになっています。
5
環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PROJECTCACHETTL で上書きできる設定オプション。プロジェクトのクォータオブジェクトのエビクションタイムアウトを指定します。有効な時間文字列 (例: 2m) を取ります。空白の場合は、デフォルトのタイムアウトが取得されます。ゼロ (0m) の場合、キャッシングは無効にされます。
6
環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_BLOBREPOSITORYCACHETTL で上書きできる設定オプション。Blob と含まれているレポジトリーの関連付けについてのエビクションタイムアウトを指定します。値のフォーマットは projectcachettl のケースと同じです。
2.5.5.5.4. イメージのプルスルー

この機能を有効にすると、Blob がローカルに存在しない限り、レジストリーは要求された Blob をリモートレジストリーから取得しようと試みます。リモートの候補は、クライアントがプルする イメージストリームの状態で保存された DockerImage エントリーから算出されます。このエントリーのすべての固有のリモートレジストリーの参照は Blob が見つかるまで繰り返し試行されます。

プルスルーは、プルされているイメージのイメージストリームタグが存在する場合にのみ発生します。たとえば、プルされているイメージが docker-registry.default.svc:5000/yourproject/yourimage:prod である場合、レジストリーは、プロジェクト yourprojectyourimage:prod という名前のイメージストリームタグを検索します。タグが見つかると、レジストリーはそのイメージストリームタグに関連付けられた dockerImageReference を使ってイメージのプルを試行します。

プルスルーを実行すると、レジストリーは、参照されているイメージストリームタグに関連付けられたプロジェクトにあるプル認証情報を使用します。また、この機能を使用すると、ユーザーは、イメージを参照しているイメージストリームタグにアクセスできる限り、アクセスに必要な認証情報を持たないレジストリーのイメージをプルすることができます。

使用しているレジストリーに、プルスルーの実行対象である外部レジストリーを信頼するのに必要な証明書があることを確認してください。証明書は Pod の /etc/pki/tls/certs ディレクトリーに配置する必要があります。証明書は設定マップまたはシークレットを使ってマウントできます。ここで、/etc/pki/tls/certs ディレクトリー全体を置き換える必要があることに注意してください。新しい証明書を組み込み、マウントするシークレットまたは設定マップのシステム証明書を置き換えます。

デフォルトでは、イメージストリームタグは Source の参照ポリシータイプを使用することに注意してください。これは、イメージストリームの参照がイメージのプル仕様に対して解決される場合、使用される仕様はイメージのソースを参照することを意味します。外部レジストリーでホストされているイメージであれば、外部レジストリーが参照され、この結果としてリソースは外部レジストリーでイメージを参照し、プルします。この場合、registry.access.redhat.com/openshift3/jenkins-2-rhel7 とプルスルーは適用されません。イメージストリームを参照しているリソースが内部レジストリーを参照しているプル仕様を使用するようにするには、イメージストリームタグは Local の参照ポリシータイプを使用する必要があります。詳細は、「参照ポリシー」を参照してください。

この機能はデフォルトでオンになっています。ただし、設定オプションを使って無効にすることができます。

デフォルトでは、この方法で提供されるすべてのリモート Blob は、mirrorpullthrough が無効にされていない限りローカルに格納され、その後のアクセスが高速になります。ミラーリング機能の欠点はストレージの使用量が増えることにあります。

注記

ミラーリングは、クライアントが Blob を 1 バイト以上取得しようとする際に開始されます。実際に必要になる前に、特定イメージを統合レジストリーに事前にフェッチするには、以下のコマンドを実行します。

$ oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
  xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
  http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}
注記

OpenShift Container Platform のミラーリング機能をアップストリームの レジストリーのプルスルーキャッシュ機能と混同しないようにしてください。これらは似ていますが、全く異なる機能です。

2.5.5.5.5. Manifest Schema v2 サポート

各イメージには、Blob を記述するマニフェスト、それを実行するための命令、および追加のメタデータがあります。マニフェストはバージョン管理されており、バージョンごとに構造やフィールドが異なります。同一イメージが複数のマニフェストバージョンで表現されます。それぞれのバージョンはそれぞれ異なるダイジェストがあります。

現在サポートされているレジストリーは manifest v2 schema 1 (schema1) と manifest v2 schema 2 (schema2) です。前者は古くなっていますが、今後もしばらくはサポートされます。

各種の Docker クライアントとの互換性の問題に注意する必要があります。

  • Docker クライアントのバージョン 1.9 以前は、schema1 のみをサポートしています。このクライアントがプルまたはプッシュするマニフェストはレガシースキーマになります。
  • Docker クライアントのバージョン 1.10 は、schema1schema2 の両方をサポートしています。デフォルトでは、新しい方のスキーマをサポートする場合はこちらをレジストリーにプッシュします。

イメージを schema1 で格納するレジストリーは、常にイメージを変更せずにクライアントに返します。Schema2 は新規の Docker クライアントにのみ変更しない状態で移動します。古いクライアントの場合は、オンザフライで schema1 に変換されます。

これにより、大きな影響が想定されます。たとえば、新規 Docker クライアントでレジストリーにプッシュされたイメージは、古い Docker のダイジェストでプルすることはできません。格納されたイメージのマニフェストは schema2 であり、そのダイジェストはこのバージョンのマニフェストをプルする場合にのみ使用できるためです。

このため、レジストリーはデフォルトでは schema2 を格納しないように設定されています。これにより、すべての Docker クライアントはクライアントのバージョンに関係なく、プッシュされたイメージをレジストリーからプルできます。

すべてのレジストリークライアントが schema2 をサポートしていることを確認できたら、そのサポートをレジストリーで有効にすることができます。特定のオプションについては、上記の「ミドルウェア設定の参照」を参照してください。

2.5.5.6. OpenShift

このセクションでは、OpenShift Container Platform に特有の機能のグローバル設定について説明します。今後のリリースでは、 Middleware セクションにある openshift 関連の設定は廃止される予定です。

現在、このセクションではレジストリーメトリクスの収集を設定できます。

openshift:
  version: 1.0 1
  server:
    addr: docker-registry.default.svc 2
  metrics:
    enabled: false 3
    secret: <secret> 4
  requests:
    read:
      maxrunning: 10 5
      maxinqueue: 10 6
      maxwaitinqueue 2m 7
    write:
      maxrunning: 10 8
      maxinqueue: 10 9
      maxwaitinqueue 2m 10
1
このセクションの設定バージョンを指定する必須エントリー。サポートされている値は 1.0 のみです。
2
レジストリーのホスト名。マスターで設定されている値と同じ値に設定される必要があります。これは環境変数 REGISTRY_OPENSHIFT_SERVER_ADDR で上書きされる可能性があります。
3
メトリクスの収集を有効にするには true に設定します。これはブール環境変数 REGISTRY_OPENSHIFT_METRICS_ENABLED で上書きされる可能性があります。
4
クライアント要求の承認に使用されるシークレット。メトリクスのクライアントは これを Authorization ヘッダーでベアラートークンとして使用します。環境変数 REGISTRY_OPENSHIFT_METRICS_SECRET で上書きできます。
5
同時に行えるプル要求の最大数。環境変数 REGISTRY_OPENSHIFT_REQUESTS_READ_MAXRUNNING で上書きできます。ゼロは無制限を意味します。
6
キューに入れられるプル要求の最大数。環境変数 REGISTRY_OPENSHIFT_REQUESTS_READ_MAXINQUEUE で上書きできます。ゼロは無制限を意味します。
7
拒否されるまでのキューにあるプル要求の最大待機時間。環境変数 REGISTRY_OPENSHIFT_REQUESTS_READ_MAXWAITINQUEUE で上書きできます。ゼロは無制限を意味します。
8
同時に行えるプッシュ要求の最大数。環境変数 REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXRUNNINGで上書きできます。ゼロは無制限を意味します。
9
キューにあるプッシュ要求の最大数。環境変数 REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXINQUEUE で上書きできます。ゼロは無制限を意味します。
10
拒否されるまでのキューにあるプッシュ要求の最大待機時間。環境変数 REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXWAITINQUEUE で上書きできます。ゼロは無制限を意味します。

使用状況の情報については レジストリーメトリクスへのアクセスを参照してください。

2.5.5.7. レポート (Reporting)

レポート (Reporting) はサポートされていません。

2.5.5.8. HTTP

アップストリームのオプションはサポートされています。環境変数を使って設定を変更する方法についてはこちらを参照してください。変更の必要があるのは tls セクションのみです。以下は例になります。

http:
  addr: :5000
  tls:
    certificate: /etc/secrets/registry.crt
    key: /etc/secrets/registry.key

2.5.5.9. 通知

アップストリームのオプションはサポートされています。REST API リファレンス はより包括的な統合オプションを提供します。

例:

notifications:
  endpoints:
    - name: registry
      disabled: false
      url: https://url:port/path
      headers:
        Accept:
          - text/plain
      timeout: 500
      threshold: 5
      backoff: 1000

2.5.5.10. Redis

Redis はサポートされていません。

2.5.5.11. 健全性

アップストリームのオプションはサポートされています。レジストリーのデプロイメント設定は、 /healthz で統合されたヘルスチェックを提供します。

2.5.5.12. プロキシー

プロキシー設定は有効にできません。この機能は OpenShift Container Platform リポジトリーのミドルウェア拡張pullthrough: true で提供されます。

2.5.5.13. キャッシュ

統合レジストリーは、データをアクティブにキャッシュして、速度の遅い外部リソースに対する呼び出しの回数を減らします。キャッシュには 2 種類あります。

  1. Blob のメタデータのキャッシュに使用されるストレージキャッシュ。このキャッシュには有効期限がなく、データは明示的に削除されるまで残り続けます。
  2. アプリケーションキャッシュには、Blob とリポジトリーの関連付けが含まれます。このキャッシュ内のデータには有効期限があります。

キャッシュを完全にオフににするには設定を変更する必要があります。

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache: {} 1
openshift:
  version: 1.0
  cache:
    disabled: true 2
    blobrepositoryttl: 10m
1
ストレージのバックエンドでアクセスしたメタデータのキャッシュを無効にします。このキャッシュがない場合、レジストリーサーバーはメタデータのバックエンドに絶えずアクセスします。
2
Blob とリポジトリーの関連付けを含むキャッシュを無効にします。このキャッシュがない場合、レジストリーサーバーは継続的にマスター API のデータを照会し、関連付けを再計算します。

2.6. 既知の問題

2.6.1. 概要

以下は、統合レジストリーのデプロイまたは使用時の既知の問題です。

2.6.2. レジストリーのプルスルーに伴う同時ビルド

ローカルの docker-registry デプロイメントは追加の負荷を受けます。デフォルトで、ここでは registry.access.redhat.com からのコンテンツをキャッシュするようになりました。STI ビルドの registry.access.redhat.com のイメージはローカルレジストリーに保存されます。それらをプルしようとすると、ローカル docker-registry からのプルが試行され。その結果として、過剰な数の同時ビルドがプルでタイムアウトになり、ビルドが失敗する可能性のある状況になります。この問題を軽減するには、docker-registry デプロイメントを複数のレプリカにスケーリングします。Pod のログでタイムアウトの有無をチェックします。

2.6.3. 共有 NFS ボリュームとスケーリングされたレジストリーの使用時のイメージのプッシュエラー

スケーリングされたレジストリーを共有 NFS ボリュームで使用すると、イメージのプッシュ時に以下のいずれかのエラーが発生することがあります。

  • digest invalid: provided digest did not match uploaded content
  • blob upload unknown
  • blob upload invalid

これらのエラーは、Docker のイメージのプッシュの試行時に内部レジストリーサービスによって返されます。その原因は、ノード間のファイル属性の同期に起因します。NFS クライアント側のキャッシング、ネットワーク待機時間およびレイヤーサイズなどはすべて、デフォルトのラウンドロビンロードバランシング設定を使用してイメージをプッシュする際に発生するエラーの要因になる可能性があります。

このような障害の可能性を最小限に抑えるには、以下の手順を実行します。

  1. docker-registry サービスの sessionAffinityClientIP に設定されていることを確認します。

    $ oc get svc / docker-registry --template = '{{。spec.sessionAffinity}}'

    これにより ClientIP が返されるはずです。ClientIP は OpenShift Container Platform の最近のバージョンのデフォルトです。これが返されない場合は、以下のように変更してください。

    $ oc patch svc / docker-registry -p '{' spec ':{' sessionAffinity ':' ClientIP '}}'
  2. NFS サーバー上のレジストリーボリュームの NFS エクスポート行に no_wdelay オプションが一覧表示されていることを確認します。no_wdelay オプションは、サーバーによる書き込みの遅延を防ぎ、このレジストリーの要件である、書き込み直後の読み取りの整合性を大幅に改善します。
重要

テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。

他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。

2.6.4. 内部で管理されたイメージのプルに失敗し「見つかりません (not found)」のエラーが表示される

このエラーは、プルされたイメージがプルしたイメージストリームとは異なるイメージストリームにプッシュされた場合に発生します。これは、ビルドされたイメージを任意のイメージストリームに再タグ付けすることによって発生します。

$ oc tag srcimagestream:latest anyproject/pullimagestream:latest

その後、以下のようなイメージ参照を使用してプルします。

internal.registry.url:5000 / anyproject / pullimagestream:latest

Docker を手動でプルするときにも同様のエラーが発生します。

Error: image anyproject/pullimagestream:latest not found

このエラーを防ぐには、内部で管理されたイメージのタグ付けを完全に避けるか、またはビルドしたイメージを必要な namespace に 手動で再プッシュします。

2.6.5. S3 ストレージでのイメージのプッシュが失敗し「500 内部サーバーエラー (500 Internal Server Error)」と表示される

レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます。 Docker レジストリーへのプッシュは、以下のエラーを出して失敗することがあります。

Received unexpected HTTP status: 500 Internal Server Error

これをデバッグするには、レジストリーのログを表示する必要があります。ログで、プッシュの失敗時に発生した同様のエラーメッセージを探します。

time="2016-03-30T15:01:21.22287816-04:00" level=error msg="unknown error completing upload: driver.Error{DriverName:\"s3\", Enclosed:(*url.Error)(0xc20901cea0)}" http.request.method=PUT
...
time="2016-03-30T15:01:21.493067808-04:00" level=error msg="response completed with error" err.code=UNKNOWN err.detail="s3: Put https://s3.amazonaws.com/oso-tsi-docker/registry/docker/registry/v2/blobs/sha256/ab/abe5af443833d60cf672e2ac57589410dddec060ed725d3e676f1865af63d2e2/data: EOF" err.message="unknown error" http.request.method=PUT
...
time="2016-04-02T07:01:46.056520049-04:00" level=error msg="error putting into main store: s3: The request signature we calculated does not match the signature you provided. Check your key and signing method." http.request.method=PUT
atest

このようなエラーを確認した場合には、Amazon S3 サポートにお問い合わせください。リージョンや特定のバケットで問題がある可能性があります。

2.6.6. イメージのプルーニングの失敗

イメージのプルーニング時に以下のエラーが発生した場合:

BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob

さらに、レジストリーのログに以下の情報が含まれている場合。

error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported

上記に該当する場合、お使いのカスタム設定ファイルにはストレージセクションに必須のエントリー、つまり true に設定された storage:delete:enabled が含まれていないことを意味します。これらを追加し、レジストリーを再デプロイして、再度イメージプルーニングの操作を行ってください。

第3章 ルーターのセットアップ

3.1. ルーターの概要

3.1.1. ルーターについて

トラフィックをクラスターに送る方法は多数あります。最も一般的な方法として、 OpenShift Container Platform インストールで OpenShift Container Platform ルーターを、サービス向けの外部トラフィックの ingress ポイントとして使用できます。

OpenShift Container Platform は以下のルータープラグインを提供し、サポートしています。

  • HAProxy テンプレートルーターはデフォルトのプラグインです。これは、openshift3/ose-haproxy-router イメージを使用して、OpenShift Container Platform のコンテナーにあるテンプレートルータープラグインと共に HAProxy インスタンスを実行します。現在は、HTTP(S) トラフィックと SNI を使用した TLS 対応のトラフィックをサポートしています。ルーターのコンテナーは、プライベート IP でのみリッスンする多数のコンテナーとは異なり、ホストのネットワークインターフェースでリッスンします。ルーターは、ルートに関連付けられたサービスで識別される実際の Pod の IP に対するルート名の外部要求をプロキシー処理します。
  • F5 ルーターは、ルートを同期するためにお使いの環境で既存の F5 BIG-IP® システムに統合されます。F5 iControl REST API を使用するには、F5 BIG-IP® バージョン 11.4 以降が必要です。
注記

F5 ルータープラグインは OpenShift Container Platform 3.0.2 以降で利用できます。

3.1.2. ルーターのサービスアカウント

OpenShift Container Platform クラスターをデプロイする前に、ルーターのサービスアカウントを用意しておく必要があります。これには、クラスターのインストール時に自動的に作成されます。このサービスアカウントには、ホストのポートの指定に使用できる SCC (security context constraints) へのパーミッションがあります。

3.1.2.1. ラベルにアクセスするためのパーミッション

namespace ラベルが使用されている場合 (ルーターシャードを作成している場合など)、ルーターのサービスアカウントにはcluster-reader のパーミッションが必要になります。

$ oc adm policy add-cluster-role-to-user \
    cluster-reader \
    system:serviceaccount:default:router

サービスアカウントを準備したら、デフォルト HAProxy ルーターカスタマイズ HAProxy ルーター、または F5 ルーターのインストールに進むことができます。

3.2. デフォルト HAProxy ルーターの使用

3.2.1. 概要

oc adm router コマンドには、新規インストールでのルーターのセットアップタスクを単純化する管理者 CLI が提供されます。oc adm router コマンドは、サービスとデプロイメント設定オブジェクトを作成します。 --service-account オプションを使用して、ルーターがマスターとの通信で使用するサービスアカウントを指定します。

ルーターサービスアカウントは事前に作成するか、oc adm router --service-account コマンドで作成することができます。

OpenShift Container Platform コンポーネント間のあらゆる形式の通信は TLS によって保護され、各種の証明書や認証方法を使用します。--default-certificate .pem フォーマットファイルは提供されるか、または oc adm router コマンドで作成されます。ルートが作成されると、ユーザーはルートの処理時にルーターが使用するルート証明書を提供できるようになります。

重要

ルーターを削除する際に、デプロイ設定やサービス、およびシークレットも削除されていることを確認します。

ルーターは特定のノードにデプロイされます。これにより、クラスター管理者と外部ネットワークマネージャーはどの IP アドレスがルーターを実行し、ルーターがどのトラフィックを処理するかについて調整しやすくなります。ノードセレクターを使用してルーターを特定のノードにデプロイします。

重要

ルーターはデフォルトでホストネットワークを使用し、ホストのすべてのインターフェースのポート 80 と 443 に直接割り当てられます。ポート 80/443 が利用できるホストにルーターを制限し、他のサービスに使用されないようにします。これはノードセレクタースケジューラー設定を使用して設定します。たとえば、これはルートなどのサービスの実行用として専用のインフラストラクチャーノードを設定することで実行できます。

重要

お使いのルーターで個別の openshift-router サービスアカウントを使用することをお勧めします。--service-account フラグを oc adm router コマンドで使用してこれを指定できます。

$ oc adm router --dry-run --service-account=router 1
1
--service-account は、openshift-routerサービスアカウントの名前です。
重要

oc adm router を使用して作成されるルーター Pod には、ルーター Pod がデプロイされるためにノードが満たさなければならないデフォルトのリソース要求が設定されます。デフォルトのリソース要求は、インフラストラクチャーコンポーネントの信頼性を向上させる取り組みとして、ルーター Pod の QoS 層をリソース要求を持たない Pod よりも高く設定するために使用されます。デフォルト値は、基本的なルーターがデプロイされるのに必要な最小限のリソースを表しており、ルーターデプロイメント設定で編集できます。また、ルーターの負荷に基づいてそれらの値を引き上げることもできます。

3.2.2. ルーターの作成

ルーターが存在しない場合は、以下を実行してルーターを作成します。

$ oc adm router <router_name> --replicas=<number> --service-account=router

高可用性の設定が作成されない限り、--replicas は通常 1 になります。

ルーターのホスト IP アドレスを見つけるには、以下を実行します。

$ oc get po <router-pod>  --template={{.status.hostIP}}

また、ルーターシャードを使用して、ルーターを特定の namespace またはルートに絞り込むか、ルーターの作成後に環境変数を設定できます。この場合には、シャードごとにルーターを作成します。

3.2.3. その他の基本ルーターコマンド

デフォルトルーターの確認
router という名前のデフォルトのルーターサービスアカウントは、クラスターのインストール時に自動的に作成されます。このアカウントがすでに存在することを確認するには、以下を実行します。
$ oc adm router --dry-run --service-account=router
デフォルトルーターの表示
デフォルトルーターが作成されている場合でそれを確認するには、以下を実行します。
$ oc adm router --dry-run -o yaml --service-account=router
ラベル付けされたノードへのルーターのデプロイ
指定されたノードラベルに一致するノードにルーターをデプロイするには、以下を実行します。
$ oc adm router <router_name> --replicas=<number> --selector=<label> \
    --service-account=router

たとえば、router という名前のルーターを作成し、それを node-role.kubernetes.io/infra=true とラベルが付けられたノードに配置するには、以下を実行します。

$ oc adm router router --replicas=1 --selector='node-role.kubernetes.io/infra=true' \
  --service-account=router

クラスターのインストール時に、openshift_router_selector および openshift_registry_selector の Ansible 設定はデフォルトで node-role.kubernetes.io/infra=true に設定されます。デフォルトのルーターおよびレジストリーは、node-role.kubernetes.io/infra=true ラベルに一致するノードがある場合にのみ自動的にデプロイされます。

ラベルの更新に関する情報については、「Updating Labels on Nodes」を参照してください。

複数のインスタンスがスケジューラーポリシーに従って複数の異なるホストに作成されます。

複数の異なるルーターイメージの使用
複数の異なるルーターイメージを使用し、使用されるルーター設定を表示するには、以下を実行します。
$ oc adm router <router_name> -o <format> --images=<image> \
    --service-account=router

以下は例を示しています。

$ oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
    --service-account=router

3.2.4. ルートを特定のルーターに絞り込む

ROUTE_LABELS 環境変数を使用してルートを絞り込むことで、特定のルーターによってのみ使用されるようにできます。

たとえば、複数のルーターと 100 のルートがある場合、ラベルをルートに割り当てることで、それらの一部を 1 つのルーターで処理し、残りを別のルーターで処理するようにできます。

  1. ルーターの作成後に、ROUTE_LABELS 環境変数を使用してルーターにタグ付けします。

    $ oc env dc/<router=name>  ROUTE_LABELS="key=value"
  2. ラベルを必要なルートに追加します。

    oc label route <route=name> key=value
  3. ラベルがルートに割り当てられていることを確認するには、ルートの設定をチェックします。

    $ oc describe route/<route_name>
同時接続の最大数の設定
ルーターはデフォルトで最大 20000 の接続を処理できるようになっています。この上限は必要に応じて変更できます。接続が少なすぎると、ヘルスチェックが機能せず、不必要な再起動が実行されます。システムをこの接続の最大数に対応するように設定する必要があります。'sysctl fs.nr_open''sysctl fs.file-max' に示される上限は十分に大きな値である必要があります。そうでない場合には HAproxy は起動しません。

ルーターを作成したら、--max-connections= オプションで必要な上限を設定します。

$ oc adm router --max-connections=10000   ....

ルーターのデプロイメント設定で ROUTER_MAX_CONNECTIONS 環境変数を編集し、値を変更します。ルーター Pod は新しい値で再起動されます。ROUTER_MAX_CONNECTIONS が存在しない場合は、デフォルト値の 20000 が使用されます。

注記

接続にはフロントエンドおよび内部バックエンドが含まれます。これは 2 つの接続としてカウントされます。必ず ROUTER_MAX_CONNECTIONS の値を作成しようとしている接続数の 2 倍以上になるように設定してください。

3.2.5. HAProxy Strict SNI

HAProxy strict-sni は、ルーターのデプロイメント設定の ROUTER_STRICT_SNI 環境変数によって管理できます。また、これは --strict-sni コマンドラインオプションを使用してルーターを作成する時にも設定できます。

$ oc adm router --strict-sni

3.2.6. TLS 暗号化スイート

ルーターの作成時に --ciphers オプションを使用して、ルーターの暗号化スイートを設定します。

$ oc adm router --ciphers=modern   ....

値は modernintermediate、または old で、デフォルトは intermediateです。または、 ":" で区切られた暗号セットを指定することもできます。暗号は以下によって表示されるセットから取られたものである必要があります。

$ openssl ciphers

また、既存のルーターには ROUTER_CIPHERS 環境変数を使用します。

3.2.7. 高可用性ルーター

IP フェイルオーバーを使用して OpenShift Container Platform クラスターで高可用性ルーターをセットアップできます。このセットアップには複数の異なるノードの複数のレプリカが含まれるため、フェイルオーバーソフトウェアは現在のレプリカが失敗したら別のレプリカに切り替えることができます。

3.2.8. ルーターサービスポートのカスタマイズ

環境変数の ROUTER_SERVICE_HTTP_PORTROUTER_SERVICE_HTTPS_PORT を設定することで、テンプレートルーターがバインドするサービスポートをカスタマイズできます。これは、テンプレートルーターを作成し、そのデプロイメント設定を編集することで実行できます。

以下の例では、0 レプリカのルーターデプロイメントを作成し、ルーターサービス HTTP と HTTPS ポートをカスタマイズし、これを適切に (1 レプリカに) スケーリングしています。

$ oc adm router --replicas=0 --ports='10080:10080,10443:10443' 1
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080  \
                   ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1
1
公開されるポートがコンテナーネットワークモード --host-network=false を使用するルーターに対して適切に設定されていることを確認します。
重要

テンプレートルーターサービスポートをカスタマイズする場合は、ルーター Pod が実行されるノードのファイアウォールでカスタムポートが開いているようにする必要があります (Ansible または iptables のいずれか、または firewall-cmd で使用するその他のカスタム方法を使用します)。

以下は、カスタムルーターサービスポートを開くために iptables を使用した例です。

$ iptables -A INPUT -p tcp --dport 10080 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 10443 -j ACCEPT

3.2.9. 複数ルーターの使用

管理者は同じ定義を使用して複数のルーターを作成し、同じルートのセットを提供することができます。各ルーターは複数の異なるノードに置かれ、異なる IP アドレスを持ちます。ネットワーク管理者は、各ノードに必要なトラフィックを送る必要があります。

複数のルーターをグループ化して、クラスター内や複数テナントでのルーティングの負荷を別のルーターまたはシャードに分散することができます。グループの各ルーターまたはシャードは、ルーターのセレクターに基づいてルートを許可します。管理者は ROUTE_LABELS を使用してクラスター全体でシャードを作成できます。ユーザーは NAMESPACE_LABELS を使用して namespace (プロジェクト) でシャードを作成できます。

3.2.10. デプロイメント設定へのノードセレクターの追加

特定のルーターを特定のノードにデプロイするには、2 つの手順を実行する必要があります。

  1. ラベルを必要なノードに追加します。

    $ oc label node 10.254.254.28 "router=first"
  2. ノードセレクターをルーターのデプロイメント設定に追加します。

    $ oc edit dc <deploymentConfigName>

    template.spec.nodeSelector フィールドに、ラベルに対応するキーと値を追加します。

    ...
      template:
        metadata:
          creationTimestamp: null
          labels:
            router: router1
        spec:
          nodeSelector:      1
            router: "first"
    ...
    1
    router=first ラベルに対応するキーと値はそれぞれ routerfirst になります。

3.2.11. ルーターシャードの使用

ルーターのシャード化 により、NAMESPACE_LABELSROUTE_LABELS を使用してルーターの namespace とルートの絞り込みが実行されます。これにより、複数のルーターデプロイメントでルートのサブセットを分散させることができます。重複しないサブセットを使用することにより、ルートセットのパーティション設定を効果的に行うことができます。または、重複するルートのサブセットを構成する複数のシャードを定義することもできます。

デフォルトで、ルーターはすべてのプロジェクト (namespace) からすべてのルートを選択します。シャード化によってラベルがルートまたはルーターの namespace およびラベルセレクターに追加されます。各ルーターシャードは特定のラベルのセットで選択されるルーターを構成するか、または特定のラベルセレクターで選択される namespace に属します。

注記

ルーターサービスアカウントには [cluster reader] パーミッションセットを設定し、他の namespace のラベルにアクセスできるようにする必要があります。

ルーターのシャード化および DNS

外部 DNS サーバーは要求を必要なシャードにルートするために必要となるので、管理者はプロジェクトの各ルーターに個別の DNS エントリーを作成する必要があります。ルーターは不明なルートを別のルーターに転送することはありません。

以下は例を示しています。

  • Router A はホスト 192.168.0.5 にあり、*.foo.com のルートを持つ。
  • Router B はホスト 192.168.1.9 にあり、*.example.com のルートを持つ。

各 DNS エントリーは *.foo.com を Router A をホストするノードに解決し、*.example.com を Router B をホストするノードに解決する必要があります。

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9

ルーターのシャード化の例

このセクションでは、namespace およびルートラベルを使用するルーターのシャード化について説明します。

図3.1 namespace ラベルに基づくルーターのシャード化

Router Sharding Based on Namespace Labels
  1. namespace ラベルセレクターでルーターを設定します。

    $ oc set env dc/router NAMESPACE_LABELS="router=r1"
  2. ルーターには namespace にセレクターがあるため、ルーターは一致する namespace のルートのみを処理します。このセレクターが namespace に一致するようにするには、namespace に適宜ラベルを付けます。

    $ oc label namespace default "router=r1"
  3. ルートをデフォルトの namespace に作成すると、ルートはデフォルトのルーターで利用できるようになります。

    $ oc create -f route1.yaml
  4. 新規プロジェクト (namespace) を作成し、route2 というルートを作成します。

    $ oc new-project p1
    $ oc create -f route2.yaml

    ルートがルーターで利用できないことを確認します。

  5. namespace p1router=r1 のラベルを付けます。

    $ oc label namespace p1 "router=r1"

このラベルを追加すると、ルートはルーターで利用できるようになります。

ルーターのデプロイメント finops-router はルートセレクター NAMESPACE_LABELS="name in (finance, ops)" を使用して設定され、ルーターのデプロイメント dev-router はラベルセレクター NAMESPACE_LABELS="name=dev" を使用して設定されます。

すべてのルートが name=financename=ops、および name=dev というラベルの付けられた namespace にある場合、この設定により、2 つのルーターのデプロイメント間でルートが効果的に分散されます。

上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。

ルート選択の基準によって、ルートの分散方法が決まります。複数のルーターデプロイメントに重複するルートのサブセットを設定することも可能です。

上記の例では finops-routerdev-router のほかに devops-router があり、これはラベルセレクター NAMESPACE_LABELS="name in (dev, ops)" を使用して設定されます。

name=dev または name=ops というラベルが付けられた namespace のルートは 2 つの異なるルーターデプロイメントによって提供されるようになりました。これは、「namespace ラベルに基づくルーターのシャード化」の手順で説明されているように、ルートの重複するサブセットを定義するケースです。

また、これによりさらに複雑なルーティングルールを作成し、優先度の高いトラフィックを専用の finops-router に転送し、優先度の低いトラフィックは devops-router に送信できます。

ルートのラベルに基づくルーターのシャード化

NAMESPACE_LABELS によって、提供するプロジェクトをフィルターでき、それらのプロジェクトからすべてのルートを選択できますが、ルートはルート自体に関連する他の基準に基づいてパーティション設定する必要がある場合があります。ROUTE_LABELS セレクターを使用すると、ルート自体を細かくフィルターできます。

ルーターデプロイメント prod-router はルートセレクター ROUTE_LABELS="mydeployment=prod" を使用して設定され、ルーターデプロイメント devtest-router はラベルセレクター ROUTE_LABELS="mydeployment in (dev, test)" を使用して設定されます。

この設定は、namespace の種類を問わず、ルートのラベルに基づいて 2 つのルーターデプロイメント間でルートのパーティション設定を行います。

この例では、提供されるルートすべてがラベル "mydeployment=<tag>" でタグ付けされていることを想定しています。

3.2.11.1. ルーターシャードの作成

このセクションでは、ルーターシャードのさらに詳細な例を示します。さまざまなラベルを持つ a — z という 26 のルートがあることを想定してください。

ルートで使用可能なラベル

sla=high       geo=east     hw=modest     dept=finance
sla=medium     geo=west     hw=strong     dept=dev
sla=low                                   dept=ops

これらのラベルは、サービスレベルアグリーメント、地理的な場所、ハードウェア要件、部門などの概念を表しています。ルートは各列のラベルを最大 1 つ持つことができます。ルートによっては他のラベルを持つことことも、ラベルをまったく持たないこともあります。

名前SLAGeo (地理的な場所)HWDept (部門)その他のラベル

a

high

east

modest

finance

type=static

b

 

west

strong

 

type=dynamic

c, d, e

low

 

modest

 

type=static

g — k

medium

 

strong

dev

 

l — s

high

 

modest

ops

 

t — z

 

west

  

type=dynamic

これは oc adm routeroc set envoc scale がどのように連携してルーターシャードを作成するかを表している便利なスクリプト mkshard です。

#!/bin/bash
# Usage: mkshard ID SELECTION-EXPRESSION
id=$1
sel="$2"
router=router-shard-$id           1
oc adm router $router --replicas=0  2
dc=dc/router-shard-$id            3
oc set env   $dc ROUTE_LABELS="$sel"  4
oc scale $dc --replicas=3         5
1
作成されたルーターは router-shard-<id> という名前を持ちます。
2
ここではスケーリングを指定しません。
3
ルーターのデプロイメント設定。
4
oc set env を使用して選択式を設定します。選択式は環境変数 ROUTE_LABELS の値です。
5
拡張します。

mkshard を複数回実行して、複数のルーターを作成します。

ルーター選択式ルート

router-shard-1

sla=high

a, l — s

router-shard-2

geo=west

b, t — z

router-shard-3

dept=dev

g — k

3.2.11.2. ルーターシャードの変更

ルーターシャードはラベルに基づいた構成なので、(oc label を使用して) ラベルまたは (oc set env を使用して) 選択式のいずれかを変更できます。

このセクションでは「ルーターシャードの作成」セクションで扱った例をさらに詳細に取り上げ、選択式の変更方法を示します。

これは、新規の選択式を使用できるよう既存のルーターを変更する便利なスクリプト modshard です。

#!/bin/bash
# Usage: modshard ID SELECTION-EXPRESSION...
id=$1
shift
router=router-shard-$id       1
dc=dc/$router                 2
oc scale $dc --replicas=0     3
oc set env   $dc "$@"             4
oc scale $dc --replicas=3     5
1
変更後のルーターの名前は router-shard-<id> になります。
2
変更が発生するデプロイメント設定。
3
縮小します。
4
oc set env を使用して新しい選択式を設定します。「ルーターシャードの作成」セクションの mkshard とは異なり、modshardID 以外の引数として指定される選択式には環境変数名とその値が含まれている必要があります。
5
拡大して元に戻します。
注記

modshard では、router-shard-<id>デプロイメントストラテジーローリングの場合、oc scale コマンドは不要です。

たとえば router-shard-3 の部門を拡張して opsdev を含めるには、以下を実行します。

$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'

結果として、router-shard-3 はルート g — s (g — kl — s の組み合わせ) を選択します。

この例ではシャードから除外する 1 つの部門を指定します。このシナリオ例では 3 つの部門しかないため、これによって前述の例と同じ結果が得られます。

$ modshard 3 ROUTE_LABELS='dept != finance'

この例は 3 つのコンマで区切られた属性を指定しており、結果としてルート b のみが選択されます。

$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'

ルートのラベルを使用する ROUTE_LABELS と同様に、NAMESPACE_LABELS 環境変数を使用して、ルートはルートの namespace ラベルのラベルに基づいて選択できます。この例では、ラベル frequency=weekly を持つルートの namespace を提供するように router-shard-3 を変更します。

$ modshard 3 NAMESPACE_LABELS='frequency=weekly'

最後の例は ROUTE_LABELSNAMESPACE_LABELS を組み合わせて、ラベルsla=low を持ち、ラベル frequency=weekly を持つ namespace のルート選択します。

$ modshard 3 \
    NAMESPACE_LABELS='frequency=weekly' \
    ROUTE_LABELS='sla=low'

3.2.12. ルーターのホスト名の検索

サービスを公開する際に、ユーザーは外部ユーザーがアプリケーションにアクセスするために使用する DNS 名からの同じルートを使用できます。外部ネットワークのネットワーク管理者は、ホスト名がルートを許可したルーター名に解決することを確認する必要があります。ユーザーはこのホスト名を指す CNAME を使用して DNS をセットアップできます。ただし、ユーザーはルーターのホスト名を知らない場合があり、その場合はクラスター管理者がホスト名を知らせることができます。

クラスター管理者は、--router-canonical-hostname オプションをルーター作成時のルーターの正規ホスト名で使用できます。以下は例になります。

# oc adm router myrouter --router-canonical-hostname="rtr.example.com"

これは、ルーターのホスト名を含む ROUTER_CANONICAL_HOSTNAME 環境変数をルーターのデプロイメント設定に作成します。

すでに存在しているルーターの場合、クラスター管理者はルーターのデプロイメント設定を編集し、ROUTER_CANONICAL_HOSTNAME 環境変数を追加します。

spec:
  template:
    spec:
      containers:
        - env:
          - name: ROUTER_CANONICAL_HOSTNAME
            value: rtr.example.com

ROUTER_CANONICAL_HOSTNAME 値は、ルートを許可したすべてのルーターのルートステータスに表示されます。ルートステータスはルーターがリロードされるたびに更新されます。

ユーザーがルートを作成すると、すべてのアクティブなルーターはそのルートを評価し、条件を満たしていればそのルートを許可します。ROUTER_CANONICAL_HOSTNAME 環境変数を定義するルーターがルートを許可すると、ルーターはルートステータスの routerCanonicalHostname フィールドに値を入力します。ユーザーはルートステータスを検証して、どのルーターがルートを許可したかを確認でき、ルーターを一覧から選択し、ネットワーク管理者に渡すルーターのホスト名を見つけることができます (該当する場合)。

status:
  ingress:
    conditions:
      lastTransitionTime: 2016-12-07T15:20:57Z
      status: "True"
      type: Admitted
      host: hello.in.mycloud.com
      routerCanonicalHostname: rtr.example.com
      routerName: myrouter
      wildcardPolicy: None

oc describe にはホスト名が含まれます (利用可能な場合)。

$ oc describe route/hello-route3
...
Requested Host: hello.in.mycloud.com exposed on router myroute (host rtr.example.com) 12 minutes ago

上記の情報を使用して、ユーザーは DNS 管理者に対し、ルートのホスト hello.in.mycloud.com から CNAME をルーターの正規ホスト名 rtr.example.com に応じてセットアップするよう依頼できます。この結果として、hello.in.mycloud.com へのトラフィックがユーザーのアプリケーションに到達するようになります。

3.2.13. デフォルトのルーティングサブドメインのカスタマイズ

マスター設定ファイル (デフォルトでは /etc/origin/master/master-config.yaml ファイル) を変更することで、お使いの環境のデフォルトルーティングサブドメインとして使用されるサフィックスをカスタマイズできます。ホスト名を指定しないルートの場合、このデフォルトのルーティングサブドメインを使用してホスト名が生成されます。

以下の例は、設定されたサフィックスを v3.openshift.test に設定する方法を示しています。

routingConfig:
  subdomain: v3.openshift.test
注記

この変更には、マスターを実行している場合は再起動が必要となります。

OpenShift Container Platform マスターが上記の設定を実行している場合、 namespace の mynamespace に追加されるホスト名を持たない no-route-hostname というルートの例では、生成されるホスト名は以下のようになります。

no-route-hostname-mynamespace.v3.openshift.test

3.2.14. カスタムルーティングサブドメインへのルートホスト名の強制

管理者がすべてのルートを特定のルーティングサブドメインに限定する場合、--force-subdomain オプションを oc adm router コマンドに渡すことができます。これはルートで指定されたホスト名を上書きし、--force-subdomain オプションに提供されるテンプレートに基づいてホスト名を生成するようルーターに強制します。

以下の例ではルーターを実行し、カスタムサブドメインテンプレート ${name}-${namespace}.apps.example.com を使用してルートホスト名を上書きしています。

$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'

3.2.15. ワイルドカード証明書の使用

証明書を含まない TLS 対応のルートはルーターのデフォルト証明書を代わりに使用します。ほとんどの場合、この証明書は信頼された認証局から提供されますが、利便性を考慮して OpenShift Container Platform CA を使用して証明書を作成することができます。以下は例になります。

$ CA=/etc/origin/master
$ oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
      --signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
      --hostnames='*.cloudapps.example.com' \
      --cert=cloudapps.crt --key=cloudapps.key
注記

oc adm ca create-server-cert コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。

Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

ルーターは、証明書とキーが単一ファイルに PEM 形式で入力されていると予想します。

$ cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem

ここで --default-cert フラグを使用できます。

$ oc adm router --default-cert=cloudapps.router.pem --service-account=router
注記

ブラウザーは、ワイルドカードを 1 つ深いレベルのサブドメインに有効であると見なします。この例では、証明書は a.cloudapps.example.com に対して有効ですが、a.b.cloudapps.example.com には有効ではありません。

3.2.16. 証明書を手動で再デプロイする

ルーター証明書を手動で再デプロイするには、以下を実行します。

  1. デフォルトのルーター証明書を含むシークレットがルーターに追加されているかどうかを確認します。

    $ oc volumes dc/router
    
    deploymentconfigs/router
      secret/router-certs as server-certificate
        mounted at /etc/pki/tls/private

    証明書が追加されている場合は、以下の手順を省略してシークレットを上書きします。

  2. デフォルト証明書ディレクトリーが以下の変数 DEFAULT_CERTIFICATE_DIR に設定されていることを確認します。

    $ oc env dc/router --list
    
    DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private

    設定されていない場合は、以下のコマンドを使用してディレクトリーを作成します。

    $ oc env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private
  3. 証明書を PEM 形式にエクスポートします。

    $ cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crt
  4. ルーター証明書シークレットを上書きするか、またはこれを作成します。

    証明書シークレットがルーターに追加されている場合は、シークレットを上書きします。追加されていなければ、新規シークレットを作成します。

    シークレットを上書きするには、以下のコマンドを実行します。

    $ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -o json --dry-run | oc replace -f -

    新規シークレットを作成するには、以下のコマンドを実行します。

    $ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls
    
    $ oc volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs
  5. ルーターをデプロイします。

    $ oc rollout latest dc/router

3.2.17. セキュリティー保護されたルートの使用

現時点で、パスワードで保護されたキーファイルはサポートされていません。HAProxy は開始時にパスワードのプロンプトを出しますが、このプロセスを自動化する方法は提供しません。キーファイルからパスフレーズを削除するには、以下を実行できます。

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

以下の例は、トラフィックが宛先にプロキシー処理される前に TLS 終端がルーターで生じる場合にセキュアな edge termination ルートを使用する方法を示しています。セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、ルーターのフロントエンドで提供されます。

最初にルーターインスタンスを起動します。

# oc adm router --replicas=1 --service-account=router

次に、セキュアな edge ルートのプライベートキー、CSR、証明書を作成します。この手順はお使いの認証局やプロバイダーによって異なります。www.example.test というドメインの単純な自己署名証明書の場合は、以下の例を参照してください。

# sudo openssl genrsa -out example-test.key 2048
#
# sudo openssl req -new -key example-test.key -out example-test.csr  \
  -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=www.example.test"
#
# sudo openssl x509 -req -days 366 -in example-test.csr  \
      -signkey example-test.key -out example-test.crt

上記の証明書とキーを使用してルートを生成します。

$ oc create route edge --service=my-service \
    --hostname=www.example.test \
    --key=example-test.key --cert=example-test.crt
route "my-service" created

その定義を確認します。

$ oc get route/my-service -o yaml
apiVersion: v1
kind: Route
metadata:
  name:  my-service
spec:
  host: www.example.test
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
    key: |
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

www.example.test の DNS エントリーがルーターインスタンスを指し、ドメインへのルートが利用できることを確認します。以下の例では、Curl をローカルリゾルバーと共に使用して DNS ルックアップのシミュレーションを行っています。

# routerip="4.1.1.1"  #  replace with IP address of one of your router instances.
# curl -k --resolve www.example.test:443:$routerip https://www.example.test/

3.2.18. (サブドメインの) ワイルドカードルートの使用

HAProxy ルーターはワイルドカードルートをサポートしており、ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を true に設定することでこれを有効にできます。ルーター許可のチェックをパスする Subdomain のワイルドカードポリシーを持つすべてのルートは HAProxy ルーターによって提供されます。次に、HAProxy ルーターはルートのワイルドカードポリシーに基づいて (ルートの) 関連サービスを公開します。

重要

ルートのワイルドカードポリシーを変更するには、ルートを削除してから更新されたワイルドカードポリシーでこれを再作成する必要があります。ルートの .yaml ファイルでルートのワイルドカードポリシーのみを編集しても機能しません。

$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1

Web コンソールでワイルドカードルートを設定する方法についてはこちらを参照してください。

セキュアなワイルドカード edge termination ルートの使用

以下の例では、トラフィックが宛先にプロキシー処理される前にルーターで生じる TLS 終端を反映しています。サブドメイン example.org (*.example.org) のホストに送られるトラフィックは公開されるサービスにプロキシーされます。

セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、サブドメイン (*.example.org) に一致するすべてのホストのルーターのフロントエンドによって提供されます。

  1. ルーターインスタンスを起動します。

    $ oc adm router --replicas=0 --service-account=router
    $ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
    $ oc scale dc/router --replicas=1
  2. セキュリティー保護された edge ルートについてのプライベートキー、証明書署名要求 (CSR) および証明書を作成します。

    この手順はお使いの認証局やプロバイダーによって異なります。*.example.test というドメインの単純な自己署名証明書の場合はこの例を参照してください。

    # sudo openssl genrsa -out example-test.key 2048
    #
    # sudo openssl req -new -key example-test.key -out example-test.csr  \
      -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=*.example.test"
    #
    # sudo openssl x509 -req -days 366 -in example-test.csr  \
          -signkey example-test.key -out example-test.crt
  3. 上記の証明書とキーを使用してワイルドカードのルートを生成します。

    $ cat > route.yaml  <<REOF
    apiVersion: v1
    kind: Route
    metadata:
      name:  my-service
    spec:
      host: www.example.test
      wildcardPolicy: Subdomain
      to:
        kind: Service
        name: my-service
      tls:
        termination: edge
        key: "$(perl -pe 's/\n/\\n/' example-test.key)"
        certificate: "$(perl -pe 's/\n/\\n/' example-test.cert)"
    REOF
    $ oc create -f route.yaml

    *.example.test の DNS エントリーがお使いのルーターインスタンスを指し、ドメインへのルートが利用できることを確認します。

    この例では curl をローカルリゾルバーと共に使用し、DNS ルックアップのシミュレーションを行います。

    # routerip="4.1.1.1"  #  replace with IP address of one of your router instances.
    # curl -k --resolve www.example.test:443:$routerip https://www.example.test/
    # curl -k --resolve abc.example.test:443:$routerip https://abc.example.test/
    # curl -k --resolve anyname.example.test:443:$routerip https://anyname.example.test/

ワイルドカードルートを許可しているルーター (ROUTER_ALLOW_WILDCARD_ROUTEStrue に設定する) の場合、ワイルドカードルートに関連付けられたサブドメインの所有権についてのいくつかの注意点があります。

ワイルドカードルートの設定前に、所有権は、最も古いルートを持つ namespace のホスト名についての要求に基づいて設定されました (これはその他の要求を行うルートよりも優先されました)。たとえば、ルート r1 がルート r2 より古い場合、one.example.test の要求を持つ namespace ns1 のルート r1 は同じホスト名 one.example.test について namespace ns2 のルート ns2 よりも優先されます。

さらに、他の namespace のルートは重複しないホスト名を要求することを許可されていました。たとえば、namespace ns1 のルート ronewww.example.test を要求でき、namespace d2 の別のルート rtwoc3po.example.test を要求できました。

これは、同じサブドメイン (上記の例では example.test) を要求するワイルドカードルートがない場合には同様になります。

ただし、ワイルドカードルートはサブドメイン内のホスト名 ( \*.example.test 形式のホスト名) をすべて要求する必要があります。ワイルドカードルートの要求は、そのサブドメイン (example.test) の最も古いルートがワイルドカードルートと同じ namespace 内にあるかどうかによって許可または拒否されます。最も古いルートは通常のルートまたはワイルドカードルートのいずれかになります。

たとえば、ホスト owner.example.test を要求する 最も古い ルートが namespace ns1 にすでに存在し、後からそのサブドメイン (example.test) のルートを要求する新規のワイルドカードルート wildthing が追加される場合、そのワイルドカードルートによる要求は、そのルートが所有ルートと同じ namespace (ns1) にある場合にのみ許可されます。

以下の例では、ワイルドカードルートの要求が成功する場合と失敗する場合のさまざまなシナリオを示しています。

以下の例では、ワイルドカードルートを許可するルーターは、ワイルドカードルートがサブドメインを要求していない限り、サブドメイン example.test のホストに対する重複しない要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test
$ oc expose service myservice --hostname=bname.example.test

$ oc project ns2
$ oc expose service anotherservice --hostname=second.example.test
$ oc expose service anotherservice --hostname=cname.example.test

$ oc project otherns
$ oc expose service thirdservice --hostname=emmy.example.test
$ oc expose service thirdservice --hostname=webby.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 なので、owner.example.test または aname.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test

$ oc project ns2
$ oc expose service secondservice --hostname=bname.example.test
$ oc expose service secondservice --hostname=cname.example.test

$ # Router will not allow this claim with a different path name `/p1` as
$ # namespace `ns1` has an older route claiming host `aname.example.test`.
$ oc expose service secondservice --hostname=aname.example.test --path="/p1"

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `owner.example.test`.
$ oc expose service secondservice --hostname=owner.example.test

$ oc project otherns

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `aname.example.test`.
$ oc expose service thirdservice --hostname=aname.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、そのワイルドカードルートが同じ namespace に属しているので、`\*.example.test の要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will allow this claim.

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、ワイルドカードルートが別の namespace cyclone に属するため、`\*.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Switch to a different namespace/project.
$ oc project cyclone

$ # Reusing the route.yaml from a prior example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will deny (_NOT_ allow) this claim.

同様に、ワイルドカードルートを持つ namespace がサブドメインを要求すると、その namespace 内のルートのみがその同じサブドメインでホストを要求できます。

以下の例では、ワイルドカードルートを持つ namespace ns1 のルートがサブドメイン example.test を要求すると、namespace ns1 内のルートのみがその同じサブドメインのホストを要求することを許可されます。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service otherservice --hostname=other.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `other.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for deux.example.test
$ oc expose service mysecondservice --hostname=deux.example.test

$ # namespace `ns1` is allowed to claim for deux.example.test with path /p1
$ oc expose service mythirdservice --hostname=deux.example.test --path="/p1"

$ oc project otherns

$ # namespace `otherns` is not allowed to claim for deux.example.test
$ # with a different path '/otherpath'
$ oc expose service otherservice --hostname=deux.example.test --path="/otherpath"

$ # namespace `otherns` is not allowed to claim for owner.example.test
$ oc expose service yetanotherservice --hostname=owner.example.test

$ # namespace `otherns` is not allowed to claim for unclaimed.example.test
$ oc expose service yetanotherservice --hostname=unclaimed.example.test

以下の例では、所有権のあるルートが削除され、所有権が namespace 内または namespace 間で渡されるさまざまなシナリオが示されています。namespace ns1 のホスト eldest.example.test を要求するルートが存在する場合、その namespace 内のワイルドカードルートはサブドメイン example.test を要求できます。ホスト eldest.example.test のルートが削除されると、次に古いルート senior.example.test が最も古いルートになりますが、これは他のルートに影響を与えません。ホスト senior.example.test のルートが削除されると、次に古いルート junior.example.test が最も古いルートになり、ワイルドカードルートの要求をブロックします。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=eldest.example.test
$ oc expose service seniorservice --hostname=senior.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service juniorservice --hostname=junior.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `junior.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for dos.example.test
$ oc expose service mysecondservice --hostname=dos.example.test

$ # Delete route for host `eldest.example.test`, the next oldest route is
$ # the one claiming `senior.example.test`, so route claims are unaffacted.
$ oc delete route myservice

$ # Delete route for host `senior.example.test`, the next oldest route is
$ # the one claiming `junior.example.test` in another namespace, so claims
$ # for a wildcard route would be affected. The route for the host
$ # `dos.example.test` would be unaffected as there are no other wildcard
$ # claimants blocking it.
$ oc delete route seniorservice

3.2.19. コンテナーネットワークスタックの使用

OpenShift Container Platform ルーターはコンテナー内で実行され、デフォルトの動作として、ホスト (例: ルーターコンテナーが実行されるノードなど) のネットワークスタックを使用します。このデフォルトの動作には、リモートクライアントからのネットワークトラフィックがターゲットサービスとコンテナーに到達するためにユーザー空間で複数のホップを使用する必要がないので、パフォーマンス上のメリットがあります。

さらに、このデフォルト動作によってルーターはノードの IP アドレスではなくリモート接続の実際のソース IP アドレスを取得できます。これは、発信元の IP に基づいて ingress ルールを定義し、スティッキーセッションをサポートし、他に使用されているものの中でトラフィックを監視するのに役立ちます。

このホストネットワークの動作は --host-network ルーターコマンドラインオプションによって制御でき、デフォルトの動作は --host-network=true を使用した場合と等しくなります。コンテナーネットワークスタックを使用してルーターを実行する場合は、ルーターを作成する際に --host-network=false オプションを使用します。以下は例になります。

$ oc adm router --service-account=router --host-network=false

内部的には、これは外部ネットワークがルーターと通信するために、ルーターコンテナーが 80 と 443 ポートを公開する必要があることを意味します。

注記

コンテナーネットワークスタックを使用して実行することで、ルーターは接続のソース IP アドレスを実際のリモート IP アドレスではなくノードの NAT された IP アドレスとして扱うことを意味します。

注記

マルチテナントネットワークの分離を使用する OpenShift Container Platform クラスターでは、--host-network=false オプションを指定したデフォルト以外の namespace のルーターはクラスターのすべてのルートを読み込みますが、ネットワークの分離により複数の namespace にあるルートには到達できません。--host-network=true オプションを指定すると、ルートはコンテナーネットワークをバイパスし、クラスターの任意の Pod にアクセスできます。この場合、分離が必要な場合は、複数の namespace のルートを追加しないでください。

3.2.20. ルーターメトリクスの公開

HAProxy ルーターメトリクス は、外部メトリクス収集および集約システム (例: Prometheus、statsd) で使用されるようにデフォルトで Prometheus 形式で公開されます。メトリクスは独自の HTML 形式でブラウザーで閲覧したり CSV ダウンロードを実行するために HAProxy ルーターから直接利用することもできます。これらのメトリクスには、HAProxy ネイティブメトリクスおよび一部のコントローラーメトリクスが含まれます。

以下のコマンドを使用してルーターを作成する場合、OpenShift Container Platform は Prometheus 形式のメトリクスをデフォルトが 1936 の統計ポートで利用可能にします。

$ oc adm router --service-account=router
  • Prometheus 形式で未加工統計を抽出するには、以下を実行します。

    curl <user>:<password>@<router_IP>:<STATS_PORT>

    以下は例を示しています。

    $ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics

    メトリクスにアクセスするために必要な情報は、ルーターサービスのアノテーションで確認できます。

    $ oc edit router service <router-service-name>
    
    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        prometheus.io/port: "1936"
        prometheus.io/scrape: "true"
        prometheus.openshift.io/password: IImoDqON02
        prometheus.openshift.io/username: admin

    prometheus.io/port はデフォルトが 1936 の統計ポートです。アクセスを許可するようファイウォールを設定する必要がある場合があります。直前のユーザー名およびパスワードを使用してメトリクスにアクセスします。パスは /metrics です。

    $ curl <user>:<password>@<router_IP>:<STATS_PORT>
    for example:
    $ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics
    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
  • ブラウザーでメトリクスを取得するには、以下を実行します。

    1. 以下の環境変数をルーターデプロイメント設定ファイルから削除します。

      $ oc edit service router
      
      - name: ROUTER_LISTEN_ADDR
        value: 0.0.0.0:1936
      - name: ROUTER_METRICS_TYPE
        value: haproxy
    2. ブラウザーで以下の URL を使用して統計ウィンドウを起動します。ここでは、STATS_PORT 値はデフォルトで 1936 になります。

      http://admin:<Password>@<router_IP>:<STATS_PORT>

      ;csv を URL に追加して CVS 形式の統計を取得できます。

      以下は例を示しています。

      http://admin:<Password>@<router_IP>:1936;csv

      ルーター IP、admin 名、およびパスワードを取得するには、以下を実行します。

      oc describe pod <router_pod>
  • メトリクス収集を制限するには、以下を実行します。

    $ oc adm router --service-account=router --stats-port=0

    大規模クラスターの ARP キャッシュのチューニング

(net.ipv4.neigh.default.gc_thresh3 の値 (デフォルトで65536) を上回る) 多数のルート を持つ OpenShift Container Platform クラスターでは、ARP キャッシュでより多くのエントリーを許可するためにルーター Pod を実行するクラスターの各ノードで sysctl 変数のデフォルト値を増やす必要があります。

問題が発生している場合、以下のようなカーネルメッセージが表示されます。

[ 1738.811139] net_ratelimit: 1045 callbacks suppressed
[ 1743.823136] net_ratelimit: 293 callbacks suppressed

この問題が発生すると、oc コマンドは以下のエラーを出して失敗することがあります。

Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument

IPv4 の ARP エントリーの実際の量を確認するには、以下を実行します。

# ip -4 neigh show nud all | wc -l

数字が net.ipv4.neigh.default.gc_thresh3 しきい値に近づき始めたら、値を増やします。以下を実行して現在値を取得します。

# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh2 = 512
# sysctl net.ipv4.neigh.default.gc_thresh3
net.ipv4.neigh.default.gc_thresh3 = 1024

以下の sysctl は変数を OpenShift Container Platform の現在のデフォルト値に設定します。

# sysctl net.ipv4.neigh.default.gc_thresh1=8192
# sysctl net.ipv4.neigh.default.gc_thresh2=32768
# sysctl net.ipv4.neigh.default.gc_thresh3=65536

これらの設定を永続化するには、このドキュメントを参照してください。

3.2.21. DDoS 攻撃からの保護

timeout http-request をデフォルトの HAProxy ルーターイメージに追加して、分散型の denial-of-service (DDoS) 攻撃 (slowloris など) からデプロイメントを保護します。

# and the haproxy stats socket is available at /var/run/haproxy.stats
global
  stats socket ./haproxy.stats level admin

defaults
  option http-server-close
  mode http
  timeout http-request 5s
  timeout connect 5s 1
  timeout server 10s
  timeout client 30s
1
timeout http-request は最大 5 秒に設定されます。HAProxy は HTTP 要求全体の送信のための 5 秒をクライアントに対して指定します。この指定がないと、HAProxy はエラーを出して接続を切断します。

また、環境変数 ROUTER_SLOWLORIS_TIMEOUT が設定されている場合、クライアントが HTTP 要求全体を送信するためにかかる合計時間が制限されます。これが設定されていない場合、HAProxy は接続を切断します。

環境変数を設定することで、情報をルーターのデプロイメント設定の一部として取得でき、テンプレートを手動で変更することが不要になります。一方、HAProxy 設定を手動で追加すると、ルーター Pod の再ビルドとルーターテンプレートファイルの保守が必要になります。

アノテーションを使用して、以下を制限する機能を含む基本的な DDoS 保護を HAProxy テンプレートルーターに実装します。

  • 同時 TCP 接続の数
  • クライアントが TCP 接続を要求できるレート
  • HTTP 要求を実行できるレート

アプリケーションによってはトラフィックのパターンが完全に異なる場合があるため、これらはルートごとに有効にされます。

表3.1 HAProxy テンプレートルーター設定

設定説明

haproxy.router.openshift.io/rate-limit-connections

設定した内容を有効にします (true に設定した場合など)。

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

このルートの同じ IP アドレスで接続できる同時 TCP 接続の数。

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

クライアント IP で開くことができる TCP 接続の数。

haproxy.router.openshift.io/rate-limit-connections.rate-http

クライアント IP が 3 秒間で実行できる HTTP 要求の数。

3.3. カスタマイズされた HAProxy ルーターのデプロイ

3.3.1. 概要

デフォルトの HAProxy ルーターは多数のユーザーのニーズを対応することを目的としています。ただし、このルーターは HAProxy のすべての機能を公開している訳ではありません。そのため、ユーザーはそれぞれのニーズに合わせてルーターを変更する必要があります。

新機能をアプリケーションバックエンド内で実装したり、現在の操作を変更する必要がある場合があります。ルータープラグインはこのカスタマイズを行うために必要なすべての機能を提供します。

ルーター Pod はテンプレートファイルを使用して必要な HAProxy 設定ファイルを作成します。テンプレートファイルは golang テンプレート です。テンプレートを処理する際に、ルーターはルーターのデプロイメント設定、許可されたルートのセット、一部のヘルパー機能などの OpenShift Container Platform 情報にアクセスします。

ルーター Pod が起動し、リロードされるたびに、HAProxy 設定ファイルが作成され、HAProxy が起動します。『HAProxy 設定マニュアル』には HAProxy のすべての機能と有効な設定ファイルの作成方法が記載されています。

configMap を使用して新規テンプレートをルーター Pod に追加することができます。この方法により、ルーターデプロイメント設定を変更して、configMap をルーター Pod のボリュームとしてマウントできます。 TEMPLATE_FILE 環境変数はルーター Pod のテンプレートファイルのフルパス名に設定されます。

または、カスタムルーターイメージをビルドし、ルーターの一部またはすべてをデプロイする際にこれを使用することができます。すべてのルーターが同じイメージを実行する必要はありません。これを実行するには、 haproxy-template.config ファイルを変更し、ルーターイメージを再ビルドします。新しいイメージはクラスターの Docker リポジトリーにプッシュされ、ルーターのデプロイメント設定の image: フィールドが新しい名前で更新されます。クラスターが更新されたら、イメージを再ビルドし、プッシュする必要があります。

いずれの場合でも、ルーター Pod はテンプレートファイルを使用して起動します。

3.3.2. ルーター設定テンプレートの取得

HAProxy テンプレートファイルはかなり大きく複雑です。一部を変更するのであれば、すべてを書き換えるよりも既存のテンプレートを変更する方が簡単です。マスターでルーターを実行し、ルーター Pod を参照することで実行中のルーターから haproxy-config.templateファイルを取得できます。

# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc rsh router-2-40fc3 cat haproxy-config.template > haproxy-config.template
# oc rsh router-2-40fc3 cat haproxy.config > haproxy.config

または、ルーターを実行しているノードにログオンします。

# docker run --rm --interactive=true --tty --entrypoint=cat \
    registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7 haproxy-config.template

イメージ名は docker イメージ から取られます。

この内容をカスタマイズされたテンプレートのベースとして使用するためにファイルに保存します。保存された haproxy.config は実際に実行されているものを示します。

3.3.3. ルーター設定テンプレートの変更

3.3.3.1. 背景

このテンプレートは golang テンプレートに基づいています。これは、ルーターのデプロイメント設定の環境変数や、以下に示す設定情報およびルーターが提供するヘルパー機能を参照することができます。

テンプレートファイルの構造は作成される HAProxy 設定ファイルを反映します。テンプレートの処理時に、{{" something "}} によって囲まれていないものはすべて設定ファイルに直接コピーされます。{{" something "}} で囲まれている部分は評価されます。生成されるテキスト (ある場合) は設定ファイルにコピーされます。

3.3.3.2. Go テンプレートアクション

define アクションは、処理されるテンプレートを含むファイルに名前を付けます。

{{define "/var/lib/haproxy/conf/haproxy.config"}}pipeline{{end}}

表3.2 テンプレートルーター関数

関数意味

processEndpointsForAlias(alias ServiceAliasConfig, svc ServiceUnit, action string) []Endpoint

有効なエンドポイントの一覧を返します。アクションが「Shuffle」の場合、エンドポイントの順序はランダム化されます。

env(variable, default …​string) string

Pod からの名前付き環境変数の取得を試行します。これが定義されていないか、または空の場合、オプションの 2 つ目の引数が返されます。それ以外の場合には空の文字列を返します。

matchPattern(pattern, s string) bool

1 つ目の引数は正規表現を含む文字列で、2 つ目の引数はテストに使用できる変数です。1 つ目の引数として提供される正規表現が 2 つ目の引数として提供される文字列と一致するかどうかを示すブール値を返します。

isInteger(s string) bool

指定された変数が整数かどうかを判別します。

firstMatch(s string, allowedValues …​string) bool

所定の文字列を許可された文字列の一覧と比較します。左から右にスキャンし、最初の一致を返します。

matchValues(s string, allowedValues …​string) bool

指定された文字列と許可された文字列の一覧を比較します。文字列が許可される値の場合は「true」を返します。それ以外の場合は、「false」を返します。

generateRouteRegexp(hostname, path string, wildcard bool) string

ルートホスト (とパス) に一致する正規表現を生成します。最初の引数はホスト名であり、2 つ目はパス、3 つ目はワイルドカードブール値です。

genCertificateHostName(hostname string, wildcard bool) string

証明書の提供/証明書のマッチングに使用するホスト名を生成します。1 つ目の引数はホスト名で、2 つ目はワイルドカードブール値です。

isTrue(s string) bool

指定された変数に「true」が含まれるかどうかを判別します。

これらの関数は、HAProxy テンプレートルータープラグインによって提供されます。

3.3.3.3. ルーターが提供する情報

このセクションでは、ルーターがテンプレートで利用可能にする OpenShift Container Platform の情報について説明しますす。ルーター設定パラメーターは HAProxy ルータープラグインに与えられるデータセットです。フィールドには (dot) .Fieldname を使用してアクセスします。

以下のルーター設定パラメーター表は各種フィールドの定義を詳しく取り上げています。特に .State には許可されたルートセットが設定されます。

表3.3 ルーター設定パラメーター

フィールド種類説明

WorkingDir

string

ファイルが書き込まれるディレクトリー。デフォルトは /var/lib/containers/router に設定されます。

State

map[string](ServiceAliasConfig)`

ルート。

ServiceUnits

map[string]ServiceUnit

サービスのルックアップ。

DefaultCertificate

string

pem 形式のデフォルト証明書へのフルパス名。

PeerEndpoints

`[]Endpoint

ピア。

StatsUser

string

統計の公開に使用するユーザー名 (テンプレートがサポートしている場合)。

StatsPassword

string

統計の公開に使用するパスワード (テンプレートがサポートしている場合)。

StatsPort

int

統計の公開に使用するポート (テンプレートがサポートしている場合)。

BindPorts

bool

ルーターがデフォルトポートをバインドすべきかどうか。

表3.4 ルーター ServiceAliasConfig (Route)

フィールド種類説明

Name

string

ルートのユーザー固有の名前。

Namespace

string

ルートの namespace。

Host

string

ホスト名。例: www.example.com

Path

string

オプションのパス。例: www.example.com/myservice (ここでは、myservice がパスになります)。

TLSTermination

routeapi.TLSTerminationType

このバックエンドの終端ポリシー。マッピングファイルとルーター設定を利用します。

Certificates

map[string]Certificate

このバックエンドをセキュリティー保護するために使用する証明書。証明書 ID で指定します。

Status

ServiceAliasConfigStatus

永続化する必要がある設定のステータスを示します。

PreferPort

string

ユーザーが公開したいポートを示します。空の場合、サービスのポートが選択されます。

InsecureEdgeTerminationPolicy

routeapi.InsecureEdgeTerminationPolicyType

edge termination ルートへの非セキュアな接続の必要な動作を示します。 none (または disable)、allow、または redirect

RoutingKeyName

string

Cookie ID を隠すために使用するルート + namespace 名のハッシュ。

IsWildcard

bool

このサービスユニットが ワイルドカードサポートを必要とすることを示します。

Annotations

map[string]string

このルートに割り当てられるアノテーション。

ServiceUnitNames

map[string]int32

このルートをサポートするサービスコレクション。マップの他のエントリーに関連してサービス名で指定され、これに割り当てられた重みで評価されます。

ActiveServiceUnits

int

ゼロ以外の重みを持つ ServiceUnitNames の数。

ServiceAliasConfig はサービスのルートです。ホスト + パスによって特定されます。デフォルトのテンプレートは {{range $cfgIdx, $cfg := .State }} を使用してルートを繰り返し処理します。その {{range}} ブロック内で、テンプレートは $cfg.Field を使用して現在の ServiceAliasConfig のフィールドを参照できます。

表3.5 ルーター ServiceUnit

フィールド種類説明

Name

string

名前はサービス名 + namespace に対応します。ServiceUnit を特定します。

EndpointTable

[]Endpoint

サービスをサポートするエンドポイント。これはルーターの最終のバックエンド実装に変換されます。

ServiceUnit はサービスをカプセル化したものであり、そのサービスをサポートするエンドポイントであり、またサービスを参照するルートです。これは、ルーター設定ファイルの作成を進めるデータです。

表3.6 ルーターエンドポイント

フィールド種類

ID

string

IP

string

Port

string

TargetName

string

PortName

string

IdHash

string

NoHealthCheck

bool

Endpoint は、Kubernetes エンドポイントの内部表現です。

表3.7 ルーター証明書、ServiceAliasConfigStatus

フィールド種類説明

Certificate

string

パブリック/プライベートキーのペアを表します。これは ID で識別され、ファイル名になります。CA 証明書には PrivateKey が設定されません。

ServiceAliasConfigStatus

string

この設定に必要なファイルがディスクに永続化されていることを示します。有効な値の例: "saved" または "" (ブランク)。

表3.8 ルーター証明書タイプ

フィールド種類説明

ID

string

 

Contents

string

証明書。

PrivateKey

string

プライベートキー。

表3.9 ルーター TLSTerminationType

フィールド種類説明

TLSTerminationType

string

セキュアな通信が停止する場合を指示します。

InsecureEdgeTerminationPolicyType

string

ルートへの非セキュアな接続の必要な動作を示します。各ルーターは公開するポートを独自に決定することがありますが、通常はポート 80 になります。

TLSTerminationTypeInsecureEdgeTerminationPolicyType はセキュアな通信が停止する場合を指示します。

表3.10 ルーター TLSTerminationType 値

定数意味

TLSTerminationEdge

edge

edge ルーターでの暗号化を終了します。

TLSTerminationPassthrough

passthrough

宛先での暗号化を終了し、宛先でトラフィックを復号化します。

TLSTerminationReencrypt

reencrypt

edge ルーターで暗号化を終了し、送信先から提供される新規の証明書で再暗号化します。

表3.11 ルーター InsecureEdgeTerminationPolicyType 値

種類意味

Allow

トラフィックは非セキュアなポートのサーバーに送信されます (デフォルト)。

Disable

トラフィックは非セキュアなポートでは許可されません。

Redirect

クライアントはセキュアなポートにリダイレクトされます。

なし ("") は Disable と同じです。

3.3.3.4. アノテーション

各ルートにはアノテーションが割り当てることができます。各アノテーションは名前と値のみで構成されます。

apiVersion: v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms
[...]

名前は既存のアノテーションと競合しないものにできます。値は文字列です。文字列では複数のトークンをスペースで区切ることができます (例: aa bb cc)。テンプレートは {{index}} を使用してアノテーションの値を抽出します。以下は例になります。

{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}

この例は、これをどのようにクライアントの相互承認に使用できるかを示しています。

{{ with $cnList := index $cfg.Annotations "whiteListCertCommonName" }}
  {{   if ne $cnList "" }}
    acl test ssl_c_s_dn(CN) -m str {{ $cnList }}
    http-request deny if !test
  {{   end }}
{{ end }}

このコマンドを使用してホワイトリストの CN を処理できます。

$ oc annotate route <route-name> --overwrite whiteListCertCommonName="CN1 CN2 CN3"

詳細は、「Route-specific Annotations」を参照してください。

3.3.3.5. 環境変数

テンプレートはルーター Pod に存在する任意の環境変数を使用できます。環境変数はデプロイメント設定に設定できます。また、新規の環境変数を追加できます。

これらは env 関数で参照されます。

{{env "ROUTER_MAX_CONNECTIONS" "20000"}}

1 つ目の文字列は変数であり、変数がないか、または nil の場合には 2 つ目の文字列がデフォルトになります。ROUTER_MAX_CONNECTIONS が設定されていないか、または nil の場合、20000 が使用されます。環境変数はマップと言えます。ここでキーは環境変数名で、内容は変数の値になります。

詳細は、「Route-specific Environment variables」を参照してください。

3.3.3.6. 使用例

以下で HAProxy テンプレートファイルに基づく単純なテンプレートを示します。

以下のコメントで開始します。

{{/*
  Here is a small example of how to work with templates
  taken from the HAProxy template file.
*/}}

テンプレートは任意の数の出力ファイルを作成できます。define コンストラクトを使用して出力ファイルを作成します。ファイル名は定義する引数として指定され、define ブロック内の一致する終了部分までのすべての情報がそのファイルの内容として書き込まれます。

{{ define "/var/lib/haproxy/conf/haproxy.config" }}
global
{{ end }}

上記は global/var/lib/haproxy/conf/haproxy.config ファイルにコピーし、ファイルを閉じます。

ロギングを環境変数に基づいてセットアップします。

{{ with (env "ROUTER_SYSLOG_ADDRESS" "") }}
  log {{.}} {{env "ROUTER_LOG_FACILITY" "local1"}} {{env "ROUTER_LOG_LEVEL" "warning"}}
{{ end }}

env 関数は、環境変数の値を抽出します。環境変数が定義されていないか、または nil の場合、2 つ目の引数が返されます。

with コンストラクトは with ブロック内の "." (ドット) の値を with に引数として提供される値に設定します。with アクションは Dot で nil をテストします。nil ではない場合、その句はend (終了部分) まで処理されます。上記では、ROUTER_SYSLOG_ADDRESS/var/log/msg が含まれ、ROUTER_LOG_FACILITY が定義されておらず、ROUTER_LOG_LEVELinfo が含まれていると想定しています。以下が出力ファイルにコピーされます。

  log /var/log/msg local1 info

許可された各ルートは設定ファイルの行を生成します。range を使用して、許可されたルートを確認します。

{{ range $cfgIdx, $cfg := .State }}
  backend be_http_{{$cfgIdx}}
{{end}}

.StateServiceAliasConfig のマップです。ここで、キーはルート名になります。range はマップを通じて、パスするたびに keyを使用して $cfgIdx を設定し、`$cfg がルートを記述する ServiceAliasConfig をポイントするよう設定します。 myroutehisroute という 2 つのルートがある場合、上記により以下が出力ファイルにコピーされます。

  backend be_http_myroute
  backend be_http_hisroute

ルートアノテーション $cfg.Annotations もマップであり、アノテーション名がキーとなり、コンテンツの文字列が値になっています。ルートは必要な数だけアノテーションを持つことができ、テンプレートの作成者が使用方法を定義します。ユーザーはアノテーションをルートにコード化し、テンプレート作成者は HAProxy テンプレートをカスタマイズしてそのアノテーションを処理できるようにします。

通常はアノテーションをインデックス化して値を取得します。

{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}

インデックスは指定されたアノテーションの値を抽出します。そのため、`$balanceAlgo はアノテーションまたは nil に関連付けられた文字列が含まれます。上記のように、nil 以外の文字列についてテストし、with コンストラクトを使用して影響を確認することができます。

{{ with $balanceAlgo }}
  balance $balanceAlgo
{{ end }}

$balanceAlgonil でない場合、balance $balanceAlgo は出力ファイルにコピーされます。

2 つ目の例では、アノテーションのタイムアウト値の設定に基づいてサーバータイムアウトを設定します。

$value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"

$value を評価して、適切に作成された文字列が含まれていることを確認できます。matchPattern 関数は正規表現を受け入れ、引数が表現を満たしていれば true を返します。

matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value

これにより 5000ms を受け入れますが、7y は受け取りません。この結果はテストで使用できます。

{{if (matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value) }}
  timeout server  {{$value}}
{{ end }}

これを使用してトークンに一致させることもできます。

matchPattern "roundrobin|leastconn|source" $balanceAlgo

または、matchValues を使用してトークンと一致させることもできます。

matchValues $balanceAlgo "roundrobin" "leastconn" "source"

3.3.4. ConfigMap を使用してルーター設定テンプレートを置き換える

ConfigMap を使用して、ルーターイメージを再ビルドすることなくルーターインスタンスをカスタマイズできます。ルーター環境変数の作成し、変更することができるだけでなく、haproxy-config.templatereload-haproxy その他のスクリプトを変更することもできます。

  1. 上記のように変更する haproxy-config.template をコピーして、必要に応じて変更します。
  2. ConfigMap を作成します。

    $ oc create configmap customrouter --from-file=haproxy-config.template

    customrouter ConfigMap には変更された haproxy-config.template ファイルのコピーが含まれています。

  3. ルーターデプロイメント設定を変更し、ConfigMap をファイルとしてマウントし、TEMPLATE_FILE 環境変数がこれをポイントするようにします。これは、 oc set envoc volume コマンドを使用するか、またはルーターデプロイメント設定を編集して実行できます。

    oc コマンドの使用
    $ oc volume dc/router --add --overwrite \
        --name=config-volume \
        --mount-path=/var/lib/haproxy/conf/custom \
        --source='{"configMap": { "name": "customrouter"}}'
    $ oc set env dc/router \
        TEMPLATE_FILE=/var/lib/haproxy/conf/custom/haproxy-config.template
    ルーターデプロイメント設定の編集

    oc edit dc router を使用して、テキストエディターでルーターデプロイメント設定を編集します。

    ...
            - name: STATS_USERNAME
              value: admin
            - name: TEMPLATE_FILE  1
              value: /var/lib/haproxy/conf/custom/haproxy-config.template
            image: openshift/origin-haproxy-routerp
    ...
            terminationMessagePath: /dev/termination-log
            volumeMounts: 2
            - mountPath: /var/lib/haproxy/conf/custom
              name: config-volume
          dnsPolicy: ClusterFirst
    ...
          terminationGracePeriodSeconds: 30
          volumes: 3
          - configMap:
              name: customrouter
            name: config-volume
    ...
    1
    spec.container.env フィールドに TEMPLATE_FILE 環境変数を追加して、マウントされた haproxy-config.template ファイルをポイントするようにします。
    2
    spec.container.volumeMounts フィールドを追加して、マウントポイントを作成します。
    3
    新しい spec.volumes フィールドを追加し、ConfigMap を示唆します。

    変更を保存し、エディターを終了します。ルーターが再起動します。

3.3.5. Stick Table の使用

以下のカスタマイズの例を高可用なルーティングセットアップで使用することで、ピア間の同期を行う stick-table を使用できます。

ピアセクションの追加

ピア間で stick-table を同期するには、HAProxy 設定でピアセクションを定義する必要があります。このセクションによって、HAProxy がどのようにピアを識別し、接続するかが決まります。プラグインはデータを .PeerEndpoints 変数にあるテンプレートに提供するので、ルーターサービスのメンバーを簡単に識別できます。以下を追加することで、ピアセクションをルーターイメージ内の haproxy-config.template ファイルに追加することができます。

{{ if (len .PeerEndpoints) gt 0 }}
peers openshift_peers
  {{ range $endpointID, $endpoint := .PeerEndpoints }}
    peer {{$endpoint.TargetName}} {{$endpoint.IP}}:1937
  {{ end }}
{{ end }}

リロードスクリプトの変更

stick-table を使用する場合、HAProxy にピアセクションでローカルホスト名として見なすものをオプションで指示することができます。エンドポイントの作成時に、プラグインは TargetName をエンドポイントの TargetRef.Name の値に設定するよう試みます。TargetRef が設定されていない場合、TargetName は IP アドレスに設定されます。TargetRef.Name は Kubernetes ホスト名に対応しているので、-L オプションを reload-haproxy スクリプトに追加してローカルホストをピアセクションで識別できます。

peer_name=$HOSTNAME 1

if [ -n "$old_pid" ]; then
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name -sf $old_pid
else
  /usr/sbin/haproxy -f $config_file -p $pid_file -L $peer_name
fi
1
ピアセクションで使用されるエンドポイントターゲット名と一致している必要があります。

バックエンドの変更

最後に、stick-table をバックエンド内で使用するために、HAProxy 設定を変更して stick-table およびピアセットを使用することができます。以下は、stick-table を使用するように TCP 接続の既存のバックエンドを変更している例です。

            {{ if eq $cfg.TLSTermination "passthrough" }}
backend be_tcp_{{$cfgIdx}}
  balance leastconn
  timeout check 5000ms
  stick-table type ip size 1m expire 5m{{ if (len $.PeerEndpoints) gt 0 }} peers openshift_peers {{ end }}
  stick on src
                {{ range $endpointID, $endpoint := $serviceUnit.EndpointTable }}
  server {{$endpointID}} {{$endpoint.IP}}:{{$endpoint.Port}} check inter 5000ms
                {{ end }}
            {{ end }}

この変更を行った後に、ルーターを再ビルドできます。

3.3.6. ルーターの再ビルド

ルーターを再ビルドするには、実行中のルーターにある複数のファイルのコピーが必要になります。作業ディレクトリーを作成し、ルーターからファイルをコピーします。

# mkdir - myrouter/conf
# cd myrouter
# oc get po
NAME                       READY     STATUS    RESTARTS   AGE
router-2-40fc3             1/1       Running   0          11d
# oc rsh router-2-40fc3 cat haproxy-config.template > conf/haproxy-config.template
# oc rsh router-2-40fc3 cat error-page-503.http > conf/error-page-503.http
# oc rsh router-2-40fc3 cat default_pub_keys.pem > conf/default_pub_keys.pem
# oc rsh router-2-40fc3 cat ../Dockerfile > Dockerfile
# oc rsh router-2-40fc3 cat ../reload-haproxy > reload-haproxy

これらのファイルのいずれも編集するか、または置き換えることができます。ただし、conf/haproxy-config.templatereload-haproxy が変更される可能性が高くなります。

ファイルの更新後:

# docker build -t openshift/origin-haproxy-router-myversion .
# docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion 1
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest 2
1
このバージョンをリポジトリーでタグ付けします。この場合、リポジトリーは 172.30.243.98:5000 になります。
2
タグ付けバージョンをリポジトリーにプッシュします。まずリポジトリーに docker ログイン する必要がある場合があります。

新規ルーターを使用するには、image: 文字列を変更するか、または --images=<repo>/<image>:<tag> フラグを oc adm router コマンドに追加してルーターデプロイ設定を編集します。

変更のデバッグ時に、デプロイメント設定で imagePullPolicy: Always を設定して各 Pod の作成時にイメージプルを強制的に実行すると便利です。デバッグが完了したら、これを imagePullPolicy: IfNotPresent に戻して各 Pod の起動時のプルを回避します。

3.4. PROXY プロトコルを使用するように HAProxy ルーターを設定する

3.4.1. 概要

デフォルトで HAProxy ルーターは、非セキュアな edge および re-encrypt ルートへの受信接続に HTTP を使用することを想定しています。ただし、PROXY プロトコルを使用することで、ルーターが受信要求を予想するよう設定することができます。このトピックでは、HAProxy ルーターと外部ロードバランサーを PROXY プロトコルを使用するように設定する方法を説明しています。

3.4.2. PROXY プロトコルを使用する理由

プロキシーサーバーやロードバランサーなどの中間サービスが HTTP 要求を転送する際に、これは接続のソースアドレスを要求の「Forwarded」ヘッダーに追加して、この情報を後続の中間サービスと、要求が最終的に転送されるバックエンドサービスに提供できます。ただし、接続が暗号化されている場合、中間サービスは「Forwarded」ヘッダーを変更できません。この場合、要求が転送されても HTTP ヘッダーは元のソースアドレスを正確に通信することができません。

この問題を解決するために、一部のロードバランサーは、単純に HTTP を転送する代替手段として PROXY プロトコルを使用して HTTP 要求をカプセル化します。カプセル化によって、ロードバランサーは転送される要求自体を変更することなく、情報を要求に追加することができます。これにより、ロードバランサーは、暗号化された接続を転送する場合でもソースアドレスを通信できます。

HAProxy ルーターが PROXY プロトコルを受け入れ、HTTP 要求のカプセル化を解除するように設定できます。ルーターは edge および re-encrypt ルートの暗号化を終了するので、ルーターは要求の「Forwarded」HTTP ヘッダー (および関連する HTTP ヘッダー) を更新でき、PROXY プロトコルを使用して通信されるソースアドレスを追加できます。

警告

PROXY プロトコルと HTTP は互換性がなく、組み合わせることはできません。ルーターの前にロードバランサーを使用する場合、これらがどちらも PROXY プロトコルまたは HTTP のいずれかを使用する必要があります。一方を PROXY プロトコルを使用するように設定し、他方を HTTP を使用するように設定すると、ルーティングが失敗します。

3.4.3. PROXY プロトコルの使用

デフォルトで、HAProxy ルーターは PROXY プロトコルを使用しません。ROUTER_USE_PROXY_PROTOCOL 環境変数を使用することで、ルーターが受信接続に PROXY プロコトルの使用を予想するように設定できます。

PROXY プロコトルの有効化

$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=true

変数を true または TRUE 以外の値に設定し、PROXY プロコトルを無効にします。

PROXY プロトコルの無効化

$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=false

ルーターで PROXY プロトコルを有効にする場合、ルーターの前のロードバランサーが PROXY プロコトルを使用するように設定する必要があります。以下は、Amazon の Elastic Load Balancer (ELB) サービスを PROXY プロトコルを使用するように設定した例です。この例では、ELB がポート 80 (HTTP)、443 (HTTPS)、5000 (イメージレジストリーの場合) を 1 つ以上の EC2 インスタンスで実行されるルーターに転送することを想定しています。

Amazon ELB を設定して PROXY プロコトルを使用する

  1. 後続の手順を単純化するために、最初に一部の Shell 変数を設定します。

    $ lb='infra-lb' 1
    $ instances=( 'i-079b4096c654f563c' ) 2
    $ secgroups=( 'sg-e1760186' ) 3
    $ subnets=( 'subnet-cf57c596' ) 4
    1
    ELB の名前。
    2
    ルーターが実行されているインスタンス。
    3
    この ELB のセキュリティーグループ。
    4
    この ELB のサブネット。
  2. 次に、適切なリスナーやセキュリティーグループおよびサブネットを使用して ELB を作成します。

    注記

    すべてのリスナーが HTTP プロトコルではなく TCP プロトコルを使用するよう設定する必要があります。

    $ aws elb create-load-balancer --load-balancer-name "$lb" \
       --listeners \
        'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80' \
        'Protocol=TCP,LoadBalancerPort=443,InstanceProtocol=TCP,InstancePort=443' \
        'Protocol=TCP,LoadBalancerPort=5000,InstanceProtocol=TCP,InstancePort=5000' \
       --security-groups $secgroups \
       --subnets $subnets
    {
        "DNSName": "infra-lb-2006263232.us-east-1.elb.amazonaws.com"
    }
  3. ルーターインスタンスを ELB に登録します。

    $ aws elb register-instances-with-load-balancer --load-balancer-name "$lb" \
       --instances $instances
    {
        "Instances": [
            {
                "InstanceId": "i-079b4096c654f563c"
            }
        ]
    }
  4. ELB のヘルスチェックを設定します。

    $ aws elb configure-health-check --load-balancer-name "$lb" \
       --health-check 'Target=HTTP:1936/healthz,Interval=30,UnhealthyThreshold=2,HealthyThreshold=2,Timeout=5'
    {
        "HealthCheck": {
            "HealthyThreshold": 2,
            "Interval": 30,
            "Target": "HTTP:1936/healthz",
            "Timeout": 5,
            "UnhealthyThreshold": 2
        }
    }
  5. 最後に、ProxyProtocol 属性を有効にしたロードバランサーのポリシーを作成し、ELB の TCP ポート 80 および 443 でポリシーを設定します。

    $ aws elb create-load-balancer-policy --load-balancer-name "$lb" \
       --policy-name "${lb}-ProxyProtocol-policy" \
       --policy-type-name 'ProxyProtocolPolicyType' \
       --policy-attributes 'AttributeName=ProxyProtocol,AttributeValue=true'
    $ for port in 80 443
      do
        aws elb set-load-balancer-policies-for-backend-server \
         --load-balancer-name "$lb" \
         --instance-port "$port" \
         --policy-names "${lb}-ProxyProtocol-policy"
      done

設定の確認

ロードバランサーを以下のように検証して、設定が正しいことを確認します。

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
    jq '.LoadBalancerDescriptions| [.[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 1
    },
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": ["infra-lb-ProxyProtocol-policy"] 2
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": [] 3
    }
  ]
]
1
TCP ポート 80 のリスナーには PROXY プロトコルを使用するポリシーが設定されている必要があります。
2
TCP ポート 443 のリスナーには同じポリシーが設定されている必要があります。
3
TCP ポート 5000 のリスナーにはこのポリシーを設定できません

または、ELB をすでに設定していても、PROXY プロトコルを使用するよう設定されていない場合は、 TCP ポート 80 の既存リスナーを、HTTP ではなく TCP プロコトルを使用するように変更する必要があります (TCP ポート 443 はすでに TCP プロトコルを使用しているはずです)。

$ aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \
   --load-balancer-ports 80
$ aws elb create-load-balancer-listeners --load-balancer-name "$lb" \
   --listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'

プロコトル更新の確認

プロコトルが以下のように更新されていることを確認します。

$ aws elb describe-load-balancers --load-balancer-name "$lb" |
   jq '[.LoadBalancerDescriptions[]|.ListenerDescriptions]'
[
  [
    {
      "Listener": {
        "InstancePort": 443,
        "LoadBalancerPort": 443,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 5000,
        "LoadBalancerPort": 5000,
        "Protocol": "TCP",
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    },
    {
      "Listener": {
        "InstancePort": 80,
        "LoadBalancerPort": 80,
        "Protocol": "TCP", 1
        "InstanceProtocol": "TCP"
      },
      "PolicyNames": []
    }
  ]
]
1
TCP ポート 80 のリスナーなど、すべてのリスナーが TCP プロコトルを使用している必要があります。

次にロードバランサーポリシーを作成し、上記の手順 5 に説明されているようにこれを ELB に追加します。

3.5. F5 ルータープラグインの使用

3.5.1. 概要

注記

F5 ルータープラグインは OpenShift Container Platform 3.0.2 以降で利用できます。

警告

F5 ルータープラグインは OpenShift Container Platform バージョン 3.11 で非推奨になります。F5 ルータープラグインの機能は OpenShift 向けの F5 BIG-IP® Controller に置き換わります。詳細は、「F5 BIG-IP Controller for OpenShift」を参照してください。F5 ルータープラグインから OpenShift 向けの BIG-IP Controller に既存デプロイメントを移行する方法については、詳細は、「Replace the F5 Router with the F5 BIG-IP Controller for OpenShift」を参照してください。

F5 ルーターブラグインはコンテナーイメージとして提供され、デフォルトの HAProxy ルーターのように Pod として実行されます。

重要

F5 と Red Hat 間のサポート体制により、Red Hat は F5 統合のモデルとして F5 ルータープラグインおよび OpenShift 向けの F5 BIG-IP Controller の両方を完全にサポートしています。F5 ルータープラグインを使用している場合、Red Hat サポートは必要な場合に初期サポートを提供し、F5 サポートと共同でサポートします。また、OpenShift 向けの F5 BIG-IP Controller を使用している場合、F5 は必要な場合に初期サポートを提供し、Red Hat と共同でサポートします。

3.5.2. 前提条件とサポート容易性

F5 ルータープラグインのデプロイ時に、以下の要件を満たしていることを確認してください。

  • F5 ホスト IPに以下が設定されている:

    • API アクセスの認証情報
    • プライベートキーによる SSH アクセス
  • 高度な Shell アクセスを持つ F5 ユーザー
  • HTTP ルートの仮想サーバー:

    • HTTP プロファイルhttp である必要があります。
  • HTTP プロファイルルートを持つ仮想サーバー:

    • HTTP プロファイルhttp である必要があります。
    • SSL プロファイル (クライアント)clientssl である必要があります。
    • SSL プロファイル (サーバー)serverssl である必要があります。
  • edge 統合の場合 (非推奨):

    • 稼働中の Ramp ノード
    • Ramp ノードへの稼働中のトンネル
  • ネイティブ統合の場合:

    • ポート 4789/UDP のすべてのノードと通信できるホストの内部 IP
    • F5 ホストにインストールされた sdn-services アドオンライセンス

OpenShift Container Platform 向けの F5 ルータープラグインは以下の F5 BIG-IP バージョンのみをサポートしています。

  • 11.x
  • 12.x

OpenShift 向けの F5 BIG-IP Controller は、F5 ドキュメンテーションの「F5 BIG-IP Controller for OpenShift releases and versioning」のページにある OpenShift Container Platform バージョンをサポートしています。

重要

以下の機能は、F5 ルータープラグインを使用する際に F5 BIG-IP でサポートされていません。

  • ワイルドカードルートと re-encrypt ルートの併用: ルートに証明書とキーを指定する必要があります。証明書、キー、認証局 (CA) を指定しても、CA は使用されません。
  • 関連ルートを持たないサービスを含め、すべてのサービスのプールが作成されます。
  • アプリケーションのアイドリング
  • redirect モードの暗号化されていない HTTP トラフィックと TLS edge termination。(insecureEdgeTerminationPolicy: Redirect)
  • シャード化、つまり F5 で複数の vservers を設定する。
  • SSL 暗号 (ROUTER_CIPHERS=modern/old)
  • エンドポイントのヘルスチェックの間隔やチェックタイプのカスタマイズ。
  • メトリクスサーバーの使用による F5 メトリクスの提供。
  • サービスでされるポートではない各種ターゲットポート (PreferPort/TargetPort) の指定。
  • ソース IP ホワイトリストのカスタマイズ。つまり特定の IP アドレスのルートのみに対してトラフィックを許可する。
  • max connect time または tcp FIN timeout などのタイムアウト値のカスタマイズ。
  • F5 BIG-IP の HA モード。

3.5.2.1. 仮想サーバーの設定

F5 ルータープラグインを使用する前提条件として、2 つの仮想サーバー (HTTP および HTTPS プロファイルのそれぞれに 1 つの仮想サーバー) を F5 BIG-IP アプライアンスでセットアップする必要があります。

F5 BIG-IP アプライアンスで仮想サーバーを設定するには、F5 の指示に従います。

仮想サーバーを作成する際に、以下の設定が有効であることを確認します。

  • HTTP サーバーの場合は、ServicePort'http'/80 に設定します。
  • HTTPS サーバーの場合は、ServicePort'https'/443 に設定します。
  • 基本設定で、両方の仮想サーバーの HTTP プロファイルを /Common/http に設定します。
  • HTTPS サーバーの場合は、 デフォルトの client-ssl プロファイルを作成し、SSL プロファイル (クライアント) に対してこれを選択します。

    • デフォルトのクライアント SSL プロファイルを作成するには、F5 の指示、特に「Configuring the fallback (default) client SSL profile」セクションに従います。このセクションは、この証明書/キーペアはデフォルトで、ルートまたはサービス名にカスタムの証明書が指定されていない場合に提供されることについて説明しています。

3.5.3. F5 ルータープラグインの使用

重要

ルート証明書は scp コマンドを使用してコピーされるため、F5 ルーターは特権モードで実行される必要があります。

$ oc adm policy remove-scc-from-user hostnetwork -z router
$ oc adm policy add-scc-to-user privileged -z router

oc adm router コマンドを使用して F5 ルータープラグインをデプロイしますが、F5 BIG-IP ホストの以下のパラメーターを指定する追加のフラグ (または環境変数) を提供します。

フラグ説明

--type=f5-router

デフォルトの haproxy-router ではなく F5 ルータープラグインの起動を指定します (デフォルトの --typehaproxy-routerです)。

--external-host

F5 BIG-IP ホストの管理インターフェースのホスト名または IP アドレスを指定します。

--external-host-username

F5 BIG-IP のユーザー名 (通常は admin) を指定します。F5 BIG-IP のユーザーアカウントは F5 BIG-IP システムの Advanced Shell (Bash) へのアクセスがなければなりません。

--external-host-password

F5 BIG-IP のパスワードを指定します。

--external-host-http-vserver

HTTP 接続の F5 仮想サーバーの名前を指定します。これは、ルーター Pod の起動前にユーザーによって設定される必要があります。

--external-host-https-vserver

HTTPS 接続の F5 仮想サーバーの名前を指定します。これは、ルーター Pod の起動前にユーザーによって設定される必要があります。

--external-host-private-key

F5 BIG-IP ホストの SSH プライベートキーファイルへのパスを指定します。ルートのキーと証明書ファイルをアップロードし、削除する必要があります。

--external-host-insecure

F5 ルータープラグインが F5 BIG-IP ホストの証明書の厳密な検証を省略することを示す Boolean フラグです。

--external-host-partition-path

F5 BIG-IP® パーティションパス (デフォルトは /Common) を指定します。

以下は例を示しています。

$ oc adm router \
    --type=f5-router \
    --external-host=10.0.0.2 \
    --external-host-username=admin \
    --external-host-password=mypassword \
    --external-host-http-vserver=ose-vserver \
    --external-host-https-vserver=https-ose-vserver \
    --external-host-private-key=/path/to/key \
    --host-network=false \
    --service-account=router

HAProxy ルーターの場合のように、oc adm router コマンドがサービスとデプロイメント設定オブジェクトを作成するため、F5 ルータープラグイン自体が実行されるレプリケーションコントローラーと Pod が作成されます。レプリケーションコントローラーはクラッシュが発生した場合に F5 ルータープラグインを再起動します。F5 ルータープラグインはルート、エンドポイント、ノードを監視し、F5 BIG-IP を適宜設定するため、 F5 ルーターを適切に設定された F5 BIG-IP デプロイメントで実行すると高可用性の要件を満たすことができます。

3.5.4. F5 ルータープラグインのパーティションパス

パーティションパスによって、デフォルトの /Common パーティションではなく、カスタムの F5 BIG-IP 管理パーティションで OpenShift Container Platform ルーティング設定を保存できます。カスタム管理パーティションを使用して F5 BIG-IP 環境を保護することができます。つまり、F5 BIG-IP システムオブジェクトに保存される OpenShift Container Platform 特有の設定が論理コンテナー内にあり、管理者はその管理パーティションでアクセス制御を定義できます。

管理パーティションの詳細については、F5 BIG-IP ドキュメントを参照してください。

パーティションパスについて OpenShift Container Platform を設定するには、以下を実行します。

  1. オプションで一部のクリーニング手順を実行できます。

    1. F5 が /Common および /Custom パスに切り替えられるよう設定されていることを確認してください。
    2. vxlan5000 の静的 FDB を削除します。詳細は、F5 BIG-IP® ドキュメントを参照してください。
  2. カスタムパーティションの仮想サーバーを設定します。
  3. パーティションパスを指定するには、--external-host-partition-path フラグを使用して F5 ルーターをデプロイします。

    $ oc adm router --external-host-partition-path=/OpenShift/zone1 ...

3.5.5. F5 ルータープラグインのセットアップ

注記

このセクションでは、OpenShift Container Platform への F5 ネイティブ統合のセットアップ方法を確認します。F5 アプライアンスと OpenShift Container Platform 接続の概念および F5 ルータープラグインのデータフローはルートに関するトピックの「F5 Router Plug-in」セクションで説明されています。

注記

F5 BIG-IP アプライアンスのバージョン 11.x および 12.x のみが、このセクションに記載されている F5 ルータープラグインに対応します。また、適切に統合を行うために sdn-services アドオンライセンスが必要になります。バージョン 11.x の場合は、ramp ノード のセットアップ手順に従ってください。

OpenShift Container Platform の F5 ルータープラグインでは、OpenShift SDN で作成されるオーバーレイネットワーク上の Pod に到達できるように ramp ノードを設定する必要はありません。

F5 ルータープラグイン Pod は、Pod に直接正常に接続できるようにするために必要な十分な情報を使って起動する必要があります。

  1. OpenShift Container Platform クラスターにゴースト hostsubnet を作成します。

    $ cat > f5-hostsubnet.yaml << EOF
    {
        "kind": "HostSubnet",
        "apiVersion": "v1",
        "metadata": {
            "name": "openshift-f5-node",
            "annotations": {
            "pod.network.openshift.io/assign-subnet": "true",
    	"pod.network.openshift.io/fixed-vnid-host": "0"  1
            }
        },
        "host": "openshift-f5-node",
        "hostIP": "10.3.89.213"  2
    } EOF
    $ oc create -f f5-hostsubnet.yaml
    1
    F5 をグローバルにします。
    2
    F5 アプライアンスの内部 IP です。
  2. 作成したゴースト hostsubnet に割り当てるサブネットを決定します。

    $ oc get hostsubnets
    NAME                    HOST                    HOST IP       SUBNET
    openshift-f5-node       openshift-f5-node       10.3.89.213   10.131.0.0/23
    openshift-master-node   openshift-master-node   172.17.0.2    10.129.0.0/23
    openshift-node-1        openshift-node-1        172.17.0.3    10.128.0.0/23
    openshift-node-2        openshift-node-2        172.17.0.4    10.130.0.0/23
  3. 新たに作成した hostsubnetSUBNET を確認します。この例では 10.131.0.0/23 です。
  4. Pod ネットワーク全体の CIDR を取得します。

    $ oc get clusternetwork

    この値は 10.128.0.0/14 のように表示されます。マスク (この例では 14) に注意してください。

  5. ゲートウェイアドレスを作成するには、hostsubnet から任意の IP アドレス (例: 10.131.0.5) を選択します。Pod ネットワークのマスク (14) を使用します。ゲートウェイアドレスは 10.131.0.5/14 になります。
  6. こちらの指示に従って F5 ルータープラグイン Pod を起動してください。さらに、サービスアカウントに「ノード」のクラスターリソースへのアクセスを許可し、VXLAN のネイティブ統合に 2 つの新しい追加オプションを使用します。

    $ # Add policy to allow router to access nodes using the sdn-reader role
    $ oc adm policy add-cluster-role-to-user system:sdn-reader system:serviceaccount:default:router
    $ # Launch the F5 router plug-in pod with vxlan-gw and F5's internal IP as extra arguments
    $ #--external-host-internal-ip=10.3.89.213
    $ #--external-host-vxlan-gw=10.131.0.5/14
    $ oc adm router \
        --type=f5-router \
        --external-host=10.3.89.90 \
        --external-host-username=admin \
        --external-host-password=mypassword \
        --external-host-http-vserver=ose-vserver \
        --external-host-https-vserver=https-ose-vserver \
        --external-host-private-key=/path/to/key \
        --service-account=router \
        --host-network=false \
        --external-host-internal-ip=10.3.89.213 \
        --external-host-vxlan-gw=10.131.0.5/14
    注記

    external-host-username は、F5 BIG-IP システムの Advanced Shell (Bash) へのアクセスを持つ F5 BIG-IP ユーザーアカウントです。

第4章 Red Hat CloudForms のデプロイ

4.1. Red Hat CloudForms の OpenShift Container Platform へのデプロイ

4.1.1. はじめに

OpenShift Container Platform インストーラーには、Red Hat CloudForms 4.6 (CloudForms Management Engine 5.9 または CFME) を OpenShift Container Platform にデプロイするための Ansible ロールの openshift-management と Playbook が含まれています。

警告

現在の実装には、OpenShift Container Platform 3.6 ドキュメントで説明されているように、Red Hat CloudForms 4.5 のテクノロジープレビューのデプロイメントプロセスとの互換性はありません。

Red Hat CloudForms を OpenShift Container Platform にデプロイする際には、以下の 2 つ点について決定する必要があります。

  1. 外部またはコンテナー化された (Pod 化された とも言う) PostgreSQL データベースを使用するかどうか。
  2. 永続ボリューム (PV) をどのストレージクラスでサポートするか。

最初の点については、Red Hat CloudForms で使用する PostgreSQL データベースが置かれている場所によって Red Hat CloudForms を以下のいずれかの方法でデプロイできます。

デプロイのバリアント説明

完全コンテナー化

すべてのアプリケーションサービスと PostgreSQL データベースは、OpenShift Container Platform で Pod として実行されます。

外部データベース

アプリケーションは外部でホストされた PostgreSQL データベースサーバーを使用し、その他すべてのサービスは OpenShift Container Platform で Pod として実行されます。

2 つ目の点については、openshift-management ロールが、多くのデフォルトのデプロイメントパラメーターの上書き用にカスタマイズオプションを提供します。これには、 PV をサポートするための以下のストレージクラスのオプションが含まれています。

ストレージクラス説明

NFS (デフォルト)

ローカル、クラスター上

NFS (外部)

NFS の他の場所 、ストレージアプライアンスなど

クラウドプロバイダー

クラウドプロバイダー (Google Cloud Engine、Amazon Web Services、または Microsoft Azure) の自動ストレージプロビジョニングを使用

事前設定 (詳細)

ユーザーが事前にすべてを作成済みであることを前提とする

本書では、Red Hat CloudForms を OpenShift Container Platform で実行するための要件、利用可能な設定変数の説明、および OpenShift Container Platform の初回インストール時かクラスターのプロビジョニング後のいずれかでインストーラーを実行する方法などについてのトピックを扱います。

4.2. Red Hat CloudForms を OpenShift Container Platform で使用するための要件

 
デフォルトの要件は以下の表に記載されています。これらはテンプレートパラメーターをカスタマイズして上書きできます。

重要

以下の要件を満たしていないと、アプリケーションのパフォーマンスが低下するか、またはデプロイに失敗する可能性があります。

表4.1 デフォルトの要件

項目要件説明カスタマイズパラメーター

アプリケーションメモリー

≥ 4.0 Gi

アプリケーションのメモリー最小要件

APPLICATION_MEM_REQ

アプリケーションストレージ

≥ 5.0 Gi

アプリケーションの PV サイズ最小要件

APPLICATION_VOLUME_CAPACITY

PostgreSQL メモリー

≥ 6.0 Gi

データベースのメモリー最小要件

POSTGRESQL_MEM_REQ

PostgreSQL ストレージ

≥ 15.0 Gi

データベースの PV サイズ最小要件

DATABASE_VOLUME_CAPACITY

クラスターホスト

≥ 3

クラスター内のホスト数

該当なし

以上の要件をまとめると以下のようになります。

  • ユーザーにはいくつかのクラスターノードが必要である。
  • クラスターノードには多くの利用可能なメモリーが必要である。
  • ユーザーは、ローカルまたはクラウドプロバイダーに数 GiB の利用可能なストレージを持っている必要がある。
  • PV サイズはテンプレートパラメーターの値を上書きして変更できる。

4.3. ロール変数の設定

4.3.1. 概要

以下のセクションでは、Ansible インベントリーファイル で使用されるロール変数について説明します。ロール変数は、インストーラーを実行する際に Red Hat CloudForms インストールの動作を制御するために使用されます。

4.3.2. 一般的な変数

変数必須デフォルト説明

openshift_management_install_management

No

false

ブール値。アプリケーションをインストールするには true に設定します。

openshift_management_app_template

必要

cfme-template

インストールする Red Hat CloudForms のデプロイメントバリアントです。コンテナー化されたデータベースに cfme-template を設定するか、または外部データベースに cfme-template-ext-db を設定します。

openshift_management_project

No

openshift-management

Red Hat CloudForms インストールの namespace (プロジェクト)。

openshift_management_project_description

No

CloudForms Management Engine

namespace (プロジェクト) の説明。

openshift_management_username

No

admin

デフォルトの管理ユーザー名。この値を変更してもユーザー名は変更されません。名前をすでに変更しており、統合スクリプト (コンテナープロバイダーを追加するためのスクリプトなど) を実行している場合にのみこの値を変更してください。

openshift_management_password

No

smartvm

デフォルトの管理パスワード。この値を変更してもパスワードは変更されません。このパスワードをすでに変更しており、統合スクリプト (コンテナープロバイダーを追加するためのスクリプトなど) を実行している場合にのみこの値を変更してください。

4.3.3. テンプレートパラメーターのカスタマイズ

openshift_management_template_parameters Ansible ロール変数は、アプリケーションまたは PV テンプレートで上書きする必要のあるテンプレートを指定するために使用します。

たとえば、PostgreSQL Pod のメモリー要件を減らしたい場合には、以下を設定します。

openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}

Red Hat CloudForms テンプレートが処理される際に、1GiPOSTGRESQL_MEM_REQ テンプレートパラメーターの値に使用されます。

すべてのテンプレートパラメーターが (コンテナー化されたデータベースと外部データベースの) 両方 のテンプレートバリアントにある訳ではありません。たとえば、Pod 化されたデータベースのテンプレートには POSTGRESQL_MEM_REQ パラメーターがありますが、このパラメーターは外部のデータベーステンプレートにはありません。そこには Pod を必要とするデータベースが存在せず、この情報は必要とされないためです。

したがって、テンプレートパラメーターを上書きする場合には十分注意する必要があります。テンプレートで定義されていないパラメーターを追加するとエラーの原因になります。管理アプリケーションの作成を確認するタスクの実行時にエラーを受信した場合は、インストーラーを再度実行する前にアンインストールのスクリプトを実行してください。

4.3.4. データベース変数

4.3.4.1. コンテナー化された (Pod 化された) データベース

cfme-template.yaml ファイルにある POSTGRES_* または DATABASE_* テンプレートパラメーターは、インベントリーファイルの openshift_management_template_parameters ハッシュを使用してカスタマイズすることができます。

4.3.4.2. 外部データベース

cfme-template-ext-db.yaml ファイルにある POSTGRES_* または DATABASE_* テンプレートパラメーターは、インベントリーファイルの openshift_management_template_parameters ハッシュを使用してカスタマイズすることができます。

外部 PostgreSQL データベースは、ユーザーにデータベース接続パラメーターを指定するように要求します。必要な接続キーはインベントリーの openshift_management_template_parameters パラメーターに設定する必要があります。必要なキー以下の通りです。

  • DATABASE_USER
  • DATABASE_PASSWORD
  • DATABASE_IP
  • DATABASE_PORT (ほとんどの PostgreSQL サーバーはポート 5432 で実行されます)
  • DATABASE_NAME
注記

外部データベースで PostgreSQL 9.5 が実行されていることを確認します。実行されていないと、CloudForms アプリケーションを正常にデプロイできない場合があります。

インベントリーに、以下のような行が含まれているはずです。

[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db 1
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
1
openshift_management_app_template パラメーターを cfme-template-ext-db に設定します。

4.3.5. ストレージクラス変数

変数必須デフォルト説明

openshift_management_storage_class

No

nfs

使用されるストレージのタイプ。オプションには nfsnfs_externalpreconfiguredcloudprovider があります。

openshift_management_storage_nfs_external_hostname

No

false

NetApp アプライアンスなどの外部 NFS サーバーを使用している場合、ここにホスト名を設定する必要があります。外部 NFS を使用していない場合は値を false のままにしておきます。さらに外部 NFS では、ユーザーがアプリケーション PV とオプションでデータベース PV をサポートする NFS エクスポートを作成する必要があります。

openshift_management_storage_nfs_base_dir

No

/exports/

外部 NFS を使用している場合、ベースパスをこのエクスポートの位置に設定できます。ローカルの NFS の場合、ローカルの NFS エクスポートに使用されているデフォルトのパスを変更する必要がある場合にも、この値を変更します。

openshift_management_storage_nfs_local_hostname

No

false

[nfs] グループがインベントリーにない場合や、ローカルの NFS ホストをクラスターに手動で定義する必要がある場合は、このパラメーターを必要な NFS サーバーのホスト名に設定します。サーバーは OpenShift Container Platform クラスターの一部である必要があります。

4.3.5.1. NFS (デフォルト)

NFS ストレージクラスは、概念実証およびテストデプロイメントに最も適しています。このクラスは、デプロイメント用のデフォルトのステージクラスにもなります。これを選択した場合、追加の設定は不要です。

このストレージクラスは、必要な PV をサポートするように NFS をクラスターホスト (デフォルトではインベントリーファイルの最初のマスター) に設定します。アプリケーションは PV を必要とし、データベース (外部でホストされている可能性がある) は 2 番目の PV が必要となる場合があります。PV サイズの最小要件は、Red Hat CloudForms アプリケーションは 5GiB、PostgreSQL データベースは 15GiB です (NFS 専用で使用する場合は、ボリュームまたはパーティション上の使用可能な最小領域は 20GiB です)。

カスタマイズは、以下のロール変数を使って行われます。

  • openshift_management_storage_nfs_base_dir
  • openshift_management_storage_nfs_local_hostname

4.3.5.2. NFS (外部)

外部 NFS は、必要な PV にエクスポートを提供するために事前設定された NFS サーバーを使用します。外部 NFS の場合、ユーザーは cfme-app とオプションで cfme-db (コンテナー化されたデータベース用) のエクスポートが必要です。

設定は、以下のロール変数を使って提供されます。

  • openshift_management_storage_nfs_external_hostname
  • openshift_management_storage_nfs_base_dir

openshift_management_storage_nfs_external_hostnameパラメーターは、外部 NFS サーバーのホスト名または IP に設定する必要があります。

/exports がエクスポートの親ディレクトリーではない場合、ベースディレクトリーを openshift_management_storage_nfs_base_dir パラメーターで設定する必要があります。

たとえば、サーバーエクスポートが /exports/hosted/prod/cfme-app の場合は、openshift_management_storage_nfs_base_dir=/exports/hosted/prod を設定する必要があります。

4.3.5.3. クラウドプロバイダー

ストレージクラスに OpenShift Container Platform のクラウドプロバイダー統合を使用している場合、Red Hat CloudForms は必要な PV をサポートするためにこのクラウドプロバイダーを使用することができます。これを正常に実行するには、openshift_cloudprovider_kind 変数 (AWS または GCE 用)と、ユーザーが選択したクラウドプロバイダーに固有のすべての関連パラメーターを設定している必要があります。

アプリケーションがこのストレージクラスを使って作成されている場合、必要な PV は、設定済みのクラウドプロバイダーのストレージ統合を使って自動的にプロビジョニングされます。

このストレージクラスの動作を設定するために使用される追加の変数はありません。

4.3.5.4. 事前設定 (詳細)

preconfigured (事前設定されている) ストレージクラスの場合、ユーザーは各自の操作を正確に把握しており、すべてのストレージ要件が事前に配慮されていることを意味します。この場合、通常は適切なサイズに設定された PV がすでに作成されているので、インストーラーはストレージ設定を変更する必要がありません。

このストレージクラスの動作を設定するために使用される追加の変数はありません。

4.4. インストーラーの実行

4.4.1. OpenShift Container Platform のインストール時またはインストール後の Red Hat CloudForms のデプロイ

Red Hat CloudForms のデプロイを、OpenShift Container Platform の初回インストール時か、またはクラスターのプロビジョニング後のいずれかに実行することを選択できます。

  1. openshift_management_install_management がインベントリーファイルの [OSEv3:vars] セクションの下で true に設定されていることを確認します。

    [OSEv3:vars]
    openshift_management_install_management=true
  2. インベントリーファイルにある Red Hat CloudForms のその他のロール変数を、「ロール変数の設定」で説明されているように設定します。「インベントリーファイルの例」には、これを実行するのに役立つリソースがあります。
  3. OpenShift Container Platform がすでにプロビジョニングされているかどうかに応じて、実行する Playbook を選択します。

    1. Red Hat CloudForms を、OpenShift Container Platform クラスターのインストールと同時にインストールする必要がある場合には、「インストール Playbook の実行」で説明されているように標準の config.yml Playbook を呼び出して、OpenShift Container Platform クラスターと Red Hat CloudForms のインストールを開始します。
    2. Red Hat CloudForms を、すでにプロビジョニングされている OpenShift Container Platform クラスターにインストールする必要がある場合には、Red Hat CloudForms Playbook を直接呼び出してインストールを開始します。

      # ansible-playbook -v [-i /path/to/inventory] \
          /usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.yml

4.4.2. インベントリーファイルの例

このセクションでは、インベントリーファイルのスニペットの例について説明し、使い始めに役立つ OpenShift Container Platform での Red Hat CloudForms の各種の設定について説明します。

注記

変数の詳しい説明については、「ロール変数の設定」を参照してください。

4.4.2.1. すべてのデフォルト

以下は、すべてのデフォルト値と選択肢を使用した最も単純な例です。これで、Red Hat CloudForms のインストールが完全にコンテナー化 (Pod 化) されます。すべてのアプリケーションコンポーネントと PostgreSQL データベースが OpenShift Container Platform に Pod として作成されます。

[OSEv3:vars]
openshift_management_app_template=cfme-template

4.4.2.2. 外部 NFS ストレージ

以下は、前述の例と同様に (ただしローカルの NFS サービスをクラスターで使用する代わりに)、既存の外部 NFS サーバー (ストレージアプライアンスなど) を使用しています。

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_storage_class=nfs_external 1
openshift_management_storage_nfs_external_hostname=nfs.example.com 2
1
nfs_external に設定します。
2
NFS サーバーのホスト名に設定します。

外部 NFS ホストが /exports/hosted/prod などの異なる親ディレクトリーの下でエクスポートディレクトリーをホストしている場合は、以下の変数を追加します。

openshift_management_storage_nfs_base_dir=/exports/hosted/prod

4.4.2.3. PV サイズの上書き

以下の例では、永続ボリューム (PV) のサイズを上書きします。PV サイズは openshift_management_template_parameters で設定する必要があります。これにより、アプリケーションとデータベースは相互に干渉しあうことなく作成済みの PV で要求を実行できます。

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}

4.4.2.4. メモリー要件の上書き

テストまたは概念実証のインストールでは、アプリケーションとデータベースのメモリー要件を設定している容量内に収めるようにする必要がある場合があります。メモリーの上限を下げると、パフォーマンスが低下するか、またはアプリケーションの初期化に完全に失敗したりする可能性があることに注意してください。

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}

この例では、インストーラーに対し、パラメーター APPLICATION_MEM_REQ3000Mi に、POSTGRESQL_MEM_REQ1Gi に、さらに ANSIBLE_MEM_REQ512Miに設定してアプリケーションテンプレートを処理するように指示します。

これらのパラメーターは、前述の例 PV サイズの上書きに示されているパラメーターと組み合せることができます。

4.4.2.5. 外部 PostgreSQL データベース

外部データベースを使用するには、openshift_management_app_template パラメーターの値を cfme-template-ext-db に変更する必要があります。

さらに、データベース接続情報を openshift_management_template_parameters 変数を使って入力する必要があります。詳細は、「ロール変数の設定」を参照してください。

[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
重要

PostgreSQL 9.5 が実行中であることを確認してください。実行されていないと、アプリケーションを正常にデプロイできない場合があります。

4.5. コンテナープロバイダー統合の有効化

4.5.1. 単一コンテナープロバイダーの追加

インストーラーの実行」で説明されているように Red Hat CloudForms を OpenShift Container Platform にデプロイした後にコンテナープロバイダーの統合を有効にする方法として 、OpenShift Container Platform をコンテナープロバイダーとして手動で追加する方法と、このロールに含まれている Playbook を試行する方法の 2 つの方法があります。

4.5.1.1. 手動の追加

OpenShift Container Platform クラスターをコンテナープロバイダーとして手動で追加する手順については、以下の Red Hat CloudForms ドキュメントを参照してください。

4.5.1.2. 自動の追加

コンテナープロバイダーの自動的な統合は、このロールに含まれている Playbook を使用して実行できます。

この Playbook は以下を実行します。

  1. 必要な認証シークレットを収集します。
  2. Red Hat CloudForms アプリケーションとクラスター API への公開ルートを検索します。
  3. REST の呼び出しを実行し、OpenShift Container Platform クラスターをコンテナープロバイダーとして追加します。

コンテナープロバイダーの Playbook を実行するには、以下を実行します。

# ansible-playbook -v [-i /path/to/inventory] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_container_provider.yml

4.5.2. 複数のコンテナープロバイダー

このロールには、最新の OpenShift Container Platform クラスターを Red Hat CloudForms デプロイメントに統合するための Playbook に加え、複数のコンテナープラットフォームを任意の Red Hat CloudForms サーバーに コンテナープロバイダーとして追加することを可能にするスクリプトが含まれています。コンテナープラットフォームは、OpenShift Container Platform または OpenShift Origin です。

複数のプロバイダースクリプトを使用する場合、Playbook の実行時に EXTRA_VARS パラメーターを CLI に手動で設定することが必要になります。

4.5.2.1. スクリプトの作成

複数のプロバイダースクリプトを作成するには、以下の手動の設定を実行します。

  1. /usr/share/ansible/openshift-ansible/roles/openshift_management/files/examples/container_providers.yml のサンプルを、/tmp/cp.yml など別の場所にコピーします。このファイルは後で変更します。
  2. Red Hat CloudForms の名前またはパスワードを変更している場合は、コピーしたcontainer_providers.yml ファイルの management_server キーにある hostnameuserpassword の各パラメーターを更新します。
  3. コンテナープロバイダーとして追加する必要のある各 Container Platform クラスターについて、container_providers キーの下にエントリーを入力します。

    1. 以下のパラメーターを設定する必要があります。

      • auth_key - cluster-admin 権限を持つサービスアカウントのトークンです。
      • hostname - クラスター API をポイントしているホスト名です。各コンテナープロバイダーは固有のホスト名を持っている必要があります。
      • name - Red Hat CloudForms サーバーのコンテナープロバイダーの概要ページに表示されるクラスター名です。この名前は固有でなければなりません。
      ヒント

      auth_key ベアラートークンをクラスターから取得するには、以下を実行します。

      $ oc serviceaccounts get-token -n management-infra management-admin
    2. 以下のパラメーターは任意で設定することができます。

      • port - Container Platform クラスターが API を 8443 以外のポートで実行している場合は、このキーを更新します。
      • endpoint - SSL 検証を有効にする (verify_ssl) か、または検証設定を ssl-with-validation に変更することができます。現時点では、カスタムの信頼される CA 証明書のサポートは利用できません。
4.5.2.1.1. 例

例として以下のシナリオを見てみましょう。

  • container_providers.yml ファイルを /tmp/cp.yml にコピーしている。
  • 2 つの OpenShift Container Platform クラスターを追加する必要がある。
  • Red Hat CloudForms サーバーが mgmt.example.com で実行されている。

このシナリオでは、/tmp/cp.yml を以下のようにカスタマイズします。

container_providers:
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 1
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname1>"
    name: <display_name1>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
  - connection_configurations:
      - authentication: {auth_key: "<token>", authtype: bearer, type: AuthToken} 2
        endpoint: {role: default, security_protocol: ssl-without-validation, verify_ssl: 0}
    hostname: "<provider_hostname2>"
    name: <display_name2>
    port: 8443
    type: "ManageIQ::Providers::Openshift::ContainerManager"
management_server:
  hostname: "<hostname>"
  user: <user_name>
  password: <password>
1 2
<token> をこのクラスターの管理トークンに置き換えます。

4.5.2.2. Playbook の実行

複数プロバイダー統合スクリプトを実行するには、コンテナープロバイダーの設定ファイルへのパスを EXTRA_VARS パラメーターとしてansible-playbook コマンドに指定する必要があります。container_providers_config を設定ファイルパスに設定するには、-e (または --extra-vars) パラメーターを使用します。

# ansible-playbook -v [-i /path/to/inventory] \
    -e container_providers_config=/tmp/cp.yml \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_many_container_providers.yml

Playbook が完成すると、Red Hat CloudForms サービスに 2 つの新しいコンテナープロバイダーが見つかるはずです。コンピュート → コンテナー → プロバイダー の順にページを進んで概要を確認してください。

4.5.3. プロバイダーの更新

単一または複数のコンテナープロバイダーを追加したら、新規プロバイダーを Red Hat CloudForms で更新し、コンテナープロバイダーと管理されているコンテナーに関する最新データをすべて取得する必要があります。そのためには、Red Hat CloudForms Web コンソールの各プロバイダーに進み、それぞれについて更新ボタンをクリックします。

手順については、以下の Red Hat CloudForms ドキュメントを参照してください。

4.6. Red Hat CloudForms のアンインストール

4.6.1. アンインストール Playbook の実行

デプロイした Red Hat CloudForms インストールを OpenShift Container Platform からアンインストールして削除するには、以下の Playbook を実行します。

# ansible-playbook -v [-i /path/to/inventory] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-management/uninstall.yml
重要

NFS エクスポートの定義とNFS エクスポートに格納されているデータは自動的に削除されません。新規デプロイメントの初期化を試行する前に、古いアプリケーションまたはデータベースデプロイメントのデータを手動で消去することが推奨されます。

4.6.2. トラブルシューティング

古い PostgreSQL データの消去に失敗すると連鎖的なエラーが発生し、postgresql Pod が crashloopbackoff の状態になる可能性があります。この状態になると cfme Pod の起動が阻止されます。crashloopbackoff は、以前のデプロイ時に作成されたデータベース NFS エクスポートの不正なファイル権限に起因します。

次に進むには、PostgreSQL エクスポートからすべてのデータを削除し、Pod (デプロイヤー Pod ではない) を削除します。以下の Pod がある場合の例を示します。

$ oc get pods
NAME                 READY     STATUS             RESTARTS   AGE
httpd-1-cx7fk        1/1       Running            1          21h
cfme-0               0/1       Running            1          21h
memcached-1-vkc7p    1/1       Running            1          21h
postgresql-1-deploy  1/1       Running            1          21h
postgresql-1-6w2t4   0/1       CrashLoopBackOff   1          21h

この場合、以下を実行します。

  1. データベース NFS エクスポートのデータを消去します。
  2. 以下を実行します。

    $ oc delete postgresql-1-6w2t4

PostgreSQL デプロイヤー Pod は、削除した Pod を置き換えるために新規の postgresql Pod の拡張を試みます。 postgresql Pod が実行された後に、cfme Pod は阻止する操作を停止し、アプリケーションの初期化を開始します。

第5章 マスターとノードの設定

openshift start コマンドおよびそのサブコマンド (マスターサーバーを起動するための master および node server を起動するための node) が受け取る引数のセット数は限定的ですが、これらは開発または実験環境でサーバーを起動するのには十分です。

ただしこれらの引数は、実稼働環境に必要な設定およびセキュリティーオプションのセットを詳細に記述し、管理するには不十分です。これらのオプションを指定するには、/etc/origin/master/master-config.yamlマスターホストファイル、および ノード設定マップでこれらのオプションを指定する必要があります。

上記のファイルは、デフォルトプラグインの上書き、etcd への接続、サービスアカウントの自動作成、イメージ名の作成、プロジェクト要求のカスタマイズ、ボリュームプラグインの設定などの各種オプションを定義します。

このトピックでは、OpenShift Container Platform のマスターとノードのホストのカスタマイズに使用できるオプションについて説明し、インストール後に設定を変更する方法を紹介します。

これらのファイルはデフォルト値なしで完全に指定されます。したがって、空の値は、ユーザーがそのパラメーターを空の値で起動しようとしていることを意味します。これによりユーザーの設定を正確に推測することを簡単になりますが、指定する必要のあるすべてのオプションを思い出す必要があるという点では容易な作業にはなりません。これをより容易にするには、設定ファイルを --write-config オプションを使って作成し、次に --config オプションを指定して使用することができます。

5.1. インストールの依存関係

実稼働環境は、標準のクラスターインストールプロセスを使用してインストールする必要があります。実稼働環境では、高可用性 (HA) を維持するために複数のマスターを使用することが適しています。3 つのマスターで構成されるクラスターアーキテクチャーが推奨され、HAproxy の使用が推奨されるソリューションになります。

注意

etcd が マスターホストにインストールされている場合は、etcd は権限を持つマスターを判別できないために、クラスターを 3 つ以上のマスターを使用するように設定する必要があります。2 つのマスターのみを正常に実行できるのは、etcd をマスター以外のホストにインストールしている場合です。

5.2. マスターとノードの設定

マスターとノードの設定ファイルの設定に使用する方法は、OpenShift Container Platform クラスターのインストールに使用した方法と同じでなければなりません。標準のクラスターインストールプロセスに従う場合は、Ansible インベントリーファイルで設定の変更を加えます。

5.3. Ansible を使用した設定の変更

このセクションは、Ansible に精通していることを前提に説明を行います。

Ansible に公開されているのは、利用可能なホスト設定オプションの一部のみです。OpenShift Container Platform のインストール後、Ansible は インベントリーファイルを置き換えられた値で作成します。このインベントリーファイルを変更し、Ansible インストーラー Playbook を再実行することで、OpenShift Container Platform クラスターをカスタマイズできます。

OpenShift Container Platform は Ansible をクラスターインストールで使用することに対応していますが、Ansible Playbook とインベントリーファイルを使うことで、PuppetChefSalt などの他の管理ツールを使用することもできます。

ユースケース: HTPasswd 認証を使用するようにクラスターを設定する

注記
  • このユースケースは、Playbook で参照されているすべてのノードに SSH キー がセットアップされていることを前提としています。
  • htpasswd ユーティリティーは httpd-tools パッケージにあります。

    # yum install httpd-tools

Ansible インベントリーを変更し、設定の変更を行うには、以下を実行します。

  1. ./hosts インベントリーファイルを開きます。
  2. 新規の変数をファイルの [OSEv3:vars] セクションに追加します。

    # htpasswd auth
    openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
    # Defining htpasswd users
    openshift_master_htpasswd_users={'<name>': '<hashed-password>', '<name>': '<hashed-password>'}
    # or
    #openshift_master_htpasswd_file=<path/to/local/pre-generated/htpasswdfile>

    HTPasswd 認証では、指定されたユーザーとパスワードを作成する openshift_master_htpasswd_users 変数か、またはすでに作成済みのユーザーとパスワードを持つ事前生成されたフラットファイル (htpasswd ファイル) を指定する openshift_master_htpasswd_file 変数のいずれかを使用できます。

    OpenShift Container Platform は、HTPasswd 認証を設定するためにハッシュ化されたパスワードを必要とします。以下のセクションに示されるように htpasswd コマンドを使用してユーザー用のハッシュ化されたパスワードを生成するか、またはユーザーおよび関連付けられたハッシュ化されたパスワードを持つフラットファイルを作成することができます。

    以下の例では、認証方法をデフォルトの deny all 設定から htpasswd に変更し、指定されたファイルを使って jsmith および bloblaw ユーザーのユーザー ID とパスワードを生成します。

    # htpasswd auth
    openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider'}]
    # Defining htpasswd users
    openshift_master_htpasswd_users={'jsmith': '$apr1$wIwXkFLI$bAygtKGmPOqaJftB', 'bloblaw': '7IRJ$2ODmeLoxf4I6sUEKfiA$2aDJqLJe'}
    # or
    #openshift_master_htpasswd_file=<path/to/local/pre-generated/htpasswdfile>
  3. 変更を有効にするために、Ansible Playbook を再実行します。

    $ ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.yml

    Playbook が設定を更新し、OpenShift Container Platform マスターサービスを再起動して変更を適用します。

これで、Ansible を使用したマスターとノードの設定ファイルの変更が完了しました。ここまでは単純なユースケースですが、次は、どのマスターノードの設定オプションが Ansibleに公開されているかを確認し、各自の Ansible インベントリーをカスタマイズします。

5.3.1. htpasswd コマンドの使用

OpenShift Container Platform クラスターを HTPasswd 認証を使用するように設定するには、ハッシュ化されたパスワードを持つ 1 名以上のユーザーをインベントリーファイルに追加する必要があります。

以下を実行することができます。

ユーザーおよびハッシュ化されたパスワードを作成するには、以下を実行します。

  1. 以下のコマンドを実行して指定されたユーザーを追加します。

    $ htpasswd -n <user_name>
    注記

    -b オプションを追加すると、パスワードをコマンドラインに指定できます。

    $ htpasswd -nb <user_name> <password>
  2. ユーザーのクリアテキストのパスワードを入力し、確定します。

    以下は例を示しています。

    $ htpasswd -n myuser
    New password:
    Re-type new password:
    myuser:$apr1$vdW.cI3j$WSKIOzUPs6Q

    このコマンドはパスワードのハッシュ化バージョンを生成します。

これで、HTPasswd 認証を設定する際にハッシュ化パスワードを使用できます。ハッシュ化パスワードは、: の後に続く文字列です。上記の例では、次を入力します。

openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}

ユーザー名とハッシュ化パスワードを持つフラットファイルを作成するには、以下を実行します。

  1. 以下のコマンドを実行します。

    $ htpasswd -c </path/to/users.htpasswd> <user_name>
    注記

    -b オプションを追加すると、パスワードをコマンドラインに指定できます。

    $ htpasswd -c -b <user_name> <password>
  2. ユーザーのクリアテキストのパスワードを入力し、確定します。

    以下は例を示しています。

    htpasswd -c users.htpasswd user1
    New password:
    Re-type new password:
    Adding password for user user1

    このコマンドは、ユーザー名とユーザーパスワードのハッシュ化されたバージョンを含むファイルを生成します。

これで、HTPasswd 認証を設定する際にこのパスワードファイルを使用できます。

注記

htpasswd コマンドについての詳細は、「HTPasswd Identity Provider」を参照してください。

5.4. 手動による設定変更

ユースケース: HTPasswd 認証を使用するようにクラスターを設定する

設定ファイルを手動で変更するには、以下を実行します。

  1. 変更する必要のある設定ファイルを開きます。ここでは /etc/origin/master/master-config.yaml ファイルです。
  2. 以下の新規変数をファイルの identityProviders スタンザに追加します。

    oauthConfig:
      ...
      identityProviders:
      - name: my_htpasswd_provider
        challenge: true
        login: true
        mappingMethod: claim
        provider:
          apiVersion: v1
          kind: HTPasswdPasswordIdentityProvider
          file: /path/to/users.htpasswd
  3. 変更を保存してファイルを閉じます。
  4. 変更を有効にするために、マスターを再起動します。

    $ master-restart api
    $ master-restart controllers

これでマスターとノードの設定ファイルが手動で変更されました。ここまでは単純なユースケースです。次は、すべてのマスターノードの設定オプションを確認し、変更を加えることでクラスターをさらにカスタマイズします。

注記

クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。node-config.yaml ファイルは手動で変更しないようにしてください。

5.5. マスター設定ファイル

このセクションでは、master-config.yaml ファイルに記述されているパラメーターについて説明します。

新規のマスター設定ファイルを作成して、OpenShift Container Platform のインストール済みバージョンに有効なオプションを確認できます。

重要

master-config.yaml ファイルを変更する際には常にマスターを再起動して変更を有効にしてください。「OpenShift Container Platform サービスの再起動」を参照してください。

5.5.1. 受付制御の設定

表5.1 受付制御設定パラメーター

パラメーター名説明

AdmissionConfig

受付制御プラグイン設定が含まれています。OpenShift Container Platform には、API オブジェクトが作成または変更されるたびにトリガーされる、受付制御プラグインの設定可能な一覧が含まれます。このオプションを使用して、一部のプラグインの無効化、他の設定の追加、順序の変更や設定の指定など、デフォルトのプラグイン一覧を上書きできます。プラグインの一覧とその設定はどちらも Ansible で制御することができます。

APIServerArguments

API サーバーのコマンドライン引数に一致する Kube API サーバーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、KubernetesMasterConfig の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。APIServerArgumentsevent-ttl という値で使用し、イベントを etcd に保存します。デフォルトは 2h ですが、メモリーの増加を防ぐためにより小さい値に設定することができます。

apiServerArguments:
  event-ttl:
  - "15m"

ControllerArguments

Kube コントローラーマネージャーのコマンドライン引数に一致する、コントローラーマネージャーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、KubernetesMasterConfig の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。

DefaultAdmissionConfig

各種の受付プラグインの有効化または無効化に使用されます。このタイプが pluginConfig の下に configuration オブジェクトとして存在し、受付プラグインがこれをサポートしている場合、デフォルトでオフ にされている受付プラグインが有効になります。

PluginConfig

設定ファイルを受付制御プラグインごとに指定することができます。

PluginOrderOverride

マスターにインストールされる受付制御プラグイン名の一覧です。順序には意味があります。空の場合は、プラグインのデフォルトの一覧が使用されます。

SchedulerArguments

スケジューラーのコマンドライン引数に一致する、Kube スケジューラーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、KubernetesMasterConfig の他の設定を上書きする場合があり、これにより無効な設定が生じる可能性があります。

5.5.2. アセットの設定

表5.2 アセットの設定パラメーター

パラメーター名説明

AssetConfig

これが存在する場合には、アセットサーバーは事前に定義されたパラメーターに基づいて起動します。以下は例になります。

assetConfig:
  logoutURL: ""
  masterPublicURL: https://master.ose32.example.com:8443
  publicURL: https://master.ose32.example.com:8443/console/
  servingInfo:
    bindAddress: 0.0.0.0:8443
    bindNetwork: tcp4
    certFile: master.server.crt
    clientCA: ""
    keyFile: master.server.key
    maxRequestsInFlight: 0
    requestTimeoutSeconds: 0

corsAllowedOrigins

異なるホスト名を使用して Web アプリケーションから API サーバーにアクセスするには、設定フィールドに corsAllowedOrigins を指定するか、または --cors-allowed-origins オプションを openshift start に指定してそのホスト名をホワイトリスト化する必要があります。その値の固定 (pinning) やエスケープは実行されません。使用例については、「Web Console」を参照してください。

DisabledFeatures

起動することのできない機能の一覧です。null に設定してください。この機能を手動で無効にする必要性はほとんどなく、この操作を実行することも推奨されません。

Extensions

サブコンテクストの下位のアセットサーバーファイルシステムから提供されるファイルです。

ExtensionDevelopment

true に設定されている場合、起動時だけでなく要求が出されるたびに拡張機能スクリプトとスタイルシートをリロードするようアセットサーバーに指示します。変更のたびにサーバーを再起動しなくても、拡張機能を展開することができます。

ExtensionProperties

コンソールのグローバル変数 OPENSHIFT_EXTENSION_PROPERTIES の下に挿入されるキー - (文字列) 値 - (文字列) のペアです。

ExtensionScripts

Web コンソールが読み込む際にスクリプトとして読み込まれるアセットサーバーファイル上のファイルパスです。

ExtensionStylesheets

Web コンソールが読み込む際にスタイルシートとして読み込まれるアセットサーバーファイル上のファイルパスです。

LoggingPublicURL

ロギング用のパブリックエンドポイント (オプション) です。

LogoutURL

Web コンソールからログアウトした後に Web ブラウザーをリダイレクトするオプションの絶対 URL です。指定されていない場合は、ビルトインされたログアウトページが表示されます。

MasterPublicURL

Web コンソールが OpenShift Container Platform サーバーにアクセスする方法について示します。

MetricsPublicURL

メトリクス用のパブリックエンドポイント (オプション) です。

PublicURL

アセットサーバーの URL です。

5.5.3. 認証と承認の設定

表5.3 認証および承認パラメーター

パラメーター名説明

authConfig

認証および承認設定オプションを保持します。

AuthenticationCacheSize

キャッシュされる認証結果の数を示します。0 の場合は、デフォルトのキャッシュサイズが使用されます。

AuthorizationCacheTTL

承認結果がキャッシュされる期間を示します。有効な時間文字列 (「5 m」など) を取り、空の場合はデフォルトのタイムアウトが取得されます。ゼロ (「0 m」など) の場合、キャッシシングは無効になります。

5.5.4. コントローラーの設定

表5.4 コントローラー設定パラメーター

パラメーター名説明

Controllers

起動するコントローラーの一覧です。none に設定されている場合、コントローラーは自動的に起動されません。デフォルト値は * であり、これによりすべてのコントローラーが起動します。* を使用している場合は、コントローラーの名前の先頭に - を追加することでそのコントローラーを除外できます。この時点で他の値は認識されません。

ControllerLeaseTTL

コントローラーの選択を有効にし、マスターに対してコントローラーが起動する前にリースを取得するように指示して、この値で定義された秒数内にリースを更新します。負の値以外の値を設定することで pauseControllers=true が強制的に実行されます。デフォルトの値はオフ (0 または省略) であり、コントローラーの選択は -1 で無効にできます。

PauseControllers

マスターに対してコントローラーを自動的に開始せず、起動前にサーバーへの通知が受信するまで待機するように指示します。

5.5.5. etcd の設定

表5.5 etcd 設定パラメーター

パラメーター名説明

Address

etcd へのクライアント接続用に公開される host:port です。

etcdClientInfo

etcd に接続する方法についての情報が含まれます。etcd を組み込みまたは組み込み以外の方法で実行するかどうかを指定し、ホストを指定します。残りの設定は Ansible インベントリーで処理されます。以下は例になります。

etcdClientInfo:
  ca: ca.crt
  certFile: master.etcd-client.crt
  keyFile: master.etcd-client.key
  urls:
  - https://m1.aos.example.com:4001

etcdConfig

これがある場合、etcd は定義されたパラメーターに基づいて起動します。以下は例になります。

etcdConfig:
  address: master.ose32.example.com:4001
  peerAddress: master.ose32.example.com:7001
  peerServingInfo:
    bindAddress: 0.0.0.0:7001
    certFile: etcd.server.crt
    clientCA: ca.crt
    keyFile: etcd.server.key
  servingInfo:
    bindAddress: 0.0.0.0:4001
    certFile: etcd.server.crt
    clientCA: ca.crt
    keyFile: etcd.server.key
  storageDirectory: /var/lib/origin/openshift.local.etcd

etcdStorageConfig

API リソースを etcd に格納する方法についての情報が含まれます。これらの値は、etcd がクラスターのバッキングストアである場合にのみ関連する値になります。

KubernetesStoragePrefix

Kubernetes のリソースがその下位に置かれる etcd 内のパスです。この値が変更されると etcd 内の既存のオブジェクトは検索できなくなります。デフォルトの値は kubernetes.io です。

KubernetesStorageVersion

etcd 内の Kubernetes リソースがシリアライズされる API バージョン。etcd から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまでこの値を変更 することができません

OpenShiftStoragePrefix

OpenShift Container Platform リソースがその下位に置かれる etcd 内のパスです。この値が変更されると、etcd 内の既存のオブジェクトは検索できなくなります。デフォルトの値は openshift.io です。

OpenShiftStorageVersion

etcd 内の OS リソースがシリアライズされる API バージョンです。etcd から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまで、この値を変更することができません

PeerAddress

etcd へのピア接続用に公開される host:port です。

PeerServingInfo

etcd ピアの提供を開始する方法を記述します。

ServingInfo

提供を開始する方法を記述します。以下は例になります。

servingInfo:
  bindAddress: 0.0.0.0:8443
  bindNetwork: tcp4
  certFile: master.server.crt
  clientCA: ca.crt
  keyFile: master.server.key
  maxRequestsInFlight: 500
  requestTimeoutSeconds: 3600

StorageDir

etcd ストレージディレクトリーへのパスです。

5.5.6. 付与の設定

表5.6 付与の設定パラメーター

パラメーター名説明

GrantConfig

付与を処理する方法を記述します。

GrantHandlerAuto

クライアントの承認付与の要求を自動承認します。

GrantHandlerDeny

クライアントの承認付与の要求を自動的に拒否します。

GrantHandlerPrompt

ユーザーに対し、クライアントの新規の承認付与要求を承認することを求めるプロンプトを出します。

Method

OAuth クライアントが付与を要求したときに使用するデフォルトのストラテジーを決定します。この方法は特定の OAuth クライアントが独自のストラテジーを提供しない場合にのみ使用します。付与を処理するための有効な方法は以下の通りです。

  • auto: 付与要求を常に承認します。信頼されるクライアントの場合に役立ちます。
  • prompt: エンドユーザーに対し、付与要求の承認を求めるプロンプトを出します。サードパーティーのクライアントの場合に役立ちます。
  • deny: 付与要求を常に拒否します。ブラックリスト化されたクライアントの場合に役立ちます。

5.5.7. イメージ設定

表5.7 イメージ設定パラメーター

パラメーター名説明

Format

システムコンポーネント用に作成される名前のフォーマットです。

Latest

最新のタグをレジストリーからプルするかどうかを決定します。

5.5.8. イメージポリシーの設定

表5.8 イメージポリシー設定パラメーター

パラメーター名説明

DisableScheduledImport

スケジュールされたイメージのバックグラウンドインポートの無効化を許可します。

MaxImagesBulkImportedPerRepository

ユーザーが Docker リポジトリーの一括インポートを行う際に、インポートされるイメージの数を制御します。デフォルトの値は 5 に設定され、ユーザーが誤って大量のイメージをインポートすることを防ぎます。-1 に設定すると無制限になります

MaxScheduledImageImportsPerMinute

スケジュールされたイメージストリームがバックグラウンドでインポートされる 1 分あたりの最大数です。デフォルト値は 60 です。

ScheduledImageImportMinimumIntervalSeconds

バックグラウンドのインポートがスケジュールされているイメージストリームが、アップストリームのリポジトリーと照合される際の最小間隔 (秒単位) です。デフォルト値は 15 秒です。

AllowedRegistriesForImport

標準ユーザーがイメージのインポートに使用する Docker レジストリーを制限します。この一覧を、有効な Docker イメージを含むものとユーザーが信頼し、アプリケーションのインポート元となるレジストリーに設定します。Images または ImageStreamMappings を API 経由で作成するパーミッションを持つユーザーは、このポリシーによる影響を受けません。通常、これらのパーミッションを持っているのは管理者またはシステム統合管理者のみです。

InternalRegistryHostname

デフォルトの内部イメージレジストリーのホスト名を設定します。値は hostname[:port] 形式である必要があります。後方互換性を考慮して、ユーザーは引き続き OPENSHIFT_DEFAULT_REGISTRY 環境変数を使用できますが、この設定はこの環境変数を上書きします。このパラメーターが設定されると、内部レジストリーにはそのホスト名も設定される必要があります。詳細は、「レジストリーのホスト名の設定」を参照してください。

ExternalRegistryHostname

ExternalRegistryHostname は、デフォルトの外部イメージレジストリーのホスト名を設定します。この外部ホスト名は、イメージレジストリーが外部に公開される場合にのみ設定されます。値は ImageStreams の publicDockerImageRepository フィールドで使用されます。値は hostname[:port] 形式でなければなりません。

5.5.9. Kubernetes のマスター設定

表5.9 Kubernetes のマスター設定パラメーター

パラメーター名説明

APILevels

起動時に有効にする必要のある API レベルの一覧です (v1 など)。

DisabledAPIGroupVersions

無効にする必要のあるバージョン (または *) のグループのマップです。

KubeletClientInfo

Kubelets に接続する方法についての情報が含まれます。

KubernetesMasterConfig

kubelet の KubernetesMasterConfig への接続方法についての情報が含まれます。これがある場合、Kubernetes のマスターをこのプロセスで起動します。

MasterCount

実行されていることが予想されるマスターの数です。デフォルトの値は 1 であり、正の整数に設定できますが、-1 に設定されている場合はそれがクラスターの一部であることを示します。

MasterIP

Kubernetes リソースのパブリック IP アドレスです。空の場合、net.InterfaceAddrs の最初の結果が使用されます。

MasterKubeConfig

このノードをマスターに接続する方法を記述した .kubeconfig ファイルのファイル名です。

ServicesNodePortRange

サービスのパブリックポートをホストに割り当てる際に使用される範囲です。デフォルトは 30000-32767 です。

ServicesSubnet

サービス IP の割り当てに使用されるサブネットです。

StaticNodeNames

静的に認識されるノードの一覧です。

5.5.10. ネットワーク設定

IPv4 アドレス領域はノード上のすべてのユーザーが共有するため、CIDR を以下のパラメーターで慎重に選択してください。OpenShift Container Platform はそれ自体に使用する CIDR を IPv4 アドレス領域から予約し、外部ユーザーとクラスターが共有するアドレス用の CIDR を IPv4 アドレス領域から予約します。

表5.10 ネットワーク設定パラメーター

パラメーター名説明

ClusterNetworkCIDR

グローバルなオーバーレイネットワークの L3 領域を指定する CIDR 文字列です。クラスターネットワークの内部使用のために予約されています。

externalIPNetworkCIDRs

サービスの外部 IP フィールドで許可される値を制御します。空の場合、externalIP は設定できません。これには CIDR の一覧を含めることができ、この一覧はアクセスについてチェックされます。CIDR にプレフィックス ! が付いている場合、その CIDR の IP は拒否されます。最初に拒否が適用され、その後に IP が許可された CIDR のいずれかに対してチェックされます。セキュリティー上の理由から、この範囲はユーザーのノード、Pod 、またはサービス CIDR と重複させることはできません。

HostSubnetLength

各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。

ingressIPNetworkCIDR

ベアメタル上のタイプ LoadBalancer のサービス用に ingress IP を割り当てる範囲を制御します。そこから割り当てられる単一の CIDR を含めることができます。デフォルトは 172.46.0.0/16 に設定されています。セキュリティー上の理由から、この範囲は外部 IP 、ノード、Pod、またはサービス用に予約されている CIDR と重複しないようにする必要があります。

HostSubnetLength

各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。

NetworkConfig

compiled-in-network プラグインに渡されます。ここでのオプションの多くは Ansible インベントリーで制御されます。

  • NetworkPluginName (文字列)
  • ClusterNetworkCIDR (文字列)
  • HostSubnetLength (署名なし整数)
  • ServiceNetworkCIDR (文字列)
  • ExternalIPNetworkCIDRs (文字列の配列): サービスの外部 IP フィールドで許可される値を制御します。空の場合、外部 IP を設定できません。CIDR の一覧を含むことができ、そのアクセスがチェックされます。CIDR にプレフィックス ! が付いている場合、その CIDR のIP は拒否されます。最初に拒否が適用され、次に IP が許可された CIDR のいずれかに対してチェックされます。セキュリティー上の理由から、この範囲はユーザーのノード、Pod、またはサービス CIDR と重複しないようにする必要があります。

以下は例になります。

networkConfig:
  clusterNetworks
  - cidr: 10.3.0.0/16
    hostSubnetLength: 8
  networkPluginName: example/openshift-ovs-subnet
# serviceNetworkCIDR must match kubernetesMasterConfig.servicesSubnet
  serviceNetworkCIDR: 179.29.0.0/16

NetworkPluginName

使用されるネットワークプラグインの名前です。

ServiceNetwork

サービスネットワークを指定する CIDR 文字列です。

5.5.11. OAuth 認証設定

表5.11 OAuth 設定パラメーター

パラメーター名説明

AlwaysShowProviderSelection

単一プロバイダーしかない場合でも、プロバイダーの選択ページを強制的にレンダリングします。

AssetPublicURL

外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。

Error

認証または付与フローでエラーページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのエラーページが使用されます。

IdentityProviders

ユーザーが自身を確認する方法の順序付きの一覧です。

Login

ログインページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのログインページが使用されます。

MasterCA

TLS 接続が MasterURL に戻っていることを確認するための CA です。

MasterPublicURL

外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。

MasterURL

アクセストークンの承認コードを交換するためのサーバー間の呼び出しに使用されます。

OAuthConfig

これがある場合、/oauth エンドポイントは定義されたパラメーターに基づいて開始します。以下は例になります。

oauthConfig:
  assetPublicURL: https://master.ose32.example.com:8443/console/
  grantConfig:
    method: auto
  identityProviders:
  - challenge: true
    login: true
    mappingMethod: claim
    name: htpasswd_all
    provider:
      apiVersion: v1
      kind: HTPasswdPasswordIdentityProvider
      file: /etc/origin/openshift-passwd
  masterCA: ca.crt
  masterPublicURL: https://master.ose32.example.com:8443
  masterURL: https://master.ose32.example.com:8443
  sessionConfig:
    sessionMaxAgeSeconds: 3600
    sessionName: ssn
    sessionSecretsFile: /etc/origin/master/session-secrets.yaml
  tokenConfig:
    accessTokenMaxAgeSeconds: 86400
    authorizeTokenMaxAgeSeconds: 500

OAuthTemplates

ログインページなどページのカスタマイズを許可します。

ProviderSelection

プロバイダーの選択ページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定されていない場合、デフォルトのプロバイダー選択ページが使用されます。

SessionConfig

セッションの設定に関する情報を保持します。

Templates

ログインページなどのページのカスタマイズを許可します。

TokenConfig

承認とアクセストークンのオプションが含まれます。

5.5.12. プロジェクトの設定

表5.12 プロジェクト設定パラメーター

パラメーター名説明

DefaultNodeSelector

デフォルトのプロジェクトノードのラベルセレクターを保持します。

ProjectConfig

プロジェクト作成とデフォルトに関する情報を保持します。

  • DefaultNodeSelector (文字列): デフォルトのプロジェクトノードのラベルセレクターを保持します。
  • ProjectRequestMessage (文字列): この文字列は、ユーザーが projectrequest API エンドポイントからプロジェクトを要求できない場合に提示されます。
  • ProjectRequestTemplate (文字列): projectrequest への応答としてプロジェクトを作成する際に使用されるテンプレートです。フォーマット <namespace>/<template> が使用されます。これはオプションであり、指定されていない場合はデフォルトのテンプレートが使用されます。
  • SecurityAllocator: UID と MCS ラベルのプロジェクトに対する自動割り当てを制御します。空の場合、割り当ては無効にされます。

    • mcsAllocatorRange (文字列): namespace に割り当てられる MCS カテゴリーの範囲を定義します。フォーマットは <prefix>/<numberOfLabels>[,<maxCategory>] です。デフォルトは s0/2 であり、c0 から c1023 に割り当てられます。つまり、これは合計 535000 のラベルが利用可能であることを意味します。この値を起動後に変更すると、新規プロジェクトは、すでに他のプロジェクトに割り当てられているラベルを受信することがあります。プレフィックスには SELinux の有効な用語のセット (ユーザー、ロール、タイプなど) を使用できます。ただし、プレフィックスをデフォルトとして残しておくと、サーバーはそれらを自動的に設定できます。たとえば、s0:/2 はラベルを s0:c0,c0 から s0:c511,c511 に割り当て、s0:/2,512 はラベルを s0:c0,c0,c0 から s0:c511,c511,511 に割り当てます。
    • mcsLabelsPerProject (整数): プロジェクトごとに予約するラベルの数を定義します。デフォルトは、デフォルトの UID と MCS の範囲に一致する 5 です。
    • uidAllocatorRange (文字列): プロジェクトに自動的に割り当てられる Unix ユーザー ID (UID) の合計セット数と、各 namespace が取得するブロックのサイズを定義します。たとえば、 1000-1999/10 は namespace ごとに 10 の UID を割り当て、空間を使い果たす前に最大 100 のブロックを割り当てることが可能です。デフォルトでは、1 万のブロックに 10 億から 20 億を割り当てます。これは、ユーザーの namespace の起動時にコンテナーイメージについて予想される範囲のサイズです。

ProjectRequestMessage

この文字列は、プロジェクトの要求 API エンドポイントからプロジェクトを要求できない場合にユーザーに提示されます。

ProjectRequestTemplate

projectrequest への応答としてプロジェクトを作成する際に使用されるテンプレートです。フォーマットは namespace/template です。これはオプションであり、指定されていない場合はデフォルトのテンプレートが使用されます。

5.5.13. スケジューラーの設定

表5.13 スケジューラー設定パラメーター

パラメーター名説明

SchedulerConfigFile

スケジューラーのセットアップ方法を記述しているファイルをポイントします。空の場合、デフォルトのスケジューリングルールが取得されます。

5.5.14. セキュリティーアロケーターの設定

表5.14 セキュリティーアロケーターパラメーター

パラメーター名説明

MCSAllocatorRange

namespace に割り当てられる MCS カテゴリーの範囲を定義します。フォーマットは <prefix>/<numberOfLabels>[,<maxCategory>] です。デフォルトは s0/2 であり、c0 から c1023 に割り当てられます。つまり、合計 535000 のラベルが利用可能であることを意味します (1024 は 2 ~ 535000 を選択します)。この値を起動後に変更すると、新規プロジェクトは、すでに別のプロジェクトに割り当てられているラベルを受信することがあります。プレフィックスには、SELinux の有効な用語のセット (ユーザー、ロール、タイプなど) にすることができます。ただしこれらをデフォルトとして残しておくと、サーバーはこれらを自動的に設定できます。

SecurityAllocator

UID と MCS ラベルのプロジェクトへの自動割り当てを制御します。空の場合、割り当ては無効にされます。

UIDAllocatorRange

プロジェクトに自動的に割り当てられる Unix ユーザー ID (UID) の合計セット数と、各 namespace が取得するブロックのサイズを定義します。たとえば、1000-1999/10 は namespace ごとに 10 の UID を割り当て、空間を使い果たす前に最大 100 のブロックを割り当てることが可能です。デフォルトでは、1 万のブロックに 10 億から 20 億 (ユーザー namespace の起動時にコンテナーイメージが使用する範囲の予想されるサイズ) を割り当てます。

5.5.15. サービスアカウントの設定

表5.15 サービスアカウント設定パラメーター

パラメーター名説明

LimitSecretReferences

サービスアカウントに、明示的な参照なしに namespace のシークレットの参照を許可するかどうかを制御します。

ManagedNames

すべての namespace に自動作成されるサービスアカウント名の一覧です。名前が指定されていない場合、ServiceAccountsController は起動しません。

MasterCA

TLS 接続がマスターに戻っていることを確認する CA です。サービスアカウントのコントローラーは、マスターへの接続を検証できるようにこのファイルの内容を Pod に自動的に挿入します。

PrivateKeyFile

PEM でエンコードされた RSA プライベートキーを含むファイルです。これはサービスアカウントのトークンの署名に使用されます。プライベートキーが指定されていない場合、サービスアカウント TokensController は起動しません。

PublicKeyFiles

PEM でエンコードされた RSA パブリックキーを含むファイルの一覧です。いずれかのファイルにプライベートキーが含まれている場合、そのキーのパブリックの部分が使用されます。パブリックキーの一覧は、表示されているサービスアカウントのトークンの確認に使用されます。それぞれのキーは、一覧がすべて使用されるまで、または確認が正常に実行されるまで順番に試行されます。キーが指定されていない場合、サービスアカウントの認証は使用できません。

ServiceAccountConfig

サービスアカウントに関連するオプションを保持します。

  • LimitSecretReferences (ブール値): サービスアカウントに、明示的な参照なしに namespace のシークレットの参照を許可するかどうかを制御します。
  • ManagedNames (文字列): それぞれの namespace に自動作成されるサービスアカウント名の一覧です。名前が指定されていない場合、ServiceAccountsController は起動しません。
  • MasterCA (文字列): TLS 接続がマスターに戻っていることを確認する認証局です。サービスアカウントコントローラーは、マスターへの接続を検証できるようにこのファイルの内容を Pod に自動的に挿入します。
  • PrivateKeyFile (文字列): PEM でエンコードされた RSA プライベートキーが含まれ、サービスアカウントのトークンの署名に使用されます。プライベートキーが指定されていない場合、サービスアカウント TokensController は起動しません。
  • PublicKeyFiles (文字列): PEM でエンコードされた RSA パブリックキーを含むファイルの一覧です。いずれかのファイルにプライベートキーが含まれている場合、OpenShift Container Platform はキーのパブリックの部分を使用します。パブリックキーの一覧は、サービスアカウントのトークンの確認に使用されます。それぞれのキーは、一覧がすべて使用されるまで、または確認が正常に実行されるまで順番に試行されます。キーが指定されていない場合、サービスアカウントの認証は使用できません。

5.5.16. 提供情報の設定

表5.16 提供情報設定パラメーター

パラメーター名説明

AllowRecursiveQueries

マスター上の DNS サーバーがクエリーに再帰的に応答することを許可します。オープンリゾルバーは DNS アンプ攻撃に使用される可能であり、マスター DNS は公開ネットワークでアクセスできないようにする必要があることに注意してください。

BindAddress

提供に使用される ip:port です。

BindNetwork

イメージをインポートするための制限と動作を制御します。

CertFile

PEM でエンコードされた証明書を含むファイルです。

CertInfo

セキュアなトラフィックを提供するための TLS 証明書情報です。

ClientCA

クライアント証明書が受信される際にユーザーが認識するすべての署名者の証明書バンドルです。

dnsConfig

これがある場合、DNS サーバーが定義されたパラメーターに基づいて起動します。以下は例になります。

dnsConfig:
  bindAddress: 0.0.0.0:8053
  bindNetwork: tcp4

DNSDomain

ドメインサフィックスを保持します。

DNSIP

IP を保持します。

KeyFile

CertFile が指定した証明書の PEM でエンコードされたプライベートキーを含むファイルです。

MasterClientConnectionOverrides

マスターへの接続に使用されたクライアント接続を上書きします。

MaxRequestsInFlight

サーバーに許可されている同時要求数です。ゼロの場合は無制限です。

NamedCertificates

特定のホスト名への要求を保護するのに使用される証明書の一覧です。

RequestTimeoutSecond

要求がタイムアウトするまでの秒数です。デフォルトは 60 分です。-1 の場合、要求について無制限となります。

ServingInfo

アセット用の HTTP 提供情報です。

5.5.17. ボリュームの設定

表5.17 ボリューム設定パラメーター

パラメーター名説明

DynamicProvisioningEnabled

動的なプロビジョニングを有効化または無効化するブール値です。デフォルトは true です。

FSGroup

各ノードでそれぞれの FSGroup についてローカルストレージクォータを有効にします。現時点では、これは emptyDir ボリュームについて、基礎となる volumeDirectory が XFS ファイルシステムにある場合にのみ実装されます。

MasterVolumeConfig

マスターノードのボリュームプラグインを設定するオプションが含まれます。

NodeVolumeConfig

ノードのボリュームを設定するオプションが含まれます。

VolumeConfig

ノードのボリュームプラグインを設定するオプションが含まれます。

  • DynamicProvisioningEnabled (ブール値): デフォルト値は true です。false の場合は動的プロビジョニングはオフに切り替わります。

VolumeDirectory

ボリュームがその下に保存されるディレクトリーです。

5.5.18. 基本的な監査

監査は、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードを提供します。

監査は API サーバーレベルで実行され、サーバーに送られるすべての要求をログに記録します。それぞれの監査ログには以下の 2 つのエントリーが含まれます。

  1. 以下を含む要求行。

    1. 応答行 (以下の 2 を参照してください) と一致する固有 ID
    2. 要求のソース IP
    3. 呼び出されている HTTP メソッド
    4. 操作を呼び出している元のユーザー
    5. 操作を実行するための偽装ユーザー (self はユーザー自身を指します)
    6. 操作を実行するための偽装グループ (lookup はユーザーのグループを指します)
    7. 要求または <none> の namespace
    8. 要求される URI
  2. 以下を含む応答行。

    1. 上記 1 の固有の ID
    2. 応答コード

Pod の一覧を要求するユーザー admin の出力例。

AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"

openshift_master_audit_config 変数は、API サービス監査を有効にします。これは以下のオプションの配列を取ります。

表5.18 監査設定パラメーター

パラメーター名説明

enabled

監査ログを有効または無効にするブール値です。デフォルト値は false です。

auditFilePath

要求をログに記録するファイルパスです。設定されていない場合、ログはマスターログに出力されます。

maximumFileRetentionDays

ファイル名にエンコードされるタイムスタンプに基づいて古い監査ログファイルを保持する最大日数を指定します。

maximumRetainedFiles

古い監査ログファイルを保持する最大数を指定します。

maximumFileSizeMegabytes

ログファイルがローテーションされる前に、ファイルの最大サイズをメガバイトで指定します。デフォルトは 100 MB です。

監査の設定例

auditConfig:
  auditFilePath: "/var/log/audit-ocp.log"
  enabled: true
  maximumFileRetentionDays: 10
  maximumFileSizeMegabytes: 10
  maximumRetainedFiles: 10

監査ログの高度なセットアップ

監査ログの高度なセットアップを使用する必要がある場合には、以下を使用できます。

openshift_master_audit_config={"enabled": true}

auditFilePath のディレクトリーが、存在していない場合に作成されます。

openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/lib/origin/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}

5.5.19. 高度な監査

高度な監査機能は、詳細なイベントのフィルタリングや複数の出力バックエンドなど、基本的な監査機能に対するいくつかの改良機能を提供します。

高度な監査機能を有効にするには、以下の値を openshift_master_audit_config パラメーターに指定します。

openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/oscp-audit/-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5, "policyFile": "/etc/security/adv-audit.yaml", "logFormat":"json"}
重要

ポリシーファイル /etc/security/adv-audit.yaml は各マスターノードで利用可能でなければなりません。

以下の表には、使用できる追加のオプションが含まれています。

表5.19 高度な監査設定パラメーター

パラメーター名説明

policyFile

監査ポリシー設定を定義するファイルへのパスです。

policyConfiguration

組み込まれる監査ポリシー設定です。

logFormat

保存される監査ログのフォーマットを指定します。許可されている値は legacy (基本的な監査に使用されるフォーマット) と json です。

webHookKubeConfig

監査の Webhook 設定を定義する .kubeconfig でフォーマットされたファイルへのパスです。ここにイベントが送信されます。

webHookMode

監査イベントを送信するためのストラテジーを指定します。許可される値は block (直前のイベント処理が完了するまで別のイベントの処理をブロックする) と batch (イベントをバッファー処理し、バッチで提供する) です。

重要

高度な監査機能を有効にするには、監査ポリシールールを記述する policyFile または policyConfiguration を指定する必要があります。

監査ポリシーの設定例

apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:

  # Do not log watch requests by the "system:kube-proxy" on endpoints or services
  - level: None 1
    users: ["system:kube-proxy"] 2
    verbs: ["watch"] 3
    resources: 4
    - group: ""
      resources: ["endpoints", "services"]

  # Do not log authenticated requests to certain non-resource URL paths.
  - level: None
    userGroups: ["system:authenticated"] 5
    nonResourceURLs: 6
    - "/api*" # Wildcard matching.
    - "/version"

  # Log the request body of configmap changes in kube-system.
  - level: Request
    resources:
    - group: "" # core API group
      resources: ["configmaps"]
    # This rule only applies to resources in the "kube-system" namespace.
    # The empty string "" can be used to select non-namespaced resources.
    namespaces: ["kube-system"] 7

  # Log configmap and secret changes in all other namespaces at the metadata level.
  - level: Metadata
    resources:
    - group: "" # core API group
      resources: ["secrets", "configmaps"]

  # Log all other resources in core and extensions at the request level.
  - level: Request
    resources:
    - group: "" # core API group
    - group: "extensions" # Version of group should NOT be included.

  # A catch-all rule to log all other requests at the Metadata level.
  - level: Metadata 8

  # Log login failures from the web console or CLI. Review the logs and refine your policies.
  - level: Metadata
    nonResourceURLs:
    - /login* 9
    - /oauth* 10

1 8
すべてのイベントは以下の 4 つのレベルでログに記録できます。
  • None - このルールに一致するイベントは記録されません。
  • Metadata - 要求のメタデータ (要求しているユーザー、タイムスタンプ、リソース、verb など) をログに記録します。要求または応答本体はログに記録しません。基本的な監査で使用されるレベルと同じレベルになります。
  • Request - イベントのメタデータと要求本体をログに記録します。応答本体はログに記録しません。
  • RequestResponse - イベントのメタデータ、要求、および応答本体をログに記録します。
2
このルールが適用されるユーザーの一覧です。一覧が空の場合はすべてのユーザーに適用されます。
3
このルールが適用される verb の一覧です。一覧が空の場合はすべての verb に適用されます。これは API 要求に関連付けられる Kubernetes の verb です (getlistwatchcreateupdatepatchdeletedeletecollectionproxy など)。
4
このルールが適用されるリソースの一覧です。一覧が空の場合はすべてのリソースに適用されます。各リソースは、それが割り当てられるグループ (例: 空の場合は Kubernetes core API、バッチ、build.openshift.io などを指します) 、およびそのグループのリソース一覧として指定されます。
5
このルールが適用されるグループの一覧です。一覧が空の場合はすべてのグループに適用されます。
6
このルールが適用されるリソース以外の URL の一覧です。
7
このルールが適用される namespace の一覧です。一覧が空の場合はすべての namespace に適用されます。
9
Web コンソールが使用するエンドポイントです。
10
CLI が使用するエンドポイントです。

高度な監査についての詳細は、Kubernetes のドキュメントを参照してください。

5.5.20. etcd の TLS 暗号の指定

マスターと etcd サーバー間の通信で使用するサポートされている TLS 暗号を指定できます。

  1. 各 etcd ノードで、etcd をアップグレードします。

    # yum update etcd iptables-services
  2. お使いのバージョンが 3.2.22 以降であることを確認します。

    # etcd --version
    etcd Version: 3.2.22
  3. 各マスターホストで、/etc/origin/master/master-config.yaml ファイルで有効にする暗号を指定します。

    servingInfo:
      ...
      minTLSVersion: VersionTLS12
      cipherSuites:
      - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      - TLS_RSA_WITH_AES_256_CBC_SHA
      - TLS_RSA_WITH_AES_128_CBC_SHA
    ...
  4. 各マスターホストで、マスターサービスを再起動します。

    # master-restart api
    # master-restart controllers
  5. 暗号が適用されていることを確認します。たとえば、TLSv1.2 暗号 ECDHE-RSA-AES128-GCM-SHA256 については、以下のコマンドを実行します。

    # openssl s_client -connect etcd1.example.com:2379 1
    CONNECTED(00000003)
    depth=0 CN = etcd1.example.com
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 CN = etcd1.example.com
    verify error:num=21:unable to verify the first certificate
    verify return:1
    139905367488400:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:s3_pkt.c:1493:SSL alert number 42
    139905367488400:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
    ---
    Certificate chain
     0 s:/CN=etcd1.example.com
       i:/CN=etcd-signer@1529635004
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIEkjCCAnqgAwIBAgIBATANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDDBZldGNk
    ........
    ....
    eif87qttt0Sl1vS8DG1KQO1oOBlNkg==
    -----END CERTIFICATE-----
    subject=/CN=etcd1.example.com
    issuer=/CN=etcd-signer@1529635004
    ---
    Acceptable client certificate CA names
    /CN=etcd-signer@1529635004
    Client Certificate Types: RSA sign, ECDSA sign
    Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA1:ECDSA+SHA1
    Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA1:ECDSA+SHA1
    Peer signing digest: SHA384
    Server Temp Key: ECDH, P-256, 256 bits
    ---
    SSL handshake has read 1666 bytes and written 138 bytes
    ---
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES128-GCM-SHA256
        Session-ID:
        Session-ID-ctx:
        Master-Key: 1EFA00A91EE5FC5EDDCFC67C8ECD060D44FD3EB23D834EDED929E4B74536F273C0F9299935E5504B562CD56E76ED208D
        Key-Arg   : None
        Krb5 Principal: None
        PSK identity: None
        PSK identity hint: None
        Start Time: 1529651744
        Timeout   : 300 (sec)
        Verify return code: 21 (unable to verify the first certificate)
    1
    etcd1.example.com は etcd ホストの名前です。

5.6. ノード設定ファイル

以下の node-config.yaml ファイルは、現時点でデフォルト値で生成されるノード設定ファイルのサンプルです。

注記

クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。node-config.yaml ファイルは手動で変更しないようにしてください。

例5.1 ノード設定ファイルのサンプル

allowDisabledDocker: false
apiVersion: v1
authConfig:
  authenticationCacheSize: 1000
  authenticationCacheTTL: 5m
  authorizationCacheSize: 1000
  authorizationCacheTTL: 5m
dnsDomain: cluster.local
dnsIP: 0.0.0.0 1
dockerConfig:
  execHandlerName: native
imageConfig:
  format: openshift/origin-${component}:${version}
  latest: false
iptablesSyncPeriod: 5s
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
  mtu: 1450
  networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig: 2
  path: "/path/to/pod-manifest-file" 3
  fileCheckIntervalSeconds: 30 4
proxyArguments:
  proxy-mode:
  - iptables 5
servingInfo:
  bindAddress: 0.0.0.0:10250
  bindNetwork: tcp4
  certFile: server.crt
  clientCA: node-client-ca.crt
  keyFile: server.key
  namedCertificates: null
volumeDirectory: /root/openshift.local.volumes
1
ここにアドレスを追加することで、Pod の /etc/resolv.conf の先頭に追加される IP アドレスを設定します。
2
特定のノードセット上、またはすべてのノード上に、スケジューラーを介することなく Pod を直接配置することを許可します。ユーザーは、Pod を使って同じ管理タスクを実行し、各ノードで同じサービスをサポートすることができます。
3
Pod のマニフェストファイルまたはディレクトリーへのパスを指定します。ディレクトリーの場合、1 つ以上のマニフェストファイルが含まれることが予想されます。これは、Pod をノード上に作成するために Kubelet によって使用されます。
4
新規データのマニフェストファイルをチェックする間隔 (秒単位) です。この値は正の値で入力する必要があります。
5

ノード設定ファイルはノードのリソースを決定します。詳細は、「Allocating node resources section in the Cluster Administrator guide」を参照してください。

5.6.1. Pod とノードの設定

表5.20 Pod とノードの設定パラメーター

パラメーター名説明

NodeConfig

OpenShift Container Platform ノードを起動する完全に指定された設定です。

NodeIP

ノードは複数の IP を持つことがあるため、Pod のトラフィックルーティングに使用する IP を指定します。指定されていない場合、nodeName でネットワーク解析/ルックアップが実行され、最初の非ループバックアドレスが使用されます。

NodeName

クラスターの特定ノードを識別するために使用される値です。可能な場合、この値はユーザーの完全修飾ホスト名にできます。ユーザーが静的ノードのセットをマスターに記述している場合、この値は一覧にある値のいずれかに一致している必要があります。

PodEvictionTimeout

失敗したノード上の Pod を削除するための猶予期間を制御します。有効な時間文字列を取ります。空の場合、Pod のデフォルトのエビクションタイムアウトを取ります。

ProxyClientInfo

Pod へのプロキシー処理時に使用するクライアント証明書/キーを指定します。

5.6.2. Docker の設定

表5.21 Docker 設定パラメーター

パラメーター名説明

AllowDisabledDocker

true の場合、Kubelet は Docker のエラーを無視します。これは、Docker を起動させていないマシンでノードを起動できることを意味します。

DockerConfig

Docker 関連の設定オプションを保持します。

ExecHandlerName

Docker コンテナーでのコマンドの実行に使用するハンドラーです。

5.6.3. ローカルストレージの設定

XFS クォータサブシステムを使用して emptyDir ボリューム、および各ノードのシークレットおよび設定マップなどの emptyDir ボリュームに基づくボリュームのサイズを制限できます。

XFS ファイルシステムで emptyDir ボリュームのサイズを制限するには、openshift-node プロジェクトで node-config-compute 設定マップを使用し、それぞれ一意の FSGroup についてローカルボリュームクォータを設定します。

apiVersion: kubelet.config.openshift.io/v1
kind: VolumeConfig
  localQuota: 1
    perFSGroup: 1Gi 2
1
ノードのローカルボリュームクォータを制御するオプションが含まれます。
2
この値を、1Gi512Mi など [FSGroup] 別、ノード別に必要なクォータを示すリソース量に設定します volumeDirectorygrpquota オプションを指定してマウントされた XFS ファイルシステムになければなりません。一致する SCC (security context constraint) の fsGroup タイプは MustRunAs に設定する必要があります。

FSGroup が指定されていない場合、つまり要求が RunAsAny の SCC に一致することを示す場合、クォータの適用は省略されます。

注記

/etc/origin/node/volume-config.yaml ファイルは直接編集しないでください。このファイルは node-config-compute 設定マップを基に作成されます。node-config-compute 設定マップを使用して volume-config.yaml ファイルでパラメーターの作成または編集を実行します。

5.6.4. Docker 1.9 以降を使用したイメージの並行プル

Docker 1.9 以降を使用している場合は、イメージの並行プルを有効にしておくことができます。デフォルトでは、イメージは一度に 1 つずつプルされます。

注記

Docker 1.9 よりも前のバージョンでは、データの破損による問題が発生する可能性があります。1.9 以降では破損の問題は解消し、並行プルに安全に切り替えることができます。

kubeletArguments:
  serialize-image-pulls:
  - "false" 1
1
並行プルを無効にするには true に変更します (デフォルトの設定)。

5.7. パスワードおよびその他の機密データ

認証設定によっては、LDAP bindPassword または OAuth clientSecret の値が必須になる場合があります。これらの値は、マスター設定ファイルに直接指定する代わりに、環境変数、外部ファイルまたは暗号化ファイルとして指定することができます。

環境変数の例

  ...
  bindPassword:
    env: BIND_PASSWORD_ENV_VAR_NAME

外部ファイルの例

  ...
  bindPassword:
    file: bindPassword.txt

暗号化された外部ファイルの例

  ...
  bindPassword:
    file: bindPassword.encrypted
    keyFile: bindPassword.key

上記の例の暗号化ファイルとキーファイルを作成するには、以下を入力します。

$ oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted
> Data to encrypt: B1ndPass0rd!

Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

警告

暗号化データのセキュリティーレベルは復号化キーと同程度です。ファイルシステムのパーミッションとキーファイルへのアクセスを制限する際には十分な注意が必要です。

5.8. 新規設定ファイルの作成

OpenShift Container Platform 設定をゼロから定義するときは、新規設定ファイルを作成することから開始します。

マスターホストの設定ファイルでは、openshift start コマンドを --write-config オプションと共に使用して設定ファイルを作成します。ノードホストの場合は、oc adm create-node-config コマンドを使用して設定ファイルを作成します。

以下のコマンドは、関連する起動設定ファイル、証明書ファイルその他ファイルを指定された --write-config または --node-dir ディレクトリーに書き込みます。

生成される証明書ファイルは 2 年間有効です。一方、認証局 (CA) の証明書は 5 年間有効です。この値は --expire-days--signer-expire-days のオプションを使用して変更できますが、セキュリティー上の理由によりこの値をこれ以上大きい値に変更しないことが推奨されます。

オールインワンサーバー (マスターとノードが同一ホスト上にある) の設定ファイルを指定されたディレクトリーに作成するには、以下を入力します。

$ openshift start --write-config=/openshift.local.config

マスター設定ファイルとその他の必須ファイルを指定されたディレクトリーに作成するには、以下を実行します。

$ openshift start master --write-config=/openshift.local.config/master

ノード設定ファイルとその他の関連ファイルを指定されたディレクトリーに作成するには、以下を実行します。

$ oc adm create-node-config \
    --node-dir=/openshift.local.config/node-<node_hostname> \
    --node=<node_hostname> \
    --hostnames=<node_hostname>,<ip_address> \
    --certificate-authority="/path/to/ca.crt" \
    --signer-cert="/path/to/ca.crt" \
    --signer-key="/path/to/ca.key"
    --signer-serial="/path/to/ca.serial.txt"
    --node-client-certificate-authority="/path/to/ca.crt"

ノード設定ファイルを作成する際に、--hostnames オプションは、サーバー証明書を有効にする必要のあるすべてのホスト名または IP アドレスのコンマ区切りの一覧を受け入れます。

5.9. 設定ファイルの使用によるサーバーの起動

マスターまたはノード設定ファイルをユーザー仕様に変更すると、これを引数として指定してサーバーを起動すると、使用できるようになります。設定ファイルを指定する場合は、ユーザーが渡す他のコマンドラインオプションはいずれも認識されないことに注意してください。

注記

クラスターのノードを変更するには、ノード設定マップを必要に応じて更新します。node-config.yaml ファイルは手動で変更しないようにしてください。

マスター設定およびノード設定ファイルを使用してオールインワンサーバーを起動するには、以下を実行します。

$ openshift start --master-config=/openshift.local.config/master/master-config.yaml --node-config=/openshift.local.config/node-<node_hostname>/node-config.yaml

マスター設定ファイルを使用してマスターサーバーを起動するには、以下を実行します。

$ openshift start master --config=/openshift.local.config/master/master-config.yaml

ノード設定ファイルを使ってノードサーバーを起動するには、以下を実行します。

$ openshift start node --config=/openshift.local.config/node-<node_hostname>/node-config.yaml

5.10. マスターおよびノードログの表示

OpenShift Container Platform は、ノードの systemd-journald.service およびスクリプトを使用して、デバッグ用にログメッセージを収集します (マスターの場合は master-logs を使用)。

ロギングでは、以下のような Kubernetes のロギング規則に基づいて 5 段階のログメッセージの重要度を使用します。

表5.22 ログレベルのオプション

オプション説明

0

エラーと警告のみ

2

通常の情報

4

デバッグレベルの情報

6

API レベルのデバッグ情報 (要求 / 応答)

8

本体レベルの API のデバッグ情報

ユーザーは、必要に応じてマスターまたはノードのログレベルをそれぞれ別個に変更できます

ノードログの表示

ノードシステムのログを表示するには、以下のコマンドを実行します。

# journalctl -r -u <journal_name>

最新のエントリーから表示するには、-r オプションを使用します。

マスターログの表示

マスターコンポーネントのログを表示するには、以下のコマンドを実行します。

# /usr/local/bin/master-logs <component> <container>

以下は例を示しています。

# /usr/local/bin/master-logs controllers controllers
# /usr/local/bin/master-logs api api
# /usr/local/bin/master-logs etcd etcd

マスターログのファイルへのリダイレクト

マスターログの出力をファイルにリダイレクトするには、以下のコマンドを実行します。

master-logs api api 2> file

5.10.1. ロギングレベルの設定

ユーザーは、ノード設定ファイルまたは /etc/origin/master/master.env ファイルに DEBUG_LOGLEVEL オプションを設定することにより、ログに記録する INFO メッセージを制御できます。すべてのメッセージを収集するようにログを設定すると、解釈が困難な膨大なログが生成され、多くの領域が占領されます。すべてのメッセージの収集は、デバッグで使用する場合にとどめる必要があります。

注記

FATAL、ERROR、WARNING、および一部の INFO の重要度を伴うメッセージは、ログの設定に関係なくログに表示されます。

ロギングレベルを変更するには、以下を実行します。

  1. マスターの /etc/origin/master/master.env ファイル、またはノードの /etc/sysconfig/atomic-openshift-node ファイルを編集します。
  2. Log Level Options 表の値を DEBUG_LOGLEVEL フィールドに入力します。

    以下は例を示しています。

    DEBUG_LOGLEVEL=4
  3. マスターまたはノードを再起動します。「OpenShift Container Platform サービスの再起動」を参照してください。

再起動後は、すべての新しいログメッセージは新しい設定に従ったメッセージに従います。古いメッセージは変更されません。

注記

デフォルトのログレベルは標準のクラスターインストールプロセスを使用して設定できます。詳細は、「クラスター変数」を参照してください。

以下の例は、各種のログレベルのリダイレクトされたマスターログファイルの抜粋です。システム情報はこれらの例から削除されています。

master-logs api api 2> file output at loglevel=2 の抜粋

W1022 15:08:09.787705       1 server.go:79] Unable to keep dnsmasq up to date, 0.0.0.0:8053 must point to port 53
I1022 15:08:09.787894       1 logs.go:49] skydns: ready for queries on cluster.local. for tcp4://0.0.0.0:8053 [rcache 0]
I1022 15:08:09.787913       1 logs.go:49] skydns: ready for queries on cluster.local. for udp4://0.0.0.0:8053 [rcache 0]
I1022 15:08:09.889022       1 dns_server.go:63] DNS listening at 0.0.0.0:8053
I1022 15:08:09.893156       1 feature_gate.go:190] feature gates: map[AdvancedAuditing:true]
I1022 15:08:09.893500       1 master.go:431] Starting OAuth2 API at /oauth
I1022 15:08:09.914759       1 master.go:431] Starting OAuth2 API at /oauth
I1022 15:08:09.942349       1 master.go:431] Starting OAuth2 API at /oauth
W1022 15:08:09.977088       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:08:09.977176       1 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/10/22 15:08:09 log.go:33: [restful/swagger] listing is available at https://openshift.com:443/swaggerapi
[restful] 2018/10/22 15:08:09 log.go:33: [restful/swagger] https://openshift.com:443/swaggerui/ is mapped to folder /swagger-ui/
I1022 15:08:10.231405       1 master.go:431] Starting OAuth2 API at /oauth
W1022 15:08:10.259523       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:08:10.259555       1 swagger.go:38] No API exists for predefined swagger description /api/v1
I1022 15:08:23.895493       1 logs.go:49] http: TLS handshake error from 10.10.94.10:46322: EOF
I1022 15:08:24.449577       1 crdregistration_controller.go:110] Starting crd-autoregister controller
I1022 15:08:24.449916       1 controller_utils.go:1019] Waiting for caches to sync for crd-autoregister controller
I1022 15:08:24.496147       1 logs.go:49] http: TLS handshake error from 127.0.0.1:39140: EOF
I1022 15:08:24.821198       1 cache.go:39] Caches are synced for APIServiceRegistrationController controller
I1022 15:08:24.833022       1 cache.go:39] Caches are synced for AvailableConditionController controller
I1022 15:08:24.865087       1 controller.go:537] quota admission added evaluator for: { events}
I1022 15:08:24.865393       1 logs.go:49] http: TLS handshake error from 127.0.0.1:39162: read tcp4 127.0.0.1:443->127.0.0.1:39162: read: connection reset by peer
I1022 15:08:24.966917       1 controller_utils.go:1026] Caches are synced for crd-autoregister controller
I1022 15:08:24.967961       1 autoregister_controller.go:136] Starting autoregister controller
I1022 15:08:24.967977       1 cache.go:32] Waiting for caches to sync for autoregister controller
I1022 15:08:25.015924       1 controller.go:537] quota admission added evaluator for: { serviceaccounts}
I1022 15:08:25.077984       1 cache.go:39] Caches are synced for autoregister controller
W1022 15:08:25.304265       1 lease_endpoint_reconciler.go:176] Resetting endpoints for master service "kubernetes" to [10.10.94.10]
E1022 15:08:25.472536       1 memcache.go:153] couldn't get resource list for servicecatalog.k8s.io/v1beta1: the server could not find the requested resource
E1022 15:08:25.550888       1 memcache.go:153] couldn't get resource list for servicecatalog.k8s.io/v1beta1: the server could not find the requested resource
I1022 15:08:29.480691       1 healthz.go:72] /healthz/log check
I1022 15:08:30.981999       1 controller.go:105] OpenAPI AggregationController: Processing item v1beta1.servicecatalog.k8s.io
E1022 15:08:30.990914       1 controller.go:111] loading OpenAPI spec for "v1beta1.servicecatalog.k8s.io" failed with: OpenAPI spec does not exists
I1022 15:08:30.990965       1 controller.go:119] OpenAPI AggregationController: action for item v1beta1.servicecatalog.k8s.io: Rate Limited Requeue.
I1022 15:08:31.530473       1 trace.go:76] Trace[1253590531]: "Get /api/v1/namespaces/openshift-infra/serviceaccounts/serviceaccount-controller" (started: 2018-10-22 15:08:30.868387562 +0000 UTC m=+24.277041043) (total time: 661.981642ms):
Trace[1253590531]: [661.903178ms] [661.89217ms] About to write a response
I1022 15:08:31.531366       1 trace.go:76] Trace[83808472]: "Get /api/v1/namespaces/aws-sb/secrets/aws-servicebroker" (started: 2018-10-22 15:08:30.831296749 +0000 UTC m=+24.239950203) (total time: 700.049245ms):

master-logs api api 2> file output at loglevel=4 の抜粋

I1022 15:08:09.746980       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: AlwaysDeny.
I1022 15:08:09.747597       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: ResourceQuota.
I1022 15:08:09.748038       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: openshift.io/ClusterResourceQuota.
I1022 15:08:09.786771       1 start_master.go:458] Starting master on 0.0.0.0:443 (v3.10.45)
I1022 15:08:09.786798       1 start_master.go:459] Public master address is https://openshift.com:443
I1022 15:08:09.786844       1 start_master.go:463] Using images from "registry.access.redhat.com/openshift3/ose-<component>:v3.10.45"
W1022 15:08:09.787046       1 dns_server.go:37] Binding DNS on port 8053 instead of 53, which may not be resolvable from all clients
W1022 15:08:09.787705       1 server.go:79] Unable to keep dnsmasq up to date, 0.0.0.0:8053 must point to port 53
I1022 15:08:09.787894       1 logs.go:49] skydns: ready for queries on cluster.local. for tcp4://0.0.0.0:8053 [rcache 0]
I1022 15:08:09.787913       1 logs.go:49] skydns: ready for queries on cluster.local. for udp4://0.0.0.0:8053 [rcache 0]
I1022 15:08:09.889022       1 dns_server.go:63] DNS listening at 0.0.0.0:8053
I1022 15:08:09.893156       1 feature_gate.go:190] feature gates: map[AdvancedAuditing:true]
I1022 15:08:09.893500       1 master.go:431] Starting OAuth2 API at /oauth
I1022 15:08:09.914759       1 master.go:431] Starting OAuth2 API at /oauth
I1022 15:08:09.942349       1 master.go:431] Starting OAuth2 API at /oauth
W1022 15:08:09.977088       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:08:09.977176       1 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/10/22 15:08:09 log.go:33: [restful/swagger] listing is available at https://openshift.com:443/swaggerapi
[restful] 2018/10/22 15:08:09 log.go:33: [restful/swagger] https://openshift.com:443/swaggerui/ is mapped to folder /swagger-ui/
I1022 15:08:10.231405       1 master.go:431] Starting OAuth2 API at /oauth
W1022 15:08:10.259523       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:08:10.259555       1 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/10/22 15:08:10 log.go:33: [restful/swagger] listing is available at https://openshift.com:443/swaggerapi
[restful] 2018/10/22 15:08:10 log.go:33: [restful/swagger] https://openshift.com:443/swaggerui/ is mapped to folder /swagger-ui/
I1022 15:08:10.444303       1 master.go:431] Starting OAuth2 API at /oauth
W1022 15:08:10.492409       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:08:10.492507       1 swagger.go:38] No API exists for predefined swagger description /api/v1
[restful] 2018/10/22 15:08:10 log.go:33: [restful/swagger] listing is available at https://openshift.com:443/swaggerapi
[restful] 2018/10/22 15:08:10 log.go:33: [restful/swagger] https://openshift.com:443/swaggerui/ is mapped to folder /swagger-ui/
I1022 15:08:10.774824       1 master.go:431] Starting OAuth2 API at /oauth
I1022 15:08:23.808685       1 logs.go:49] http: TLS handshake error from 10.128.0.11:39206: EOF
I1022 15:08:23.815311       1 logs.go:49] http: TLS handshake error from 10.128.0.14:53054: EOF
I1022 15:08:23.822286       1 customresource_discovery_controller.go:174] Starting DiscoveryController
I1022 15:08:23.822349       1 naming_controller.go:276] Starting NamingConditionController
I1022 15:08:23.822705       1 logs.go:49] http: TLS handshake error from 10.128.0.14:53056: EOF
+24.277041043) (total time: 661.981642ms):
Trace[1253590531]: [661.903178ms] [661.89217ms] About to write a response
I1022 15:08:31.531366       1 trace.go:76] Trace[83808472]: "Get /api/v1/namespaces/aws-sb/secrets/aws-servicebroker" (started: 2018-10-22 15:08:30.831296749 +0000 UTC m=+24.239950203) (total time: 700.049245ms):
Trace[83808472]: [700.049245ms] [700.04027ms] END
I1022 15:08:31.531695       1 trace.go:76] Trace[1916801734]: "Get /api/v1/namespaces/aws-sb/secrets/aws-servicebroker" (started: 2018-10-22 15:08:31.031163449 +0000 UTC m=+24.439816907) (total time: 500.514208ms):
Trace[1916801734]: [500.514208ms] [500.505008ms] END
I1022 15:08:44.675371       1 healthz.go:72] /healthz/log check
I1022 15:08:46.589759       1 controller.go:537] quota admission added evaluator for: { endpoints}
I1022 15:08:46.621270       1 controller.go:537] quota admission added evaluator for: { endpoints}
I1022 15:08:57.159494       1 healthz.go:72] /healthz/log check
I1022 15:09:07.161315       1 healthz.go:72] /healthz/log check
I1022 15:09:16.297982       1 trace.go:76] Trace[2001108522]: "GuaranteedUpdate etcd3: *core.Node" (started: 2018-10-22 15:09:15.139820419 +0000 UTC m=+68.548473981) (total time: 1.158128974s):
Trace[2001108522]: [1.158012755s] [1.156496534s] Transaction committed
I1022 15:09:16.298165       1 trace.go:76] Trace[1124283912]: "Patch /api/v1/nodes/master-0.com/status" (started: 2018-10-22 15:09:15.139695483 +0000 UTC m=+68.548348970) (total time: 1.158434318s):
Trace[1124283912]: [1.158328853s] [1.15713683s] Object stored in database
I1022 15:09:16.298761       1 trace.go:76] Trace[24963576]: "GuaranteedUpdate etcd3: *core.Node" (started: 2018-10-22 15:09:15.13159057 +0000 UTC m=+68.540244112) (total time: 1.167151224s):
Trace[24963576]: [1.167106144s] [1.165570379s] Transaction committed
I1022 15:09:16.298882       1 trace.go:76] Trace[222129183]: "Patch /api/v1/nodes/node-0.com/status" (started: 2018-10-22 15:09:15.131269234 +0000 UTC m=+68.539922722) (total time: 1.167595526s):
Trace[222129183]: [1.167517296s] [1.166135605s] Object stored in database

master-logs api api 2> file output at loglevel=8 の抜粋

1022 15:11:58.829357       1 plugins.go:84] Registered admission plugin "NamespaceLifecycle"
I1022 15:11:58.839967       1 plugins.go:84] Registered admission plugin "Initializers"
I1022 15:11:58.839994       1 plugins.go:84] Registered admission plugin "ValidatingAdmissionWebhook"
I1022 15:11:58.840012       1 plugins.go:84] Registered admission plugin "MutatingAdmissionWebhook"
I1022 15:11:58.840025       1 plugins.go:84] Registered admission plugin "AlwaysAdmit"
I1022 15:11:58.840082       1 plugins.go:84] Registered admission plugin "AlwaysPullImages"
I1022 15:11:58.840105       1 plugins.go:84] Registered admission plugin "LimitPodHardAntiAffinityTopology"
I1022 15:11:58.840126       1 plugins.go:84] Registered admission plugin "DefaultTolerationSeconds"
I1022 15:11:58.840146       1 plugins.go:84] Registered admission plugin "AlwaysDeny"
I1022 15:11:58.840176       1 plugins.go:84] Registered admission plugin "EventRateLimit"
I1022 15:11:59.850825       1 feature_gate.go:190] feature gates: map[AdvancedAuditing:true]
I1022 15:11:59.859108       1 register.go:154] Admission plugin AlwaysAdmit is not enabled.  It will not be started.
I1022 15:11:59.859284       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: AlwaysAdmit.
I1022 15:11:59.859809       1 register.go:154] Admission plugin NamespaceAutoProvision is not enabled.  It will not be started.
I1022 15:11:59.859939       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: NamespaceAutoProvision.
I1022 15:11:59.860594       1 register.go:154] Admission plugin NamespaceExists is not enabled.  It will not be started.
I1022 15:11:59.860778       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: NamespaceExists.
I1022 15:11:59.863999       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: NamespaceLifecycle.
I1022 15:11:59.864626       1 register.go:154] Admission plugin EventRateLimit is not enabled.  It will not be started.
I1022 15:11:59.864768       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: EventRateLimit.
I1022 15:11:59.865259       1 register.go:154] Admission plugin ProjectRequestLimit is not enabled.  It will not be started.
I1022 15:11:59.865376       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: ProjectRequestLimit.
I1022 15:11:59.866126       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: OriginNamespaceLifecycle.
I1022 15:11:59.866709       1 register.go:154] Admission plugin openshift.io/RestrictSubjectBindings is not enabled.  It will not be started.
I1022 15:11:59.866761       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: openshift.io/RestrictSubjectBindings.
I1022 15:11:59.867304       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: openshift.io/JenkinsBootstrapper.
I1022 15:11:59.867823       1 plugins.go:149] Loaded 1 admission controller(s) successfully in the following order: openshift.io/BuildConfigSecretInjector.
I1022 15:12:00.015273       1 master_config.go:476] Initializing cache sizes based on 0MB limit
I1022 15:12:00.015896       1 master_config.go:539] Using the lease endpoint reconciler with TTL=15s and interval=10s
I1022 15:12:00.018396       1 storage_factory.go:285] storing { apiServerIPInfo} in v1, reading as __internal from storagebackend.Config{Type:"etcd3", Prefix:"kubernetes.io", ServerList:[]string{"https://master-0.com:2379"}, KeyFile:"/etc/origin/master/master.etcd-client.key", CertFile:"/etc/origin/master/master.etcd-client.crt", CAFile:"/etc/origin/master/master.etcd-ca.crt", Quorum:true, Paging:true, DeserializationCacheSize:0, Codec:runtime.Codec(nil), Transformer:value.Transformer(nil), CompactionInterval:300000000000, CountMetricPollPeriod:60000000000}
I1022 15:12:00.037710       1 storage_factory.go:285] storing { endpoints} in v1, reading as __internal from storagebackend.Config{Type:"etcd3", Prefix:"kubernetes.io", ServerList:[]string{"https://master-0.com:2379"}, KeyFile:"/etc/origin/master/master.etcd-client.key", CertFile:"/etc/origin/master/master.etcd-client.crt", CAFile:"/etc/origin/master/master.etcd-ca.crt", Quorum:true, Paging:true, DeserializationCacheSize:0, Codec:runtime.Codec(nil), Transformer:value.Transformer(nil), CompactionInterval:300000000000, CountMetricPollPeriod:60000000000}
I1022 15:12:00.054112       1 compact.go:54] compactor already exists for endpoints [https://master-0.com:2379]
I1022 15:12:00.054678       1 start_master.go:458] Starting master on 0.0.0.0:443 (v3.10.45)
I1022 15:12:00.054755       1 start_master.go:459] Public master address is https://openshift.com:443
I1022 15:12:00.054837       1 start_master.go:463] Using images from "registry.access.redhat.com/openshift3/ose-<component>:v3.10.45"
W1022 15:12:00.056957       1 dns_server.go:37] Binding DNS on port 8053 instead of 53, which may not be resolvable from all clients
W1022 15:12:00.065497       1 server.go:79] Unable to keep dnsmasq up to date, 0.0.0.0:8053 must point to port 53
I1022 15:12:00.066061       1 logs.go:49] skydns: ready for queries on cluster.local. for tcp4://0.0.0.0:8053 [rcache 0]
I1022 15:12:00.066265       1 logs.go:49] skydns: ready for queries on cluster.local. for udp4://0.0.0.0:8053 [rcache 0]
I1022 15:12:00.158725       1 dns_server.go:63] DNS listening at 0.0.0.0:8053
I1022 15:12:00.167910       1 htpasswd.go:118] Loading htpasswd file /etc/origin/master/htpasswd...
I1022 15:12:00.168182       1 htpasswd.go:118] Loading htpasswd file /etc/origin/master/htpasswd...
I1022 15:12:00.231233       1 storage_factory.go:285] storing {apps.openshift.io deploymentconfigs} in apps.openshift.io/v1, reading as apps.openshift.io/__internal from storagebackend.Config{Type:"etcd3", Prefix:"openshift.io", ServerList:[]string{"https://master-0.com:2379"}, KeyFile:"/etc/origin/master/master.etcd-client.key", CertFile:"/etc/origin/master/master.etcd-client.crt", CAFile:"/etc/origin/master/master.etcd-ca.crt", Quorum:true, Paging:true, DeserializationCacheSize:0, Codec:runtime.Codec(nil), Transformer:value.Transformer(nil), CompactionInterval:300000000000, CountMetricPollPeriod:60000000000}
I1022 15:12:00.248136       1 compact.go:54] compactor already exists for endpoints [https://master-0.com:2379]
I1022 15:12:00.248697       1 store.go:1391] Monitoring deploymentconfigs.apps.openshift.io count at <storage-prefix>//deploymentconfigs
W1022 15:12:00.256861       1 swagger.go:38] No API exists for predefined swagger description /oapi/v1
W1022 15:12:00.258106       1 swagger.go:38] No API exists for predefined swagger description /api/v1

5.11. マスターおよびノードサービスの再起動

マスターまたはノード設定の変更を適用するには、それぞれのサービスを再起動する必要がります。

マスター設定の変更を再度読み込むには、master-restart コマンドを使用してコントロールプレーンの静的 Pod で実行されているマスターサービスを再起動します。

# master-restart api

ノード設定の変更を再度読み込むには、ノードホストでノードサービスを再起動します。

# systemctl restart atomic-openshift-node

第6章 OpenShift Ansible Broker の設定

6.1. 概要

OpenShift Ansible Broker (OAB) をクラスターにデプロイする際に、その動作の大半は、起動時に読み込まれるブローカーの設定ファイルによって決定されます。ブローカーの設定は、ブローカーの namespace (デフォルトでは (openshift-ansible-service-broker) に ConfigMap オブジェクトとして格納されます。

OpenShift Ansible Broker 設定ファイルの例

registry: 1
  - type: dockerhub
    name: docker
    url: https://registry.hub.docker.com
    org: <dockerhub_org>
    fail_on_error: false
  - type: rhcc
    name: rhcc
    url: https://registry.access.redhat.com
    fail_on_error: true
    white_list:
      - "^foo.*-apb$"
      - ".*-apb$"
    black_list:
      - "bar.*-apb$"
      - "^my-apb$"
  - type: local_openshift
    name: lo
    namespaces:
      - openshift
    white_list:
      - ".*-apb$"
dao: 2
  etcd_host: localhost
  etcd_port: 2379
log: 3
  logfile: /var/log/ansible-service-broker/asb.log
  stdout: true
  level: debug
  color: true
openshift: 4
  host: ""
  ca_file: ""
  bearer_token_file: ""
  image_pull_policy: IfNotPresent
  sandbox_role: "edit"
  keep_namespace: false
  keep_namespace_on_error: true
broker: 5
  bootstrap_on_startup: true
  dev_broker: true
  launch_apb_on_bind: false
  recovery: true
  output_request: true
  ssl_cert_key: /path/to/key
  ssl_cert: /path/to/cert
  refresh_interval: "600s"
  auth:
    - type: basic
      enabled: true
secrets: 6
  - title: Database credentials
    secret: db_creds
    apb_name: dh-rhscl-postgresql-apb

1
詳細は「レジストリー設定」を参照してください。
2
詳細は「DAO 設定」を参照してください。
3
詳細は「ログ設定」を参照してください。
4
詳細は「OpenShift 設定」を参照してください。
5
詳細は「ブローカー設定」を参照してください。
6
詳細は「シークレット設定」を参照してください。

6.2. OpenShift Ansible Broker 設定の変更

OAB のデフォルト設定をデプロイした後に変更するには、以下を実行します。

  1. OAB の namespace の broker-config ConfigMap オブジェクトを、cluster-admin 権限を持つユーザーとして編集します。

    $ oc edit configmap broker-config -n openshift-ansible-service-broker
  2. 更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。

    $ oc rollout latest dc/asb -n openshift-ansible-service-broker

6.3. レジストリー設定

registry セクションでは、ブローカーが APB 用に参照する必要があるレジストリーを定義できます。

表6.1 registry セクションの設定オプション

フィールド説明必須

name

レジストリーの名前です。このレジストリーから APB を識別するためにブローカーによって使用されます。

Y

user

レジストリーに対して認証するためのユーザー名です。auth_typesecret または file に設定されている場合は使用されません。

N

pass

レジストリーに対して認証するためのパスワードです。auth_typesecret または file に設定されている場合は使用されません。

N

auth_type

レジストリー認証情報が userpass でブローカー設定に定義されていない場合にブローカーがレジストリー認証情報を読み取る方法です。secret (シークレットをブローカー namespace で使用する) または file (マウントされたファイルを使用する) を指定できます。

N

auth_name

読み取る必要があるレジストリー認証情報を格納しているシークレットまたはファイルの名前です。auth_typesecret に設定されている場合に使用されます。

N (auth_typesecret または file に設定されているに場合にのみ必要)

org

イメージが含まれている namespace または組織です。

N

type

レジストリーのタイプです。使用可能なアダプターは mockrhccopenshiftdockerhub、および local_openshift です。

Y

namespaces

local_openshift レジストリータイプの設定に使用する namespace の一覧です。デフォルトでは、ユーザーは openshift を使用する必要があります。

N

url

イメージ情報を取得するために使用される URL です。これは、RHCC の場合に広範囲に使用されます。dockerhub タイプでは、ハードコードされた URL が使用されます。

N

fail_on_error

このレジストリーが失敗した場合にブートストラップ要求を失敗させるかどうかを指定します。失敗させる場合、その他のレジストリーの読み込みの実行を停止します。

N

white_list

許可されるイメージ名を定義するための正規表現の一覧です。カタログへの APB の追加を許可するホワイトリストを作成する必要があります。レジストリー内のすべての APB を取得する必要がある場合は、最も許容度の高い正規表現である .*-apb$ を使用できます。詳細については、「APB のフィルタリング」を参照してください

N

black_list

許可できないイメージ名を定義するために使用される正規表現の一覧です。詳細については、「APB のフィルタリング」を参照してください。

N

images

OpenShift Container レジストリーで使用されるイメージの一覧です。

N

6.3.1. 実稼働または開発

実稼働ブローカー設定は、Red Hat Container Catalog (RHCC) などの信頼できるコンテナーディストリビューションレジストリーを参照するように設計されています。

registry:
  - name: rhcc
    type: rhcc
    url: https://registry.access.redhat.com
    tag: v3.10
    white_list:
      - ".*-apb$"
  - type: local_openshift
    name: localregistry
    namespaces:
      - openshift
    white_list: []

開発ブローカー設定は、主にブローカーの開発作業に取り組む開発者によって使用されます。開発者設定を有効にするには、レジストリー名を dev に設定し、broker セクションの dev_brokerフィールドを true に設定します。

registry:
  name: dev
broker:
  dev_broker: true

6.3.2. レジストリー認証情報の保存

ブローカー設定は、ブローカーによるレジストリー認証情報の読み取り方法を決定します。レジストリー認証情報は、registry セクションの user 値と pass 値から読み取ることができます。以下は例になります。

registry:
  - name: isv
    type: openshift
    url: https://registry.connect.redhat.com
    user: <user>
    pass: <password>

これらの認証情報にパブリックにアクセスできないようにするには、registry セクションの auth_type フィールドを secret または file タイプに設定します。secret タイプは、ブローカーの namespace からシークレットを使用するようにレジストリーを設定します。一方、file タイプは、ボリュームとしてマウントされているシークレットを使用するようにレジストリーを設定します。

secret または file タイプを使用するには、以下を実行します。

  1. 関連するシークレットには、usernamepassword の値が定義されている必要があります。シークレットを使用する場合は、openshift-ansible-service-broker namespace が存在していることを確認する必要があります。シークレットはこの namespace から読み取られるためです。

    たとえば、reg-creds.yaml ファイルを作成します。

    $ cat reg-creds.yaml
    ---
    username: <user_name>
    password: <password>
  2. このファイルから openshift-ansible-service-broker namespace にシークレットを作成します。

    $ oc create secret generic \
        registry-credentials-secret \
        --from-file reg-creds.yaml \
        -n openshift-ansible-service-broker
  3. secret または file のどちらのタイプを使用するか選択します。

    • secret タイプを使用するには、以下を実行します。

      1. ブローカー設定で、auth_typesecret に、auth_name をシークレットの名前に設定します。

        registry:
          - name: isv
            type: openshift
            url: https://registry.connect.redhat.com
            auth_type: secret
            auth_name: registry-credentials-secret
      2. シークレットが置かれている namespace を設定します。

        openshift:
          namespace: openshift-ansible-service-broker
    • file タイプを使用するには、以下を実行します。

      1. asb デプロイメント設定を編集し、ファイルを /tmp/registry-credentials/reg-creds.yaml にマウントします。

        $ oc edit dc/asb -n openshift-ansible-service-broker

        containers.volumeMounts セクションに、以下を追加します。

        volumeMounts:
          - mountPath: /tmp/registry-credentials
            name: reg-auth

        volumes セクションに、以下を追加します。

            volumes:
              - name: reg-auth
                secret:
                  defaultMode: 420
                  secretName: registry-credentials-secret
      2. ブローカー設定で、auth_typefile に、auth_type をファイルの場所に設定します。

        registry:
          - name: isv
            type: openshift
            url: https://registry.connect.redhat.com
            auth_type: file
            auth_name: /tmp/registry-credentials/reg-creds.yaml

6.3.3. モックレジストリー

モックレジストリーは、ローカルの APB 仕様を読み取る場合に便利です。イメージ仕様を検索するために外部のレジストリーにアクセスする代わりに、ローカル仕様の一覧を使用します。 モックレジストリーを使用するには、レジストリーの名前を mock に設定します。

registry:
  - name: mock
    type: mock

6.3.4. Dockerhub レジストリー

dockerhub タイプを使用すると、DockerHub の特定の組織から APB を読み込むことができます (例: ansibleplaybookbundle)。

registry:
  - name: dockerhub
    type: dockerhub
    org: ansibleplaybookbundle
    user: <user>
    pass: <password>
    white_list:
      - ".*-apb$"

6.3.5. APB のフィルタリング

APB は、ブローカー設定内のレジストリーベースに設定された white_list または black_list パラメーターの組み合わせを使用して、イメージ名でフィルタリングできます。

これらはどちらもオプションの正規表現の一覧であり、特定のレジストリーで一致するものを判別できるように検出されたすべての APB に対して実行されます。

表6.2 APB フィルターの動作

存在するパラメーター許可ブロック

ホワイトリストのみ

一覧の正規表現に一致。

一致しないすべての APB。

ブラックリストのみ

一致しないすべての APB。

一覧の正規表現に一致する APB。

両方とも存在する

ホワイトリストの正規表現に一致し、ブラックリストの正規表現に一致しない。

ブラックリストの正規表現に一致する APB。

なし

レジストリーのどの APB も許可されない。

レジストリーのすべての APB。

以下は例を示しています。

ホワイトリストのみ

white_list:
  - "foo.*-apb$"
  - "^my-apb$"

この場合は、foo.*-apb$my-apb に一致する APB が許可されます。それ以外の APB はすべて拒否されます。

ブラックリストのみ

black_list:
  - "bar.*-apb$"
  - "^foobar-apb$"

この場合は、bar.*-apb$foobar-apb に一致する APB がブロックされます。それ以外の APB はすべて許可されます。

ホワイトリストとブラックリスト

white_list:
  - "foo.*-apb$"
  - "^my-apb$"
black_list:
  - "^foo-rootkit-apb$"

ここでは、foo-rootkit-apb はホワイトリストに一致するにもかかわらず、ブラックリストによって明確にブロックされます。これは、ホワイトリストの一致が上書きされるためです。

そうでない場合は、foo.*-apb$my-apb に一致する APB のみが許可されます。

ブローカー設定の registry セクションのサンプル:

registry:
  - type: dockerhub
    name: dockerhub
    url: https://registry.hub.docker.com
    user: <user>
    pass: <password>
    org: <org>
    white_list:
      - "foo.*-apb$"
      - "^my-apb$"
    black_list:
      - "bar.*-apb$"
      - "^foobar-apb$"

6.3.6. ローカルの OpenShift Container レジストリー

local_openshift タイプを使用すると、OpenShift Container Platform クラスター内の OpenShift Container レジストリーから APB を読み込むことができます。公開された APB を検索する namespace を設定できます。

registry:
  - type: local_openshift
    name: lo
    namespaces:
      - openshift
    white_list:
      - ".*-apb$"

6.3.7. Red Hat Container Catalog レジストリー

rhcc タイプを使用すると、Red Hat Container Catalog (RHCC) レジストリーに公開された APB を読み込むことができます。

registry:
  - name: rhcc
    type: rhcc
    url: https://registry.access.redhat.com
    white_list:
      - ".*-apb$"

6.3.8. Red Hat Connect Partner Registry

Red Hat Container Catalog のサードパーティーのイメージは Red Hat Connect Partner レジストリー (https://registry.connect.redhat.com) から提供されます。partner_rhcc タイプは、APB の一覧を取得し、それらの仕様を読み込むためにブローカーが Partner レジストリーからブートストラップすることを可能にします。Partner レジストリーには、有効な Red Hat カスタマーポータルのユーザー名およびパスワードを使った、イメージをプルするための認証が必要です。

registry:
  - name: partner_reg
    type: partner_rhcc
    url:  https://registry.connect.redhat.com
    user: <registry_user>
    pass: <registry_password>
    white_list:
      - ".*-apb$"

Partner レジストリーには認証が必要なため、ブローカーを Partner レジストリー URL を使用するように設定するには以下の手動の手順も必要になります。

  1. OpenShift Container Platform クラスターのすべてのノードで以下のコマンドを実行します。

    # docker --config=/var/lib/origin/.docker \
        login -u <registry_user> -p <registry_password> \
        registry.connect.redhat.com

6.3.9. 複数のレジストリー

複数のレジストリーを使用して APB を論理的な組織に分割し、それらを同じブローカーから管理できます。レジスターには一意の空でない名前が必要です。一意の名前がない場合、サービスブローカーは起動に失敗し、問題について警告するエラーメッセージを表示します。

registry:
  - name: dockerhub
    type: dockerhub
    org: ansibleplaybookbundle
    user: <user>
    pass: <password>
    white_list:
      - ".*-apb$"
  - name: rhcc
    type: rhcc
    url: <rhcc_url>
    white_list:
      - ".*-apb$"

6.4. ブローカー認証

ブローカーは認証をサポートします。つまり、ブローカーに接続する際に、呼び出し側は各要求に対して Basic 認証または Bearer 認証の認証情報を指定する必要があります。curl を使用し、以下のように簡単に実行できます。

-u <user_name>:<password>

または、以下が表示されます。

-h "Authorization: bearer <token>

上記をコマンドに指定します。サービスカタログをユーザー名とパスワードの組み合わせ、またはベアラートークンが含まれるシークレットで設定する必要があります。

6.4.1. Basic 認証

Basic 認証の使用を有効にするには、ブローカー設定で以下を設定します。

broker:
   ...
   auth:
     - type: basic 1
       enabled: true 2
1
type フィールドは使用する認証タイプを指定します。
2
enabled フィールドでは、特定の認証タイプを無効にすることができます。これにより、これを無効にするために auth のセクション全体を削除する必要がなくなります。

6.4.1.1. デプロイメントテンプレートおよびシークレット

通常、ブローカーはデプロイメントテンプレートで ConfigMap を使用して設定されます。ファイル設定と同様の方法で認証設定を指定できます。

以下は、デプロイメントテンプレートのサンプルになります。

auth:
  - type: basic
    enabled: ${ENABLE_BASIC_AUTH}

Basic 認証の別の部分には、ブローカーに対して認証するために使用されるユーザー名とパスワードが含まれます。Basic 認証の実装は別のバックエンドサービスでサポートされる可能性があるものの、現時点でサポートされている実装は シークレット に対応します。シークレットは /var/run/asb_auth の場所にあるボリュームマウントで Pod に挿入される必要があります。これは、ブローカーがユーザー名とパスワードを読み取る場所です。

デプロイメントテンプレート では、シークレットが指定される必要があります。以下は例になります。

- apiVersion: v1
  kind: Secret
  metadata:
    name: asb-auth-secret
    namespace: openshift-ansible-service-broker
  data:
    username: ${BROKER_USER}
    password: ${BROKER_PASS}

シークレットにはユーザー名とパスワードが含まれる必要があります。値は base64 エンコードである必要があります。それらのエントリーの値を生成する最も簡単な方法として、echo および base64 コマンドを使用できます。

$ echo -n admin | base64 1
YWRtaW4=
1
-n オプションは非常に重要になります。

このシークレットはボリュームマウントで Pod に挿入される必要があります。これはデプロイメントテンプレートでも設定されます。

spec:
  serviceAccount: asb
  containers:
  - image: ${BROKER_IMAGE}
    name: asb
    imagePullPolicy: IfNotPresent
    volumeMounts:
      ...
      - name: asb-auth-volume
        mountPath: /var/run/asb-auth

次に volumes セクションで、シークレットをマウントします。

volumes:
  ...
  - name: asb-auth-volume
    secret:
      secretName: asb-auth-secret

上記により、/var/run/asb-auth にボリュームマウントが作成されます。このボリュームには、asb-auth-secret シークレットで作成されるユーザー名およびパスワードの 2 つのファイルがあります。

6.4.1.2. サービスカタログおよびブローカー通信の設定

ブローカーが Basic 認証を使用するように設定されているため、サービスカタログに対してブローカーとの通信方法について指示する必要があります。これは、ブローカーリソースの authInfo セクションで実行できます。

以下は、サービスカタログで broker リソースを作成する例になります。spec はサービスカタログに対し、ブローカーがリッスンしている URL を示唆します。authInfo は認証情報を取得するために読み取る必要のあるシークレットを示唆します。

apiVersion: servicecatalog.k8s.io/v1alpha1
kind: Broker
metadata:
  name: ansible-service-broker
spec:
  url: https://asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io
  authInfo:
    basicAuthSecret:
      namespace: openshift-ansible-service-broker
      name: asb-auth-secret

サービスカタログの v0.0.17 以降、ブローカーのリソース設定は変更されています。

apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceBroker
metadata:
  name: ansible-service-broker
spec:
  url: https://asb-1338-openshift-ansible-service-broker.172.17.0.1.nip.io
  authInfo:
    basic:
      secretRef:
        namespace: openshift-ansible-service-broker
        name: asb-auth-secret

6.4.2. Bearer 認証

デフォルトで、認証が指定されていない場合、ブローカーはベアラートークン認証 (Bearer Auth) を使用します。Bearer 認証は Kubernetes apiserver ライブラリーから委任された認証を使用します。

注記

Bearer 認証は OpenShift Container Platform 3.7 以降でのみ利用できます。

この設定は、Kubernetes RBAC ロールおよびロールバインディングにより、URL プレフィックスへのアクセスを付与します。ブローカーは設定オプション cluster_url を追加して url_prefix を指定します。この値はデフォルトで openshift-ansible-service-broker になります。

クラスターロールの例

- apiVersion: authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: access-asb-role
  rules:
  - nonResourceURLs: ["/ansible-service-broker", "/ansible-service-broker/*"]
    verbs: ["get", "post", "put", "patch", "delete"]

6.4.2.1. デプロイメントテンプレートおよびシークレット

以下は、サービスカタログが使用できるシークレットの作成例です。この例では、ロールの access-asb-role がすでに作成されていることを前提としています。また、デプロイメントテンプレート が使用されています。

- apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ansibleservicebroker-client
    namespace: openshift-ansible-service-broker

- apiVersion: authorization.openshift.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: ansibleservicebroker-client
  subjects:
  - kind: ServiceAccount
    name: ansibleservicebroker-client
    namespace: openshift-ansible-service-broker
  roleRef:
    kind: ClusterRole
    name: access-asb-role

- apiVersion: v1
  kind: Secret
  metadata:
    name: ansibleservicebroker-client
    annotations:
      kubernetes.io/service-account.name: ansibleservicebroker-client
  type: kubernetes.io/service-account-token

上記の例ではサービスアカウントを作成し、アクセスを access-asb-role に付与し、サービスアカウントトークンのシークレットを作成します。

6.4.2.2. サービスカタログおよびブローカー通信の設定

ブローカーが Bearer 認証トークンを使用するように設定されているため、サービスカタログに対してブローカーとの通信方法について指示する必要があります。これは、broker リソースの authInfo セクションで実行できます。

以下は、サービスカタログで broker リソースを作成する例になります。spec はサービスカタログに対し、ブローカーがリッスンしている URL を示唆します。authInfo は認証情報を取得するために読み取る必要のあるシークレットを示唆します。

apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceBroker
metadata:
  name: ansible-service-broker
spec:
  url: https://asb.openshift-ansible-service-broker.svc:1338${BROKER_URL_PREFIX}/
  authInfo:
    bearer:
      secretRef:
        kind: Secret
        namespace: openshift-ansible-service-broker
        name: ansibleservicebroker-client

6.5. DAO 設定

フィールド説明必須

etcd_host

etcd ホストの URL です。

Y

etcd_port

etcd_host との通信時に使用するポートです。

Y

6.6. ログ設定

フィールド説明必須

logfile

ブローカーのログを書き込む場所です。

Y

stdout

ログを標準出力に書き込みます。

Y

level

ログ出力のレベルです。

Y

color

ログに色付けします。

Y

6.7. OpenShift 設定

フィールド説明必須

host

OpenShift Container Platform ホストです。

N

ca_file

認証局ファイルの場所です。

N

bearer_token_file

使用するベアラートークンの場所です。

N

image_pull_policy

イメージをプルするタイミングです。

Y

namespace

ブローカーがデプロイされている namespace です。シークレットを介して渡されるパラメーター値などに重要です。

Y

sandbox_role

APB サンドボックス環境に対して指定するロールです。

Y

keep_namespace

APB の実行後に namespace を常に保持します。

N

keep_namespace_on_error

APB の実行でエラーが発生した後に namespace を保持します。

N

6.8. ブローカー設定

broker セクションでは、有効/無効にする機能をブローカーに指示します。また、完全な機能を有効にするファイルがディスク上のどこにあるかをブローカーに指示します。

フィールド説明デフォルト値必須

dev_broker

開発ルートにアクセスできるようにします。

false

N

launch_apb_on_bind

バインドが no-op (無処理) になることを許可します。

false

N

bootstrap_on_startup

ブローカーが起動時に自らをブートストラップできるようにします。APB を設定済みのレジストリーから取得します。

false

N

recovery

etcd にある保留中のジョブを処理することによって、ブローカーが自らをリカバリーできるようにします。

false

N

output_request

デバッグを容易に行えるように、ブローカーが要求の受信時にそれをログファイルに出力できるようにします。

false

N

ssl_cert_key

TLS キーファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはキーファイルの作成を試みます。

""

N

ssl_cert

TLS .crt ファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはファイルの作成を試みます。

""

N

refresh_interval

レジストリーで新規イメージ仕様をクエリーする間隔です。

"600s"

N

auto_escalate

ブローカーが APB の実行中にユーザーのパーミッションをエスカレーションできるようにします。

false

N

cluster_url

ブローカーが予期する URL のプレフィックスを設定します。

openshift-ansible-service-broker

N

注記

非同期のバインドまたはバインド解除は実験的な機能であり、サポートされていないか、デフォルトでは有効になっていません。非同期バインドがない場合に launch_apb_on_bindtrue に設定すると、バインドアクションがタイムアウトになり、再試行が実行されます。これはパラメーターの異なる同じバインド要求であるため、ブローカーは「409 Conflicts」で処理します。

6.9. シークレット設定

secrets セクションでは、ブローカーの namespace のシークレットとブローカーが実行する APB 間の関連付けを作成します。ブローカーは、これらのルールに従って実行中の APB にシークレットをマウントします。これにより、ユーザーはシークレットを使用して、パラメーターをカタログやユーザーに公開せずに渡すことができます。

このセクションは一覧の形式であり、各エントリーは以下の構造を持ちます。

フィールド説明必須

title

ルールのタイトルです。表示と出力の目的でのみ使用されます。

Y

apb_name

指定されたシークレットに関連付けられる APB の名前です。これは完全修飾名 (<registry_name>-<image_name>) です。

Y

secret

パラメーターをプルするシークレットの名前です。

Y

create_broker_secret.py ファイルをダウンロードし、これを使用して、この設定セクションの作成とフォーマットを行うことができます。

secrets:
- title: Database credentials
  secret: db_creds
  apb_name: dh-rhscl-postgresql-apb

6.10. プロキシー環境での実行

プロキシー化された OpenShift Container Platform クラスター内で OAB を実行する場合は、その中心的な概念を理解し、外部ネットワークアクセスに使用するプロキシーのコンテキストで検討することが重要です。

概要としては、ブローカー自体はクラスター内で Pod として実行され、そのレジスターの設定方法に応じて外部ネットワークにアクセスする必要があります。

6.10.1. レジストリーアダプターのホワイトリスト

ブローカーの設定済みレジストリーアダプターは、正常にブートストラップしてリモートの APB マニフェストを読み込むために、外部レジスターと通信できなければなりません。これらの要求はプロキシー経由で実行できますが、プロキシーでは必要なリモートホストにアクセスできるようにする必要があります。

必要なホワイトリスト化されたホストの例:

レジストリーアダプターのタイプホワイトリスト化されたホスト

rhcc

registry.access.redhat.comaccess.redhat.com

dockerhub

docker.io

6.10.2. Ansible を使用したプロキシー環境でのブローカーの設定

初期インストール時に OpenShift Container Platform クラスターがプロキシーの環境下で実行されるように設定した場合 (「グローバルプロキシーオプションの設定」を参照)、OAB はデプロイ時に以下を実行します。

  • クラスター全体のプロキシー設定を自動的に継承する
  • cidr フィールドおよび serviceNetworkCIDR を含む必要な NO_PROXY 一覧を生成する

それ以外の設定は必要ありません。

6.10.3. プロキシー環境でのブローカーの手動設定

クラスターのグローバルプロキシーオプションが初期インストール時またはブローカーのデプロイ前に設定されていない場合や、グローバルプロキシー設定を変更した場合、ブローカーの外部アクセスについてプロキシー経由で手動で設定する必要があります。

  1. OAB をプロキシー環境で実行する前に「HTTP プロキシーの使用」を確認し、クラスターがプロキシー環境で実行されるように適切に設定されていることを確認してください。

    特に、クラスターは内部クラスター要求をプロキシー処理しないように設定されている必要があります。通常、これは以下の NO_PROXY 設定を使用して設定されます。

    .cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.default

    その他の必要な NO_PROXY 設定も追加する必要があります。詳細については、「NO_PROXY の設定」を参照してください。

    注記

    バージョンなしまたは v1 の APB をデプロイするブローカーは、172.30.0.1NO_PROXY の一覧に追加する必要があります。v2 より前の APB は、シークレットの交換ではなく、exec HTTP 要求を使用して実行中の APB Pod から認証情報を抽出しました。実験的なプロキシーサポートがあるブローカーを OpenShift Container Platform 3.9 より前のクラスターで実行していない限り、この点を心配する必要はおそらくありません。

  2. ブローカーの DeploymentConfigcluster-admin 権限を持つユーザーとして編集します。

    $ oc edit dc/asb -n openshift-ansible-service-broker
  3. 以下の環境変数を設定します。

    • HTTP_PROXY
    • HTTPS_PROXY
    • NO_PROXY
    注記

    詳細については、「Pod でのプロキシー環境変数の設定」を参照してください。

  4. 更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。

    $ oc rollout latest dc/asb -n openshift-ansible-service-broker

6.10.4. Pod でのプロキシー環境変数の設定

一般に、APB Pod 自体もプロキシー経由の外部アクセスを必要とします。ブローカーは、自らにプロキシー設定があることを認識すると、生成する APB Pod にこれらの環境変数を透過的に適用します。APB 内で使用されるモジュールが環境変数経由でプロキシー設定に従う限り、APB もこれらの設定に基づいて動作します。

最後に、APB によって生成されたサービスもプロキシー経由の外部ネットワークアクセスを必要とする場合があります。APB は、それ自体の実行環境でこのようなサービスを検出した場合にこれらの環境変数を明示的に設定するように作成されている必要があります。そうでない場合には、クラスターオペレーターが必要なサービスを変更してそれらを環境に組み込む必要があります。

第7章 ホストの既存クラスターへの追加

7.1. ホストの追加

scaleup.yml Playbook を実行して新規ホストをクラスターに追加できます。この Playbook は、マスターをクエリーし、新規ホストの新規証明書を生成して配布し、これらの新規ホストでのみ、設定 Playbook を実行します。scaleup.yml Playbook を実行する前に、前提条件となる「ホストの準備」手順をすべて完了してください。

重要

scaleup.yml の Playbook は新規ホストの設定のみを実行します。マスターサービスの NO_PROXY の更新やマスターサービスの再起動は行いません。

scaleup.yml Playbook を実行するには、現在のクラスター設定を表す既存のインベントリーファイル (/etc/ansible/hosts など) が必要です。以前に atomic-openshift-installer コマンドを使用してインストールを実行した場合は、~/.config/openshift/hosts を調べて、インストーラーによって生成された最新のインベントリーファイルを見つけ、それをそのまま使用するか、必要に応じて、インベントリーファイルを変更することができます。その場合には、ansible-playbook を呼び出すときに、-i オプションを使用してそのファイルを指定する必要があります。

重要

推奨される最大ノード数については、「クラスターの制限」のセクションを参照してください。

手順

  1. atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。

    # yum update atomic-openshift-utils
  2. /etc/ansible/hosts ファイルを編集し、 new_<host_type>[OSEv3:children] セクションに追加します。

    たとえば、新規ノードホストを追加するには、new_nodes を追加します。

    [OSEv3:children]
    masters
    nodes
    new_nodes

    新規マスターホストを追加するには、new_masters を追加します。

  3. [new_<host_type>] セクションを作成して、新規ホストのホスト情報を指定します。このセクションは、以下の新規ノードの追加例で示されているように、既存のセクションと同じような形式で作成します。

    [nodes]
    master[1:3].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]
    node3.example.com openshift_node_group_name='node-config-infra'

    その他のオプションについては、「ホスト変数の設定」を参照してください。

    新規マスターを追加する場合は、[new_masters] セクションと [new_nodes] セクションの両方に新規ホストを追加して、新規マスターホストが OpenShift SDN の一部となるようにします。

    [masters]
    master[1:2].example.com
    
    [new_masters]
    master3.example.com
    
    [nodes]
    master[1:2].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]
    master3.example.com
    重要

    マスターホストに node-role.kubernetes.io/infra=true ラベルを付け、それ以外に専用インフラストラクチャーノードがない場合は、エントリーに openshift_schedulable=true を追加してホストにスケジュール可能であることを示すマークを明示的に付ける必要もあります。そうしないと、レジストリー Pod とルーター Pod をどこにも配置できなくなります。

  4. scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

    • ノードを追加する場合は、以下を指定します。

      # ansible-playbook [-i /path/to/file] \
          /usr/share/ansible/openshift-ansible/playbooks/openshift-node/scaleup.yml
    • マスターを追加する場合は、以下を実行します。

      # ansible-playbook [-i /path/to/file] \
          /usr/share/ansible/openshift-ansible/playbooks/openshift-master/scaleup.yml
  5. ノードラベルを logging-infra-fluentd: "true" に設定します。

    # oc label node/new-node.example.com logging-infra-fluentd: "true"
  6. Playbook の実行後に、インストールの検証を行います。
  7. [new_<host_type>] セクションで定義したホストを適切なセクションに移動します。このようにホストを移動することで、このインベントリーファイルを使用するその後の Playbook の実行で、正しくノードが処理されるようになります。[new_<host_type>] セクションは空のままで結構です。たとえば、新規ノードを追加する場合は以下のように指定します。

    [nodes]
    master[1:3].example.com
    node1.example.com openshift_node_group_name='node-config-compute'
    node2.example.com openshift_node_group_name='node-config-compute'
    node3.example.com openshift_node_group_name='node-config-compute'
    infra-node1.example.com openshift_node_group_name='node-config-infra'
    infra-node2.example.com openshift_node_group_name='node-config-infra'
    
    [new_nodes]

7.2. etcd ホストの既存クラスターへの追加

etcd scaleup Playbook を実行して新規 etcd ホストを追加することができます。この Playbook は、マスターをクエリーし、新規ホストの新規証明書を生成してこれを配布し、設定 Playbook を新規ホストにのみ実行します。etcd scaleup.yml Playbook を実行する前に、前提条件となる「ホストの準備」の手順をすべて完了してください。

etcd ホストを既存クラスターに追加するには、以下を実行します。

  1. atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。

    $ yum update atomic-openshift-utils
  2. /etc/ansible/hosts ファイルを編集し、new_<host_type>[OSEv3:children] グループに、ホストを new_<host_type> グループに追加します。

    たとえば、新規 etcd を追加するには、new_etcd を追加します。

    [OSEv3:children]
    masters
    nodes
    etcd
    new_etcd
    
    [etcd]
    etcd1.example.com
    etcd2.example.com
    
    [new_etcd]
    etcd3.example.com
  3. etcd scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、-i オプションで場所を指定します。

    $ ansible-playbook [-i /path/to/file] \
      /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/scaleup.yml
  4. Playbook が正常に完了したら、インストールの検証を行います。

7.3. 共存する etcd での既存のマスターの置き換え

マシンを別のデータセンターに移行し、割り当てられているネットワークと IP が変更される場合には、以下の手順を実行します。

  1. プライマリー「etcd」と「マスター」ノードをバックアップします。

    重要

    etcd バックアップ」の説明にあるように、/etc/etcd/ ディレクトリーがバックアップされていることを確認します。

  2. 置き換えるマスターの数だけ、新規マシンをプロビジョニングします。
  3. クラスターを追加または拡張します。たとえば、etcd が共存するマスターを 3 つ追加する場合には、マスターノード 3 つに拡張します。
重要

OpenShift Container Platform バージョン 3.11 の初期リリースについては、scaleup.yml Playbook は etcd をスケールアップしません。これについては、BZ#1628201 にて今後のリリースで修正されます。

  1. マスターを追加します。このプロセスのステップ 3 で、[new_masters][new_nodes] に新規データセンターのホストを追加して、マスターの scaleup.yml Playbook を実行します。
  2. 同じホストを「etcd」セクションに配置して、etcd scaleup.yml Playbook を実行します。
  3. ホストが追加されたことを確認します。

    # oc get nodes
  4. マスターホストの IP が追加されたことを確認します。

    # oc get ep kubernetes
  5. etcd が追加されたことを確認します。ETCDCTL_API の値は、使用するバージョンにより異なります。

    # source /etc/etcd/etcd.conf
    # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
  6. /etc/origin/master ディレクトリーから、インベントリーファイルの最初に記載されている新規マスターホストに、/etc/origin/master/ca.serial.txt をコピーします。デフォルトでは、これは /etc/ansible/hosts です。

    1. etcd ホストを削除します。
  7. /etc/etcd/ca ディレクトリーを、インベントリーファイルの最初に記載されている新規 etcd ホストにコピーします。デフォルトでは、これは /etc/ansible/hosts です。
  8. master-config.yaml ファイルから以前の etcd クライアントを削除します。

    # grep etcdClientInfo -A 11 /etc/origin/master/master-config.yaml
  9. マスターを再起動します。

    # master-restart api
    # master-restart controllers
  10. クラスターから以前の etcd メンバーを削除します。ETCDCTL_API の値は、使用するバージョンにより異なります。

    # source /etc/etcd/etcd.conf
    # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
  11. 上記のコマンドの出力から ID を取得して、この ID で以前のメンバーを削除します。

    # etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
      --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227
  12. etcd Pod 定義を削除し、古い etcd ホストで etcd サービスを停止します。

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    1. 定義ファイルを静的 Pod のディレクトリー /etc/origin/node/pods から移動して、古いマスター API およびコントローラーサービスをシャットダウンします。

      # mkdir -p /etc/origin/node/pods/disabled
      # mv /etc/origin/node/pods/controller.yaml /etc/origin/node/pods/disabled/:
    2. ネイティブのインストールプロセス時に、デフォルトでロードバランサーとしてインストールされていたマスターノードを、HA プロキシー設定から削除します。
    3. マシンの使用を停止します。
  13. etcd Pod 定義を削除し、ホストを再起動して、削除されるマスターでノードサービスを停止します。

    # mkdir -p /etc/origin/node/pods-stopped
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-stopped/
    # reboot
  14. ノードリソースを削除します。

    # oc delete node

7.4. ノードの移行

ノード上のサービスの実行方法やスケーリング方法、慣れた方法により、ノードを個別での移行や、グループ (2、5、10 ずつなど) 単位での移行が可能です。

  1. 移行するノードについては、新規データセンターのノードで使用するために新規の仮想マシンをプロビジョニングします。
  2. 新規ノードを追加するには、インフラストラクチャーを拡張します。新規ノードのラベルが適切に設定されており、新規 API サーバーがロードバランサーに追加され、トラフィックを適切に送信していることを確認します。
  3. 評価および縮小を実行します。

    1. 現在のノード (古いデータセンター内にある) に「スケジュール対象外」のマークを付けます。
    2. ノードの退避を実行し、ノード上の Pod が他のノードにスケジュールされるようにします。
    3. 退避したサービスが新規ノードで実行されていることを確認します。
  4. ノードを削除します。

    1. ノードが空であり、実行中のプロセスがないことを確認します。
    2. サービスを停止するか、またはノードを削除します。

第8章 デフォルトのイメージストリームとテンプレートの追加

8.1. 概要

x86_64 アーキテクチャーのサーバーに OpenShift Container Platform をインストールしている場合、クラスターには Red Hat が提供するイメージストリームおよびテンプレートの便利なセットが含まれます。これにより、開発者は新規アプリケーションを簡単に作成することができます。デフォルトで、クラスターインストールプロセスは、すべてのユーザーが表示アクセスを持つデフォルトのグローバルプロジェクトである openshift プロジェクトにこれらのセットを自動的に作成します。

IBM POWER アーキテクチャーのサーバーに OpenShift Container Platform をインストールしている場合には、イメージストリームおよびテンプレートをクラスターに追加することができます。

8.2. サブスクリプションタイプ別のサービス

お使いの Red Hat アカウントのアクティブなサブスクリプションに応じて、以下のイメージストリームとテンプレートのセットが Red Hat によって提供され、サポートされます。サブスクリプションの詳細については、Red Hat の営業担当者にお問い合わせください。

8.2.1. OpenShift Container Platform サブスクリプション

アクティブな OpenShift Container Platform サブスクリプション により、イメージストリームとテンプレートのコアのセットが提供され、サポートされます。これには以下のテクノロジーが含まれます。

種類テクノロジー

言語とフレームワーク

データベース

ミドルウェアサービス

他のサービス

8.2.2. xPaaS ミドルウェアアドオンサブスクリプション

xPaaS ミドルウェアイメージのサポートは、xPaaS ミドルウエアアドオンサブスクリプション で提供されます。これらのサブスクリプションは、xPaaS 製品ごとに独立したサブスクリプションとなっています。お使いのアカウントで該当するサブスクリプションがアクティブになっている場合は、以下のテクノロジーのイメージストリームとテンプレートが提供され、サポートされます。

8.3. 作業を開始する前に

このトピックのタスクの実行を検討する前に、以下のいずれかを実行してこれらのイメージストリームとテンプレートが OpenShift Container Platform クラスターにすでに登録されているかどうかを確認してください。

  • Web コンソールにログインして Add to Project をクリックします。
  • CLI を使用して openshift プロジェクト用のイメージストリームとテンプレートの一覧を表示します。

    $ oc get is -n openshift
    $ oc get templates -n openshift

デフォルトのイメージストリームとテンプレートが削除または変更されている場合は、このトピックに従ってデフォルトのオブジェクトを各自で作成できます。そうしない場合は、以下の指示に従う必要はありません。

8.4. 前提条件

デフォルトのイメージストリームとテンプレートを作成する前に、以下を確認してください。

  • 統合 Docker レジストリーサービスが OpenShift Container Platform インストールにデプロイされている必要があります。
  • oc create コマンドを cluster-admin 権限で実行できる必要があります。デフォルトの openshift プロジェクト で動作できるようにするためです。
  • atomic-openshift-utils RPM パッケージがインストールされている必要があります。手順については、「ソフトウェアの前提条件」を参照してください。
  • イメージストリームとテンプレートが含まれているディレクトリーのシェル変数を定義します。これにより、以降のセクションで使用するコマンドが大幅に短くなります。これを実行するには、以下のように入力します。

    • x86_64 サーバーでのクラウドインストールおよびオンプレミスインストールの場合は、以下のようになります。
$ IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.10/image-streams"; \
    XPAASSTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.10/xpaas-streams"; \
    XPAASTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.10/xpaas-templates"; \
    DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.10/db-templates"; \
    QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.10/quickstart-templates"
  • IBM POWER8 または IBM POWER9 サーバーでのオンプレミスインストールの場合は、以下のようになります。
IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/image-streams"; \
    DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/db-templates"; \
    QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/ppc64le/quickstart-templates"

8.5. OpenShift Container Platform イメージのイメージストリームの作成

Red Hat サブスクリプションマネージャーで、ノードのホストをサブスクライブしており、Red Hat Enterprise Linux (RHEL) 7 ベースのイメージを使用したイメージストリームのコアセットを使用する場合には、以下を実行します。

$ oc create -f $IMAGESTREAMDIR/image-streams-rhel7.json -n openshift

または、CentOS 7 ベースのイメージを使用するイメージストリームのコアセットを作成するには、以下を実行します。

$ oc create -f $IMAGESTREAMDIR/image-streams-centos7.json -n openshift

CentOS と RHEL の両方のイメージストリームセットは同じ名前なので、両方を作成することはできません。両方のイメージストリームセットをユーザーが使用できるようにするには、一方のセットを別のプロジェクトに作成するか、いずれかのファイルを編集し、イメージストリームの名前を一意の名前に変更します。

8.6. xPaaS ミドルウェアイメージのイメージストリームの作成

xPaaS ミドルウェアイメージストリームは、JBoss EAPJBoss JWSJBoss A-MQJBoss Fuse Integration ServicesDecision ServerJBoss Data Virtualization、および JBoss Data Grid のイメージを提供します。それらのイメージは、提供されるテンプレートを使用してこれらのプラットフォームのアプリケーションを作成するために使用できます。

xPaaS ミドルウェアイメージストリームセットを作成するには、以下を実行します。

$ oc create -f $XPAASSTREAMDIR/jboss-image-streams.json -n openshift
注記

これらのイメージストリームによって参照されるイメージにアクセスするには、該当する xPaaS ミドルウェアサブスクリプションが必要です。

8.7. データベースサービステンプレートの作成

データベースサービステンプレートを使用すると、他のコンポーネントで利用できるデータベースイメージを簡単に実行できます。データベース (MongoDBMySQL、および PostgreSQL) ごとに、2 つのテンプレートが定義されています。

1 つのテンプレートはコンテナー内の一時ストレージを使用します。つまり、保存データは Pod の移動などによってコンテナーが再起動されると失われます。このテンプレートは、デモ目的にのみ使用してください。

もう 1 つのテンプレートは永続ボリュームをストレージに使用しますが、OpenShift Container Platform インストールに永続ボリュームが設定されている必要があります。

データベーステンプレートのコアセットを作成するには、以下を実行します。

$ oc create -f $DBTEMPLATES -n openshift

テンプレートを作成したら、ユーザーは各種のテンプレートを簡単にインスタンス化し、データベースデプロイメントにすばやくアクセスできるようになります。

8.8. インスタントアプリケーションおよびクイックスタートテンプレートの作成

インスタントアプリケーションおよびクイックスタートテンプレートでは、実行中のアプリケーションのオブジェクトの完全なセットを定義します。これには以下が含まれます。

  • GitHub パブリックリポジトリーにあるソースからアプリケーションをビルドするためのビルド設定
  • ビルド後にアプリケーションイメージをデプロイするためのデプロイメント設定
  • アプリケーション Pod に負荷分散を提供するサービス
  • アプリケーションに外部アクセスを提供するルート

いくつかのテンプレートでは、アプリケーションがデータベース操作を実行できるように、データベースデプロイメントとサービスも定義します。

注記

データベースを定義するテンプレートでは、一時ストレージを使用してデータベースコンテンツを格納します。何らかの理由でデータベース Pod が再起動すると、すべてのデータベースデータが失われるため、これらのテンプレートはデモ目的にのみ使用してください。

これらのテンプレートを使用すると、ユーザーは、OpenShift Container Platform で提供される各種の言語イメージを使用する完全なアプリケーションを簡単にインスタンス化できます。また、インストール時にテンプレートのパラメーターをカスタマイズし、サンプルリポジトリーではなく独自のリポジトリーからソースがビルドされるようにできます。つまり、これは新規アプリケーションのビルドの単純な開始点となります。

コアのインスタントアプリケーションおよびクイックスタートテンプレートを作成するには、以下を実行します。

$ oc create -f $QSTEMPLATES -n openshift

各種の xPaaS ミドルウェア製品 (JBoss EAPJBoss JWSJBoss A-MQJBoss Fuse Integration ServicesDecision Server、および JBoss Data Grid) を使用するアプリケーションを作成するためのテンプレートのセットも用意されています。このテンプレートセットを登録するには、以下を実行します。

$ oc create -f $XPAASTEMPLATES -n openshift
注記

xPaaS ミドルウェアテンプレートには、xPaaS ミドルウェアイメージストリームが必要です。さらに、xPaaS ミドルウェアイメージストリームには、該当する xPaaS ミドルウェアサブスクリプションが必要です。

注記

データベースを定義するテンプレートでは、一時ストレージを使用してデータベースコンテンツを格納します。何らかの理由でデータベース Pod が再起動すると、すべてのデータベースデータが失われるため、これらのテンプレートはデモ目的にのみ使用してください。

8.9. 次のステップ

これらのアーティファクトを作成したら、開発者は「Web コンソール」にログインし、「テンプレートからの作成」フローを実行できるようになります。任意のデータベースまたはアプリケーションテンプレートを選択し、現在のプロジェクトで実行するデータベースサービスまたはアプリケーションを作成できます。一部のアプリケーションテンプレートでは独自のデータベースサービスも定義することに注意してください。

サンプルアプリケーションはすべて、SOURCE_REPOSITORY_URL パラメーター値が示すように、テンプレートのデフォルトの参照先である GitHub リポジトリーからビルドされます。これらのリポジトリーはフォークすることができ、テンプレートから作成する際にフォークを SOURCE_REPOSITORY_URL パラメーター値として指定できます。これにより、開発者は独自のアプリケーションの作成を試行することができます。

開発者は、開発者ガイドの「インスタントアプリおよびクイックスタートテンプレートの使用」セクションでこれらの手順を確認できます。

第9章 カスタム証明書の設定

9.1. 概要

管理者は、OpenShift Container Platform API のパブリックホスト名および Web コンソール用のカスタム提供証明書を設定できます。この設定は、クラスターインストールの実行時か、またはインストール後に行うことができます。

9.2. インストール時のカスタム証明書の設定

クラスターインストールの実行時に、カスタム証明書はインベントリーファイルで設定可能な openshift_master_named_certificates パラメーターと openshift_master_overwrite_named_certificates パラメーターを使用して設定できます。詳細については、「Ansible を使用したカスタム証明書の設定」を参照してください。

カスタム証明書の設定パラメーター

openshift_master_overwrite_named_certificates=true 1
openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}] 2
openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} 3

1
openshift_master_named_certificates パラメーターの値を指定した場合は、このパラメーターを true に設定します。
2
マスター API 証明書をプロビジョニングします。
3
ワイルドカード API 証明書をプロビジョニングします。

以下は、マスター API 証明書のパラメーターの例です。

openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master-bundle.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem" ]

以下は、ワイルドカード API 証明書のパラメーターの例です。

openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}

9.3. Web コンソールまたは CLI 用カスタム証明書の設定

Web コンソールおよび CLI 用のカスタム証明書は、「マスター設定ファイル」の servingInfo セクションで指定できます。

  • servingInfo.namedCertificates セクションでは、Web コンソール用のカスタム証明書を指定します。
  • servingInfo セクションでは、CLI およびその他の API 呼び出し用のカスタム証明書を指定します。

この方法で複数の証明書を設定し、それぞれの証明書を複数のホスト名複数のルーター、または OpenShift Container Platform イメージレジストリーに関連付けることができます。

デフォルトの証明書は、namedCertificates のほかにも servingInfo.certFile および servingInfo.keyFile 設定セクションに設定する必要があります。

注記

namedCertificates セクションは、/etc/origin/master/master-config.yaml ファイルの masterPublicURL および oauthConfig.assetPublicURL 設定に関連付けられたホスト名についてのみ設定する必要があります。masterURL に関連付けられたホスト名にカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API と通信しようとするため、TLS エラーが発生します。

カスタム証明書の設定

servingInfo:
  logoutURL: ""
  masterPublicURL: https://openshift.example.com:8443
  publicURL: https://openshift.example.com:8443/console/
  bindAddress: 0.0.0.0:8443
  bindNetwork: tcp4
  certFile: master.server.crt 1
  clientCA: ""
  keyFile: master.server.key 2
  maxRequestsInFlight: 0
  requestTimeoutSeconds: 0
  namedCertificates:
    - certFile: wildcard.example.com.crt 3
      keyFile: wildcard.example.com.key 4
      names:
        - "openshift.example.com"
  metricsPublicURL: "https://metrics.os.example.com/hawkular/metrics"

1 2
CLI およびその他の API 呼び出し用の証明書とキーファイルへのパス。
3 4
Web コンソール用の証明書とキーファイルへのパス。

Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) の openshift_master_cluster_public_hostname パラメーターと openshift_master_cluster_hostname パラメーターは異なっていなければなりません。これらが同じであると、名前付き証明書が失敗し、証明書の再インストールが必要になります。

# Native HA with External LB VIPs
openshift_master_cluster_hostname=internal.paas.example.com
openshift_master_cluster_public_hostname=external.paas.example.com

OpenShift Container Platform で DNS を使用する方法の詳細については、「DNS のインストールの前提条件」を参照してください。

この方法では、OpenShift Container Platformによって生成される自己署名証明書を利用して、必要に応じて信頼できるカスタム証明書を個々のコンポーネントに追加できます。

内部インフラストラクチャーの証明書は自己署名のままであることに注意してください。これは一部のセキュリティーチームや PKI チームから不適切な使用法と見なされる場合があります。ただし、これらの証明書を信頼するクライアントはクラスター内のその他のコンポーネントだけであるため、これに伴うリスクは最小限です。外部のユーザーとシステムはすべて、信頼できるカスタム証明書を使用します。

相対パスは、マスター設定ファイルの場所に基づいて解決されます。設定の変更が反映されるようにサーバーを再起動します。

9.4. カスタムマスターホスト証明書の設定

OpenShift Container Platform の外部ユーザーとの信頼できる接続を容易にするために、Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) の openshift_master_cluster_public_hostname パラメーターで指定されたドメイン名に一致する名前付き証明書をプロビジョニングできます。

この証明書は Ansible がアクセスできるディレクトリーに置き、以下のように Ansible インベントリーファイルにパスを追加する必要があります。

openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]

パラメーター値は以下のようになります。

  • certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
  • keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
  • names は、クラスターのパブリックホスト名です。

ファイルパスは、Ansible が実行されるシステムにとってローカルでなければなりません。証明書はマスターホストにコピーされ、/etc/origin/master ディレクトリー内にデプロイされます。

レジストリーのセキュリティーを保護する場合、サービスのホスト名と IP アドレスをレジストリーのサーバー証明書に追加します。SAN (Subject Alternative Name) には以下の情報が含まれている必要があります。

  • 2 つのサービスホスト名。

    docker-registry.default.svc.cluster.local
    docker-registry.default.svc
  • サービス IP アドレス。

    以下は例を示しています。

    172.30.252.46

    以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。

    oc get service docker-registry --template='{{.spec.clusterIP}}'
  • パブリックホスト名。

    docker-registry-default.apps.example.com

    以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。

    oc get route docker-registry --template '{{.spec.host}}'

たとえば、サーバー証明書には以下のような SAN の詳細が記載されるはずです。

X509v3 Subject Alternative Name:
               DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98

9.5. デフォルトルーター用のカスタムワイルドカード証明書の設定

OpenShift Container Platform のデフォルトルーターをデフォルトのワイルドカード証明書を使って設定できます。デフォルトのワイルドカード証明書を使用すると、OpenShift Container Platform にデプロイされているアプリケーションでカスタム証明書を使用せずにデフォルトの暗号化を簡単に使用することができます。

注記

デフォルトのワイルドカード証明書の使用は、非実稼働環境でのみ推奨されます。

デフォルトのワイルドカード証明書を設定するには、.<app_domain> で有効な証明書をプロビジョニングします。ここで、<app_domain> は、Ansible インベントリーファイル(デフォルトでは /etc/ansible/hosts) の openshift_master_default_subdomain の値です。プロビジョニングが完了したら、証明書、キー、CA 証明書ファイルを Ansible ホストに置き、以下の行を Ansible インベントリーファイルに追加します。

openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}

以下は例を示しています。

openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}

パラメーター値は以下のようになります。

  • certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
  • keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
  • cafile は、このキーと証明書のルート CA を含むファイルへのパスです。中間 CA を使用している場合は、中間 CA とルート CA の両方がこのファイルに含まれている必要があります。

これらの証明書ファイルを OpenShift Container Platform クラスターで初めて使用する場合は、Ansible deploy_router.yml Playbook を実行し、これらのファイルを OpenShift Container Platform 設定ファイルに追加します。この Playbook は、証明書ファイルを /etc/origin/master/ ディレクトリーに追加します。

# ansible-playbook [-i /path/to/inventory] \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/deploy_router.yml

これらの証明書を使用するのが初めてでない場合、たとえば、既存の証明書を変更するか、期限切れの証明書を置き換える場合は、以下の Playbook を実行します。

ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
注記

この Playbook を実行する場合は、証明書名を変更しないでください。証明書名を変更した場合は、新規証明書の場合と同様に Ansible deploy_cluster.yml Playbook を再実行してください。

9.6. イメージレジストリー用のカスタム証明書の設定

OpenShift Container Platform イメージレジストリーは、ビルドとデプロイメントを容易にする内部サービスです。レジストリーとの通信の大部分は、OpenShift Container Platform の内部コンポーネントによって処理されます。そのため、レジストリーサービス自体が使用する証明書を置き換える必要はありません。

ただし、デフォルトでは、レジストリーは、外部のシステムとユーザーがイメージのプルとプッシュを実行できるルートを使用します。内部の自己署名証明書を使用する代わりに、外部ユーザーに提供されるカスタム証明書を使用してre-encrypt ルートを使用することができます。

これを設定するには、コードの以下の行を、Ansible インベントリーファイル (デフォルトは /etc/ansible/hosts ファイルの [OSEv3:vars] セクションに追加します。レジストリールートで使用する証明書を指定します。

openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com 1
openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"} 2
openshift_hosted_registry_routetermination=reencrypt 3
1
レジストリーのホスト名です。
2
cacertroot、および cafile ファイルの場所です。
  • certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
  • keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
  • cafile は、このキーと証明書のルート CA を含むファイルへのパスです。中間 CA を使用している場合は、中間 CA とルート CA の両方がこのファイルに含まれている必要があります。
3
暗号化を実行する場所を指定します。
  • edge ルーターで暗号化を終了し、送信先から提供される新規の証明書で再暗号化するには、 reencrypt に設定し、re-encrypt ルートを指定します。
  • 送信先で暗号化を終了するには、passthrough に設定します。トラフィックは送信先で復号化されます。

9.7. ロードバランサー用のカスタム証明書の設定

OpenShift Container Platform クラスターでデフォルトのロードバランサーか、またはエンタープライズレベルのロードバランサーを使用している場合、カスタム証明書の使用により、 パブリックに署名されたカスタム証明書を使って Web コンソールと API を外部で利用できるようにし、既存の内部証明書を内部のエンドポイント用に残しておくことができます。

カスタム証明書をこの方法で使用するように OpenShift Container Platform を設定するには、以下を実行します。

  1. マスター設定ファイルservingInfo セクションを編集します。

    servingInfo:
      logoutURL: ""
      masterPublicURL: https://openshift.example.com:8443
      publicURL: https://openshift.example.com:8443/console/
      bindAddress: 0.0.0.0:8443
      bindNetwork: tcp4
      certFile: master.server.crt
      clientCA: ""
      keyFile: master.server.key
      maxRequestsInFlight: 0
      requestTimeoutSeconds: 0
      namedCertificates:
        - certFile: wildcard.example.com.crt 1
          keyFile: wildcard.example.com.key 2
          names:
            - "openshift.example.com"
      metricsPublicURL: "https://metrics.os.example.com/hawkular/metrics"
    1
    Web コンソールの証明書ファイルへのパスです。
    2
    Web コンソールのキーファイルへのパスです。
    注記

    masterPublicURL および oauthConfig.assetPublicURL 設定に関連付けられたホスト名についてのみ namedCertificates セクションを設定します。masterURL に関連付けられたホスト名にカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API と通信しようとするため、TLS エラーが発生します。

  2. Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) で openshift_master_cluster_public_hostname パラメーターと openshift_master_cluster_hostname パラメーターを指定します。これらの値は異なっていなければなりません。同じ値を指定した場合、名前付き証明書が失敗します。

    # Native HA with External LB VIPs
    openshift_master_cluster_hostname=paas.example.com 1
    openshift_master_cluster_public_hostname=public.paas.example.com 2
    1
    SSL パススルー用に設定された内部ロードバランサーの FQDN です。
    2
    カスタム (パブリック) 証明書を使用する外部ロードバランサーの FQDN です。

お使いのロードバランサー環境に固有の情報については、お使いのプロバイダーについての OpenShift Container Platform リファレンスアーキテクチャーと「Custom Certificate SSL Termination (Production)」を参照してください。

9.8. カスタム証明書の変更およびクラスターへの組み込み

カスタムマスター証明書とカスタムルーター証明書を変更して、既存の OpenShift Container Platform クラスターに組み込むことができます。これを行うには、Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) を編集し、Playbook を実行します。

9.8.1. カスタムマスター証明書の変更およびクラスターへの組み込み

カスタム証明書を変更するには、以下を実行します。

  1. Ansible インベントリーファイルを編集して openshift_master_overwrite_named_certificates=true を設定します。
  2. openshift_master_named_certificates パラメーターを使用して証明書へのパスを指定します。

    openshift_master_overwrite_named_certificates=true
    openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}] 1
    1
    マスター API 証明書へのパスです。
  3. 以下の Playbook を実行します。

    ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml

9.8.2. カスタムルーター証明書の変更およびクラスターへの組み込み

カスタムルーター証明書を変更し、これを組み込むには、以下を実行します。

  1. Ansible インベントリーファイルを編集して openshift_master_overwrite_named_certificates=true を設定します。
  2. openshift_hosted_router_certificate パラメーターを使用して証明書へのパスを指定します。

    openshift_master_overwrite_named_certificates=true
    openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} 1
  3. 以下の Playbook を実行します。

    ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml

9.9. 他のコンポーネントでのカスタム証明書の使用

ロギングやメトリクスなどのその他のコンポーネントでカスタム証明書を使用する方法については、「Certificate Management」を参照してください。

第10章 証明書の再デプロイ

10.1. 概要

OpenShift Container Platform は、以下のコンポーネントで証明書を使用してセキュアな接続を提供します。

  • マスター (API サーバーとコントローラー)
  • etcd
  • ノード
  • レジストリー
  • ルーター

インストーラーによって提供される Ansible Playbook を使用すると、クラスター証明書の有効期限を自動的にチェックできます。これらの証明書を自動的にバックアップしたり、再デプロイしたりするための Playbook も提供されます。これらの Playbook を使用すると、一般的な証明書エラーを修正できます。

証明書の再デプロイのユースケースとして以下が考えられます。

  • インストーラーによって誤ったホスト名が検出され、そのことがすぐに判明しなかった。
  • 証明書の有効期限が切れており、証明書を更新する必要がある。
  • 新しい CA があり、その CA を代わりに使用する証明書を作成する。

10.2. 証明書の有効期限のチェック

インストーラーを使用して、設定可能な日数内に有効期限が切れる証明書に関する警告やすでに有効期限が切れた証明書に関する通知を受け取ることができます。証明書の有効期限切れ Playbook では、Ansible の openshift_certificate_expiry ロールが使用されます。

ロールによって検査される証明書には、以下が含まれます。

  • マスターおよびノードサービス証明書
  • etcd シークレットのルーターおよびレジストリーサービス証明書
  • マスター、ノード、ルーター、レジストリー、および cluster-admin ユーザーの kubeconfig ファイル
  • etcd 証明書 (組み込み証明書を含む)

10.2.1. ロール変数

openshift_certificate_expiry ロールは、以下の変数を使用します。

表10.1 コア変数

変数名デフォルト値説明

openshift_certificate_expiry_config_base

/etc/origin

OpenShift Container Platform 基本設定ディレクトリーです。

openshift_certificate_expiry_warning_days

30

現在を起点として指定された日数内に有効期限が切れる証明書にフラグを付けます。

openshift_certificate_expiry_show_all

no

正常な (期限切れや警告のない) 証明書を結果に組み込みます。

表10.2 オプションの変数

変数名デフォルト値説明

openshift_certificate_expiry_generate_html_report

no

有効期限切れのチェック結果に関する HTML レポートを生成します。

openshift_certificate_expiry_html_report_path

/tmp/cert-expiry-report.html

HTML レポートを保存するための完全パスです。

openshift_certificate_expiry_save_json_results

no

有効期限のチェック結果を JSON ファイルとして保存します。

openshift_certificate_expiry_json_results_path

/tmp/cert-expiry-report.json

JSON レポートを保存するための完全パスです。

10.2.2. 証明書の有効期限切れ Playbook の実行

OpenShift Container Platform インストーラーは、openshift_certificate_expiry ロールのさまざまな設定セットを使用して証明書の有効期限切れ Playbook のサンプル一式を提供します。

これらの Playbook は、クラスターを表す インベントリーファイルと一緒に使用する必要があります。最適な結果を得るには、ansible-playbook-v オプションを指定して実行します。

easy-mode.yaml のサンプル Playbook を使用すると、ロールアウトを仕様に合わせて調整する前に試すことができます。この Playbook は以下を実行します。

  • JSON レポートと定型化された HTML レポートを /tmp/ に生成します。
  • ほぼ常に結果が得られるように警告期間を長い期間に設定します。
  • すべての証明書 (正常であるかどうかを問わず) を結果に組み込みます。

easy-mode.yaml Playbook

- name: Check cert expirys
  hosts: nodes:masters:etcd
  become: yes
  gather_facts: no
  vars:
    openshift_certificate_expiry_warning_days: 1500
    openshift_certificate_expiry_save_json_results: yes
    openshift_certificate_expiry_generate_html_report: yes
    openshift_certificate_expiry_show_all: yes
  roles:
    - role: openshift_certificate_expiry

easy-mode.yaml Playbook を実行するには、以下を実行します。

$ ansible-playbook -v -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/easy-mode.yaml
他のサンプル Playbook

その他のサンプル Playbook も /usr/share/ansible/openshift-ansible/playbooks/certificate_expiry/ ディレクトリーから直接実行できます。

表10.3 他のサンプル Playbook

ファイル名使用法

default.yaml

openshift_certificate_expiry ロールのデフォルトの動作を生成します。

html_and_json_default_paths.yaml

HTML および JSON アーティファクトをデフォルトのパスに生成します。

longer_warning_period.yaml

有効期限切れの警告期間を 1500 日に変更します。

longer-warning-period-json-results.yaml

有効期限切れの警告期間を 1500 日に変更し、結果を JSON ファイルとして保存します。

これらのサンプル Playbook を実行するには、以下を実行します。

$ ansible-playbook -v -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/<playbook>

10.2.3. 出力形式

上述のように、チェックレポートは 2 つの形式で出力できます。機械の解析に適した JSON 形式と簡単にスキミングできる定型化された HTML ページを使用できます。

HTML レポート

インストーラーには、HTML レポートのサンプルが付属しています。以下のファイルをブラウザーで開いて表示できます。

/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.html

JSON レポート

保存された JSON の結果には、datasummary の 2 つの最上位のキーがあります。

data キーは、検証された各ホストの名前がキーとして、該当するホストごとに特定された証明書の確認結果が値として含まれるハッシュです。

summary キーは、以下の条件に当てはまる証明書の合計数をまとめたハッシュです。

  • クラスター全体で検査済み
  • 問題なし
  • 設定された警告期間内に有効期限が切れる
  • すでに有効期限が切れている

完全な JSON レポートのサンプルについては、/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.json を参照してください。

JSON データのサマリーでは、さまざまなコマンドラインツールを使用して警告や有効期限を簡単にチェックできます。たとえば、grep を使用して summary という語を検索し、一致した箇所の後ろの 2 行を出力できます (-A2)。

$ grep -A2 summary /tmp/cert-expiry-report.json
    "summary": {
        "warning": 16,
        "expired": 0

また、jq ツールが使用可能な場合は、このツールを使用して特定の値を選択できます。以下の最初の 2 つの例は、warning または expired のいずれかの値を選択する方法を示しています。3 つ目の例は、両方の値を一度に選択する方法を示しています。

$ jq '.summary.warning' /tmp/cert-expiry-report.json
16

$ jq '.summary.expired' /tmp/cert-expiry-report.json
0

$ jq '.summary.warning,.summary.expired' /tmp/cert-expiry-report.json
16
0

10.3. 証明書の再デプロイ

該当するすべてのホストにマスター、etcd、ノード、レジストリーまたはルーター証明書を再デプロイするには、以下の Playbook を使用します。現在の CA を使用してこれらすべての証明書を一度に再デプロイすることも、特定のコンポーネント用の証明書のみを再デプロイすることも、新しく生成された CA またはカスタム CA 自体を再デプロイすることもできます。

証明書の有効期限切れ Playbook と同様に、これらの Playbook はクラスターを表すインベントリーファイルを使用して実行する必要があります。

特にインベントリーでは、すべてのホスト名と IP アドレスが現在のクラスター設定に一致するように、以下の変数でそれらを指定するか、または上書きする必要があります。

  • openshift_public_hostname
  • openshift_public_ip
  • openshift_master_cluster_hostname
  • openshift_master_cluster_public_hostname

以下のコマンドを実行すると、必要な Playbook が利用できるようになります。

# yum install atomic-openshift-utils
注記

再デプロイ中に自動生成された証明書の有効性 (有効期限が切れるまでの日数) も Ansible で設定できます。「証明書の有効性の設定」を参照してください。

注記

OpenShift Container Platform CA および etcd 証明書の有効期限は 5 年です。署名付きの OpenShift Container Platform 証明書の有効期限は 2 年です。

10.3.1. 現行の OpenShift Container Platform および etcd CA を使用したすべての証明書の再デプロイ

redeploy-certificates.yml Playbook は、OpenShift Container Platform CA 証明書を再生成しません。新しいマスター 、etcd、ノード、レジストリー、およびルーター証明書は、新規の証明書に署名するために現在の CA 証明書を使用して作成されます。

これには、以下の順次の再起動も伴います。

  • etcd
  • マスターサービス
  • ノードサービス

現行の OpenShift Container Platform CA を使用してマスター、etcd、およびノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml

10.3.2. 新規またはカスタムの OpenShift Container Platform CA の再デプロイ

openshift-master/redeploy-openshift-ca.yml Playbook は、新規の CA 証明書を生成し、クライアントの kubeconfig ファイルとノードの信頼できる CA のデータベース (CA-trust) を含むすべてのコンポーネントに更新されたバンドルを配布することによって OpenShift Container Platform CA 証明書を再デプロイします。

これには、以下の順次の再起動も伴います。

  • マスターサービス
  • ノードサービス
  • Docker

さらに、証明書を再デプロイする際には、OpenShift Container Platform によって生成される CA を使用する代わりに、カスタム CA 証明書を指定することもできます。

マスターサービスが再起動すると、レジストリーとルーターは、再デプロイされなくてもマスターと引き続き通信できます。これは、マスターの提供証明書が同一であり、レジストリーとルーターの CA が依然として有効であるためです。

新たに生成される CA またはカスタム CA を再デプロイするには、以下を実行します。

  1. オプションで、カスタム CA を指定します。カスタム CA パラメーター openshift_master_ca_certificate の一部として指定する certfile には、OpenShift Container Platform 証明書に署名する単一証明書のみが含まれる必要があります。チェーンに中間証明書が含まれる場合、それらを別のファイルにバンドルする必要があります。

    1. 中間証明書なしで CA を指定するには、インベントリーファイルに以下の変数を指定します。

      # Configure custom ca certificate
      # NOTE: CA certificate will not be replaced with existing clusters.
      # This option may only be specified when creating a new cluster or
      # when redeploying cluster certificates with the redeploy-certificates
      # playbook.
      openshift_master_ca_certificate={'certfile': '</path/to/ca.crt>', 'keyfile': '</path/to/ca.key>'}
    2. 中間 CA によって発行された CA 証明書を指定するには、以下を実行します。

      1. CA の中間およびルート証明書の詳細チェーンが含まれるバンドルされた証明書を作成します。

        # cat intermediate/certs/<intermediate.cert.pem> \
              certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem
      2. 以下の変数をインベントリーファイルに設定します。

        # Configure custom ca certificate
        # NOTE: CA certificate will not be replaced with existing clusters.
        # This option may only be specified when creating a new cluster or
        # when redeploying cluster certificates with the redeploy-certificates
        # playbook.
        openshift_master_ca_certificate={'certfile': '</path/to/ca.crt>', 'keyfile': '</path/to/ca.key>'}
        openshift_additional_ca=intermediate/certs/ca-chain.cert.pem
  2. openshift-master/redeploy-openshift-ca.yml Playbook を実行し、インベントリーファイルを指定します。

    $ ansible-playbook -i <inventory_file> \
        /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-openshift-ca.yml

新規の OpenShift Container Platform CA が導入されている場合、新規の CA によって署名された証明書をすべてのコンポーネントに再デプロイする必要がある場合にはいつでも openshift-master/redeploy-certificates.yml Playbook を使用できます。

10.3.3. 新規 etcd CA の再デプロイ

openshift-etcd/redeploy-ca.yml Playbook は、新規 CA 証明書を生成し、すべての etcd ピアとマスタークライアントに更新したバンドルを配布することによって etcd CA 証明書を再デプロイします。

これには、以下の順次の再起動も伴います。

  • etcd
  • マスターサービス

新たに生成された etcd CA を再デプロイするには、以下を実行します。

  1. openshift-etcd/redeploy-ca.yml Playbook を実行し、インベントリーファイルを指定します。

    $ ansible-playbook -i <inventory_file> \
        /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-ca.yml

新規 etcd CA が導入されている場合、新規 CA によって署名された証明書を etcd ピアとマスタークライアントに再デプロイする必要がある場合にはいつでも openshift-etcd/redeploy-certificates.yml Playbook を使用できます。または、redeploy-certificates.yml Playbook を使用して、etcd ピアとマスタークライアントに加えて、OpenShift Container Platform コンポーネントの証明書も再デプロイできます。

10.3.4. マスター証明書のみの再デプロイ

openshift-master/redeploy-certificates.yml Playbook は、マスター証明書のみを再デプロイします。これには、マスターサービスの順次の再起動も伴います。

マスター証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-certificates.yml
重要

この Playbook を実行した後に、サービス提供証明書を含む既存のシークレットを削除するか、またはアノテーションを削除し、適切なサービスに再度追加して、サービス提供証明書またはキーペアを再生成する必要があります。

10.3.5. etcd 証明書のみの再デプロイ

openshift-etcd/redeploy-certificates.yml Playbook は、マスタークライアント証明書を含む etcd 証明書のみを再デプロイします。

これには、以下の順次の再起動も伴います。

  • etcd
  • マスターサービス

etcd 証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-certificates.yml

10.3.6. ノード証明書のみの再デプロイ

openshift-node/redeploy-certificates.yml Playbook は、ノード証明書のみを再デプロイします。これには、ノードサービスの順次の再起動も伴います。

ノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-node/redeploy-certificates.yml

10.3.7. レジストリー証明書またはルーター証明書のみの再デプロイ

openshift-hosted/redeploy-registry-certificates.yml Playbook と openshift-hosted/redeploy-router-certificates.yml Playbook は、インストーラーによって作成されたレジストリー証明書とルーター証明書を置き換えます。レジストリーとルーターでカスタム証明書が使用されている場合にそれらを手動で置き換えるには、「 カスタムのレジストリー証明書またはルーター証明書の再デプロイ」を参照してください。

10.3.7.1. レジストリー証明書のみの再デプロイ

レジストリー証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-registry-certificates.yml

10.3.7.2. ルーター証明書のみの再デプロイ

ルーター証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。

$ ansible-playbook -i <inventory_file> \
    /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml

10.3.8. カスタムのレジストリー証明書またはルーター証明書の再デプロイ

再デプロイされた CA が原因でノードが退避させられると、レジストリー Pod とルーター Pod が再起動されます。レジストリー証明書とルーター証明書を新規 CA と共に再デプロイしなかった場合は、それらが古い証明書を使用してマスターにアクセスできなくなるため、停止状態が生じることがあります。

証明書を再デプロイする Playbook は、カスタムのレジストリー証明書またはルーター証明書を再デプロイできません。この問題を解決するため、レジストリー証明書とルーター証明書を手動で再デプロイする必要があります。

10.3.8.1. 手動によるレジストリー証明書の再デプロイ

レジストリー証明書を手動で再デプロイするには、新規レジストリー証明書を registry-certificates という名前のシークレットに追加してから、レジストリーを再デプロイする必要があります。

  1. これ以降の手順では default プロジェクトに切り替えます。

    $ oc project default
  2. 最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにシークレットをご使用ください)。

    1. 以下のコマンドを実行し、OPENSHIFT_CA_DATAOPENSHIFT_CERT_DATA、および OPENSHIFT_KEY_DATA 環境変数を探します。

      $ oc env dc/docker-registry --list
    2. これらの環境変数が存在しない場合は、この手順を省略します。存在する場合は、以下の ClusterRoleBinding を作成します。

      $ cat <<EOF |
      apiVersion: v1
      groupNames: null
      kind: ClusterRoleBinding
      metadata:
        creationTimestamp: null
        name: registry-registry-role
      roleRef:
        kind: ClusterRole
        name: system:registry
      subjects:
      - kind: ServiceAccount
        name: registry
        namespace: default
      userNames:
      - system:serviceaccount:default:registry
      EOF
      oc create -f -

      次に、以下のコマンドを実行して環境変数を削除します。

      $ oc env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
  3. 以下の環境変数をローカルに設定し、後で使用するコマンドを単純化します。

    $ REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'`
    $ REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`
  4. 新規レジストリー証明書を作成します。

    $ oc adm ca create-server-cert \
        --signer-cert=/etc/origin/master/ca.crt \
        --signer-key=/etc/origin/master/ca.key \
        --hostnames=$REGISTRY_IP,docker-registry.default.svc,docker-registry.default.svc.cluster.local,$REGISTRY_HOSTNAME \
        --cert=/etc/origin/master/registry.crt \
        --key=/etc/origin/master/registry.key \
        --signer-serial=/etc/origin/master/ca.serial.txt

    Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

  5. registry-certificates シークレットを新規レジストリー証明書で更新します。

    $ oc create secret generic registry-certificates \
        --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \
        -o json --dry-run | oc replace -f -
  6. レジストリーを再デプロイします。

    $ oc rollout latest dc/docker-registry

10.3.8.2. 手動によるルーター証明書の再デプロイ

ルーターの初回デプロイ時に、アノテーションがサービス提供証明書シークレットを自動的に作成するルーターのサービスに追加されます。

ルーター証明書を手動で再デプロイするため、そのサービス提供証明書の再作成をトリガーできます。これは、シークレットを削除し、アノテーションを削除してから router サービスに再度追加し、ルーターを再デプロイして実行できます。

  1. これ以降の手順では default プロジェクトに切り替えます。

    $ oc project default
  2. 最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにサービス提供証明書シークレットをご使用ください)。

    1. 以下のコマンドを実行し、OPENSHIFT_CA_DATAOPENSHIFT_CERT_DATA、および OPENSHIFT_KEY_DATA 環境変数を探します。

      $ oc env dc/router --list
    2. それらの変数が存在する場合は、以下の ClusterRoleBinding を作成します。

      $ cat <<EOF |
      apiVersion: v1
      groupNames: null
      kind: ClusterRoleBinding
      metadata:
        creationTimestamp: null
        name: router-router-role
      roleRef:
        kind: ClusterRole
        name: system:router
      subjects:
      - kind: ServiceAccount
        name: router
        namespace: default
      userNames:
      - system:serviceaccount:default:router
      EOF
      oc create -f -
    3. それらの変数が存在する場合は、以下のコマンドを実行してそれらを削除します。

      $ oc env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
  3. 証明書を取得します。

    • 外部の認証局 (CA) を使用して証明書に署名する場合、以下の内部プロセスに従って、新規の証明書を作成し、これを OpenShift Container Platform に指定します。
    • 内部の OpenShift Container Platform CA を使用して証明書に署名する場合は、以下のコマンドを実行します。

      重要

      以下のコマンドは、内部で署名される証明書を生成します。これは、OpenShift Container Platform CA を信頼するクライアントによってのみ信頼されます。

      $ cd /root
      $ mkdir cert ; cd cert
      $ oc adm ca create-server-cert \
          --signer-cert=/etc/origin/master/ca.crt \
          --signer-key=/etc/origin/master/ca.key \
          --signer-serial=/etc/origin/master/ca.serial.txt \
          --hostnames='*.hostnames.for.the.certificate' \
          --cert=router.crt \
          --key=router.key \

      これらのコマンドは以下のファイルを生成します。

      • router.crt という名前の新規の証明書
      • 署名する CA 証明書チェーン /etc/origin/master/ca.crt のコピーです。このチェーンには中間の CA を使用する場合に複数の証明書が含まれる場合があります。
      • router.key という名前の対応するプライベートキー。
  4. 生成された証明書を連結する新規ファイルを作成します。

    $ cat router.crt /etc/origin/master/ca.crt router.key > router.pem
  5. 新規シークレットを生成する前に、現在のシークレットをバックアップします。

    $ oc get -o yaml --export secret router-certs > ~/old-router-certs-secret.yaml
  6. 新規の証明書およびキーを保持する新規シークレットを作成し、既存のシークレットの内容を置き換えます。

    $ oc create secret tls router-certs --cert=router.pem \ 1
        --key=router.key -o json --dry-run | \
        oc replace -f -
    1
    router.pem は、生成した証明書の連結を含むファイルです。
  7. 以下のアノテーションを router サービスから削除します。

    $ oc annotate service router \
        service.alpha.openshift.io/serving-cert-secret-name- \
        service.alpha.openshift.io/serving-cert-signed-by-
  8. アノテーションを再度追加します。

    $ oc annotate service router \
        service.alpha.openshift.io/serving-cert-secret-name=router-certs
  9. ルーターを再デプロイします。

    $ oc rollout latest dc/router

第11章 認証およびユーザーエージェントの設定

11.1. 概要

OpenShift Container Platform のマスターには、OAuth サーバーがビルトインされています。開発者および管理者は OAuth アクセストークンを取得して API に対する認証を実行します。

管理者はマスター設定ファイルを使用して OAuth を アイデンティティープロバイダーを指定するように設定できます。アイデンティティープロバイダーは、クラスターインストールの実行中に設定するのが最適ですが、インストール後に設定することもできます。

注記

/:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。

Deny All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、すべてのユーザー名とパスワードについてアクセスを拒否します。アクセスを許可するには、別のアイデンティティープロバイダーを選択し、マスター設定ファイル (デフォルトでは、/etc/origin/master/master-config.yaml にあります) を適宜設定する必要があります。

設定ファイルなしでマスターを実行する場合は、Allow All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、空でないユーザー名とパスワードによるログインをすべて許可します。これはテストを行う場合に便利です。その他のアイデンティティープロバイダーを使用するか、tokengrant、または session オプション を変更する場合は、設定ファイルからマスターを実行する必要があります。

注記

外部ユーザーのセットアップを管理するためのロールが割り当てられている必要があります。

アイデンティティープロバイダーに変更を加えたら、変更を有効にするためにマスターサービスを再起動する必要があります。

# master-restart api
# master-restart controllers

11.2. アイデンティティープロバイダーパラメーター

すべてのアイデンティティープロバイダーには共通する 4 つのパラメーターがあります。

パラメーター説明

name