インスタンスの作業

Oracle Cloud Infrastructure Computeでは、インスタンスと呼ばれるコンピュート・ホストをプロビジョニングおよび管理できます。コンピュートおよびアプリケーションの要件に合せ、必要に応じてインスタンスを作成できます。インスタンスを作成したら、コンピュータからインスタンスに安全にアクセスし、再起動、ボリュームのアタッチやデタッチを行い、完了時にはインスタンスを終了できます。

セキュリティ・ゾーン

セキュリティ・ゾーンによって、クラウド・リソースがOracleのセキュリティ原則に準拠していることが保証されます。セキュリティ・ゾーン・コンパートメント内のリソースに対する操作がそのセキュリティ・ゾーンのポリシーに違反している場合、その操作は拒否されます。

次のセキュリティ・ゾーン・ポリシーは、インスタンスの作成機能に影響します:

  • セキュリティ・ゾーン内のコンピュート・インスタンスのブート・ボリュームも同じセキュリティ・ゾーン内に存在する必要があります。
  • セキュリティ・ゾーンに存在しないコンピュート・インスタンスは、セキュリティ・ゾーンにあるブート・ボリュームを使用できません。
  • セキュリティ・ゾーンのコンピュート・インスタンスは、同じセキュリティ・ゾーンにあるサブネットを使用する必要があります。
  • プラットフォーム・イメージを使用して、セキュリティ・ゾーンのすべてのコンピュート・インスタンスを作成する必要があります。セキュリティ・ゾーンのカスタム・イメージからコンピュート・インスタンスを作成することはできません。
重要

リストされたセキュリティ・ゾーン・ポリシーの1つを実装しないと、インスタンスの作成が妨げられる場合があります。

インスタンスの使用に必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者がテナンシ管理者によってポリシーでセキュリティ・アクセス権が付与されたグループのメンバーである必要があります。コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。権限がない、または認可されていないというメッセージが表示された場合は、どのタイプのアクセス権があり、どのコンパートメントでアクセスが機能するかをテナンシ管理者に確認してください。

ヒント

インスタンスを作成する場合、他にもいくつかのリソース(イメージ、クラウド・ネットワーク、サブネットなど)が関係します。このようなその他のリソースは、インスタンスと同じコンパートメント にあっても、他のコンパートメントにあってもかまいません。インスタンスを起動するために、関係する各コンパートメントに対して必要なアクセス・レベルを持っている必要があります。これは、インスタンスにボリュームをアタッチする場合にも当てはまります。同じコンパートメントにある必要はありませんが、ない場合は、各コンパートメントに対して必要なアクセス・レベルを持っている必要があります。

管理者向け: ユーザーが作成編集および終了(削除)インスタンスを許可する最も単純なポリシーは、ユーザーによるコンピュート・インスタンスの起動にリストされます。これは、指定したグループに、インスタンスおよびイメージを管理するための一般的なアクセス権、および既存のブロック・ボリュームをインスタンスにアタッチするために必要なアクセス・レベルを付与します。指定されたグループがインスタンスの起動やボリュームのアタッチを必要としない場合、そのポリシーを簡素化し、manage instance-familyのみを含めて、volume-familyおよびvirtual-network-familyに関連する文を削除できます。

そのグループがブロック・ボリュームを作成する必要がある場合は、ブロック・ボリュームを管理する権限も必要になります。ボリューム管理者によるブロック・ボリューム、バックアップおよびボリューム・グループの管理を参照してください。

グループが特にコミュニティ・イメージにアクセスする必要がある場合は、コミュニティ・イメージを読み取る権限が必要です。コミュニティ・アプリケーションの公開に関する項を参照してください。

ポリシーを初めて使用する場合は、アイデンティティ・ドメインの管理および共通ポリシーを参照してください。インスタンス、クラウド・ネットワークまたは他のCore Services APIリソースのポリシーの記述に関する参照資料については、コア・サービスの詳細を参照してください。

一部のコンピュート・タスクでは、次の項で説明するように、追加のポリシーが必要です。

パートナ・イメージ・カタログ

グループがパートナ・イメージに基づいてインスタンスを作成する必要がある場合、パートナ・イメージ・カタログに対してイメージのサブスクリプションを作成するために、app-catalog-listingの管理権限が必要になります。ユーザーにパートナ・イメージ・カタログのイメージをリストしてサブスクライブさせる を参照してください。

SSHおよびリモート・デスクトップ・アクセス

ユーザーの場合: Secure Shell (SSH)またはリモート・デスクトップ接続を使用して実行中のインスタンスに接続する場合、アクセス権を付与するIAMポリシーは必要ありません。ただし、インスタンスのパブリックIPアドレスは必要です。

管理者の場合: ユーザーがインスタンスを起動できるポリシーがある場合、そのポリシーによって、おそらくユーザーがインスタンスのIPアドレスも取得できます。両方に対応する最も単純なポリシーは、ユーザーにコンピュート・インスタンスを起動させるを参照してください。

