10 エンタープライズ・デプロイメント用のOracle Cloud Infrastructureの準備
Oracle Container Engine for Kubernetesを使用してOracle Cloud Infrastructure (OCI)にIdentity and Access Managementをデプロイする場合は、デプロイメントを容易にするためにOCIを構成する必要があります。デプロイメントの実行に必要なOCIコンポーネントを作成します。
ノート:
このガイドに記載されている手順は、公開時に正しいものです。OCIインタフェースの進化する性質により、オプションにわずかな変更がある場合があります。最新のステップを取得するには、Oracle Cloud Infrastructureのドキュメントを参照してください。- OCIデプロイメントについて
この図は、OCIにOracle Identity and Access Managementをデプロイするために必要なすべてのOCIコンポーネントを示しています。これは、様々なネットワーク要件と、OCIコンポーネントがこれらのネットワークにどのように適合するかを示します。各サブネットはセキュリティ・リストによって保護されます。 - SSHキー・ペアの作成
Oracle Cloudコンソールと要塞ノードを使用して、OCIを構成できます。SSL証明書によって、要塞ノード、コンピュート・インスタンス、OKEワーカー・ノードおよびデータベース・ホストへのセキュアなアクセスが提供されます。OCIの構成に使用するホストでSSL証明書を作成する必要があります。このホストは、ラップトップまたはデスクトップにすることができます。 - OCIコンパートメントの作成
デプロイメントを保持するために、OCIテナンシにコンテナを作成します。 - OCIでのOKEクラスタの作成
OKEでクラスタを作成するには、ユーザー入力を最小限に抑えた、クイック・クラスタを作成する方法と、より柔軟性の高い、クラスタを手動で作成する方法の2つの方法があります。 - 要塞ノードの作成
クラスタは専用サブネット内にあるため、クラスタに直接アクセスすることはできません。クラスタにアクセスするには、要塞ノードを使用します。要塞ノードは、パブリックに使用可能です。 - Oracle HTTP Serverのコンピュート・インスタンスの作成
Web層は、ロード・バランサとアプリケーション層の両方から分離された独自のサブネットに存在します。この項では、Web層に2つのコンピュート・インスタンスを作成し、それらを異なるフォルト・ドメインに配置して、アクセスを容易にするセキュリティ・リストおよびルート表を設定する手順について説明します。 - ファイル・システムとマウント・ターゲットの作成
Kubernetes永続ボリュームおよびOracle HTTP Serverインストール用のNFSファイル・システムを作成する必要があります。 - ロード・バランサの作成
2つのOCIロード・バランサを作成する必要があります。これらのロード・バランサの1つは、パブリック・トラフィックを転送するために使用され、もう1つは内部コールバック用です。内部トラフィックに使用されるロード・バランサは、OCIコンテナの外部では使用できません。 - ネットワーク・ロード・バランサの作成
このステップは、トラフィックをKubernetesワーカー・ノードにルーティングするようにロード・バランサを構成する場合にのみ必要です。 - データベースの作成
OCIでは、複数の異なるデータベースを作成できます。この例では、ベア・メタルRACデータベースを作成します。場合によっては、1つ以上のデータベースを作成する必要があります。 - ボールトの作成
ボールトは、デプロイメントの資格証明を格納するために使用されます。現時点では、ボールトを使用するOracle Identity and Access Management製品はOracle Advanced Authentication (OAA)のみです。OAAでは、OCIベースのボールト(推奨)またはファイルベースのボールトを使用できます。 - DNSサーバーの作成
このタスクはオプションです。ロード・バランサの仮想ホストを含め、すべてのホスト名を解決できることが重要です。ローカルのhostsファイルにエントリを追加することで、これらを解決可能にできます。ただし、OCIでは、プライベートDNSサーバーを使用する方が簡単な方法です。 - Kubernetes CoreDNSの更新
- 環境の検証
この項で説明するチェックを実行して、デプロイメントの準備が整った環境になっていることを確認します。 - ディザスタ・リカバリ環境の準備
ディザスタ・リカバリ環境は、プライマリ環境のレプリカで、プライマリ・リージョンとは別のリージョンに配置します。この環境は、プライマリ環境に障害が発生した場合にスイッチ・オーバーするスタンバイ環境です。
親トピック: エンタープライズ・デプロイメントの準備
OCIデプロイメントについて
この図は、OCIにOracle Identity and Access Managementをデプロイするために必要なすべてのOCIコンポーネントを示しています。これは、様々なネットワーク要件と、OCIコンポーネントがこれらのネットワークにどのように適合するかを示します。各サブネットはセキュリティ・リストによって保護されます。
図10-1 OKE用のOCIレイアウトの図

