インスタンスの作業
Oracle Cloud Infrastructure Computeでは、インスタンスと呼ばれるコンピュート・ホストをプロビジョニングおよび管理できます。コンピュートおよびアプリケーションの要件に合せ、必要に応じてインスタンスを作成できます。インスタンスを作成したら、コンピュータからインスタンスに安全にアクセスし、再起動、ボリュームのアタッチやデタッチを行い、完了時にはインスタンスを終了できます。
- インスタンスの作成: このトピックのステップに従って、ベア・メタルまたは仮想マシン(VM)のコンピュート・インスタンスを作成します。
- Oracle Linux、CentOSまたはUbuntuイメージを使用して起動されたインスタンスは、パスワードではなくSSHキー・ペアを使用してリモート・ユーザーを認証します。したがって、インスタンスに接続するためにSSHキー・ペアの作成が必要になることがあります。
- バースト可能なインスタンス、保護インスタンスおよび機密インスタンスを作成できます。
- 別の容量タイプを使用するようにインスタンスを構成できます。
- 拡張メモリーVMインスタンスを使用して、インスタンスに拡張メモリーおよびコアを追加できます。
- インスタンスへの接続: Secure Shell (SSH)接続またはリモート・デスクトップ接続を使用して、実行中のインスタンスに接続できます。
- インスタンスの編集: インスタンスを再構築したり、アプリケーションを再デプロイすることなく、コンピュート・インスタンスのプロパティを編集できます。
- インスタンスの停止、起動または再起動: ソフトウェアの更新またはエラー条件の解決のため、必要に応じて、インスタンスを停止して起動できます。
- ブート・ボリュームの置換: インスタンスを終了して再作成しなくても、インスタンスのブート・ボリュームを自動的に置換できます。
- インスタンスのコンテキスト通知の設定: コンピュート・インスタンスで問題が発生した場合にメッセージを取得できます。
- インスタンスへのユーザーの追加: コンピュート・インスタンスにユーザーを追加できます。
- インスタンスでのコマンドの実行: インスタンス内でコマンド実行機能を使用してスクリプトを実行することにより、コンピュート・インスタンスをリモートで構成、管理およびトラブルシューティングできます。
- 同時マルチスレッドの無効化: コンソールまたはCLIコマンドを使用して、インスタンスで同時マルチスレッド(SMT)を無効にできます。
- インスタンス・メタデータの取得: インスタンス・メタデータ・サービス(IMDS)は、インスタンスの詳細、アタッチされている仮想ネットワーク・インタフェース・カード(VNIC)、アタッチされているマルチパス対応のボリューム・アタッチメント、および定義したカスタム・メタデータを含む、実行中のインスタンスに関する情報を提供します。また、IMDSは、様々なシステム初期化タスクに使用できる情報もcloud-initに提供します。
- インスタンス・メタデータの更新: CLIまたはREST APIを使用して、コンピュート・インスタンスのカスタム・メタデータを追加および更新できます。
- コンピュート・インスタンスの新規ホストへの移動: 再起動移行または手動プロセスを使用してインスタンスを再配置できます。
- インスタンスの終了: 不要になったインスタンスは永続的に削除(終了)できます。アタッチされているVNICおよびボリュームは、インスタンスの終了時に自動的にデタッチされます。
セキュリティ・ゾーン
セキュリティ・ゾーンによって、クラウド・リソースがOracleのセキュリティ原則に準拠していることが保証されます。セキュリティ・ゾーン・コンパートメント内のリソースに対する操作がそのセキュリティ・ゾーンのポリシーに違反している場合、その操作は拒否されます。
次のセキュリティ・ゾーン・ポリシーは、インスタンスの作成機能に影響します:
- セキュリティ・ゾーン内のコンピュート・インスタンスのブート・ボリュームも同じセキュリティ・ゾーン内に存在する必要があります。
- セキュリティ・ゾーンに存在しないコンピュート・インスタンスは、セキュリティ・ゾーンにあるブート・ボリュームを使用できません。
- セキュリティ・ゾーンのコンピュート・インスタンスは、同じセキュリティ・ゾーンにあるサブネットを使用する必要があります。
- プラットフォーム・イメージを使用して、セキュリティ・ゾーンのすべてのコンピュート・インスタンスを作成する必要があります。セキュリティ・ゾーンのカスタム・イメージからコンピュート・インスタンスを作成することはできません。
リストされたセキュリティ・ゾーン・ポリシーの1つを実装しないと、インスタンスの作成が妨げられる場合があります。
インスタンスの使用に必要なIAMポリシー
Oracle Cloud Infrastructureを使用するには、管理者がテナンシ管理者によってポリシーでセキュリティ・アクセス権が付与されたグループのメンバーである必要があります。コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。権限がない、または認可されていないというメッセージが表示された場合は、どのタイプのアクセス権があり、どのコンパートメントでアクセスが機能するかをテナンシ管理者に確認してください。
インスタンスを作成する場合、他にもいくつかのリソース(イメージ、クラウド・ネットワーク、サブネットなど)が関係します。このようなその他のリソースは、インスタンスと同じコンパートメント にあっても、他のコンパートメントにあってもかまいません。インスタンスを起動するために、関係する各コンパートメントに対して必要なアクセス・レベルを持っている必要があります。これは、インスタンスにボリュームをアタッチする場合にも当てはまります。同じコンパートメントにある必要はありませんが、ない場合は、各コンパートメントに対して必要なアクセス・レベルを持っている必要があります。
管理者向け: ユーザーが作成、編集および終了(削除)インスタンスを許可する最も単純なポリシーは、ユーザーによるコンピュート・インスタンスの起動にリストされます。これは、指定したグループに、インスタンスおよびイメージを管理するための一般的なアクセス権、および既存のブロック・ボリュームをインスタンスにアタッチするために必要なアクセス・レベルを付与します。指定されたグループがインスタンスの起動やボリュームのアタッチを必要としない場合、そのポリシーを簡素化し、manage instance-family
のみを含めて、volume-family
およびvirtual-network-family
に関連する文を削除できます。
そのグループがブロック・ボリュームを作成する必要がある場合は、ブロック・ボリュームを管理する権限も必要になります。ボリューム管理者によるブロック・ボリューム、バックアップおよびボリューム・グループの管理を参照してください。
グループが特にコミュニティ・イメージにアクセスする必要がある場合は、コミュニティ・イメージを読み取る権限が必要です。コミュニティ・アプリケーションの公開に関する項を参照してください。
一部のコンピュート・タスクでは、次の項で説明するように、追加のポリシーが必要です。
パートナ・イメージ・カタログ
グループがパートナ・イメージに基づいてインスタンスを作成する必要がある場合、パートナ・イメージ・カタログに対してイメージのサブスクリプションを作成するために、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
コマンドの実行
管理者向け: コマンド機能の実行のポリシーを記述するには、次を実行します:
-
コマンドの発行、コマンドの取消し、およびコンパートメント内のインスタンスのコマンド出力の表示を許可するユーザーを含むグループを作成します。次に、次のポリシーを記述して、グループにアクセス権を付与します:
Allow group RunCommandUsers to manage instance-agent-command-family in compartment ABC
-
コマンドの実行を許可するインスタンスを含む動的グループを作成します。たとえば、動的グループ内のルールでは次のように記述できます:
any { instance.id = 'ocid1.instance.oc1.phx.<unique_ID_1>', 'ocid1.instance.oc1.phx.<unique_ID_2>' }
-
次のポリシーを記述して、動的グループにアクセス権を付与します:ノート
インスタンスを作成してから動的グループに追加する場合、インスタンスがコマンドのポーリングを開始するまでに最大30分かかります。最初に動的グループを作成してからインスタンスを作成する場合、インスタンスの作成直後にコマンドのポーリングが開始されます。Allow dynamic-group RunCommandDynamicGroup to use instance-agent-command-execution-family in compartment ABC where request.instance.id=target.instance.id
-
動的グループがオブジェクト・ストレージ・バケットからスクリプト・ファイルにアクセスし、レスポンスをオブジェクト・ストレージ・バケットに保存できるようにするには、次のポリシーを記述します:
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が含まれます。作業リクエストのステータスは、作業リクエストAPIでGetWorkRequest
をコールし、opc-work-request-id
ヘッダーにある作業リクエストIDを渡すことで、いつでもモニターできます。ワークフロー中にエラーが発生した場合は、作業リクエストAPIでListWorkRequestErrors
をコールし、作業リクエストIDを渡してエラーのリストを取得できます。
作業リクエストを使用したエラーのトラブルシューティングの詳細は、作業リクエストを参照してください。リクエスト・レスポンス、およびサンプル・リクエストとレスポンスをフィルタする方法など、非同期作業リクエストの詳細は、非同期作業リクエストを参照してください。
インスタンスのタグの管理
リソースにタグを適用すると、ビジネス・ニーズに応じた整理に役立ちます。リソースの作成時にタグを適用できます。また、後でリソースを更新して、タグを追加、改訂または削除できます。タグ適用についての一般情報は、リソース・タグを参照してください。
インスタンスのタグを管理するには:
- ナビゲーション・メニューを開き、「コンピュート」を選択します。「コンピュート」で、「インスタンス」を選択します。
-
目的のインスタンスを選択します。
-
既存のタグを表示または編集するには、「タグ」タブを選択します。または、「他のアクション」をクリックし、「タグの追加」をクリックして新しいタグを追加します。