制限の厳しいポリシーでは、指定されたグループが既存のインスタンスのIPアドレスを取得して、インスタンスに対して電源アクション(インスタンスの停止や起動など)を使用することはできますが、インスタンスの起動または終了は行えないようにします。このポリシーでは、インスタンスとクラウド・ネットワークが同時に1つのコンパートメント(XYZ)にあると仮定しています。

Allow group InstanceUsers to read virtual-network-family in compartment XYZ
Allow group InstanceUsers to use instance-family in compartment XYZ

インスタンス・メタデータ・サービス(IMDS)

ユーザーの場合: インスタンスにログインして、cURLを使用してインスタンス・メタデータを取得する場合、IAMポリシーは必要ありません。

管理者向け: ユーザーはインスタンス・メタデータをコンピュートAPI (たとえば、GetInstance)を使用して取得することもできます。ユーザーにコンピュート・インスタンスを起動させるのポリシーはこの権限に対応しています。

作成された新しいインスタンスで従来のIMDSv1エンドポイントを無効にすることを要求するには、次のポリシーを使用します:

Allow group InstanceLaunchers to manage instances in compartment ABC 
  where request.instanceOptions.areLegacyEndpointsDisabled= 'true'

容量予約

管理者向け: 次の例は、容量予約へのアクセス権を付与する一般的なポリシーを示しています。ポリシー継承を介してすべてのコンパートメントにアクセス権が容易に付与されるように、テナンシにポリシーを作成します。アクセス範囲を特定のコンパートメントの容量予約のみに制限するには、テナンシのかわりにコンパートメントを指定します。

アクセス・タイプ: 予約でインスタンスを起動する機能。

Allow group InstanceLaunchers to use compute-capacity-reservations in tenancy
                            

アクセス・タイプ: 容量予約を管理する機能。

Allow group InstanceLaunchers to manage compute-capacity-reservations in tenancy
                            

コマンドの実行

管理者向け: コマンド機能の実行のポリシーを記述するには、次を実行します:

  1. コマンドの発行、コマンドの取消し、およびコンパートメント内のインスタンスのコマンド出力の表示を許可するユーザーを含むグループを作成します。次に、次のポリシーを記述して、グループにアクセス権を付与します:

    Allow group RunCommandUsers to manage instance-agent-command-family in compartment ABC
  2. コマンドの実行を許可するインスタンスを含む動的グループを作成します。たとえば、動的グループ内のルールでは次のように記述できます:

    any { instance.id = 'ocid1.instance.oc1.phx.<unique_ID_1>', 'ocid1.instance.oc1.phx.<unique_ID_2>' }
  3. 次のポリシーを記述して、動的グループにアクセス権を付与します:
    ノート

    インスタンスを作成してから動的グループに追加する場合、インスタンスがコマンドのポーリングを開始するまでに最大30分かかります。最初に動的グループを作成してからインスタンスを作成する場合、インスタンスの作成直後にコマンドのポーリングが開始されます。
    Allow dynamic-group RunCommandDynamicGroup to use instance-agent-command-execution-family in compartment ABC where request.instance.id=target.instance.id
  4. 動的グループがオブジェクト・ストレージ・バケットからスクリプト・ファイルにアクセスし、レスポンスをオブジェクト・ストレージ・バケットに保存できるようにするには、次のポリシーを記述します:

    Allow dynamic-group RunCommandDynamicGroup to read objects in compartment ABC where all {target.bucket.name = '<bucket_with_script_file>'}
    Allow dynamic-group RunCommandDynamicGroup to manage objects in compartment ABC where all {target.bucket.name = '<bucket_for_command_output>'}

コンピュート・インスタンスの推奨ネットワーキング起動タイプ

VMインスタンスを作成する際、デフォルトでは、Oracle Cloud Infrastructureにより、インスタンスのシェイプとOSイメージに基づいて、VNICの推奨ネットワーク・タイプが選択されます。ネットワーク・インタフェースが、ディスク入出力やネットワーク通信などの機能を処理します。

次のネットワーク・タイプを使用可能です:

  • 準仮想化ネットワーク: エンタープライズ・アプリケーション、マイクロサービス、スモール・データベースなどの汎用ワークロードの場合。また、準仮想化ネットワークは柔軟性が高く、異なるハードウェア・プラットフォームにまたがって同じイメージを使用できます。準仮想化ネットワークを含むLinuxイメージは、インフラストラクチャ・メンテナンス中のライブ移行をサポートします。
  • ハードウェア支援(SR-IOV)ネットワーク: シングル・ルートI/O仮想化。ビデオ・ストリーミング、リアルタイム・アプリケーション、大規模またはクラスタ化データベースなどの低レイテンシ・ワークロードの場合。ハードウェア支援(SR-IOV)ネットワークではVFIOドライバ・フレームワークが使用されます。
重要

特定のネットワーク・タイプを使用するには、シェイプとイメージの両方がそのネットワーク・タイプをサポートしている必要があります。

シェイプ: 次の表に、VMシェイプのデフォルト・ネットワーク・タイプとサポートされているネットワーク・タイプを示します。

