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

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

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

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

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

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

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

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

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

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

$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \1
    --service-account=registry \2
    --images='registry.redhat.io/openshift3/ose-${component}:${version}' 3

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

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

$ oc adm registry --help

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ sudo chown 1001:root <path>

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

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

コンテナーイメージレジストリーのログを表示するには、デプロイメント設定で 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

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

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

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

メトリクスにアクセスするための別の方法は、クラスターロールの使用です。エンドポイントはここでも有効にする必要がありますが、<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 ドキュメントを参照してください。

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

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

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

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

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

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

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

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

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

# master-restart api
# master-restart controllers

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

/etc/containers/registries.conf ファイルを使用して、コンテナーイメージを検索するために Docker レジストリーの一覧を作成できます。

/etc/containers/registries.conf ファイルは、myimage:latest などのイメージの省略名を使用してユーザーがイメージをプルする際に OpenShift Container Platform が検索する必要のあるレジストリーサーバーの一覧です。検索の順序をカスタマイズし、セキュアなレジストリーおよび非セキュアなレジストリーを指定し、ブロックされたレジストリーの一覧を定義することができます。OpenShift Container Platform はブロックされた一覧でレジストリーを検索したり、レジストリーからのプルを許可しません。

たとえば、ユーザーが myimage:latest イメージをプルする必要がある場合、OpenShift Container Platform は myimage:latest が見つかるまで一覧に表示される順序でレジストリーを検索します。

レジストリー検索一覧を使用して、OpenShift Container Platform ユーザーがダウンロードできるイメージおよびテンプレートのセットをキュレートできます。これらのイメージを 1 つ以上の Docker レジストリーに配置し、レジストリーを一覧に追加し、それらのイメージをクラスターにプルすることができます。

レジストリー検索一覧を設定するには、以下を実行します。

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

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

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

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

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

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

上記の手順は、必要な設定を行えるように繰り返し実行される場合があります。たとえば、トラブルシューティング時に、デバッグ モードに切り換えるよう設定が一時的に更新される場合があります。

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

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

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

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

auth:
  openshift:
    realm: openshift

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

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

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

middleware:
  repository:
    - name: openshift
      options:
        acceptschema2: true 1
        pullthrough: true 2
        mirrorpullthrough: true 3
        enforcequota: false 4
        projectcachettl: 1m 5
        blobrepositorycachettl: 10m 6

$ 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:
  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

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

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

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: "" 1
openshift:
  version: 1.0
  cache:
    disabled: true 2
    blobrepositoryttl: 10m

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

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

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

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

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

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

$ oc tag srcimagestream:latest anyproject/pullimagestream:latest

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

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

Error: image anyproject/pullimagestream:latest not found

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

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

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 サポートにお問い合わせください。お住まいの地域や特定のバケットに関連した問題がある可能性があります。

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

BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob

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

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

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

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

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

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

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

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 アドレスがルーターを実行し、ルーターがどのトラフィックを処理するかについて調整しやすくなります。ノードセレクターを使用してルーターを特定のノードにデプロイします。

$ oc adm router --dry-run --service-account=router 1

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

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

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

--extended-logging=true は、ルーターを、 HAProxy で生成されるログを syslog コンテナーに転送するように設定します。

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

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

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

$ oc adm router --dry-run --service-account=router

$ oc adm router --dry-run -o yaml --service-account=router

$ oc adm router --extended-logging=true

以下の例は、--extended-logging=true を使用するルーターの設定です。

$ oc get pod router-1-xhdb9 -o yaml
apiVersion: v1
kind: Pod
spec:
  containers:
  - env:

    ....

    - name: ROUTER_SYSLOG_ADDRESS 1
      value: /var/lib/rsyslog/rsyslog.sock

    ....

 - command: 2
   - /sbin/rsyslogd
   - -n
   - -i
   - /tmp/rsyslog.pid
   - -f
   - /etc/rsyslog/rsyslog.conf
   image: registry.redhat.io/openshift3/ose-haproxy-router:v3.11.188
   imagePullPolicy: IfNotPresent
   name: syslog

以下のコマンドを使用して HAProxy ログを表示します。

$ oc set env dc/test-router ROUTER_LOG_LEVEL=info 1
$ oc logs -f <pod-name> -c syslog 2

HAProxy ログは以下の形式を取ります。

2020-04-14T03:05:36.629527+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.627] fe_no_sni~ be_secure:openshift-console:console/pod:console-b475748cb-t6qkq:console:10.128.0.5:8443 0/0/1/1/2 200 393 - - --NI 2/1/0/1/0 0/0 "HEAD / HTTP/1.1"
2020-04-14T03:05:36.633024+00:00 test-311-node-1 haproxy[43]: 10.0.151.166:59594 [14/Apr/2020:03:05:36.528] public_ssl be_no_sni/fe_no_sni 95/1/104 2793 -- 1/1/0/0/0 0/0

$ 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 ラベルに一致するノードがある場合にのみ自動的にデプロイされます。

ラベルの更新に関する情報については、「ノードのラベルの更新」を参照してください。

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

$ 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

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

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

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

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

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

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

$ oc adm router --strict-sni

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

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

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

$ openssl ciphers

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

ルーターおよびバックエンドサービスへのクライアントアクセスは、手動の TLS 認証を使用して制限できます。ルーターは、その authenticated セットではなくクライアントからの要求を拒否します。相互 TLS 認証はクライアント証明書で実装でき、証明書を発行する認証局 (CA)、証明書失効一覧および/または証明書件名フィルターに基づいて制御できます。ルーターの作成時に相互 TLS 設定オプションの --mutual-tls-auth、--mutual-tls-auth-ca、--mutual-tls-auth-crl および --mutual-tls-auth-filter を使用します。

$ oc adm router --mutual-tls-auth=required  \
                --mutual-tls-auth-ca=/local/path/to/cacerts.pem   ....

--mutual-tls-auth の値は required、optional、または none であり、none はデフォルトになります。--mutual-tls-auth-ca 値は 1 つ以上の CA 証明書を含むファイルを指定します。これらの CA 証明書はクライアントの証明書を検証するためにルーターによって使用されます。

--mutual-tls-auth-crl は、(有効な認証局が発行する) 証明書が取り消されているケースを処理するために証明書失効一覧を指定するために使用できます。

$ oc adm router --mutual-tls-auth=required  \
     --mutual-tls-auth-ca=/local/path/to/cacerts.pem  \
     --mutual-tls-auth-filter='^/CN=my.org/ST=CA/C=US/O=Security/OU=OSE$'  \
     ....

--mutual-tls-auth-filter 値は、証明書件名に基づくきめ細やかなアクセス制御に使用できます。この値は、証明書の件名に一致させるために使用される正規表現です。

--mutual-tls-auth=required を使用することにより、バックエンドリソースへのアクセスを認証されたクライアント のみ に許可することができます。これは、クライアントが常に認証情報 (またはクライアント証明書) を提供するために 必要である ことを意味します。相互 TLS 認証を Optional (オプション) にするには、--mutual-tls-auth=optional を使用 (または、デフォルトの none を使用) してこれを無効にします。ここで、optional とは、クライアントに認証情報の提示を要求する必要が ない ことを意味し、クライアントが認証情報を提供する場合は、その情報は X-SSL* HTTP ヘッダーでバックエンドに渡されることを意味します。

$ oc adm router --mutual-tls-auth=optional  \
     --mutual-tls-auth-ca=/local/path/to/cacerts.pem  \
     ....

相互 TLS 認証サポートが有効にされる場合 (--mutual-tls-auth フラグに required または optional 値のいずれかを使用)、クライアント認証情報は X-SSL* HTTP ヘッダーの形式でバックエンドに渡されます。

X-SSL* HTTP ヘッダーの例。X-SSL-Client-DN:証明書件名の完全識別名 (DN)。X-SSL-Client-NotBefore: YYMMDDhhmmss[Z] 形式でのクライアント証明書の開始日。X-SSL-Client-NotAfter: YYMMDDhhmmss[Z] 形式でのクライアント証明書の終了日。X-SSL-Client-SHA1: クライアント証明書の SHA-1 フィンガープリント。X-SSL-Client-DER: クライアント証明書への完全なアクセスを提供します。base-64 形式でエンコードされた DERフォーマットのクライアント証明書が含まれます。

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

環境変数の ROUTER_SERVICE_HTTP_PORT と ROUTER_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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#!/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

#!/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

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

$ modshard 3 ROUTE_LABELS='dept != finance'

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

$ modshard 3 NAMESPACE_LABELS='frequency=weekly'

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

サービスを公開する際に、ユーザーは外部ユーザーがアプリケーションにアクセスするために使用する 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 へのトラフィックがユーザーのアプリケーションに到達するようになります。

マスター設定ファイル (デフォルトでは /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

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

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

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

証明書を含まない 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

ルーターは、証明書とキーが単一ファイルに 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

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

現時点で、パスワードで保護されたキーファイルはサポートされていません。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/

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

$ 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 証明書とキー情報を指定します。TLS 証明書は、サブドメイン (*.example.org) に一致するすべてのホストのルーターのフロントエンドによって提供されます。

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

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

さらに、他の namespace のルートは重複しないホスト名を要求することを許可されていました。たとえば、namespace ns1 のルート rone は www.example.test を要求でき、namespace d2 の別のルート rtwo は c3po.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

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 ポートを公開する必要があることを意味します。

HAProxy ルーターを Dynamic Configuration Manager を使用するように設定できます。

Dynamic Configuration Manager は、HAProxy リロードのダウンタイムなしに特定のタイプのルートをオンラインにします。これは、ルートおよびエンドポイントの addition|deletion|update など、ルートおよびエンドポイントのすべてのライフサイクルイベントを処理します。

ROUTER_HAPROXY_CONFIG_MANAGER 環境変数を true に設定して Dynamic Configuration Manager を有効にします。

$ oc set env dc/<router_name> ROUTER_HAPROXY_CONFIG_MANAGER='true'

Dynamic Configuration Manager が HAProxy を動的に設定できない場合、これは設定を再作成し、HAProxy プロセスをリロードします。これには、新規ルートにカスタムタイムアウトなどのカスタムアノテーションが含まれる場合や、ルートにカスタム TLS 設定が必要な場合などが含まれます。

動的な設定は、事前に割り当てられたルートおよびバックエンドサーバーのプールと共に HAProxy ソケットおよび設定 API を内部で使用します。ルートの事前に割り当てられたプールは、ルートのブループリントを使用して作成されます。ブループリントのデフォルトセットはセキュリティー保護のないルート、カスタム TLS 設定のないセキュリティー保護された edge ルート、および passthrough ルートをサポートします。

以下の手順では、reencrypt-blueprint、annotated-edge-blueprint、および annotated-unsecured-blueprint の 3 つのルートオブジェクトがあることを前提としています。各種のルートタイプオブジェクトについては、「ルートタイプ」を参照してください。

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

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

$ oc adm router --service-account=router

(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

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

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

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

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

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

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

--threads フラグを使用してスレッドを有効にします。このフラグは、HAProxy ルーターが使用するスレッド数を指定します。

デフォルトの 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 はテンプレートファイルを使用して起動します。

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.redhat.io/openshift3/ose-haproxy-router:v{product-version} haproxy-config.template

イメージ名は コンテナーイメージ から取られます。

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

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

以下のカスタマイズの例を高可用なルーティングセットアップで使用することで、ピア間の同期を行う 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

バックエンドの変更

最後に、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 }}

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

ルーターを再ビルドするには、実行中のルーターにある複数のファイルのコピーが必要になります。作業ディレクトリーを作成し、ルーターからファイルをコピーします。

# 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.template と reload-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

新規ルーターを使用するには、image: 文字列を変更するか、または --images=<repo>/<image>:<tag> フラグを oc adm router コマンドに追加してルーターデプロイ設定を編集します。

変更のデバッグ時に、デプロイメント設定で imagePullPolicy: Always を設定して各 Pod の作成時にイメージプルを強制的に実行すると便利です。デバッグが完了したら、これを imagePullPolicy: IfNotPresent に戻して各 Pod の起動時のプルを回避します。

デフォルトで HAProxy ルーターは、非セキュアな edge および re-encrypt ルートへの受信接続に HTTP を使用することを想定しています。ただし、PROXY プロトコルを使用することで、ルーターが受信要求を予想するよう設定することができます。このトピックでは、HAProxy ルーターと外部ロードバランサーを PROXY プロトコルを使用するように設定する方法を説明しています。

プロキシーサーバーやロードバランサーなどの中間サービスが HTTP 要求を転送する際に、これは接続のソースアドレスを要求の「Forwarded」ヘッダーに追加して、この情報を後続の中間サービスと、要求が最終的に転送されるバックエンドサービスに提供できます。ただし、接続が暗号化されている場合、中間サービスは「Forwarded」ヘッダーを変更できません。この場合、要求が転送されても HTTP ヘッダーは元のソースアドレスを正確に通信することができません。

