第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
6.2. OpenShift Ansible Broker 設定の変更
OAB のデフォルト設定をデプロイした後に変更するには、以下を実行します。
OAB の namespace の broker-config ConfigMap オブジェクトを、cluster-admin 権限を持つユーザーとして編集します。
$ oc edit configmap broker-config -n openshift-ansible-service-broker
更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。
$ oc rollout latest dc/asb -n openshift-ansible-service-broker
6.3. レジストリー設定
registry セクションでは、ブローカーが APB 用に参照する必要があるレジストリーを定義できます。
表6.1 registry セクションの設定オプション
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
レジストリーの名前です。このレジストリーから APB を識別するためにブローカーによって使用されます。 |
Y |
|
|
レジストリーに対して認証するためのユーザー名です。 |
N |
|
|
レジストリーに対して認証するためのパスワードです。 |
N |
|
|
レジストリー認証情報が |
N |
|
|
読み取る必要があるレジストリー認証情報を格納しているシークレットまたはファイルの名前です。 |
N ( |
|
|
イメージが含まれている namespace または組織です。 |
N |
|
|
レジストリーのタイプです。使用可能なアダプターは |
Y |
|
|
|
N |
|
|
イメージ情報を取得するために使用される URL です。これは、RHCC の場合に広範囲に使用されます。 |
N |
|
|
このレジストリーが失敗した場合にブートストラップ要求を失敗させるかどうかを指定します。失敗させる場合、その他のレジストリーの読み込みの実行を停止します。 |
N |
|
|
許可されるイメージ名を定義するための正規表現の一覧です。カタログへの APB の追加を許可するホワイトリストを作成する必要があります。レジストリー内のすべての APB を取得する必要がある場合は、最も許容度の高い正規表現である |
N |
|
|
許可できないイメージ名を定義するために使用される正規表現の一覧です。詳細については、「APB のフィルタリング」を参照してください。 |
N |
|
|
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 タイプを使用するには、以下を実行します。
関連するシークレットには、
usernameとpasswordの値が定義されている必要があります。シークレットを使用する場合は、openshift-ansible-service-brokernamespace が存在していることを確認する必要があります。シークレットはこの namespace から読み取られるためです。たとえば、reg-creds.yaml ファイルを作成します。
$ cat reg-creds.yaml --- username: <user_name> password: <password>
このファイルから
openshift-ansible-service-brokernamespace にシークレットを作成します。$ oc create secret generic \ registry-credentials-secret \ --from-file reg-creds.yaml \ -n openshift-ansible-service-brokersecretまたはfileのどちらのタイプを使用するか選択します。secretタイプを使用するには、以下を実行します。ブローカー設定で、
auth_typeをsecretに、auth_nameをシークレットの名前に設定します。registry: - name: isv type: openshift url: https://registry.connect.redhat.com auth_type: secret auth_name: registry-credentials-secretシークレットが置かれている namespace を設定します。
openshift: namespace: openshift-ansible-service-broker
fileタイプを使用するには、以下を実行します。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-authvolumesセクションに、以下を追加します。volumes: - name: reg-auth secret: defaultMode: 420 secretName: registry-credentials-secretブローカー設定で、
auth_typeをfileに、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: mock6.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 を使用するように設定するには以下の手動の手順も必要になります。
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 26.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-secret6.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-client6.5. DAO 設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
etcd ホストの URL です。 |
Y |
|
|
|
Y |
6.6. ログ設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
ブローカーのログを書き込む場所です。 |
Y |
|
|
ログを標準出力に書き込みます。 |
Y |
|
|
ログ出力のレベルです。 |
Y |
|
|
ログに色付けします。 |
Y |
6.7. OpenShift 設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
OpenShift Container Platform ホストです。 |
N |
|
|
認証局ファイルの場所です。 |
N |
|
|
使用するベアラートークンの場所です。 |
N |
|
|
イメージをプルするタイミングです。 |
Y |
|
|
ブローカーがデプロイされている namespace です。シークレットを介して渡されるパラメーター値などに重要です。 |
Y |
|
|
APB サンドボックス環境に対して指定するロールです。 |
Y |
|
|
APB の実行後に namespace を常に保持します。 |
N |
|
|
APB の実行でエラーが発生した後に namespace を保持します。 |
N |
6.8. ブローカー設定
broker セクションでは、有効/無効にする機能をブローカーに指示します。また、完全な機能を有効にするファイルがディスク上のどこにあるかをブローカーに指示します。
| フィールド | 説明 | デフォルト値 | 必須 |
|---|---|---|---|
|
|
開発ルートにアクセスできるようにします。 |
|
N |
|
|
バインドが no-op (無処理) になることを許可します。 |
|
N |
|
|
ブローカーが起動時に自らをブートストラップできるようにします。APB を設定済みのレジストリーから取得します。 |
|
N |
|
|
etcd にある保留中のジョブを処理することによって、ブローカーが自らをリカバリーできるようにします。 |
|
N |
|
|
デバッグを容易に行えるように、ブローカーが要求の受信時にそれをログファイルに出力できるようにします。 |
|
N |
|
|
TLS キーファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはキーファイルの作成を試みます。 |
|
N |
|
|
TLS .crt ファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはファイルの作成を試みます。 |
|
N |
|
|
レジストリーで新規イメージ仕様をクエリーする間隔です。 |
|
N |
|
|
ブローカーが APB の実行中にユーザーのパーミッションをエスカレーションできるようにします。 |
|
N |
|
|
ブローカーが予期する URL のプレフィックスを設定します。 |
|
N |
非同期のバインドまたはバインド解除は実験的な機能であり、サポートされていないか、デフォルトでは有効になっていません。非同期バインドがない場合に launch_apb_on_bind を true に設定すると、バインドアクションがタイムアウトになり、再試行が実行されます。これはパラメーターの異なる同じバインド要求であるため、ブローカーは「409 Conflicts」で処理します。
6.9. シークレット設定
secrets セクションでは、ブローカーの namespace のシークレットとブローカーが実行する APB 間の関連付けを作成します。ブローカーは、これらのルールに従って実行中の APB にシークレットをマウントします。これにより、ユーザーはシークレットを使用して、パラメーターをカタログやユーザーに公開せずに渡すことができます。
このセクションは一覧の形式であり、各エントリーは以下の構造を持ちます。
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
ルールのタイトルです。表示と出力の目的でのみ使用されます。 |
Y |
|
|
指定されたシークレットに関連付けられる APB の名前です。これは完全修飾名 ( |
Y |
|
|
パラメーターをプルするシークレットの名前です。 |
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 マニフェストを読み込むために、外部レジスターと通信できなければなりません。これらの要求はプロキシー経由で実行できますが、プロキシーでは必要なリモートホストにアクセスできるようにする必要があります。
必要なホワイトリスト化されたホストの例:
| レジストリーアダプターのタイプ | ホワイトリスト化されたホスト |
|---|---|
|
|
|
|
|
|
6.10.2. Ansible を使用したプロキシー環境でのブローカーの設定
初期インストール時に OpenShift Container Platform クラスターがプロキシーの環境下で実行されるように設定した場合 (「グローバルプロキシーオプションの設定」を参照)、OAB はデプロイ時に以下を実行します。
- クラスター全体のプロキシー設定を自動的に継承する
-
cidrフィールドおよびserviceNetworkCIDRを含む必要なNO_PROXY一覧を生成する
それ以外の設定は必要ありません。
6.10.3. プロキシー環境でのブローカーの手動設定
クラスターのグローバルプロキシーオプションが初期インストール時またはブローカーのデプロイ前に設定されていない場合や、グローバルプロキシー設定を変更した場合、ブローカーの外部アクセスについてプロキシー経由で手動で設定する必要があります。
OAB をプロキシー環境で実行する前に「HTTP プロキシーの使用」を確認し、クラスターがプロキシー環境で実行されるように適切に設定されていることを確認してください。
特に、クラスターは内部クラスター要求をプロキシー処理しないように設定されている必要があります。通常、これは以下の
NO_PROXY設定を使用して設定されます。.cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.default
その他の必要な
NO_PROXY設定も追加する必要があります。詳細については、「NO_PROXY の設定」を参照してください。注記バージョンなしまたは v1 の APB をデプロイするブローカーは、
172.30.0.1もNO_PROXYの一覧に追加する必要があります。v2 より前の APB は、シークレットの交換ではなく、execHTTP 要求を使用して実行中の APB Pod から認証情報を抽出しました。実験的なプロキシーサポートがあるブローカーを OpenShift Container Platform 3.9 より前のクラスターで実行していない限り、この点を心配する必要はおそらくありません。ブローカーの
DeploymentConfigを cluster-admin 権限を持つユーザーとして編集します。$ oc edit dc/asb -n openshift-ansible-service-broker
以下の環境変数を設定します。
-
HTTP_PROXY -
HTTPS_PROXY -
NO_PROXY
注記詳細については、「Pod でのプロキシー環境変数の設定」を参照してください。
-
更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。
$ oc rollout latest dc/asb -n openshift-ansible-service-broker
6.10.4. Pod でのプロキシー環境変数の設定
一般に、APB Pod 自体もプロキシー経由の外部アクセスを必要とします。ブローカーは、自らにプロキシー設定があることを認識すると、生成する APB Pod にこれらの環境変数を透過的に適用します。APB 内で使用されるモジュールが環境変数経由でプロキシー設定に従う限り、APB もこれらの設定に基づいて動作します。
最後に、APB によって生成されたサービスもプロキシー経由の外部ネットワークアクセスを必要とする場合があります。APB は、それ自体の実行環境でこのようなサービスを検出した場合にこれらの環境変数を明示的に設定するように作成されている必要があります。そうでない場合には、クラスターオペレーターが必要なサービスを変更してそれらを環境に組み込む必要があります。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.