OCIコンテナ・インスタンスを使用して、コンテナ化されたアプリケーションの管理を合理化します

コンテナ化されたアプリケーションの実行には、仮想マシンのインスタンス化、コンテナ・イメージを実行するためのコンポーネントのインストール、およびそれをサポートするためのすべての依存関係(ソフトウェアおよびオペレーティング・システムの更新を含む)およびそれらをサポートするためのアプリケーションの監視など、多大なオーバーヘッドが必要になることがあります。これらは、最適に実行され、使用可能で、危険にさらされていないことを確認するために実行されます。

コンテナ・インスタンスは完全管理型のOracle Cloud Infrastructure (OCI)コンピュート・サービスであり、顧客はサーバーを管理せずにコンテナ化されたアプリケーションを実行できます。これにより、インフラストラクチャをデプロイおよび管理するのではなく、アプリケーションに価値を付加することに集中できるサーバーレスなエクスペリエンスが提供されます。

あるいは、コンテナ・インスタンスなしでコンテナ化されたアプリケーションを実行するには、顧客は仮想マシンをインスタンス化し、すべてのコンポーネントをインストールしてコンテナ・イメージを実行する必要があります。これには、DockerやPodmanなどのコンテナ・ランタイムと、それをサポートするためのすべての依存関係が含まれます。また、お客様は最新のセキュリティ・パッチをインストールし、適切なセキュリティ設定を適用することで、仮想マシンを保護する必要があります。ソフトウェアおよびオペレーティング・システムの新しい更新が導入されたら、更新およびパッチを一貫して適用する必要があります。アプリケーションが実行中の場合、アプリケーションが最適に動作し、使用可能で、危険にさらされていないことを確認するために監視を行う必要があります。

コンテナ・インスタンスの場合、顧客はアプリケーションのコンテナ・イメージを作成してコンテナ・レジストリに格納するだけで済みます。コンテナ化されたアプリケーションは、次のステップで、CLIコマンドを使用したコンテナ・インスタンスまたはOCIコンソールのガイド付きGUIウィザードを使用してデプロイできます。

  • コンテナ・インスタンス・パラメータの定義: 顧客は、コンテナ・インスタンスを実行するためのOCIリージョンと、オプションで可用性ドメインおよびフォルト・ドメインを定義します。次に、お客様はコンテナ・インスタンスのコンピュート・シェイプを選択します。インスタンスごとに、選択したコンピュート・シェイプのCPUおよびメモリーまで割り当てることができます。たとえば、AMDのE3/E4シェイプを選択した場合は、コンテナ・インスタンスで64 OCPU (128 vCPU)および1024 GBのメモリーを使用できます。次に、オプションの高度なネットワーク構成とともに、コンテナ・インスタンスにパブリックIPアドレスとコンテナ・インスタンスのサブネットが必要かどうかなどのネットワーク設定を追加します。このステップでは、プライベートDNSレコードおよびホスト名を指定することもできます。これにより、コンテナ・インスタンスの完全修飾ドメイン名が生成されます。また、コンテナ再起動ポリシーを設定するオプションの詳細オプションもあります。
  • アプリケーションの起動構成を指定します。このステップでは、コンテナ・イメージに必要な環境変数とともに、実行するコンテナ・イメージの場所が指定されます。イメージは、Oracle Cloud Infrastructure Registry、またはコンテナ・インスタンスにIP接続があるパブリックまたはプライベートのOpen Container Initiative準拠のレジストリに存在できます。プライベート・レジストリの場合、コンテナ・イメージにアクセスするための資格証明を指定する必要があります。
  • レビューおよび作成: 最後のステップは、すべての構成を確認し、すべての構成が正確である場合は作成を続行でき、コンテナ・インスタンスは数秒で起動されます。

顧客は、通常のOracle Cloud Infrastructure Computeと同じレートでインスタンスに割り当てられたCPUおよびメモリー・リソースに対してのみ課金されます。シンプルな操作性、シームレスな操作性、サーバーレスなエクスペリエンスに対する追加料金が不要なコンテナ・インスタンスは、クラウド内のコンテナ実行に最適な価値を提供します。お客様は、標準のデータベース接続メカニズムを使用して、MySQLサービスやOracle Autonomous Databaseなどの他のOCIサービスとコンテナ・インスタンスを統合することもできるため、コンテナ化されたアプリケーションに他のOCIサービスを簡単に利用できます。

アーキテクチャ

このアーキテクチャは、コンテナ・インスタンスを使用して、統合されたMySQLデータベースを含むコンテナ化されたWordPressアプリケーションをデプロイします。コンテナ・インスタンスは、インターネットからアクセス可能なパブリックIPアドレスを持つパブリック・サブネットにデプロイされます。

コンテナ・インスタンスは、コンテナ・オーケストレーションを必要としないスタンドアロン・アプリケーション用に設計されています。これには、API、Webアプリケーション、CI/CDジョブ、自動化タスク、データとメディア処理、開発およびテスト環境などがあります。オーケストレーションが必要なコンテナ化されたアプリケーションの場合、OCIは仮想ノードとのサーバーレス・オプションを備えた管理対象KubernetesサービスであるOracle Container Engine for Kubernetes (OKE)を提供します。

各コンテナ・インスタンスは複数のコンテナを実行できます。コンテナ・インスタンス内のすべてのコンテナは、同じライフサイクル、リソース、ネットワークおよびストレージを共有します。コンテナ・インスタンスのコンテナは、メイン・アプリケーション・コンテナおよびサイドカー・コンテナをサポートするKubernetesのポッドと同じ概念を持ちます。サイドカー・コンテナは、メイン・アプリケーション・コンテナの機能を拡張または拡張するために存在します。たとえば、メインWebアプリケーションを含むコンテナ・インスタンスと、Webアプリケーション・ログをロギング・サーバーにエクスポートするサイドカー・コンテナがあります。

ノート:

アプリケーション・コンテナとともにデータベース・コンテナを実行することは、開発およびテストにのみ適しています。本番デプロイメントでのOracle MySQL Database Serviceの使用を検討します。

このリファレンス・アーキテクチャでは、コンテナ・インスタンスを含む統合データベースを含むWordPressをデプロイします。次のビデオでは、プロセスについて説明します。

次の図は、このリファレンス・アーキテクチャを示しています。



oci- container- instance- wordpress- oracle.zip

アーキテクチャには次のコンポーネントがあります。

  • テナント

    テナンシは、Oracle Cloud Infrastructureへのサインアップ時にOracleがOracle Cloud内で設定するセキュアで分離されたパーティションです。テナンシ内のOracle Cloudでリソースを作成、編成および管理できます。テナンシは、会社または組織と同義です。通常、会社は1つのテナンシを持ち、そのテナンシ内の組織構造を反映します。通常、単一のテナンシは単一のサブスクリプションに関連付けられ、1つのサブスクリプションには通常1つのテナンシのみが含まれます。

  • リージョン

    Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的な領域です。リージョンは他のリージョンから独立しており、巨大な距離は(国全体または大陸間)分離できます。

  • コンパートメント

    コンパートメントは、Oracle Cloud Infrastructureテナンシ内のリージョン間論理パーティションです。コンパートメントを使用して、Oracle Cloudでリソースを編成し、リソースへのアクセスを制御して、使用割当て制限を設定します。特定のコンパートメント内のリソースへのアクセスを制御するには、誰がリソースにアクセスできるか、どのアクションを実行できるかを指定するポリシーを定義します。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各アベイラビリティ・ドメインの物理リソースは、フォルト・トレランスを提供する他のアベイラビリティ・ドメインのリソースから分離されます。アベイラビリティ・ドメインは、電力や冷却装置などのインフラや、内部の可用性ドメイン・ネットワークを共有しません。そのため、ある可用性ドメインでの障害が、リージョン内の他の可用性ドメインに影響することはほとんどありません。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインには、独立した電源とハードウェアを備えた3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散すると、アプリケーションは、フォルト・ドメイン内の物理サーバーの障害、システム・メンテナンスおよび電源障害を許容できます。

  • 仮想クラウド・ネットワーク(VCN)とサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義ネットワークです。従来のデータ・センター・ネットワークと同様に、CNはネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる複数の重複しないCIDRブロックを含めることができます。VCNをサブネットにセグメント化できます。これは、リージョンまたは可用性ドメインにスコープを設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックでもプライベートでもかまいません。

  • セキュリティ・リスト

    サブネットごとに、サブネットの内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

  • ネットワーク・アドレス変換(NAT)ゲートウェイ

    NATゲートウェイを使用すると、VCN内のプライベート・リソースは、受信インターネット接続にリソースを公開することなく、インターネット上のホストにアクセスできます。

  • サービス・ゲートウェイ

    サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.

  • コンテナ・レジストリ

    本番ワークフローへの開発を簡素化できるOracle管理レジストリ。

推奨

開始点として次の推奨事項を使用します。要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • VCN

    VCNを作成する際、VCNのサブネットにアタッチする予定のリソース数に基づいて、必要なCIDRブロックの数および各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。

    サブネットを設計する際は、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。

  • セキュリティ

    Oracle Cloud Guardを使用して、Oracle Cloud Infrastructureのリソースのセキュリティをプロアクティブに監視および保守します。Cloud Guardでは、セキュリティの弱点についてリソースを調べたり、リスクのあるアクティビティについてオペレータとユーザーをモニターするために定義できるディテクタ・レシピを使用します。構成の誤りや安全でないアクティビティが検出された場合、クラウド・ガードは、定義できるレスポンダ・レシピに基づいて、修正アクションを推奨し、それらのアクションの実行を支援します。

    最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーンのリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureはセキュリティ・ゾーン・レシピのポリシーに対して操作を検証し、ポリシーに違反する操作を拒否します。

  • クラウド・ガード

    Oracleが提供するデフォルトのレシピをクローニングおよびカスタマイズして、カスタム・ディテクタおよびレスポンダ・レシピを作成します。これらのレシピでは、警告を生成するセキュリティ違反のタイプと、それに対して実行できるアクションを指定できます。たとえば、可視性がpublicに設定されているオブジェクト・ストレージ・バケットを検出できます。

    クラウド・ガードをテナンシ・レベルで適用して、広範な範囲に対応し、複数の構成を維持する管理上の負担を軽減します。

    管理対象リスト機能を使用して、特定の構成をディテクタに適用することもできます。

  • セキュリティ・ゾーン

    最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーンのリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureはセキュリティ・ゾーン・レシピのポリシーに対する操作を検証し、ポリシーに違反する操作を拒否します。

  • ネットワーク・セキュリティ・グループ(NSG)

    NSGを使用して、特定のVNICに適用されるイングレスおよびエグレス・ルールのセットを定義できます。NSGではVCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストではなくNSGを使用することをお薦めします。

  • ロード・バランサの帯域幅

    ロード・バランサの作成時に、固定帯域幅を提供する事前定義済のシェイプを選択するか、帯域幅範囲を設定するカスタム(柔軟性のある)シェイプを指定して、トラフィック・パターンに基づいて帯域幅を自動的にスケーリングできます。どちらの方法でも、ロード・バランサの作成後にいつでもシェイプを変更できます。

承認

  • 原本著者: Rishikesh Palve、Chiping Hwang
  • 原本協力者: John Sulyok