この問題を解決するために、一部のロードバランサーは、単純に HTTP を転送する代替手段として PROXY プロトコルを使用して HTTP 要求をカプセル化します。カプセル化によって、ロードバランサーは転送される要求自体を変更することなく、情報を要求に追加することができます。これにより、ロードバランサーは、暗号化された接続を転送する場合でもソースアドレスを通信できます。

HAProxy ルーターが PROXY プロトコルを受け入れ、HTTP 要求のカプセル化を解除するように設定できます。ルーターは edge および re-encrypt ルートの暗号化を終了するので、ルーターは要求の「Forwarded」HTTP ヘッダー (および関連する HTTP ヘッダー) を更新でき、PROXY プロトコルを使用して通信されるソースアドレスを追加できます。

デフォルトで、HAProxy ルーターは PROXY プロトコルを使用しません。ROUTER_USE_PROXY_PROTOCOL 環境変数を使用することで、ルーターが受信接続に PROXY プロコトルの使用を予想するように設定できます。

$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true

変数を true または TRUE 以外の値に設定し、PROXY プロコトルを無効にします。

$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=false

ルーターで PROXY プロトコルを有効にする場合、ルーターの前のロードバランサーが PROXY プロコトルを使用するように設定する必要があります。以下は、Amazon の Elastic Load Balancer (ELB) サービスを PROXY プロトコルを使用するように設定した例です。この例では、ELB がポート 80 (HTTP)、443 (HTTPS)、5000 (イメージレジストリーの場合) を 1 つ以上の EC2 インスタンスで実行されるルーターに転送することを想定しています。

$ 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
    }
  ]
]

または、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": []
    }
  ]
]

次にロードバランサーポリシーを作成し、上記の手順 5 に説明されているようにこれを ELB に追加します。

OpenShift Container Platform インストーラーには、Red Hat CloudForms 4.6 (CloudForms Management Engine 5.9 または CFME) を OpenShift Container Platform にデプロイするための Ansible ロールの openshift-management と Playbook が含まれています。

Red Hat CloudForms を OpenShift Container Platform にデプロイする際には、以下の 2 つ点について決定する必要があります。

最初の点については、Red Hat CloudForms で使用する PostgreSQL データベースが置かれている場所によって Red Hat CloudForms を以下のいずれかの方法でデプロイできます。

2 つ目の点については、openshift-management ロールが、多くのデフォルトのデプロイメントパラメーターの上書き用にカスタマイズオプションを提供します。これには、 PV をサポートするための以下のストレージクラスのオプションが含まれています。

本書では、Red Hat CloudForms を OpenShift Container Platform で実行するための要件、利用可能な設定変数の説明、および OpenShift Container Platform の初回インストール時かクラスターのプロビジョニング後のいずれかでインストーラーを実行する方法などについてのトピックを扱います。

以下のセクションでは、Ansible インベントリーファイル で使用されるロール変数について説明します。ロール変数は、インストーラーを実行する際に Red Hat CloudForms インストールの動作を制御するために使用されます。

openshift_management_template_parameters Ansible ロール変数は、アプリケーションまたは PV テンプレートで上書きする必要のあるテンプレートを指定するために使用します。

たとえば、PostgreSQL Pod のメモリー要件を減らしたい場合には、以下を設定します。

openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}

Red Hat CloudForms テンプレートが処理される際に、1Gi が POSTGRESQL_MEM_REQ テンプレートパラメーターの値に使用されます。

すべてのテンプレートパラメーターが (コンテナー化されたデータベースと外部データベースの) 両方 のテンプレートバリアントにある訳ではありません。たとえば、Pod 化されたデータベースのテンプレートには POSTGRESQL_MEM_REQ パラメーターがありますが、このパラメーターは外部のデータベーステンプレートにはありません。そこには Pod を必要とするデータベースが存在せず、この情報は必要とされないためです。

したがって、テンプレートパラメーターを上書きする場合には十分注意する必要があります。テンプレートで定義されていないパラメーターを追加するとエラーの原因になります。管理アプリケーションの作成を確認するタスクの実行時にエラーを受信した場合は、インストーラーを再度実行する前にアンインストールのスクリプトを実行してください。