シェイプ デフォルト・ネットワーク・タイプ サポートされているネットワーク・タイプ
VM.Standard1シリーズ SR-IOV 準仮想化、SR-IOV
VM.Standard2シリーズ 準仮想化 準仮想化、SR-IOV
VM.Standard3.Flex 準仮想化 準仮想化、SR-IOV
VM.Standard.E2シリーズ 準仮想化 準仮想化のみ
VM.Standard.E3.Flex

準仮想化

準仮想化、SR-IOV
VM.Standard.E4.Flex

準仮想化

準仮想化、SR-IOV
VM.Standard.E5.Flex

準仮想化

準仮想化、SR-IOV
VM.Standard.E6.Flex

準仮想化

準仮想化、SR-IOV
VM.Standard.A1.Flex1 準仮想化 準仮想化、SR-IOV
VM.DenseIO1シリーズ SR-IOV 準仮想化、SR-IOV
VM.DenseIO2シリーズ 準仮想化 準仮想化、SR-IOV
VM.DenseIO.E4.Flex 準仮想化 準仮想化、SR-IOV
VM.GPU2シリーズ SR-IOV 準仮想化、SR-IOV
VM.GPU3シリーズ SR-IOV 準仮想化、SR-IOV
VM.GPU.A10シリーズ SR-IOV 準仮想化、SR-IOV
VM.Optimized3.Flex

準仮想化

準仮想化、SR-IOV

イメージ: 準仮想化ネットワークは、次に示すプラットフォーム・イメージでサポートされています:

  • Oracle Linux 9、Oracle Linux 8、Oracle Autonomous Linux 8.x、Oracle Autonomous Linux 7.x、Oracle Linux Cloud Developer 8: すべてのイメージ。
  • Oracle Linux 7: 2019年3月以降に公開されたイメージ。
  • CentOS Stream 8、CentOS 7: 2019年7月以降に公開されたイメージ。
  • Ubuntu 22.04、Ubuntu 20.04: すべてのイメージ。
  • Ubuntu 18.04: 2019年3月以降に公開されたイメージ。
  • Windows Server 2022、Windows Server 2019: すべてのイメージ。
  • Windows Server 2016、Windows Server 2012 R2: 2019年8月以降に公開されたイメージ。

SR-IOVネットワークはすべてのプラットフォーム・イメージでサポートされていますが、次の例外があります:

  • Armベースのシェイプのイメージは、SR-IOVネットワークをサポートしていません。
  • Windows Server 2019およびWindows Server 2022では、VM.Standard2シリーズのシェイプを使用して起動する場合、SR-IOVネットワークはサポートされません。
  • Windows Server 2012 R2では、SR-IOVネットワークは、2021年4月以降にリリースされたプラットフォーム・イメージでサポートされています。
  • Windows ServerのServer Coreインストール・オプションは、SR-IOVネットワークをサポートしていません。

作業リクエストを使用した作成エラーのトラブルシューティング

作業リクエストを使用すると、データベース・バックアップやコンピュート・インスタンスのプロビジョニングなど、長時間実行されている操作のモニターに役立ちます。

インスタンスの作成操作などの操作に失敗する場合、またはインスタンスの状態がプロビジョニング中から終了中に直接移動する場合は、作業リクエストを使用して、エラーが発生したワークフロー内の場所を特定します。構成の問題またはユーザー・データの問題が原因でエラーが発生する可能性があります。インスタンスを作成するためのコンピュートAPIの最初のコール中に、同期エラーが発生します。最初のAPIコール後に行われるインスタンス作成ワークフロー中に、非同期エラーが発生します。作業リクエストでは、非同期検証の失敗が取得されます。HTTP 200レスポンスを返すインスタンス作成APIコールが成功した後、後続のインスタンス作成ワークフローで非同期エラーが発生する場合があります。

REST APIコールに対するレスポンスでは、opc-work-request-idヘッダーに作業リクエストのOCIDが含まれます。作業リクエストのステータスは、作業リクエストAPIGetWorkRequestをコールし、opc-work-request-idヘッダーにある作業リクエストIDを渡すことで、いつでもモニターできます。ワークフロー中にエラーが発生した場合は、作業リクエストAPIでListWorkRequestErrorsをコールし、作業リクエストIDを渡してエラーのリストを取得できます。

作業リクエストを使用したエラーのトラブルシューティングの詳細は、作業リクエストを参照してください。リクエスト・レスポンス、およびサンプル・リクエストとレスポンスをフィルタする方法など、非同期作業リクエストの詳細は、非同期作業リクエストを参照してください。

インスタンスのタグの管理

リソースにタグを適用すると、ビジネス・ニーズに応じた整理に役立ちます。リソースの作成時にタグを適用できます。また、後でリソースを更新して、タグを追加、改訂または削除できます。タグ適用についての一般情報は、リソース・タグを参照してください。

インスタンスのタグを管理するには:

  1. ナビゲーション・メニューを開き、「コンピュート」を選択します。「コンピュート」で、「インスタンス」を選択します。
  2. 目的のインスタンスを選択します。

  3. 既存のタグを表示または編集するには、「タグ」タブを選択します。または、「他のアクション」をクリックし、「タグの追加」をクリックして新しいタグを追加します。