- VCN: 環境への外部アクセスを提供する1つのパブリック仮想クラウド・ネットワークがあります。セキュリティ上の理由から、VCNは複数のサブネットに分割されます。
- サブネット: ネットワーク・トラフィックが必要な領域にのみルーティングされるように、VCNは複数のサブネットに分割されます。たとえば、データベース・サブネットへのトラフィックは、インターネットから直接使用できません。トラフィックは、データベース・サブネットと対話するアプリケーション(OKE)層でのみ使用可能です。
- セキュリティ・リスト: セキュリティ・リストは、許可されたポートおよびプロトコルに基づいて、サブネットに対するトラフィックのみを許可する追加のセキュリティ・レイヤーを提供します。
- 要塞ノード: 要塞ノードは、ログインできるVCN内のコンピュート・インスタンスです。要塞ノードは、デプロイメント内のすべてのコンポーネントと通信できます。要塞ノードは、環境の設定と継続的な管理に使用されます。したがって、要塞ノードへのアクセスをロック・ダウンして、SSLキー・ペアを使用して登録されている企業ネットワーク上のクライアントのみがアクセスできるようにする必要があります。
- ロード・バランサ: 2つのLBaaSサービスがOCIフレームワーク内に作成されます。パブリック・ロード・バランサは、インターネットからOracle Identity and Access Managementデプロイメントにアクセスするために使用されます。プライベート・ロード・バランサは、内部トラフィック用です。ルーティングはVCNの外部では使用できません。パブリック・ロード・バランサは、デプロイメントでインターネットに接続する唯一の部分です(要塞ノードを除く)。
- Oracle Container Engine for Kubernetes (OKE): これは、アプリケーションがKubernetesコンテナ内にデプロイされる場所です。これは、インターネットに直接認識されません。Oracle HTTP Serverは、OKEクラスタにデプロイされません。これらのサーバーは、独立した非武装地帯(DMZ)に配置されます。
- コンピュート・インスタンス: Oracle HTTP Serverをホストするには、少なくとも2つのコンピュート・インスタンスが必要です。これらは、ロード・バランサの下にある非武装地帯(DMZ)に配置されます。ロード・バランサは、リクエストをOHSサーバーに送信します。これにより、OKEクラスタ内に存在するアプリケーションにトラフィックが渡されます。
- データベース: データベースは、OKEクラスタの下にある専用サブネットに存在します。
- DNS: DNSサーバーはオプションです。これは、名前解決のために内部的に使用されます。個々のホスト・ファイルにエントリを保持することで、名前解決を実現できます。
次の各項では、この図に示されているコンポーネントを設定する手順について説明します:
SSHキー・ペアの作成
Oracle Cloudコンソールと要塞ノードを使用して、OCIを構成できます。SSL証明書によって、要塞ノード、コンピュート・インスタンス、OKEワーカー・ノードおよびデータベース・ホストへのセキュアなアクセスが提供されます。OCIの構成に使用するホストでSSL証明書を作成する必要があります。このホストは、ラップトップまたはデスクトップにすることができます。
デバイスで証明書を作成したら、それをOCIリソースと共有して、リソースへのアクセスとそれらの管理を有効にします。複数のデバイスを使用する場合は、それらのすべてのデバイスに対してSSLキーを登録する必要があります。
使用するデバイスのSSL証明書がない場合は、次のコマンドを使用して証明書を作成します:
ssh-keygen -t rsa -N "" -b 2048 -f id_rsa
このコマンドにより、ホーム・ディレクトリ内の.ssh
ディレクトリに2つのファイルid_rsa
およびid_rsa.pub
が作成されます。これらは、OCIリソースへのアクセスに使用する証明書ファイルです。
OCIコンパートメントの作成
デプロイメントを保持するために、OCIテナンシにコンテナを作成します。
- Oracle Cloud Infrastructureコンソールにログインし、「アイデンティティ」を選択して、「コンパートメント」をクリックします。
- 「コンパートメントの作成」をクリックします。
- 名前と説明を指定します。
- 「コンパートメントの作成」をクリックします。
OCIでのOKEクラスタの作成
クイック・クラスタを使用したOKEクラスタの作成
OCIを準備する最初のステップは、OKEクラスタの作成です。このステップでは、仮想クラウド・ネットワーク、OKEクラスタおよびワーカー・ノードを作成します。
デフォルト設定でクイック・クラスタを作成するには:
親トピック: OCIでのOKEクラスタの作成
OKEクラスタの手動作成
OKEクラスタを手動で作成するには、この項で説明するステップを完了する必要があります。たとえば、2つのVCNをリンクしてプライマリ・デプロイメントに1つのVCNを使用し、もう1つをDR (ディザスタ・リカバリ)デプロイメントに使用する場合は、ネットワークCIDRS/IPアドレスが重複しないようにすることが不可欠です。
たとえば、プライマリ・ネットワークには10.0.0.0/16、DRネットワークには10.1.0.0/16を使用できます。
親トピック: OCIでのOKEクラスタの作成
Oracle Virtual Cloud Networkの作成
これらのステップでは、パブリック・サブネットとプライベート・サブネットを作成します。
親トピック: OKEクラスタの手動作成
APIセキュリティ・リストの作成
親トピック: OKEクラスタの手動作成
APIサブネットの作成
親トピック: OKEクラスタの手動作成
要塞ノードの作成
クラスタは専用サブネット内にあるため、クラスタに直接アクセスすることはできません。クラスタにアクセスするには、要塞ノードを使用します。要塞ノードは、パブリックに使用可能です。
ノート:
要塞ノードは、使用している環境への入り口です。そのため、要塞ノードへのアクセスは厳密に制御する必要があります。要塞ノードの作成には、次のステップが含まれます:
セキュリティ・リストの作成
要塞ノードがKubernetesクラスタで使用されるサブネットと通信できるように、セキュリティ・リストを作成する必要があります。また、インターネットから要塞ノードへのアクセスを許可する必要があります。この項では、このアクセスを有効にするために実行する必要がある最小限のステップについて説明します。特定のマシン/ネットワークのみがこのノードにアクセスできるように、セキュリティ・リストを強固にする必要があります。以前に生成されたSSLキーを超えるアクセス制限に関する情報は、このドキュメントの範囲外です。
セキュリティ・リストを作成するには:
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」 > 「仮想クラウド・ネットワーク」を選択し、仮想クラウド・ネットワークの名前をクリックします。
- リソースのリストから「セキュリティ・リスト」を選択します。
プライベート・セキュリティ・リストの作成
表10-3 イングレス・ルールとエグレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | 宛先ポート範囲 |
---|---|---|---|---|---|
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
22 |
|
イングレス |
CIDR |
10.0.1.0/29 |
ICMP |
||
エグレス |
CIDR |
0.0.0.0/0 |
すべてのプロトコル |
ノート:
10.0.1.0は、要塞ノードに使用するサブネットです。この値は、必要に応じて変更できます。親トピック: セキュリティ・リストの作成
パブリック・セキュリティ・リストの作成
表10-4 イングレス・ルールとエグレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | 宛先ポート範囲 | タイプ |
---|---|---|---|---|---|---|
イングレス |
CIDR |
0.0.0.0/0 |
TCP |
22 |
||
イングレス |
CIDR |
10.0.1.0/29 |
ICMP |
3 |
||
イングレス |
CIDR |
0.0.0.0/0 |
ICMP |
|||
エグレス |
CIDR |
0.0.0.0/0 |
すべてのプロトコル |
ノート:
10.0.1.0は、要塞ノードに使用するサブネットです。この値は、必要に応じて変更できます。特に記載がないかぎり、値を空白のままにしておきます。親トピック: セキュリティ・リストの作成
設定セキュリティ・リストの作成
Oracle Identity and Access Managementの設定中に、要塞ノードでは、ビルド・プロセスの一環として作成される一部のKubernetesサービスへのアクセスが必要です。
ビルド・プロセスの完了後、アクセスは必要ありません。管理上の理由から、この目的のために別個のセキュリティ・リストを作成します。そのため、設定が完了したら、サブネットからセキュリティ・リストを削除する必要があります。さらに設定が必要な場合は、必要に応じて追加できます。
-
ノード・マネージャのプライベート・サブネット
-
db-subnet。
設定セキュリティ・リストを作成するには:
表10-5 イングレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | ソース・ポート範囲 | 宛先ポート範囲 | コメント |
---|---|---|---|---|---|---|---|
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
30701 |
OAM管理サーバーのKubernetesサービス・ポート |
||
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
31800 |
|||
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
31920 |
ノート:
前述の宛先ポートは、インストールに指定する値によって異なります。サンプル値は、このガイド内で一貫性を保つために使用されます。
Elasticsearchをデプロイする場合は、31800および31920の宛先ポート範囲が必要です。
親トピック: セキュリティ・リストの作成
ルート表の作成
要塞ノードがKubernetesクラスタで使用されるサブネットと通信できるように、ルート表を作成する必要があります。また、インターネットから要塞ノードへのアクセスを有効にする必要があります。
ルート表を作成するには:
親トピック: 要塞ノードの作成
Kubernetesノード・サブネットへのセキュリティ・リストの追加
要塞サブネットとKubernetesクラスタ・サブネット間の通信を有効にするには、Kubernetesノード・サブネットにプライベート・セキュリティ・リストを追加する必要があります。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- Kubernetesクラスタ・サマリー画面で、
oke-vcn-quick-clustername-id
のようなVCN名をクリックします。 oke-nodesubnet-quick-clustername-id-regional
のようなKubernetesノード・ネットワークをクリックします。- 「セキュリティ・リストの追加」をクリックします。
- コンパートメントを選択します。
- プライベート要塞セキュリティ・リストを選択します。たとえば:
bastion-private-seclist
。 - 「セキュリティ・リストの追加」をクリックします。
- 前述のステップを繰り返して、
bastion-setup-seclist
セキュリティ・リストを追加します。
親トピック: 要塞ノードの作成
要塞コンピュート・インスタンスの作成
ネットワークの詳細を定義したら、要塞ノードを作成します。
親トピック: 要塞ノードの作成
要塞ノードへの接続
次のSSHコマンドを使用して要塞ノードに接続できます:
ssh -i id_rsa opc@BastionIPAddress
または、SSHエージェント転送を使用することで、サーバーにキーを(パスフレーズなしで)残すかわりにローカルSSHキーを使用する場合、次のコマンドを使用できます:
ssh -A opc@BastionIPAddress
親トピック: 要塞ノードの作成
要塞ノードの構成
要塞ノードを作成したら、それを構成する必要があります。要塞ノードを構成するには、次のステップを実行します:
ノート:
この項のステップを実行するには、Oracle Cloud Infrastructureコンソールから次の情報が必要です:
- ユーザーOCID: ユーザーOCIDを取得するには、OCIコンソールでプロファイル(右上)をクリックし、「ユーザー設定」を選択してOCIDを表示します。
- テナンシOCID: テナンシOCIDを取得するには、Oracle Cloud Infrastructureコンソールでプロファイル(右上)をクリックし、テナンシを選択してテナンシOCIDを表示します。
- リージョン: クラスタをデプロイしたリージョン。
- KubeconfigをダウンロードするためのOCI CLIの設定
- Helmのインストール
- Gitのインストール
- X11パッケージのインストール
- その他のパッケージのインストール
- X11転送の有効化
- ホスト・ファイルの設定
親トピック: 要塞ノードの作成
Helmのインストール
Helmは、WebLogic OperatorおよびOracle Unified Directoryで必要です。要塞ノードにHelmをインストールするには、次のコマンドを実行します:
$ curl -fsSL -o get_helm.sh
https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
$ helm version
version.BuildInfo{Version:"v3.13.1",
GitCommit:"3547a4b5bf5edb5478ce352e18858d8a552a4110",
GitTreeState:"clean", GoVersion:"go1.20.8"}
親トピック: 要塞ノードの構成
Gitのインストール
Gitには、Oracle Fusion MiddlewareをKubernetesにデプロイするためのサンプル・コードが含まれます。次のコマンドを使用して、GITをインストールします:
sudo yum install git -y
親トピック: 要塞ノードの構成
X11パッケージのインストール
セキュリティ上の理由から、Oracle HTTP ServerはKubernetesクラスタ内にインストールされません。Oracle HTTP Serverをインストールするには、X11パッケージをインストールしてX11転送を有効にする必要があります。次のコマンドを使用して、X11パッケージをインストールします:
sudo yum install -y libXrender libXtst xauth xterm nc
親トピック: 要塞ノードの構成
その他のパッケージのインストール
sudo yum install -y openldap java
自動化スクリプトの使用方法の詳細は、「Identity and Access Managementエンタープライズ・デプロイメントの自動化」を参照してください。
親トピック: 要塞ノードの構成
ホスト・ファイルの設定
curl
コマンドを作成する必要があります。要塞ノードではプライベートDNSが使用されるため、ロード・バランサ・エンド・ポイントに対して返されるIPアドレスは、要塞ホストからアクセスできない内部ネットワークを経由します。この問題を回避するには、各エントリ・ポイントの要塞ホスト・ファイルに、ロード・バランサのパブリックIPアドレスを指すエントリを作成します。
ノート:
ロード・バランサを作成するまで、このステップは実行できません。「ロード・バランサの作成」を参照してください。129.1.1.3 login.example.com prov.example.com iadadmin.example.com igdadmin.example.com
親トピック: 要塞ノードの構成
Oracle HTTP Serverのコンピュート・インスタンスの作成
Web層は、ロード・バランサとアプリケーション層の両方から分離された独自のサブネットに存在します。この項では、Web層に2つのコンピュート・インスタンスを作成し、それらを異なるフォルト・ドメインに配置して、アクセスを容易にするセキュリティ・リストおよびルート表を設定する手順について説明します。
サービス・ゲートウェイの作成
Web層にはインターネットから直接アクセスできません。ただし、必要なパッケージの追加やアップグレードの実行のためにyumにアクセスするなどの操作を実行するには、内部リソースにアクセスする必要があります。これらの内部システムへのアクセスを有効にするには、サービス・ゲートウェイを作成する必要があります(システムで自動的に作成されなかった場合)。
サービス・ゲートウェイを作成するには:
セキュリティ・リストの作成
Web層ノードがKubernetesクラスタで使用されるサブネットと通信できるように、セキュリティ・リストを作成する必要があります。また、ロード・バランサからWeb層ホストへのアクセスを有効にする必要があります。この項では、このアクセスを有効にするために実行する必要がある最小限のステップについて説明します。特定のマシン/ネットワークのみがこのノードにアクセスできるように、セキュリティ・リストを強固にする必要があります。この部分は、このガイドの範囲外です。
セキュリティ・リストを作成するには:
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」 > 「仮想クラウド・ネットワーク」を選択し、仮想クラウド・ネットワークの名前をクリックします。
- リソースのリストから「セキュリティ・リスト」を選択します。
OHSセキュリティ・リストの作成
Oracle Identity Managementの実行中に、Web層ホストは、プロビジョニング・プロセスの一環として作成されるKubernetesサービスにリクエストをパス・スルーします。この通信を有効にするには、セキュリティ・リストを作成する必要があります。
表10-6 イングレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | プロトコル | 宛先ポート範囲 | コメント |
---|---|---|---|---|---|
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30701 |
OAM管理サーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30510 |
OAMポリシー・マネージャのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30410 |
OAMサーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30711 |
OIG管理サーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30140 |
OIMサーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30801 |
SOAサーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30901 |
OUDSMサーバーのKubernetesサービス・ポート |
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
30777 |
Nginxイングレス・コントローラ |
ノート:
この表にリストされている宛先ポートは、インストールに指定する値によって異なります。KubernetesサブネットへのOHSセキュリティ・リストの追加
Kubernetesで使用されるサブネットにセキュリティ・リストを追加する必要があります。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」 > 「仮想クラウド・ネットワーク」を選択し、仮想クラウド・ネットワークの名前をクリックします。
- 表示されるサブネットのリストからKubernetesサブリストを選択します。サブネットの名前は、
oke-nodesubnet-<ClusterName>-<id>
のようになります。 - 「セキュリティ・リストの追加」をクリックします。
- 前に作成したコンパートメントとセキュリティ・リストを選択します。たとえば:
ohs-seclist
。「OCIコンパートメントの作成」および「OHSセキュリティ・リストの作成」を参照してください。 - 「セキュリティ・リストの追加」をクリックします。
OHSコンピュート・インスタンスの作成
ネットワーキングを定義したら、Web層ノード自体を作成できます。
サマリー画面に、Web層ノードに割り当てられたプライベートIPアドレスが表示されます。このアドレスを書き留めます。ノードに接続するときにこれが必要になります。
2番目のノードで各ステップを繰り返します。
OHSコンピュート・インスタンス・フォルト・ドメインの編集
OHSノードへの接続
Web層ホストに直接接続することはできません。要塞ノードを使用する必要があります。要塞ノードに接続した後で、Web層ホストに接続できます。「要塞ノードへの接続」を参照してください。
ノート:
コンピュート・インスタンスの作成時に、ホストへの接続に使用するSSHキーを指定しました。ラップトップ/デスクトップと同じキーを使用した場合は、SSHエージェント転送を使用してWebホストに接続する必要があります。または、要塞ホストで作成したSSHキーを使用することもできます。次のSSHコマンドを使用して、要塞ノードからWebホストに接続できます:
ssh -i id_rsa opc@webhostIPAddress
または、SSHエージェント転送を使用することで、サーバーにキーを(パスフレーズなしで)残すかわりにローカルSSHキーを使用する場合、同じパス・スルー・コマンドを使用できます:
ssh -A opc@webIPAddress
OHSノードの構成
Web層ノードを作成したら、それらを構成する必要があります。ノードを構成するには、次のステップを実行します:
X11パッケージのインストール
セキュリティ上の理由から、Oracle HTTP ServerはKubernetesクラスタ内にインストールされません。Oracle HTTP Serverをインストールするには、X11パッケージをインストールしてX11転送を有効にする必要があります。
次のコマンドを使用して、X11パッケージをインストールします:
sudo yum repolist
sudo yum install -y libXrender libXtst xauth xterm nc xorg-x11*
親トピック: OHSノードの構成
追加パッケージのインストール
Oracle HTTP Serverでは、インストールの一部として追加のパッケージが存在する必要があります。次のコマンドを使用して、これらの追加パッケージをインストールします:
sudo yum install -y libaio-devel* compat-libstdc++-* compat-libcap* gcc-c++-* ksh* libnsl*
親トピック: OHSノードの構成
Oracle HTTP Serverで使用するためのコンピュート・インスタンスの準備
場合によっては、Oracle HTTP Serverのインストールおよびカーネル・パラメータの設定に必要な追加のLinuxパッケージをインストールする必要もあります。「エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備」を参照してください。
親トピック: OHSノードの構成
ファイアウォールの使用
コンピュート・インスタンスは、Oracle Linuxイメージを使用して作成されます。イメージには、デフォルトで有効になっている組込みのファイアウォールが付属しています。ネットワークにセキュリティ・ルールが定義されていても、Linuxサーバーは、組込みのLinuxファイアウォールが原因でこれらのリクエストを拒否します。
この特別なファイアウォールを使用するか、OCIセキュリティ・ルールに依存するかを決定できます。
親トピック: OHSノードの構成
ファイアウォールの無効化
ファイアウォールを無効にするには、次のコマンドを実行します:
sudo systemctl stop firewalld
sudo systemctl disable firewalld
親トピック: ファイアウォールの使用
ソフトウェア所有者アカウントの作成
OPCユーザーを使用してOracleソフトウェアをインストールすることは、お薦めしません。それより、ソフトウェアを所有するカスタム・ユーザーを作成することをお薦めします。カスタム・ユーザーを作成するには、次のコマンドを実行します:
sudo adduser -u 1001 oracle
sudo groupadd -g 1002 oinstall
sudo usermod -a -G oinstall oracle
sudo usermod -g oinstall oracle
親トピック: OHSノードの構成
ホスト・ファイルの準備
OCI環境内のネットワークの性質は、Oracle HTTP Serverインスタンスがパブリック・ロード・バランサにアクセスできないことを意味します。これにより、Oracle HTTP Serverが一部の仮想ホストにアクセスしようとしたときに問題が発生する可能性があります。
以降の項では、外部からユーザーのシステムへの接続用にパブリック・ロード・バランサを作成します。「パブリック・ロード・バランサの作成」を参照してください。
プライベート・サブネットからこのロード・バランサにリクエストをルーティングできるように、プライベート・ロード・バランサも作成します。「プライベート・ロード・バランサの作成」を参照してください。
/etc/hosts
ファイルに次のようなエントリを作成する必要があります:IP ADDRESS OF PRIVATE LOAD BALANCER login.example.com
10.0.2.7 login.example.com
親トピック: OHSノードの構成
OHSをインストールするためのコンピュート・インスタンスへの接続
Oracle HTTP Serverをインストールするには、グラフィカル表示にアクセスする必要があります。このアクセスを取得するには、X11転送を使用する必要があります。
OHSのインストール手順の詳細は、「Oracle HTTP Serverのインストールと構成」を参照してください。
親トピック: OHSノードの構成
ファイル・システムとマウント・ターゲットの作成
Kubernetes永続ボリュームおよびOracle HTTP Serverインストール用のNFSファイル・システムを作成する必要があります。
作成する必要があるファイル・システムについては、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。
エンタープライズ・デプロイメント用のファイル・システムの準備の概要
記憶域は、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。
この章では、エンタープライズ・デプロイメント用のファイル・システムを準備するプロセスの概要について説明します。この章の情報に従って記憶域を設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。
親トピック: ファイル・システムとマウント・ターゲットの作成
ファイル・システムのサマリー
作成する必要があるファイル・システムの詳細は、表4-3を参照してください。
ファイル・システムを要塞ノードにマウントする必要があるのは、初期設定時のみです。
親トピック: ファイル・システムとマウント・ターゲットの作成
ファイル・システムの作成
ノート:
最初の永続ボリューム(PV)に対してのみ、新しいマウント・ターゲットを作成します。後続のPVは、同じマウント・ターゲットを使用する必要があります。親トピック: ファイル・システムとマウント・ターゲットの作成
マウント・ターゲット・ストレージ・レポートの設定
Oracle製品をインストールすると、インストーラによって使用可能なディスク・ストレージがチェックされます。OCIファイル・システムを使用する場合、このチェックは失敗します。ディスク領域が不足していることを示すメッセージが表示されます。このエラーを抑止するため、指定した空き領域の容量をレポートするようにOCIを構成できます。
親トピック: ファイル・システムとマウント・ターゲットの作成
PVセキュリティ・リストの作成
使用するサブネットと同じサブネットにマウント・ポイントを作成しましたが、それにアクセスするにはセキュリティ・リストを作成する必要があります。Web層エントリはすでに追加されています。ただし、さらにOHSマウント・ターゲットのセキュリティ・リストを作成する必要があります。
表10-7 イングレス・ルールとエグレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | ソース・ポート範囲 | 宛先ポート範囲 |
---|---|---|---|---|---|---|
イングレス |
CIDR |
10.0.10.0/24 |
TCP |
111 |
||
イングレス |
CIDR |
10.0.10.0/24 |
TCP |
2048-2050 |
||
イングレス |
CIDR |
10.0.10.0/24 |
UDP |
111 |
||
イングレス |
CIDR |
10.0.10.0/24 |
UDP |
2048 |
||
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
111 |
||
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
2048-2050 |
||
イングレス |
CIDR |
10.0.1.0/29 |
UDP |
111 |
||
イングレス |
CIDR |
10.0.1.0/29 |
UDP |
2048 |
||
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
111 |
||
イングレス |
CIDR |
10.0.2.0/28 |
TCP |
2048-2050 |
||
イングレス |
CIDR |
10.0.2.0/28 |
UDP |
111 |
||
イングレス |
CIDR |
10.0.2.0/28 |
UDP |
2048 |
||
エグレス |
CIDR |
10.0.10.0/24 |
TCP |
111 |
||
エグレス |
CIDR |
10.0.10.0/24 |
TCP |
2048-2050 |
||
エグレス |
CIDR |
10.0.10.0/24 |
UDP |
111 |
||
エグレス |
CIDR |
10.0.1.0/29 |
TCP |
111 |
||
エグレス |
CIDR |
10.0.1.0/29 |
TCP |
2048-2050 |
||
エグレス |
CIDR |
10.0.1.0/29 |
UDP |
111 |
||
エグレス |
CIDR |
10.0.2.0/28 |
TCP |
111 |
||
エグレス |
CIDR |
10.0.2.0/28 |
TCP |
2048-2050 |
||
エグレス |
CIDR |
10.0.2.0/28 |
UDP |
111 |
ノート:
要塞サブネットのルールが必要なのは、初期設定/構成のみです。親トピック: ファイル・システムとマウント・ターゲットの作成
サブネットへのセキュリティ・リストの追加
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」 > 「仮想クラウド・ネットワーク」を選択し、仮想クラウド・ネットワークの名前をクリックします。
- oke-nodesubnetを選択します。
- 「セキュリティ・リストの追加」をクリックします。
- 前に作成したセキュリティ・リストを選択します。たとえば:
pv-seclist
。「PVセキュリティ・リストの作成」を参照してください。 - 「セキュリティ・リストの追加」をクリックします。
- サブネット
web-subnet
およびbastion-subnet
についてステップ1から6を繰り返します。
親トピック: ファイル・システムとマウント・ターゲットの作成
ホストへのファイル・システムのマウント
各マウント・ターゲットには異なるIPアドレスがあります。特定のファイル・システムのマウント方法を決定するには:
親トピック: ファイル・システムとマウント・ターゲットの作成
ロード・バランサの作成
2つのOCIロード・バランサを作成する必要があります。これらのロード・バランサの1つは、パブリック・トラフィックを転送するために使用され、もう1つは内部コールバック用です。内部トラフィックに使用されるロード・バランサは、OCIコンテナの外部では使用できません。
ロード・バランサの詳細は、「ロード・バランシングの開始」を参照してください。
パブリック・ロード・バランサの作成
このロード・バランサは、インターネットからOracle HTTP Serverにトラフィックを転送し、次にそのトラフィックをKubernetesポッドに渡します。
パブリック・ロード・バランサは、SSLを介してユーザーを対象にトラフィックを送信しますが、トラフィックはOCI仮想ネットワーク内で移動した後、暗号化されずに送信されます。復号化はSSL終端によって発生します。テストのために、独自のSSL証明書を指定するか、自己署名証明書を作成する必要があります。
パブリック・ロード・バランサを作成するには、次のステップを実行します:
- 自己署名証明書の作成
- セキュリティ・リストの作成
- ルート表の作成
- ロード・バランサのサブネットの作成
- ロード・バランサの作成
- ロード・バランサ証明書のアップロード
- ホスト名の作成
- リスナーの作成
- デフォルト・リスナーの更新
親トピック: ロード・バランサの作成
自己署名証明書の作成
openssl
パッケージにアクセスできる任意のホストで自己署名証明書を作成できます。次に、Linuxマシンでの例を示します(この例では要塞サーバーが使用されています)。
詳細は、ドキュメントID 2617046.1を参照してください。
必要に応じて、正当な認証局から提供された証明書を使用することもできます。
自己署名証明書を作成するには:
ca.crt
loadbalancer.crt
loadbalancer.key
親トピック: パブリック・ロード・バランサの作成
セキュリティ・リストの作成
セキュリティ・リストによって、ロード・バランサにアクセスできるユーザーと、ロード・バランサがリクエストを送信できる場所が決まります。
プライベート・セキュリティ・リストを作成するには:
表10-9 イングレス・ルールとエグレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | 宛先ポート範囲 |
---|---|---|---|---|---|
イングレス |
CIDR |
0.0.0.0/0 |
TCP |
80 |
|
イングレス |
CIDR |
0.0.0.0/0 |
TCP |
443 |
|
エグレス |
CIDR |
10.0.2.0/28 |
TCP |
7777 |
ノート:
10.0.2.0は、Web層に使用するサブネットです。親トピック: パブリック・ロード・バランサの作成
ロード・バランサのサブネットの作成
パブリック・ロード・バランサは、分離されたサブネットに配置されます。ロード・バランサは、一方が失敗しても他方がワークロードを引き継げるように、ペアとして作成されます。ロード・バランサは可用性ドメインに存在し、ロード・バランサごとに異なるサブネットが作成されます。ロード・バランサに異なるサブネットを使用することで、ロード・バランサにのみパブリック・アクセスを許可し、ロード・バランシングするコンポーネントは対象にしない厳格なアクセス・ルールを作成します。
親トピック: パブリック・ロード・バランサの作成
ロード・バランサ証明書のアップロード
ロード・バランサはSSLリクエストをルーティングするため、ロード・バランサの証明書をアップロードする必要があります。自己署名証明書を作成した場合は、その証明書の詳細を追加します。独自の証明書がある場合は、それらをアップロードします。
証明書をアップロードするには:
親トピック: パブリック・ロード・バランサの作成
ホスト名の作成
ホスト名は、ロード・バランサに対する様々なエントリ・ポイントをフィルタするために使用されます。「エンタープライズ・デプロイメントに必要なロード・バランサ仮想サーバーのサマリー」で説明されているロード・バランサ仮想ホストごとにホスト名を作成する必要があります。
次のホスト名を作成する必要があります:
iadadmin.example.com
igdadmin.example.com
login.example.com
prov.example.com
ロード・バランサ・ホスト名を作成するには:
ノート:
管理アクセスをネットワーク内のユーザーに制限する場合は、プライベート・ロード・バランサにホストiadadmin.example.com
およびigdadmin.example.com
を作成する必要があります。
親トピック: パブリック・ロード・バランサの作成
リスナーの作成
前に作成したホスト名ごとにリスナーを作成する必要があります。「ホスト名の作成」を参照してください。iadadmin
リスナーは、ロード・バランサの作成時に作成されています。「ロード・バランサの作成」を参照してください。
表10-10 パブリック・ロード・バランサ・リスナーのサマリー
名前 | プロトコル | ポート | SSL | バックエンド・セット | ホスト名 |
---|---|---|---|---|---|
|
http |
80 |
ohs_servers |
|
|
|
http |
80 |
ohs_servers |
|
|
|
https |
443 |
あり |
ohs_servers |
|
|
https |
443 |
あり |
ohs_servers |
|
ロード・バランサ・リスナーを作成するには:
ノート:
管理アクセスをネットワーク内のユーザーに制限する場合は、プライベート・ロード・バランサにリスナーiadadmin.example.com
およびigdadmin.example.com
を作成します。
親トピック: パブリック・ロード・バランサの作成
デフォルト・リスナーの更新
ロード・バランサを作成すると、デフォルト・リスナーも作成されます。新しく作成したホスト名をこのリスナーに割り当てる必要があります。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」に移動し、「ロード・バランサ」をクリックします。
- ロード・バランサをクリックします。たとえば: public-loadbalancer。
- リソース・リストから「リスナー」を選択します。
- リスナーを編集するには、名前の横にある3つのドットをクリックし、「編集」をクリックします。
- 前に作成したホスト名にホスト名を設定します。たとえば: iadadmin。「ホスト名の作成」を参照してください。
- 「リスナーの更新」をクリックします。
親トピック: パブリック・ロード・バランサの作成
プライベート・ロード・バランサの作成
内部コールバックのルーティングに使用されるプライベート・ロード・バランサは、Oracle Webサーバーと同じサブネットに存在します。このロード・バランサは、アプリケーション内から生成されたリクエストを処理します。
ノート:
Webサーバーは、curl
コマンドをlogin.example.com
に対して発行します。また、Webサーバーはパブリック・ロード・バランサに直接アクセスできないため、プライベート・ロード・バランサにこれを定義する必要があります。パブリック・ロード・バランサの作成時に使用したものと同じ証明書を使用できます。
プライベート・ロード・バランサを作成するには、次のステップを実行します:
ホスト名の作成
ホスト名は、ロード・バランサに対する様々なエントリ・ポイントをフィルタするために使用されます。「エンタープライズ・デプロイメントに必要なロード・バランサ仮想サーバーのサマリー」で説明されているロード・バランサ仮想ホストごとにホスト名を作成する必要があります。
igdinternal.example.com
login.example.com
iadadmin.example.com
igdadmin.example.com
ノート:
login.example.com
は、内部トラフィック・ルーティング用にここで定義されています。EDGはネットワーク分離を使用します。ここで定義しない場合、login.example.com
へのコールはパブリック・ネットワークを使用して通信を試行し、失敗します。
ロード・バランサ・ホスト名を作成するには:
親トピック: プライベート・ロード・バランサの作成
デフォルト・リスナーの更新
ロード・バランサを作成すると、デフォルト・リスナーも作成されます。新しく作成したホスト名をこのリスナーに割り当てる必要があります。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」に移動し、「ロード・バランサ」をクリックします。
- ロード・バランサをクリックします。たとえば: internal_loadbalancer。
- リソース・リストから「リスナー」を選択します。
- リスナーを編集するには、名前の横にある3つのドットをクリックし、「編集」をクリックします。
- 前に作成したホスト名にホスト名を設定します。たとえば: igdinternal。「ホスト名の作成」を参照してください。
- 「リスナーの更新」をクリックします。
親トピック: プライベート・ロード・バランサの作成
ロード・バランサ証明書のアップロード
ロード・バランサはSSLリクエストをルーティングするため、ロード・バランサの証明書をアップロードする必要があります。自己署名証明書を作成した場合は、その証明書の詳細を追加します。独自の証明書がある場合は、それらをアップロードします。
証明書をアップロードするには:
親トピック: プライベート・ロード・バランサの作成
リスナーの作成
前に作成したホスト名ごとにリスナーを作成する必要があります。「ホスト名の作成」を参照してください。
表10-11プライベート・ロード・バランサ・リスナーのサマリー
名前 | プロトコル | ポート | SSL | バックエンド・セット | ホスト名 |
---|---|---|---|---|---|
igdinternal |
http |
7777 |
なし |
ohs_servers |
|
login |
https |
443 |
あり |
ohs_servers |
|
iadadmin |
http |
80 |
なし |
ohs_servers |
|
igdadmin |
http |
80 |
なし |
ohs_servers |
|
ロード・バランサ・リスナーを作成するには:
親トピック: プライベート・ロード・バランサの作成
ネットワーク・ロード・バランサの作成
このステップは、トラフィックをKubernetesワーカー・ノードにルーティングするようにロード・バランサを構成する場合にのみ必要です。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」に移動し、「ロード・バランサ」をクリックします。
- 「ロード・バランサの作成」をクリックします。
- 「ネットワーク・ロード・バランサ」を選択し、「ロード・バランサの作成」をクリックします。
- 「ネットワーク・ロードバランサの作成」セクションで、次の情報を指定します:
- ロード・バランサ名: ロード・バランサの名前を選択します。例: k8workers。
- 可視性タイプ: 「プライベート」を選択します。
- 仮想クラウド・ネットワーク: 「仮想クラウド・ネットワーク」を選択します。
- サブネット: Kubernetesワーカー・ノードと同じサブネットを選択します。例: one-nodesubnet-quick-<clustername>-<id>。
- コンパートメント: コンパートメントを選択します。
- 「次」をクリックします。
- 「リスナー」画面で、次の情報を指定します:
- リスナー: 「TCP」を選択します。
- タイプ: 「TCP」を選択します。
- 「任意のポートを使用」を選択します。
- 「次」をクリックします。
- 「バックエンド・セット」画面で、次の情報を指定します:
- バックエンド・セット名: 「K8Workers」を選択します。
- 「バックエンドの追加」をクリックします。
- 「バックエンド」画面で、すべてのワーカー・ノードが選択されていることを確認し、「バックエンドの追加」をクリックします。
- ヘルス・チェック・ポリシー - 「TCP」を選択し、ポートを22に設定します。他の値にはすべてデフォルト値を使用します。
- 「次」をクリックします。
- 詳細を確認し、「作成」をクリックします。
データベースの作成
OCIでは、複数の異なるデータベースを作成できます。この例では、ベア・メタルRACデータベースを作成します。場合によっては、1つ以上のデータベースを作成する必要があります。
作成すべきデータベースとサービスの詳細は、「エンタープライズ・デプロイメント用の既存のデータベースの準備」を参照してください。この項では、OCIでこれらのデータベースのいずれかを作成する例を示します。
セキュリティ・リストの作成
表10-12 イングレス・ルールとエグレス・ルールの説明
ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | 宛先ポート範囲 |
---|---|---|---|---|---|
イングレス |
CIDR |
0.0.0.0/0 |
TCP |
22 |
|
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
1521 |
|
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
6200 |
|
イングレス |
CIDR |
10.0.10.0/24 |
TCP |
1521 |
|
イングレス |
CIDR |
10.0.10.0/24 |
TCP |
6200 |
|
イングレス |
CIDR |
10.0.1.0/29 |
TCP |
1521 ノート: 設定にのみ使用されます。 |
|
エグレス |
CIDR |
0.0.0.0/0 |
すべてのプロトコル |
ノート:
10.0.11.0は、データベースに使用するサブネットです。この値は、必要に応じて変更できます。親トピック: データベースの作成
データベースの作成
ネットワークを確立したら、データベースを作成できます。
ノート:
データベースが作成されると、OCIによってデータベース名に接尾辞が付けられます。Ensure that you use the complete name including this suffix when configuring the database as described in 「エンタープライズ・デプロイメント用の既存のデータベースの準備」の説明に従って、データベースを構成するときは、この接尾辞も含めた完全な名前を使用してください。親トピック: データベースの作成
セカンダリ・プラガブル・データベースの作成
データベースを作成すると、単一のプラガブル・データベース(PDB)が作成されます。場合によっては、単一のPDBでニーズに十分に対応できます。
ただし、OAM、OIG、OIRIおよびOAAが同じデータベースで異なるPDBを使用するためにさらにPDBが必要な場合は、追加のPDBを作成する必要があります。「既存のPDBをテンプレートとして使用したPDBの作成」を参照してください。
これは、データベース・レベルで、またはOracle OCIを使用している場合はOCIコンソールを介して実行できます。データベース・レベルでPDBを追加する方法は、「既存のPDBをテンプレートとして使用したPDBの作成」を参照してください。
- テナンシのOracle Cloud Infrastructureにログインします。
- 「Oracle Database」に移動し、「Oracleベース・データベース(VM、BM)」をクリックします。
- データベースをホストしているDBシステムをクリックします。
- 表示されたデータベースのリストから「コンテナ・データベース名」をクリックします。
- 「リソース」メニューの「プラガブル・データベース」をクリックします。
- 「プラガブル・データベースの作成」をクリックします。
- 新しいプラガブル・データベースの名前を追加し、コンテナ・データベースのTDEウォレット・パスワードを入力します。明示的な値を設定しない場合、このパスワードはデータベースのSYSパスワードと同じにすることができます。
- 「プラガブル・データベースの作成」をクリックします。
- 必要な追加のプラガブル・データベースごとに、ステップ6からステップ8を繰り返します。
親トピック: データベースの作成
データベース・ノードへの接続
次のSSHコマンドを使用してデータベース・ノードに接続できます:
ssh -A opc@databaseNodeIPAdddress
コマンドを使用して要塞ノードからDBノード1に接続します:
ssh -A opc@dbnode1
opc
としてDBノード1に接続した後、次のコマンドを使用してoracleユーザーに接続します:
sudo su - oracle
親トピック: データベースの作成
データベースの構成
スケルトン・データベースを作成したら、「エンタープライズ・デプロイメント用の既存のデータベースの準備」の説明に従ってデータベースを構成する必要があります。
親トピック: データベースの作成
ボールトの作成
ボールトは、デプロイメントの資格証明を格納するために使用されます。現時点では、ボールトを使用するOracle Identity and Access Management製品はOracle Advanced Authentication (OAA)のみです。OAAでは、OCIベースのボールト(推奨)またはファイルベースのボールトを使用できます。
- テナンシのOracle Cloud Infrastructureにログインします。
- 「アイデンティティとセキュリティ」を選択し、「ボールト」をクリックします。
- 「ボールトの作成」をクリックし、次の詳細を指定します:
- コンパートメント - 前に作成したコンパートメントを選択します。「OCIコンパートメントの作成」を参照してください。
- 名前 - ボールトの名前を入力します。例: oaavault。
- 「プライベート・ボールトにする」を選択します。
- 「ボールトの作成」をクリックします。
APIキーの作成
- Oracle Cloud Infrastructureコンソールにログインします。
- 「プロファイル」を選択し、「ユーザー設定」をクリックします。
- 「ユーザー設定」画面で、「APIキー」を選択します。
- 「APIキーの追加」をクリックします。
- 「APIキーのダウンロード」をクリックします。このファイルは安全に保管してください。
- 「追加」をクリックします。
- 「閉じる」をクリックします。
親トピック: ボールトの作成
DNSサーバーの作成
このタスクはオプションです。ロード・バランサの仮想ホストを含め、すべてのホスト名を解決できることが重要です。ローカルのhostsファイルにエントリを追加することで、これらを解決可能にできます。ただし、OCIでは、プライベートDNSサーバーを使用する方が簡単な方法です。
デフォルトでは、コンピュート・ホストは、プライベートDNSサーバーを使用するように構成されます。ローカル・ホストにのみエントリを追加する必要があります。
DNSレコードの作成
ゾーンを作成したら、各ホストのゾーンにレコードを作成できます。作成する必要のあるDNSレコードには、2つのタイプがあります:
- Aレコード: これは、IPアドレスとホスト名の関連付けです。
- CNAME: これは、Aレコードの別名です。
同じIPアドレスを使用している複数のホストがある場合、1つのAレコードと複数のCNAMEレコードを作成することをお薦めします。
レコードを作成するには:
親トピック: DNSサーバーの作成
Kubernetes CoreDNSの更新
Kubernetesクラスタは、組込みのCoreDNSサーバーを使用してホスト名を解決します。デフォルトでは、このサーバーは企業DNSサーバーと対話しません。このサーバーは、アプリケーション・エンド・ポイントのローカル・ホスト名解決を実行するか、企業DNSサーバーを使用してこれらのエンド・ポイントを解決するように構成する必要があります。
-
coredns_custom.yaml
というカスタム・ホストで構成マップを作成します。たとえば:apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom namespace: kube-system data: example.server: | example.com { hosts { 1.1.1.1 login.example.com 1.1.1.2 prov.example.com 1.1.1.3 iadadmin.example.com 1.1.1.4 igdadmin.example.com 1.1.1.5 igdinternal.example.com fallthrough } }
- ファイルを保存します。
-
次のコマンドを使用して、構成マップを作成します:
kubectl create -f coredns_custom.yaml
- 次のコマンドを使用してCoreDNSを再起動します:
kubectl rollout restart -n kube-system deploy coredns
次のコマンドを使用して、CoreDNSポッドが問題なく再起動することを確認します:kubectl get pods -n kube-system
次のコマンドを使用して、カスタム構成がロードされていることを確認します:kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
エラーが発生した場合は、次のコマンドを使用してエラーを表示します:kubectl logs -n kube-system coredns--<ID>
configmapを再度編集してエラーを修正します。
環境の検証
この項で説明するチェックを実行して、デプロイメントの準備が整った環境になっていることを確認します。
要塞ノードについて
- ネットワーク接続を確認してください
ping webhost1.example.com
ping webhost2.example.com
- ロード・バランサのパブリック・アドレスを解決します
ping login.example.com
ping prov.example.com
- Kubernetesが機能していることを確認します
kubectl get nodes
前述のコマンドの出力としてリストされた各ワーカー・ノードをpingします。
Web層から
-
kubernetesワーカー・ノード名が解決可能であることを確認します
nslookup k8workers
-
Web層が、通信するポートを含むKubernetesワーカー・ノードと通信できるかどうかを確認します。イングレス・コントローラを使用している場合、これはそのイングレス・コントローラに割り当てられたノード・ポートになります。個々のNodePortサービスを使用している場合は、これらの各ポートを確認する必要があります。
ネットワーク接続を確認するには、次のコマンドを使用します:
nc -zv <WORKER_NODE> <PORT>
たとえば、イングレス・サーバーがNodePortサーバー30777を使用している場合、コマンドは次のようになります:
nc -zv 1.1.1.1 30777
Ncat: バージョン7.70 ( https://nmap.org/ncat )。
Ncat: 1.1.1.1:30777に接続されました。
Ncat: 0.01秒で0バイト送信、0バイト受信。
-
ロード・バランサのパブリック・アドレスを解決します
ping login.example.com
ディザスタ・リカバリ環境の準備
ディザスタ・リカバリ環境は、プライマリ環境のレプリカで、プライマリ・リージョンとは別のリージョンに配置します。この環境は、プライマリ環境に障害が発生した場合にスイッチ・オーバーするスタンバイ環境です。
スタンバイ環境は別のクラスタに配置し、理想的にはデータ・センターも別にします。クラスタがアプリケーション専用の場合、2つ目のクラスタは、プライマリ・クラスタのミラーにする必要があり、ワーカー・ノードの数と仕様を同一にします。クラスタが、様々なアプリケーションに使用される多目的クラスタの場合は、スタンバイ・サイトに予備の容量が十分にあることを確認し、プライマリ・クラスタのアプリケーション・ワークロードをすべて実行できるようにします。
各Kubernetesクラスタで実行するオペレーティング・システムのバージョンとKubernetesのメジャー・リリースは同一にします。
ネットワークは次のようになります:
- プライマリとスタンバイのデータベース・ネットワークが相互に通信するため、Data Guardデータベースの作成が簡単です。
- プライマリとスタンバイのファイル・システム・ネットワークが相互に通信するため、ファイル・システム・データのレプリケーションが簡単です。クラスタ内でのレプリケーションを実現するために
Rsync
プロセスを実行する必要がある場合、プライマリKubernetesワーカー・ネットワークは、スタンバイ・サイトのKubernetesワーカー・ネットワークと通信することが可能です。 - グローバル・ロード・バランサにより、プライマリ・サイトとスタンバイ・サイト間のトラフィックが転送されます。このロード・バランサは、オンサイト通信に使用されるサイト固有のロード・バランサに依存しないことが多いです。
- ロード・バランサで使用されるSSL証明書は、各ロード・バランサで同じであることが必要です。ロード・バランサによってサイトが切り替えられても、トラフィックに影響が出ないようにする必要があります。
DR環境を作成する方法は、いくつかあります。このドキュメントでは、次のことを想定しています:
- プライマリ環境の正確なレプリカを作成する。
- DR環境は、プライマリ環境と同じテナンシに存在する。
- DR環境は、プライマリ環境と同じコンパートメントに存在する。
- DR環境は、プライマリ環境と異なるリージョンに存在する。
プライマリ環境と同じステップでスタンバイ環境を作成してから、次の特性を持つOKEクラスタを作成するステップを実行します:
- VCNでは別のCIDRを使用する必要がある。たとえば、プライマリ・クラスタは
10.0.0.0/16
で、スタンバイ・クラスタは10.1.0.0/16
です。 - サブネットでは異なるIPアドレス範囲を使用する。たとえば、プライマリ・サブネットは
10.0.4.0/24
で、同等のスタンバイ・サブネットは10.1.4.0/24
です。 - ロード・バランサの仮想ホスト名は同一。
- ロード・バランサのSSL証明書は同一。
- 使用するポートは同一。
- Webホスト名は同一。
- 専用の要塞ノードが存在。
両方の環境を作成したら、次のステップを追加で実行します:
動的ルーティング・ゲートウェイの作成
2つの異なる仮想クラウド・ネットワーク(VCN)が相互に通信できるようにするには、動的ルーティング・ゲートウェイ(DRG)が欠かせません。DRGはそれぞれのサイトに必要です。そのため、各サイトで次の手順を実行します。
親トピック: ディザスタ・リカバリ環境の準備
サイト1およびサイト2のVCNの接続
このステップを実行する前に、両方のサイトに動的ルーティング・ゲートウェイ(RPG) (「動的ルーティング・ゲートウェイの作成」を参照)と、リモート・ピアリング接続(RPC) (「リモート・ピアリング接続の作成」を参照)が作成されていることを確認します。次のステップを実行すると、2つのサイトをリンクできます。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」を選択し、「動的ルーティング・ゲートウェイ」をクリックします。
- 先ほど作成した動的ルーティング・ゲートウェイを選択します。たとえば、
site1-DRG
です。「動的ルーティング・ゲートウェイの作成」を参照してください。 - リソースのリストから、「リモート・ピアリング接続アタッチメント」を選択します。
- 「リモート・ピアリング接続アタッチメント」セクションで、先ほど作成したリモート・ピアリング接続を選択します。たとえば、
site1-RPC
です。「リモート・ピアリング接続の作成」を参照してください。画面上部に表示される「リモート・ピアリング接続OCID」をメモします。
サイト2で次のステップを実行します:
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」を選択し、「動的ルーティング・ゲートウェイ」をクリックします。
- 先ほど作成した動的ルーティング・ゲートウェイを選択します。たとえば、
site1-DRG
です。「動的ルーティング・ゲートウェイの作成」を参照してください。 - リソースのリストから、「リモート・ピアリング接続アタッチメント」を選択します。
- 「リモート・ピアリング接続アタッチメント」セクションで、サイト2に作成したリモート・ピアリング接続を選択します。たとえば、
site2-RPC
です。手順については、「リモート・ピアリング接続の作成」を参照してください。 - 「接続の確立」をクリックして、次の情報を入力します:
- リージョン: サイト1をホストするリージョンを選択します。
- リモート・ピアリング接続OCID: 先ほど取得したサイト1のRPC OCIDを入力します。
- 「接続の確立」をクリックします。
「ピアリング・ステータス」が「ピアリング済」に変わります。この変更には数分かかる場合があります。
親トピック: ディザスタ・リカバリ環境の準備
動的ルーティング・ゲートウェイのルーティング表の作成
サイト1のサブネットがサイト2のサブネットと通信するには、両方向にルーティング・エントリを作成する必要があります。
親トピック: ディザスタ・リカバリ環境の準備
サブネットのセキュリティ・リストの作成
サブネット間にルートを作成したら、ネットワークごとにセキュリティ・リストを作成し、対応するサブネットに追加する必要があります。
- テナンシのOracle Cloud Infrastructureコンソールにログインします。
- 「ネットワーキング」を選択し、「仮想クラウド・ネットワーク」をクリックします。
- リソースのリストから、「セキュリティ・リスト」を選択します。
- セキュリティ・リストを選択します。たとえば、
db-seclist
です。 - リソースのリストから、「イングレス・ルール」を選択します。
- 「イングレス・ルールの追加」をクリックします。
- 表10-14および表10-15の説明に従って、情報を入力します。
- 「イングレス・ルールの追加」をクリックします。
- リソースのリストから、「エグレス・ルール」を選択します。
- 「イングレス・ルールの追加」をクリックします。
- 表10-14および表10-15の説明に従って、情報を入力します。
- 「イングレス・ルールの追加」をクリックします。
表10-16 サイト1のセキュリティ・リスト
リスト | ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | ソース・ポート範囲 | 宛先ポート範囲 | タイプ |
---|---|---|---|---|---|---|---|---|
db-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
TCP |
1521 |
|||
db-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
TCP |
6200 |
|||
VCNのプライベート・サブネットのセキュリティ・リスト |
イングレス |
CIDR |
10.1.11.0/24 |
31444 |
||||
Pv-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
TCP |
111 |
|||
Pv-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
TCP |
2048-2050 |
|||
Pv-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
UDP |
111 |
|||
Pv-seclist |
イングレス |
CIDR |
10.1.11.0/24 |
UDP |
2048 |
|||
Pv-seclist |
エグレス |
CIDR |
10.1.11.0/24 |
TCP |
111 |
|||
Pv-seclist |
エグレス |
CIDR |
10.1.11.0/24 |
TCP |
2048-2050 |
|||
Pv-seclist |
エグレス |
CIDR |
10.1.11.0/24 |
UDP |
111 |
|||
Pv-seclist |
エグレス |
CIDR |
10.1.11.0/24 |
UDP |
2048 |
表10-17 サイト2のセキュリティ・リスト
リスト | ルール・タイプ | タイプ | ソースCIDR | 宛先CIDR | プロトコル | ソース・ポート範囲 | 宛先ポート範囲 | タイプ |
---|---|---|---|---|---|---|---|---|
db-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
1521 |
|||
db-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
6200 |
|||
VCNのプライベート・サブネットのセキュリティ・リスト |
イングレス |
CIDR |
10.0.11.0/24 |
31444 |
||||
Pv-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
111 |
|||
Pv-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
TCP |
2048-2050 |
|||
Pv-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
UDP |
111 |
|||
Pv-seclist |
イングレス |
CIDR |
10.0.11.0/24 |
UDP |
2048 |
|||
Pv-seclist |
エグレス |
CIDR |
10.0.11.0/24 |
TCP |
111 |
|||
Pv-seclist |
エグレス |
CIDR |
10.0.11.0/24 |
TCP |
2048-2050 |
|||
Pv-seclist |
エグレス |
CIDR |
10.0.11.0/24 |
UDP |
111 |
|||
Pv-seclist |
エグレス |
CIDR |
10.0.11.0/24 |
UDP |
2048 |
親トピック: ディザスタ・リカバリ環境の準備