Red Hat CloudForms のデプロイを、OpenShift Container Platform の初回インストール時か、またはクラスターのプロビジョニング後のいずれかに実行することを選択できます。

このセクションでは、インベントリーファイルのスニペットの例について説明し、使い始めに役立つ OpenShift Container Platform での Red Hat CloudForms の各種の設定について説明します。

[OSEv3:vars]
openshift_management_app_template=cfme-template

[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

openshift_management_storage_nfs_base_dir=/exports/hosted/prod

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}

[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}

[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'}

「インストーラーの実行」で説明されているように Red Hat CloudForms を OpenShift Container Platform にデプロイした後にコンテナープロバイダーの統合を有効にする方法として 、OpenShift Container Platform をコンテナープロバイダーとして手動で追加する方法と、このロールに含まれている Playbook を試行する方法の 2 つの方法があります。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    openshift-management/add_container_provider.yml

このロールには、最新の OpenShift Container Platform クラスターを Red Hat CloudForms デプロイメントに統合するための Playbook に加え、複数のコンテナープラットフォームを任意の Red Hat CloudForms サーバーにコンテナープロバイダーとして追加することを可能にするスクリプトが含まれています。コンテナープラットフォームは、OpenShift Container Platform または OpenShift Origin です。

複数のプロバイダースクリプトを使用する場合、Playbook の実行時に EXTRA_VARS パラメーターを CLI に手動で設定することが必要になります。

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>

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    -e container_providers_config=/tmp/cp.yml \
    playbooks/openshift-management/add_many_container_providers.yml

単一または複数のコンテナープロバイダーを追加したら、新規プロバイダーを Red Hat CloudForms で更新し、コンテナープロバイダーと管理されているコンテナーに関する最新データをすべて取得する必要があります。そのためには、Red Hat CloudForms Web コンソールの各プロバイダーに進み、それぞれについて更新ボタンをクリックします。

手順については、以下の Red Hat CloudForms ドキュメントを参照してください。

デプロイした Red Hat CloudForms インストールを OpenShift Container Platform からアンインストールして削除するには、Playbook ディレクトリーに切り替え、uninstall.yml Playbook を実行します。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v [-i /path/to/inventory] \
    playbooks/openshift-management/uninstall.yml

古い 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

この場合、以下を実行します。

PostgreSQL デプロイヤー Pod は、削除した Pod を置き換えるために新規の postgresql Pod の拡張を試みます。 postgresql Pod が実行された後に、cfme Pod は阻止する操作を停止し、アプリケーションの初期化を開始します。

モニタリングスタックは追加のリソース要件を課します。詳細は、コンピューティングリソースについての推奨事項を参照してください。

モニタリングスタックは、デフォルトで OpenShift Container Platform と共にインストールされます。これがインストールされないようにすることもできます。これを実行するには、Ansible インベントリーファイルでこの変数を false に設定します。

openshift_cluster_monitoring_operator_install

以下でこれを実行できます。

$ ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-monitoring/config.yml \
   -e openshift_cluster_monitoring_operator_install=False

Ansible ディレクトリーの一般的なパスは /usr/share/ansible/openshift-ansible/ です。この場合、設定ファイルへのパスは /usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/config.yml になります。

クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリュームに保存され、再起動または再作成される Pod を維持できます。これは、メトリクスデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、ブロックストレージ技術を使用して永続ストレージを設定することを強く推奨します。

OpenShift Container Platform Monitoring のサポートされる設定方法として、本書で説明されているオプションを使用して設定できます。それらの明示的な設定オプションを使用する方法以外でも、追加設定をスタックに挿入することは可能ですが、Prometheus リリース間で設定方法が変更される可能性があることや、またこのような変更を正常に処理できるのは設定のすべての可能性が制御されている場合のみであることから、この方法はサポート対象外になります。

明示的にサポート対象外とされているケースには、以下が含まれます。

OpenShift Container Platform Monitoring には、モニターする側のインフラストラクチャーの可用性が確保するための「dead man’s switch」という機能が同梱されています。

「dead man’s switch」は、常にトリガーする単純な Prometheus アラートルールです。Alertmanager は、dead man's switch の通知を、この機能をサポートする通知プロバイダーに絶えず送信します。また、これは Alertmanager と通知プロバイダー間の通信が機能していることを確認します。

この仕組みは、モニタリングシステム自体が停止した場合にアラートを発行するために PagerDuty によってサポートされています。詳細は、後続の「Dead man’s switch PagerDuty」を参照してください。

アラートが Alertmanager に対して発行された後に、Alertmanager はそれらを論理的にグループ化するよう設定される必要があります。

この例では、新規ルートが追加され、frontend チームのアラートルーティングが反映されます。

PagerDuty は、Dead Man’s Snitch という統合によりこの仕組みをサポートしています。単純に PagerDuty 設定をデフォルトの deadmansswitch レシーバーに追加します。上記のプロセスを使用してこの設定を追加します。

Dead Man’s Snitch を、Dad Man’s Switch アラートが 15 分間サイレントな場合に Operator を呼び出すように設定します。デフォルトの Alertmanager 設定では、Dead Man’s Switch アラートは 5 分ごとに繰り返されます。Dead Man's Snitch が 15 分後にトリガーされる場合、これは通知が少なくとも 2 回失敗したことを示します。

configure Dead Man’s Snitch を PagerDuty に設定する方法について参照してください。

OpenShift Container Platform Cluster Monitoring には、デフォルトで設定される以下のアラートルールが同梱されます。現時点で、カスタムアラートルールを追加することはできません。

一部のアラートルールでは同一の名前が使われています。これは意図的な理由によるものです。これらのルールは、それぞれのしきい値、それぞれの重大度 (severity) またはそれらの両方を使って同じイベントについてのアラートを送ります。抑制 (inhibition) ルールの場合、重大度 (severity) の低いルールは、 重大度 (severity) の高いルールが発行されると抑制されます。

アラートルールについての詳細は、「configuration file」を参照してください。

Red Hat 製品のエンタイトルメントを持たれる Red Hat のお客様は、ユーザー認証情報を持つアカウントをお持ちです。これは、お客様が Red Hat カスタマーポータルにログインされる際に使用されるユーザー名およびパスワードです。

アカウントをお持ちでない場合は、以下のオプションのいずれかに登録してアカウントを無料で取得することができます。

お客様の企業が共有アカウントを管理されている場合には、トークンを作成する必要があります。管理者は、組織に関連付けられたすべてのトークンを作成し、表示し、削除することができます。

レジストリー認証情報は、Ansible インストーラーを使用してインストールまたはアップグレード時に管理することもできます。

これにより、以下がセットアップされます。

Ansible インストーラーでは、openshift_examples_registryurl または oreg_url のいずれかのデフォルト値の registry.redhat.io を使用している場合に認証情報が必要になります。

追加の認証されたレジストリーへのアクセスを必要とするクラスターは、openshift_additional_registry_credentials を設定してレジストリーの一覧を設定できます。各レジストリーには、ホストおよびパスワードの値が必要であり、ユーザー名はユーザーを設定して指定できます。デフォルトで、指定された認証情報は、指定されたレジストリーでイメージ openshift3/ose-pod の検査を試行することによって検証されます。

代替イメージを指定するには、以下のいずれかを実行します。

レジストリーがセキュアでない場合、tls_verify を False に設定します。

この一覧のすべての認証情報には、OpenShift namespace で作成された imagestreamsecret およびすべてのノードにデプロイされた認証情報が含まれます。

以下に例を示します。

openshift_additional_registry_credentials=[{'host':'registry.example.com','user':'name','password':'pass1','test_login':'False'},{'host':'registry2.example.com','password':'token12345','tls_verify':'False','test_image':'mongodb/mongodb'}]

Red Hat レジストリーのサービスアカウントを作成し、トークンを生成した後に、追加のタスクを実行できます。

OpenShift Container Platform クラスターを HTPasswd 認証を使用するように設定するには、ハッシュ化されたパスワードを持つ 1 名以上のユーザーをインベントリーファイルに追加する必要があります。

以下を実行することができます。

ユーザーおよびハッシュ化されたパスワードを作成するには、以下を実行します。

これで、HTPasswd 認証を設定する際にハッシュ化パスワードを使用できます。ハッシュ化パスワードは、: の後に続く文字列です。上記の例では、次を入力します。

openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}

ユーザー名とハッシュ化パスワードを持つフラットファイルを作成するには、以下を実行します。

これで、HTPasswd 認証を設定する際にこのパスワードファイルを使用できます。