2.5. operator を使用した OpenShift への 3scale のデプロイメント設定オプション
本セクションでは、operator を使用した OpenShift への Red Hat 3scale API Management のデプロイメント設定オプションについて説明します。
前提条件
- コンテナーレジストリー認証の設定
- 先に OpenShift への 3scale operator のインストール の記載の手順に従って Operator を使用して 3scale をデプロイする。
OpenShift Container Platform 4.x
- OpenShift クラスターの管理者権限を持つユーザーアカウント。
2.5.1. Embedded APIcast のプロキシーパラメーターの設定 リンクのコピーリンクがクリップボードにコピーされました!
3scale の管理者は、Embedded APIcast ステージングおよび実稼働環境用のプロキシーパラメーターを設定することができます。このセクションでは、APIManager カスタムリソース (CR) でプロキシーパラメーターを指定するための参照情報を提供します。つまり、3scale operator (APIManager CR) を使用して 3scale を OpenShift にデプロイします。
これらのパラメーターは、APIManager CR を初めてデプロイするときに指定できます。または、デプロイされた APIManager CR を更新すると、Operator が更新を調整します。APIManager カスタムリソースのデプロイ を参照してください。
Embedded APIcast には、プロキシー関連の 4 つの設定パラメーターがあります。
-
allProxy -
httpProxy -
httpsProxy -
noProxy
allProxy
allProxyパラメーターは、要求でプロトコル固有のプロキシーが指定されていない場合にサービスに接続するために使用される HTTP または HTTPS プロキシーを指定します。
プロキシーを設定したら、allProxy パラメーターをプロキシーのアドレスに設定して APIcast を設定します。プロキシーでは認証機能はサポートされていません。つまり、APIcast では認証された要求はプロキシーには送信されません。
allProxy パラメーターの値は文字列で、デフォルトはなく、パラメーターは必須ではありません。この形式を使用して、spec.apicast.productionSpec.allProxy パラメーターまたは spec.apicast.stagingSpec.allProxy パラメーターを設定します。
<scheme>://<host>:<port>
以下に例を示します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
apicast:
productionSpec:
allProxy: http://forward-proxy:80
stagingSpec:
allProxy: http://forward-proxy:81
httpProxy
httpProxy パラメーターは、HTTP サービスへの接続に使用される HTTP プロキシーを指定します。
プロキシーを設定したら、httpProxy パラメーターをプロキシーのアドレスに設定して APIcast を設定します。プロキシーでは認証機能はサポートされていません。つまり、APIcast では認証された要求はプロキシーには送信されません。
httpProxy パラメーターの値は文字列で、デフォルトはなく、パラメーターは必須ではありません。この形式を使用して、spec.apicast.productionSpec.httpProxy パラメーターまたは spec.apicast.stagingSpec.httpProxy パラメーターを設定します。
http://<host>:<port>
以下に例を示します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
apicast:
productionSpec:
httpProxy: http://forward-proxy:80
stagingSpec:
httpProxy: http://forward-proxy:81
httpsProxy
httpsProxy パラメーターは、サービスへの接続に使用される HTTPS プロキシーを指定します。
プロキシーを設定したら、httpsProxy パラメーターをプロキシーのアドレスに設定して APIcast を設定します。プロキシーでは認証機能はサポートされていません。つまり、APIcast では認証された要求はプロキシーには送信されません。
httpsProxy パラメーターの値は文字列で、デフォルトはなく、パラメーターは必須ではありません。この形式を使用して、spec.apicast.productionSpec.httpsProxy パラメーターまたは spec.apicast.stagingSpec.httpsProxy パラメーターを設定します。
https://<host>:<port>
以下に例を示します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
apicast:
productionSpec:
httpsProxy: https://forward-proxy:80
stagingSpec:
httpsProxy: https://forward-proxy:81
noProxy
noProxy パラメーターは、ホスト名とドメイン名のコンマ区切りリストを指定します。要求にこれらの名前のいずれかが含まれる場合、APIcast は要求をプロキシーしません。
たとえば、メンテナンス操作中にプロキシーへのアクセスを停止する必要がある場合は、noProxy パラメーターをアスタリスク (*) に設定します。これは、すべての要求で指定されたすべてのホストに一致し、プロキシーを実質的に無効にします。
noProxy パラメーターの値は文字列で、デフォルトはなく、パラメーターは必須ではありません。spec.apicast.productionSpec.noProxy パラメーターまたは spec.apicast.stagingSpec.noProxy パラメーターを設定するには、コンマ区切りの文字列を指定します。以下に例を示します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
apicast:
productionSpec:
noProxy: theStore,company.com,big.red.com
stagingSpec:
noProxy: foo,bar.com,.extra.dot.com
2.5.2. 3scale Operator を使用したカスタム環境の注入 リンクのコピーリンクがクリップボードにコピーされました!
Embedded APIcast を使用する 3scale インストールでは、3scale Operator を使用してカスタム環境を注入できます。Embedded APIcast は、Managed APIcast または Hosted APIcast とも呼ばれます。カスタム環境は、ゲートウェイが提供するすべてのアップストリーム API に APIcast が適用する動作を定義します。カスタム環境を作成するには、Lua コードでグローバル設定を定義します。
3scale のインストールの前または後にカスタム環境を注入できます。カスタム環境を注入した後、および 3scale をインストールした後、カスタム環境を削除できます。3scale Operator は変更を調整します。
前提条件
- 3scale Operator がインストールされている。
手順
注入するカスタム環境を定義する Lua コードを記述します。たとえば、次の
env1.luaファイルは、3scale Operator がすべてのサービスに対してロードするカスタムログポリシーを示しています。local cjson = require('cjson') local PolicyChain = require('apicast.policy_chain') local policy_chain = context.policy_chain local logging_policy_config = cjson.decode([[ { "enable_access_logs": false, "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}" } ]]) policy_chain:insert( PolicyChain.load_policy('logging', 'builtin', logging_policy_config), 1) return { policy_chain = policy_chain, port = { metrics = 9421 }, }カスタム環境を定義する Lua ファイルからシークレットを作成します。以下に例を示します。
$ oc create secret generic custom-env-1 --from-file=./env1.luaシークレットには複数のカスタム環境を含めることができます。カスタム環境を定義する各ファイルの
'-from-fileオプションを指定します。Operator は各カスタム環境をロードします。作成したシークレットを参照する APIManager カスタムリソース (CR) を定義します。以下の例は、カスタム環境を定義するシークレットの参照に関連するコンテンツのみを示しています。
apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata: name: apimanager-apicast-custom-environment spec: wildcardDomain: <desired-domain> apicast: productionSpec: customEnvironments: - secretRef: name: custom-env-1 stagingSpec: customEnvironments: - secretRef: name: custom-env-1APIManager CR は、カスタム環境を定義する複数のシークレットを参照できます。Operator は各カスタム環境をロードします。
カスタム環境を追加する APIManager CR を作成します。以下に例を示します。
$ oc apply -f apimanager.yaml
次のステップ
カスタム環境を定義するシークレットのコンテンツを更新することはできません。カスタム環境を更新する必要がある場合は、以下のいずれかを実行できます。
-
推奨されるオプションは、別の名前でシークレットを作成し、APIManager (CR) フィールドの
customEnvironments[].secretRef.nameを更新することです。Operator はローリング更新をトリガーし、更新されたカスタム環境をロードします。 -
あるいは、
spec.apicast.productionSpec.replicasまたはspec.apicast.stagingSpec.replicasを 0 に設定して既存のシークレットを更新してから、spec.apicast.productionSpec.replicasまたはspec.apicast.stagingSpec.replicasを以前の値に設定して APIcast をも再デプロイし直します。
2.5.3. 3scale operator によるカスタムポリシーの注入 リンクのコピーリンクがクリップボードにコピーされました!
Embedded APIcast を使用する 3scale インストールでは、3scale operator を使用してカスタムポリシーを注入できます。Embedded APIcast は、Managed APIcast または Hosted APIcast とも呼ばれます。カスタムポリシーを注入すると、ポリシーコードが APIcast に追加されます。次に、以下のいずれかを使用して、カスタムポリシーを API 製品のポリシーチェーンに追加できます。
- 3scale API
-
Productカスタムリソース (CR)
3scale 管理ポータルを使用してカスタムポリシーを製品のポリシーチェーンに追加するには、カスタムポリシーのスキーマを CustomPolicyDefinition CR に登録する必要もあります。カスタムポリシー登録は、管理ポータルを使用して製品のポリシーチェーンを設定する場合にのみ必要です。
3scale インストールの一部として、またはインストール後にカスタムポリシーを挿入できます。カスタムポリシーを注入し、3scale をインストールした後、APIManager CR から指定内容を削除することにより、カスタムポリシーを削除できます。3scale Operator は変更を調整します。
前提条件
- 3scale operator をインストールしているか、以前にインストールしている。
-
Write your own policy で説明されているように、カスタムポリシーを定義している。つまり、カスタムポリシーを定義する
my-policy.lua、apicast-policy.json、およびinit.luaファイルなどをすでに作成している。
手順
1 つのカスタムポリシーを定義するファイルからシークレットを作成します。以下に例を示します。
$ oc create secret generic my-first-custom-policy-secret \ --from-file=./apicast-policy.json \ --from-file=./init.lua \ --from-file=./my-first-custom-policy.lua複数のカスタムポリシーがある場合は、カスタムポリシーごとにシークレットを作成します。シークレットには、カスタムポリシーを 1 つだけ含めることができます。
カスタムポリシーが含まれる各シークレットを参照する APIManager CR を定義します。APIcast ステージングと APIcast 実稼働環境に同じシークレットを指定できます。次の例は、カスタムポリシーを含む参照シークレットに関連するコンテンツのみを示しています。
apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata: name: apimanager-apicast-custom-policy spec: apicast: stagingSpec: customPolicies: - name: my-first-custom-policy version: "0.1" secretRef: name: my-first-custom-policy-secret - name: my-second-custom-policy version: "0.1" secretRef: name: my-second-custom-policy-secret productionSpec: customPolicies: - name: my-first-custom-policy version: "0.1" secretRef: name: my-first-custom-policy-secret - name: my-second-custom-policy version: "0.1" secretRef: name: my-second-custom-policy-secretAPIManager CR は、異なるカスタムポリシーを定義する複数のシークレットを参照できます。Operator は各カスタムポリシーをロードします。
カスタムポリシーが含まれるシークレットを参照する APIManager CR を作成します。以下に例を示します。
$ oc apply -f apimanager.yaml
次のステップ
カスタムポリシーを定義するシークレットのコンテンツを更新することはできません。カスタムポリシーを更新する必要がある場合は、次のいずれかを実行できます。
-
推奨されるオプションは、別の名前でシークレットを作成し、APIManager CR
customPoliciesセクションを更新して、新しいシークレットを参照することです。Operator はローリング更新をトリガーし、更新されたカスタムポリシーをロードします。 -
あるいは、
spec.apicast.productionSpec.replicasまたはspec.apicast.stagingSpec.replicasを 0 に設定して既存のシークレットを更新してから、spec.apicast.productionSpec.replicasまたはspec.apicast.stagingSpec.replicasを以前の値に設定して APIcast をも再デプロイし直します。
2.5.4. 3scale operator を使用した OpenTracing の設定 リンクのコピーリンクがクリップボードにコピーされました!
Embedded APIcast を使用する 3scale インストールでは、3scale operator を使用して OpenTracing を設定できます。OpenTracing は、ステージング環境または実稼働環境用または両方の環境で設定することができます。OpenTracing を有効にすると、APIcast インスタンスに関してより多くの洞察を得て、可観測性を向上できます。
前提条件
- 3scale operator がインストールされているか、インストール中である。
- OpenTracing を使用するための APIcast の設定 に記載の前提条件。
- Jaeger がインストールされている。
手順
stringData.configに OpenTracing 設定の詳細を含めて、シークレットを定義します。これは、OpenTracing 設定の詳細が含まれる属性の唯一有効な値です。その他の仕様では、APIcast が OpenTracing 設定の詳細を受け取れないようにします。以下の例は、有効なシークレット定義を示しています。apiVersion: v1 kind: Secret metadata: name: myjaeger stringData: config: |- { "service_name": "apicast", "disabled": false, "sampler": { "type": "const", "param": 1 }, "reporter": { "queueSize": 100, "bufferFlushInterval": 10, "logSpans": false, "localAgentHostPort": "jaeger-all-in-one-inmemory-agent:6831" }, "headers": { "jaegerDebugHeader": "debug-id", "jaegerBaggageHeader": "baggage", "TraceContextHeaderName": "uber-trace-id", "traceBaggageHeaderPrefix": "testctx-" }, "baggage_restrictions": { "denyBaggageOnInitializationFailure": false, "hostPort": "127.0.0.1:5778", "refreshInterval": 60 } } type: Opaqueシークレットを作成します。たとえば、以前のシークレット定義を
myjaeger.yamlファイルに保存した場合は、以下のコマンドを実行します。$ oc create -f myjaeger.yamlOpenTracing属性を指定する APIManager カスタムリソース (CR) を定義します。CR 定義で、openTracing.tracingConfigSecretRef.name属性を OpenTracing 設定の詳細が含まれるシークレットの名前に設定します。以下の例は、OpenTracing の設定に関するコンテンツのみを示しています。apiVersion: apps.3scale.net/v1alpha1 kind: APIManager metadata: name: apimanager1 spec: apicast: stagingSpec: ... openTracing: enabled: true tracingLibrary: jaeger tracingConfigSecretRef: name: myjaeger productionSpec: ... openTracing: enabled: true tracingLibrary: jaeger tracingConfigSecretRef: name: myjaegerOpenTracing を設定する APIManager CR を作成します。たとえば、APIManager CR を
apimanager1.yamlファイルに保存した場合は、以下のコマンドを実行します。$ oc apply -f apimanager1.yaml
次のステップ
OpenTracing のインストール方法に応じて、Jaeger サービスユーザーインターフェイスでトレースが表示されるはずです。
2.5.5. 3scale operator を使用した Pod レベルでの TLS の有効化 リンクのコピーリンクがクリップボードにコピーされました!
3scale では、実稼働環境用とステージング環境用の 2 つの APIcast インスタンスをデプロイします。TLS は、実稼働用またはステージングのみ、または両方のインスタンスに対して有効にできます。
前提条件
- TLS を有効にするための有効な証明書がある。
手順
以下のように、有効な証明書からシークレットを作成します。
$ oc create secret tls mycertsecret --cert=server.crt --key=server.keyこの設定により、APIManager カスタムリソース (CR) 内のシークレット参照が公開されます。シークレットを作成してから、以下のように APIManager CR でシークレットの名前を参照します。
-
実稼働: APIManager CR は
.spec.apicast.productionSpec.httpsCertificateSecretRefフィールドの証明書を公開します。 ステージング: APIManager CR は
.spec.apicast.stagingSpec.httpsCertificateSecretRefフィールドの証明書を公開します。必要に応じて、以下を設定できます。
-
httpsPortは、APIcast が HTTPS 接続に対してリッスンを開始するポートを示します。これが HTTP ポートと競合する場合には、APIcast はこのポートを HTTPS にのみ使用します。 httpsVerifyDepthは、クライアント証明書チェーンの最大長を定義します。注記APIManager CR から有効な証明書および参照を指定します。設定で
httpsPortにアクセスでき、httpsCertificateSecretRefではない場合、APIcast は組み込まれた自己署名証明書を使用します。これは、推奨されません。
-
実稼働: APIManager CR は
- Operators > Installed Operators の順にクリックします。
- Installed Operators のリストで、3scale Operator をクリックします。
- API Manager タブをクリックします。
- Create APIManager をクリックします。
以下の YAML 定義をエディターに追加します。
production で有効にする場合は、以下の YAML 定義を設定します。
spec: apicast: productionSpec: httpsPort: 8443 httpsVerifyDepth: 1 httpsCertificateSecretRef: name: mycertsecretstaging で有効にする場合は、以下の YAML 定義を設定します。
spec: apicast: stagingSpec: httpsPort: 8443 httpsVerifyDepth: 1 httpsCertificateSecretRef: name: mycertsecret
- Create をクリックします。
2.5.6. 評価用デプロイメントの概念実証 リンクのコピーリンクがクリップボードにコピーされました!
以降のセクションで、3scale の評価用デプロイメントの概念実証に適用される設定オプションを説明します。このデプロイメントでは、デフォルトとして内部データベースが使用されます。
外部データベースの設定は、実稼働環境向けの標準デプロイメントオプションです。
2.5.6.1. デフォルトのデプロイメント設定 リンクのコピーリンクがクリップボードにコピーされました!
コンテナーには、Kubernetes によるリソースの制限およびリクエスト が適用されます。
- これにより、最低限のパフォーマンスレベルが確保されます。
- また、外部サービスおよびソリューションの割り当てを可能にするために、リソースを制限します。
- 内部データベースのデプロイメント
ファイルストレージは、永続ボリューム (PV) がベースになります。
- ボリュームの 1 つには、読み取り、書き込み、実行 (RWX) アクセスモードが必要です。
- OpenShift は、リクエストに応じてこれらを提供するように設定されている必要があります。
- MySQL を内部リレーショナルデータベースとしてデプロイします。
デフォルトの設定オプションは、お客様による概念実証 (PoC) または評価用途に適しています。
1 つ、複数、またはすべてのデフォルト設定オプションを、APIManager CR の特定フィールドの値でオーバーライドすることができます。3scale 演算子では、利用可能なすべての組み合わせが可能です。
2.5.6.2. 評価モードでのインストール リンクのコピーリンクがクリップボードにコピーされました!
評価モードでのインストールの場合、コンテナーには Kubernetes によるリソースの制限およびリクエスト が適用されません。以下に例を示します。
- メモリーのフットプリントが小さい。
- 起動が高速である。
- ノートパソコンで実行可能である。
- プリセールス/セールスでのデモに適する。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
wildcardDomain: lvh.me
resourceRequirementsEnabled: false
関連情報
- 詳細は、APIManager CR を参照してください。
2.5.7. 外部データベースモードでのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat 3scale API Management デプロイメントからデータベースを外部化すると、アプリケーションからの分離とデータベースレベルでのサービス中断に対する回復力が提供されることになります。サービス中断に対する復元力は、データベースをホストするインフラストラクチャーまたはプラットフォームプロバイダーが提供するサービスレベルアグリーメント (SLA) によって異なります。これは 3scale では提供されていません。選択したデプロイメントによって提供されるデータベースの外部化の詳細は、関連ドキュメントを参照してください。
外部データベースのインストールは、中断のない稼働時間を提供したい場合、または独自のデータベースを再利用する予定がある運用環境に適しています。
3scale の外部データベースインストールモードを有効にすると、以下のデータベースの 1 つまたな複数を 3scale の外部として設定できます。
-
backend-redis -
system-redis -
system-database(mysql、postgresql、またはoracle) -
zync-database
3scale をデプロイするために APIManager CR を作成する前に、OpenShift シークレットを使用して以下に示す外部データベースの接続設定を提供する必要があります。
2.5.7.1. バックエンド Redis シークレット リンクのコピーリンクがクリップボードにコピーされました!
2 つの外部 Redis インスタンスをデプロイし、以下の例に示すように接続設定を入力します。
apiVersion: v1
kind: Secret
metadata:
name: backend-redis
stringData:
REDIS_STORAGE_URL: "redis://backend-redis-storage"
REDIS_STORAGE_SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
REDIS_STORAGE_SENTINEL_ROLE: "master"
REDIS_QUEUES_URL: "redis://backend-redis-queues"
REDIS_QUEUES_SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
REDIS_QUEUES_SENTINEL_ROLE: "master"
type: Opaque
シークレット 名は backend-redis にする必要があります。
2.5.7.2. システム Redis シークレット リンクのコピーリンクがクリップボードにコピーされました!
2 つの外部 Redis インスタンスをデプロイし、以下の例に示すように接続設定を入力します。
apiVersion: v1
kind: Secret
metadata:
name: system-redis
stringData:
URL: "redis://system-redis"
SENTINEL_HOSTS: "redis://sentinel-0.example.com:26379,redis://sentinel-1.example.com:26379, redis://sentinel-2.example.com:26379"
SENTINEL_ROLE: "master"
NAMESPACE: ""
type: Opaque
シークレット 名は system-redis にする必要があります。
2.5.7.3. システムデータベースシークレット リンクのコピーリンクがクリップボードにコピーされました!
-
シークレット 名は
system-databaseにする必要があります。
3scale をデプロイする場合には、システムデータベースに 3 つの代替手段があります。代替手段に関連のシークレットごとに、異なる属性と値を設定します。
- MySQL
- PostgreSQL
- Oracle データベース
MySQL、PostgreSQL、または Oracle Database のシステムデータベースシークレットをデプロイするには、以下の例のように接続設定を入力します。
MySQL システムデータベースシークレット
apiVersion: v1
kind: Secret
metadata:
name: system-database
stringData:
URL: "mysql2://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
type: Opaque
3scale 2.12 で MySQL 8.0 を使用する場合は、認証プラグインを mysql_native_password に設定する必要があります。MySQL 設定ファイルに以下を追加します。
[mysqld]
default_authentication_plugin=mysql_native_password
PostgreSQL システムデータベースシークレット
apiVersion: v1
kind: Secret
metadata:
name: system-database
stringData:
URL: "postgresql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
type: Opaque
Oracle システムデータベースシークレット
apiVersion: v1
kind: Secret
metadata:
name: system-database
stringData:
URL: "oracle-enhanced://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
ORACLE_SYSTEM_PASSWORD: "{SYSTEM_PASSWORD}"
type: Opaque
-
{DB_USER}および{DB_PASSWORD}は、通常の非システムユーザーのユーザー名およびパスワードです。 -
{DB_NAME}は Oracle Database の サービス名 です。 -
ORACLE_SYSTEM_PASSWORDはオプションです。データベースユーザーの設定 を参照してください。
2.5.7.4. Zync データベースシークレット リンクのコピーリンクがクリップボードにコピーされました!
zync データベースの設定では、spec.externalComponents.zync.database フィールドが true に設定されている場合、3scale をデプロイする前に zync という名前のシークレットを作成する必要があります。このシークレットでは、DATABASE_URL および DATABASE_PASSWORD フィールドを外部の zync データベースを参照する値に設定します。以下に例を示します。
apiVersion: v1
kind: Secret
metadata:
name: zync
stringData:
DATABASE_URL: postgresql://<zync-db-user>:<zync-db-password>@<zync-db-host>:<zync-db-port>/zync_production
ZYNC_DATABASE_PASSWORD: <zync-db-password>
type: Opaque
zync データベースは高可用性モードである必要があります。
2.5.7.5. 3scale をデプロイするための APIManager カスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
-
外部コンポーネントを有効にする場合は、3scale をデプロイする前に、外部コンポーネント (
backend-redis、system-redis、system-database、zync) ごとにシークレットを作成する必要があります。 -
外部の
system-databaseの場合は、外部化するデータベースのタイプを 1 つだけ選択します。
APIManager カスタムリソース (CR) の設定は、選択したデータベースが 3scale デプロイメントの外部にあるかどうかによって異なります。
backend-redis、system-redis、または system-database が 3scale の外部にある場合は、次の例に示すように APIManager CR externalComponents オブジェクトを設定します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
wildcardDomain: lvh.me
externalComponents:
system:
database: true
2.5.8. 3scale operator での Pod アフィニティーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
すべてのコンポーネントの 3scale operator で Pod アフィニティーを有効にすることができます。これにより、各 deploymentConfig からの Pod レプリカがクラスターの異なるノードに確実に分散され、異なるアベイラビリティーゾーン (AZ) 間で均等に分散されるようになります。
2.5.8.1. コンポーネントレベルでのノードのアフィニティーおよび容認のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
APIManager CR 属性を使用して、3scale ソリューションの Kubernetes の アフィニティー と 容認 をカスタマイズします。これを行うと、さまざまな 3scale コンポーネントを Kubernetes ノードにスケジュールするようにカスタマイズできます。
たとえば、backend-listener のカスタムノードアフィニティーと system-memcached のカスタム容認を設定するには、次の手順を実行します。
カスタムのアフィニティーと容認
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
backend:
listenerSpec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "kubernetes.io/hostname"
operator: In
values:
- ip-10-96-1-105
- key: "beta.kubernetes.io/arch"
operator: In
values:
- amd64
system:
memcachedTolerations:
- key: key1
value: value1
operator: Equal
effect: NoSchedule
- key: key2
value: value2
operator: Equal
effect: NoSchedule
次のアフィニティーブロックを apicastProductionSpec またはデータベース以外の deploymentConfig に追加します。これにより、preferredDuringSchedulingIgnoredDuringExecution を使用したソフト podAntiAffinity 設定が追加されます。スケジューラーは、この apicast-production Pod のセットを、異なる AZ の別々のホストで実行しようとします。それが不可能な場合は、別の場所で実行できるようにします。
ソフト podAntiAffinity
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
deploymentConfig: apicast-production
topologyKey: kubernetes.io/hostname
- weight: 99
podAffinityTerm:
labelSelector:
matchLabels:
deploymentConfig: apicast-production
topologyKey: topology.kubernetes.io/zone
次の例では、requiredDuringSchedulingIgnoredDuringExecution を使用してハード podAntiAffinity 設定を指定します。Pod をノードにスケジュールするには、条件が満たされる必要があります。空きリソースが少ないクラスターでは、新しい Pod をスケジュールできなくなるなどのリスクが存在します。
ハード podAntiAffinity
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
deploymentConfig: apicast-production
topologyKey: kubernetes.io/hostname
- weight: 99
podAffinityTerm:
labelSelector:
matchLabels:
deploymentConfig: apicast-production
topologyKey: topology.kubernetes.io/zone
関連情報
アフィニティーおよび容認に関連する属性の完全リストは、APIManager CDR を参照してください。
2.5.9. 複数のアベイラビリティーゾーン内の複数のクラスター リンクのコピーリンクがクリップボードにコピーされました!
障害が発生した場合、パッシブクラスターをアクティブモードにすると、手順が完了するまでサービスのプロビジョニングが中断されます。このサービス中断が生じるため、メンテナンス期間を設けるようにしてください。
このドキュメントでは、Amazon Web Services (AWS) を使用したデプロイメントに焦点を当てています。他のパブリッククラウドベンダーにも、同じ設定オプションが適用されます。このようなプロバイダーのマネージドデータベースサービスでは、複数のアベイラビリティーゾーンや複数のリージョンがサポートされてします。
3scale を複数の OpenShift クラスターおよび高可用性 (HA) ゾーンにインストールする場合は、ここで紹介するオプションを利用できます。
複数クラスターのインストールオプションでは、クラスターはアクティブ/パッシブ設定で動作し、フェイルオーバー手順にいくつかの手動手順が含まれます。
2.5.9.1. 複数クラスターのインストールの前提条件 リンクのコピーリンクがクリップボードにコピーされました!
複数の OpenShift クラスターを使用する 3scale インストールでは、以下を使用します。
-
APIManager カスタムリソース (CR) の
kubernetes.io/hostnameルールとtopology.kubernetes.io/zoneルールの両方で Pod アフィニティーを使用します。 - APIManager CR で Pod の Disruption Budget を使用します。
- 複数のクラスターにわたる 3scale インストールでは、APIManager CR で、同じ共有の wildcardDomain 属性仕様を使用する必要があります。データベースに保存されている情報が競合するため、このインストールモードではクラスターごとに異なるドメインを使用することはできません。
トークンやパスワードなどの認証情報を含むシークレットを、同じ値を使用してすべてのクラスターに手動でデプロイする必要があります。3scale operator は、クラスターごとにセキュアなランダム値を使用してシークレットを作成します。この場合、両方のクラスターで同じ認証情報が必要です。シークレットのリストとその設定方法は、3scale operator のドキュメントに記載されています。以下は、両方のクラスターでミラーリングする必要があるシークレットのリストです。
-
backend-internal-api -
system-app -
system-events-hook -
system-master-apicast system-seedbackend-redis、system-redis、system-database、およびzyncのデータベース接続文字列を使用してシークレットを手動でデプロイする必要があります。外部データベースモードでのインストール を参照してください。- クラスター間で共有されるデータベースは、すべてのクラスターで同じ値を使用する必要があります。
- 各クラスターに独自のデータベースがある場合は、クラスターごとに異なる値を使用する必要があります。
-
2.5.9.5. 同期データベースを使用した異なるリージョン上のアクティブ/パッシブクラスター リンクのコピーリンクがクリップボードにコピーされました!
このセットアップでは、異なるリージョンに 2 つ以上のクラスターを配置し、アクティブ/パッシブモードで 3scale をデプロイします。1 つのクラスターはアクティブでトラフィックを受信します。他のクラスターはスタンバイモードでトラフィックを受信しないためパッシブですが、アクティブクラスターに障害が発生した際にアクティブロールを引き受けることができるよう準備されています。
適切なデータベースアクセスレイテンシーを実現するために、各クラスターに独自のデータベースインスタンスがあります。アクティブな 3scale インストールのデータベースが 3scale パッシブインストールの読み取りレプリカデータベースにレプリケートされるため、すべてのリージョンでデータが利用可能で最新の状態になり、フェイルオーバーが可能になります。
2.5.9.6. 同期データベースの設定とインストール リンクのコピーリンクがクリップボードにコピーされました!
手順
- 異なるアベイラビリティーゾーンを使用して、異なるリージョンに 2 つ以上の OpenShift クラスターを作成します。3 つ以上のゾーンを使用することを推奨します。
すべてのリージョンで Amazon RDS Multi-AZ を有効にして、必要なすべての AWS ElastiCache インスタンスを作成します。
- Backend Redis データベース用の AWS EC を 2 つ: リージョンごとに 1 つ。
- System Redis データベース用の AWS EC を 2 つ: リージョンごとに 1 つ。
- グローバルデータストア機能を有効にしてクロスリージョンレプリケーションを使用します。これにより、パッシブリージョンのデータベースがアクティブリージョンのマスターデータベースからの読み取りレプリカになります。
すべてのリージョンで Amazon RDS Multi-AZ を有効にして、必要なすべての AWS RDS インスタンスを作成します。
- System データベース用の AWS RDS を 2 つ。
- Zync データベース用の AWS RDS を 2 つ
- クロスリージョンレプリケーションを使用します。これにより、パッシブリージョンのデータベースがアクティブリージョンのマスターデータベースからの読み取りレプリカになります。
- クロスリージョンレプリケーションを使用して、各リージョンのシステムアセット用の AWS S3 バケットを設定します。
- AWS Route53 またはお使いの DNS プロバイダーでカスタムドメインを作成し、アクティブなクラスターの OpenShift ルーターを参照するようにします。これは、APIManager CR の wildcardDomain 属性と一致する必要があります。
3scale をパッシブクラスターにインストールします。APIManager CR は、前のステップで使用したものと同一である必要があります。すべての Pod が実行されたら、すべての
backend、system、zync、およびAPIcastPod に 0 個のレプリカをデプロイするように APIManager を変更します。- アクティブなデータベースからのジョブの消費を避けるために、レプリカを 0 に設定します。最初に各レプリカが 0 に設定されていると、Pod の依存関係によりデプロイメントが失敗します。たとえば、Pod は他の Pod が実行されているかどうかを確認します。まず通常どおりにデプロイしてから、レプリカを 0 に設定します。
2.5.9.7. 同期データベースの手動フェイルオーバー リンクのコピーリンクがクリップボードにコピーされました!
手順
共有データベースの手動フェイルオーバー の手順 1、2、および 3 を実行します。
- すべてのクラスターに、独自の独立したデータベース、つまりアクティブリージョンのマスターからの読み取りレプリカがあります。
- すべてのデータベースでフェイルオーバーを手動で実行して、パッシブリージョンで新しいマスターを選択する必要があります。選択すると、そのマスターがアクティブリージョンになります。
実行する必要があるデータベースの手動フェイルオーバーは次のとおりです。
- AWS RDS: System と Zync。
- AWS ElastiCaches: Backend と System。
- 共有データベースの手動フェイルオーバー の手順 4 を実行します。
2.5.10. Amazon Simple Storage Service 3scale fileStorage のインストール リンクのコピーリンクがクリップボードにコピーされました!
3scale をデプロイするための APIManager カスタムリソース (CR) を作成する前に、OpenShift シークレットを使用して Amazon Simple Storage Service (Amazon S3) サービスの接続設定を提供します。
- ローカルファイルシステムストレージで 3scale をデプロイする場合は、このセクションを飛ばして次に進んでください。
- シークレットに選択する名前は、既存のシークレット名ではなく、APIManager CR で参照される限り、任意の名前にすることができます。
-
S3 互換ストレージに
AWS_REGION が提供されていない場合は、defaultを使用してください。そうしないと、デプロイメントが失敗します。 - 免責事項: ここに記載されている外部 Web サイトへのリンクは、お客様の利便性のみを目的として提供されています。Red Hat はリンクの内容を確認しておらず、コンテンツまたは可用性について責任を負わないものとします。外部 Web サイトへのリンクが含まれていても、Red Hat が Web サイトまたはその組織、製品、もしくはサービスを保証することを意味するものではありません。お客様は、外部サイトまたはコンテンツの使用 (または信頼) によって生じる損失または費用について、Red Hat が責任を負わないことに同意するものとします。
2.5.10.1. Amazon S3 バケットの作成 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- Amazon Web Services (AWS) アカウントを作成している。
手順
- システム資産を保存するためのバケットを作成します。
- 開発者ポータルのロゴ機能を使用する場合は、S3 のパブリックアクセスブロッカーを無効にします。
以下の最低限のパーミッションで Identity and Access Management (IAM) ポリシーを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::<target_bucket_name>",1 "arn:aws:s3:::<target_bucket_name>/*"2 ] } ] }以下のルールで CORS 設定を作成します。
<?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>https://*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> </CORSRule> </CORSConfiguration>
2.5.10.2. OpenShift シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、永続ボリューム要求 (PVC) の代わりに Amazon S3 を使用する 3scale fileStorage を示しています。
AWS S3 互換プロバイダーは、AWS_HOSTNAME、AWS_PATH_STYLE、および AWS_PROTOCOL オプションキーを使用して S3 シークレットで設定できます。詳細は、fileStorage S3 認証情報のシークレットフィールド の表を参照してください。
以下の例では、任意の シークレット 名を指定することができます。シークレット名が APIManager CR で参照されるためです。
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: null
name: aws-auth
stringData:
AWS_ACCESS_KEY_ID: <ID_123456>
AWS_SECRET_ACCESS_KEY: <ID_98765544>
AWS_BUCKET: <mybucket.example.com>
AWS_REGION: eu-west-1
type: Opaque
最後に、3scale をデプロイするための APIManager CR を作成します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: <example_apimanager>
namespace: <3scale_test>
spec:
wildcardDomain: lvh.me
system:
fileStorage:
simpleStorageService:
configurationSecretRef:
name: aws-auth
APIManager SystemS3Spec を確認してください。
次の表は、Identity and Access Management (IAM) および Security Token Service (STS) 設定の fileStorage Amazon S3 認証情報シークレットフィールドの要件を示しています。
- Secure Token Service (STS) を使用する S3 認証方法は、権限が制限された短期間のセキュリティー認証情報で使用します。
- S3 Identity and Access Management (IAM) は、長期的な権限セキュリティー認証情報で使用します。
| フィールド | 説明 | IAM に必要 | STS に必要 |
|---|---|---|---|
| AWS_ACCESS_KEY_ID |
システムの | はい | いいえ |
| AWS_SECRET_ACCESS_KEY |
システムの | はい | いいえ |
| AWS_BUCKET |
アセット用のシステムの | はい | はい |
| AWS_REGION |
アセット用のシステムの | はい | はい |
| AWS_HOSTNAME | デフォルト: Amazon エンドポイント - AWS S3 互換プロバイダーエンドポイントのホスト名 | いいえ | いいえ |
| AWS_PROTOCOL |
デフォルト: | いいえ | いいえ |
| AWS_PATH_STYLE |
デフォルト: | いいえ | いいえ |
| AWS_ROLE_ARN | AWS STS を使用して認証するためのポリシーがアタッチされているロールの ARN | いいえ | はい |
| AWS_WEB_IDENTITY_TOKEN_FILE |
マウントされたトークンファイルの場所へのパス。例: | いいえ | はい |
2.5.11. PostgreSQL のインストール リンクのコピーリンクがクリップボードにコピーされました!
MySQL 内部リレーショナルデータベースがデフォルトのデプロイメントです。このデプロイメント設定をオーバーライドして、代わりに PostgreSQL を使用することができます。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
wildcardDomain: lvh.me
system:
database:
postgresql: {}
関連情報
- 詳細は、APIManager DatabaseSpec を参照してください。
2.5.12. SMTP 変数の設定 (任意) リンクのコピーリンクがクリップボードにコピーされました!
3scale は、電子メールを使用して、通知を送信 し、新しいユーザーを招待 します。この機能を使用する場合は、独自の SMTP サーバーを提供し、system-smtp シークレットで SMTP 変数を設定する必要があります。
system-smtp シークレットで SMTP 変数を設定するには、次の手順を実行します。
手順
OpenShift にログインしていない場合はログインします。
$ oc loginoc patchコマンドを使用して、system-smtpがシークレットの名前であるシークレットタイプを指定し、その後に-pオプションを付けて、次の変数の JSON に新しい値を書き込みます。Expand 表2.2 system-smtp フィールド 説明 デフォルト値 addressこれは、使用するリモートメールサーバーのアドレス (ホスト名または IP) です。これが
""以外の値に設定されている場合、システムはメールサーバーを使用して、API 管理ソリューションで発生するイベントに関連するメールを送信します。""portこれは、使用するリモートメールサーバーのポートです。
""domainメールサーバーで HELO ドメインが必要な場合は、
domainを使用します。""認証メールサーバーで認証が必要な場合に使用します。認証タイプを設定します。plain はパスワードを
plainで送信し、loginは Base64 エンコードされたパスワードを送信します。cram_md5は HMAC-MD5 アルゴリズムに基づくチャレンジ/レスポンスメカニズムを組み合わせます。""usernameメールサーバーが認証を必要とし、認証タイプがそれを必要とする場合は、
usernameを使用します。""passwordメールサーバーが認証を必要とし、認証タイプがそれを必要とする場合は、
passwordを使用します。""openssl.verify.modeTLS を使用する場合、OpenSSL が証明書をチェックする方法を設定できます。これは、自己署名証明書やワイルドカード証明書を検証する必要がある場合に役立ちます。OpenSSL 検証定数の名前
noneまたはpeerを使用できます。""from_address無返信メールの
fromアドレス値。""例
$ oc patch secret system-smtp -p '{"stringData":{"address":"<your_address>"}}' $ oc patch secret system-smtp -p '{"stringData":{"username":"<your_username>"}}' $ oc patch secret system-smtp -p '{"stringData":{"password":"<your_password>"}}'secret 変数を設定した後、
system-appおよびsystem-sidekiqPod を再デプロイします。$ oc rollout latest dc/system-app $ oc rollout latest dc/system-sidekiqロールアウトのステータスを表示し、読み込みが完了したことを確認します。
$ oc rollout status dc/system-app $ oc rollout status dc/system-sidekiq
2.5.13. コンポーネントレベルでのコンピュートリソース要件のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
APIManager カスタムリソース (CR) 属性を使用して、3scale ソリューションの Kubernetes コンピュートリソース要件 をカスタマイズします。この操作により、特定の APIManager コンポーネントに割り当てられるコンピュートリソース (CPU およびメモリー) の要件をカスタマイズします。
以下の例で、backend-listener および zync-database の system-master の system-provider コンテナーに対するコンピュートリソース要件をカスタマイズする方法の概要を説明します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
backend:
listenerSpec:
resources:
requests:
memory: "150Mi"
cpu: "300m"
limits:
memory: "500Mi"
cpu: "1000m"
system:
appSpec:
providerContainerResources:
requests:
memory: "111Mi"
cpu: "222m"
limits:
memory: "333Mi"
cpu: "444m"
zync:
databaseResources:
requests:
memory: "111Mi"
cpu: "222m"
limits:
memory: "333Mi"
cpu: "444m"
関連情報
コンポーネントレベルの CR 要件を指定する方法の詳細は、APIManager CRD リファレンス を参照してください。
2.5.13.1. APIManager コンポーネントのデフォルトコンピュートリソース リンクのコピーリンクがクリップボードにコピーされました!
APIManager の spec.resourceRequirementsEnabled 属性を true に設定すると、デフォルトのコンピュートリソースが APIManager コンポーネントに設定されます。
以下の表に、APIManager コンポーネントに設定された特定のコンピュートリソースのデフォルト値をまとめます。
2.5.13.1.1. CPU およびメモリーの単位 リンクのコピーリンクがクリップボードにコピーされました!
コンピュートリソースのデフォルト値の表に使用される単位について、以下のリストにまとめます。CPU およびメモリーの単位の詳細は、Managing Resources for Containers を参照してください。
リソースの単位について
- m: ミリ CPU またはミリコア
- Mi: メビバイト
- Gi: ギビバイト
- G: ギガバイト
| コンポーネント | CPU 要求 | CPU 上限 | メモリー要求 | メモリー上限 |
|---|---|---|---|---|
| system-app の system-master | 50 m | 1000 m | 600 Mi | 800 Mi |
| system-app の system-provider | 50 m | 1000 m | 600 Mi | 800 Mi |
| system-app の system-developer | 50 m | 1000 m | 600 Mi | 800 Mi |
| system-sidekiq | 100 m | 1000 m | 500 Mi | 2 Gi |
| system-sphinx | 80 m | 1000 m | 250 Mi | 512 Mi |
| system-redis | 150 m | 500 m | 256 Mi | 32 Gi |
| system-mysql | 250 m | 制限なし | 512 Mi | 2 Gi |
| system-postgresql | 250 m | 制限なし | 512 Mi | 2 Gi |
| backend-listener | 500 m | 1000 m | 550 Mi | 700 Mi |
| backend-worker | 150 m | 1000 m | 50 Mi | 300 Mi |
| backend-cron | 50 m | 150 m | 40 Mi | 80 Mi |
| backend-redis | 1000 m | 2000 m | 1024 Mi | 32 Gi |
| apicast-production | 500 m | 1000 m | 64 Mi | 128 Mi |
| apicast-staging | 50 m | 100 m | 64 Mi | 128 Mi |
| zync | 150 m | 1 | 250 M | 512 Mi |
| zync-que | 250 m | 1 | 250 M | 512 Mi |
| zync-database | 50 m | 250 m | 250 M | 2 G |
2.5.14. コンポーネントレベルでのノードのアフィニティーおよび容認のカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
APIManager CR 属性を使用して Red Hat 3scale API Management ソリューションの Kubernetes の アフィニティー および 容認 をカスタマイズし、インストールのさまざまな 3scale コンポーネントが Kubernetes ノードにスケジュールされる場所および方法をカスタマイズします。
以下の例では、バックエンドのカスタムノードのアフィニティーを設定します。また、system-memcached のリスナーおよびカスタム容認も設定します。
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
backend:
listenerSpec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "kubernetes.io/hostname"
operator: In
values:
- ip-10-96-1-105
- key: "beta.kubernetes.io/arch"
operator: In
values:
- amd64
system:
memcachedTolerations:
- key: key1
value: value1
operator: Equal
effect: NoSchedule
- key: key2
value: value2
operator: Equal
effect: NoSchedule
関連情報
アフィニティーおよび容認に関連する属性の完全リストは、APIManager CRD を参照してください。
2.5.15. 調整 リンクのコピーリンクがクリップボードにコピーされました!
3scale をインストールしたら、3scale operator により、カスタムリソース (CR) からの特定パラメーターセットを更新してシステム設定オプションを変更することができます。変更は ホットスワップ により行われます。つまり、システムの停止やシャットダウンは発生しません。
APIManager カスタムリソース定義 (CRD) のパラメーターがすべて調整可能な訳ではありません。
調整可能なパラメーターのリストを以下に示します。
2.5.15.1. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
すべての 3scale コンポーネントに対するリソースの制限およびリクエスト
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
resourceRequirementsEnabled: true/false
2.5.15.2. バックエンドレプリカ リンクのコピーリンクがクリップボードにコピーされました!
バックエンド コンポーネントの Pod 数
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
backend:
listenerSpec:
replicas: X
workerSpec:
replicas: Y
cronSpec:
replicas: Z
2.5.15.3. APIcast レプリカ リンクのコピーリンクがクリップボードにコピーされました!
APIcast ステージングおよび実稼働環境コンポーネントの Pod 数
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
apicast:
productionSpec:
replicas: X
stagingSpec:
replicas: Z
2.5.15.4. システムレプリカ リンクのコピーリンクがクリップボードにコピーされました!
システム アプリケーションおよびシステム sidekiq コンポーネントの Pod 数
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
system:
appSpec:
replicas: X
sidekiqSpec:
replicas: Z
2.5.15.5. Zync レプリカ リンクのコピーリンクがクリップボードにコピーされました!
Zync アプリケーションと que コンポーネントの Pod 数
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
spec:
zync:
appSpec:
replicas: X
queSpec:
replicas: Z