5.3. 実行プレーン


テストジョブとクリーンアップジョブは、デフォルトまたはコントローラー実行プレーンでのみ実行できます。その他のすべての自動化は、実行プレーンで実行されるように設定する必要があります。

AWS サブスクリプションの Ansible Automation Platform Service の一部として、実行プレーンを実行するための 10 個の Red Hat Enterprise Linux (RHEL) エンタイトルメントが付与されます。追加の RHEL または OpenShift ライセンスは別途購入できます。

5.3.1. 形状

実行プレーンのサイズと形状は、自動化のタイプとメッシュに接続されている場所によって異なります。自動化メッシュの実装には、次のガイドラインを使用します。

Ansible Automation Platform の最小要件:

  • ホップノード: Red Hat Ansible Automation Platform Service on AWS には、顧客が実行ノードとピアリングするために使用できる 2 つのホップノードが含まれています。通常、最小限のリソースのみ必要です。ホップノードの形状は、接続されている実行ノードの数によって異なります。2 つの仮想 CPU と 2 GB の RAM を備えた仮想マシン (VM) は、2 - 4 個の実行ノードにトラフィックをルーティングできます。

  • 場所の数が少ない (特定の地域やクラウドなど) 自動化の場合は、垂直方向にスケーリングできる仮想マシンの数が少ないメッシュを作成します。ほとんどのクラウドとハイパーバイザーでは、最小限のダウンタイムで形状を変更できます。
  • CPU または RAM を集中的に使用する自動化の場合は、より大きなマシンの形状を使用します。
  • 複数の場所にまたがる自動化の場合は、それらの場所に接続するノードを含めてメッシュを作成します。
  • 実行プレーンのコストを削減するには、ARM などのさまざまな CPU アーキテクチャーと予約インスタンスの使用を検討してください。
  • 自動化メッシュで冗長性を設定するには、同じリージョン内の異なるアベイラビリティーゾーンに同じシェイプのメッシュノードを少なくとも 2 つ設定し、各マシンを両方のホストされたホップノードに接続します。
  • 実行プレーンの自動スケーリングが必要な場合は、OpenShift を使用します。

5.3.2. ネットワーク

5.3.2.1. 自動化メッシュ

Ansible Automation Platform Service on AWS は、デフォルトの “mesh-ingress” ホップノードを提供します。このようにホストされたホップノードを使用すると、実行ノードは顧客のプライベートネットワークからの Egress を通じて自動化作業をポーリングできるため、受信ファイアウォールポートを開く必要がなくなります。ホストされたホップノードは、受信トラフィックにポート 443 を使用します。

以下は、このモデルを使用して Ansible Automation Platform Service on AWS に接続された、Egress 専用のインターネットアクセスを持つプライベートアドレス空間内の実行ノードの例です。

Execution node in a private address space

また、コントロールプレーンから実行プレーンへのアウトバウンド接続を使用して自動化メッシュを設定し、自動化メッシュで使用されるポートを指定することもできます。

手順は マネージドクラウドまたは Operator 環境のドキュメントの自動化メッシュ を使用できます。

5.3.2.2. 接続性

実行プレーンは、次の条件下でコントロールプレーンと通信できます。

  • Polling (mesh-Ingress): 実行ノードは、ステートフル Egress トラフィックをポート 443 経由で Ansible Automation Platform デプロイメントドメインにルーティングする必要があります。
  • Push: Ansible Automation Platform が実行ノードに情報をプッシュできるようにするには、顧客のリモートネットワークで設定可能なファイアウォールポートを解放しておく必要があります。

ファイアウォール、プロキシーサーバー、および同様のサービスの背後に自動化メッシュノードを設定できます。これらのサービスは、自動化メッシュの機能に影響を与えるヘッダー、ペイロード、その他の情報を変更することなく、Ansible Automation Platform から発信されたトラフィックをルーティングまたはプロキシーします。

カスタマーサポートリクエスト を介して Red Hat サポートチームに CIDR ブロックを提供することで、コントロールプレーンへのアクセスを制限できます。これは、コントロールプレーンへのインバウンドアクセスを制御します。これは、パブリックインターネット経由のトラフィックに提供する IP 範囲に制限します。これらのルールの適用は、PrivateLink を介したトラフィックには適用されません。これらの制限は、コントロールプレーンから発信されるアウトバウンドトラフィックには影響しません。

5.3.3. モニタリング

実行プレーン上で、任意の監視および強化ツールを設定できます。責任を持って運用、機能、メンテナンスを行い、実行プレーンの操作に干渉しないようにします。

実行プレーン上の追加のワークロードには、ツールがデプロイされている仮想マシンまたは OpenShift クラスターからの追加リソースが必要です。これらの追加要件を満たすために、リソースのサイズを適宜確認してください。

5.3.4. DNS

実行ノードは、DNS クエリーにホストマシンの DNS 設定を使用します。自動化実行中に適切なルックアップを確実に実行できるように、標準の RHEL ネットワークプラクティスを使用して DNS を設定します。

5.3.5. 重複する CIDR ブロックを使用したネットワーク

自動化メッシュは、コントロールプレーンを、同じ Classless Inter-Domain Routing (CIDR) ブロック (つまり、異なるクラウドまたはデータセンター間で繰り返される同じクラス A アドレス空間) を共有する複数のネットワークに接続します。実行ノードは、デプロイメントネットワークをローカルネットワークと見なします。各ネットワークで自動化をターゲットにするには、インスタンスグループとペアになっている実行ノードインスタンスが少なくとも 1 つ必要です。

5.3.6. 更新とメンテナンス

自動化メッシュ実行ノードは、コントロールプレーンが更新されたときに実行プレーンにパッチを適用する必要性を最小限に抑えるように設計されています。ただし、今後、テクノロジーを更新する場合は、お客様が関与し、各実行プレーンノードのコンポーネントを更新する必要があります。パッチが必要な場合は、自動化メッシュノードの更新プロセスに従う必要があります。Receptor の更新に関するヘルプは、管理対象クラウドまたは Operator 環境の自動化メッシュReceptor の更新 セクションを参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat