インスタンスの作業

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

  • インスタンスの作成: このトピックのステップに従って、ベア・メタルまたは仮想マシン(VM)のコンピュート・インスタンスを作成します。
  • インスタンスへの接続: Secure Shell (SSH)接続またはリモート・デスクトップ接続を使用して、実行中のインスタンスに接続できます。
  • インスタンスの編集: インスタンスを再構築したり、アプリケーションを再デプロイすることなく、コンピュート・インスタンスのプロパティを編集できます。
  • インスタンスの停止、起動または再起動: ソフトウェアの更新またはエラー条件の解決のため、必要に応じて、インスタンスを停止して起動できます。
  • インスタンスへのユーザーの追加: コンピュート・インスタンスにユーザーを追加できます。
  • インスタンスでのコマンドの実行: インスタンス内でコマンド実行機能を使用してスクリプトを実行することにより、コンピュート・インスタンスをリモートで構成、管理およびトラブルシューティングできます。
  • インスタンス・メタデータの取得: インスタンス・メタデータ・サービス(IMDS)は、インスタンスの詳細、アタッチされている仮想ネットワーク・インタフェース・カード(VNIC)、アタッチされているマルチパス対応のボリューム・アタッチメント、および定義したカスタム・メタデータを含む、実行中のインスタンスに関する情報を提供します。また、IMDSは、様々なシステム初期化タスクに使用できる情報もcloud-initに提供します。
  • インスタンス・メタデータの更新: CLIまたはREST APIを使用して、コンピュート・インスタンスのカスタム・メタデータを追加および更新できます。
  • コンピュート・インスタンスの新規ホストへの移動: 再起動移行または手動プロセスを使用してインスタンスを再配置できます。
  • インスタンスの終了: 不要になったインスタンスは永続的に削除(終了)できます。アタッチされているVNICおよびボリュームは、インスタンスの終了時に自動的にデタッチされます。

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

リソースにタグを適用すると、ビジネス・ニーズに応じてそれらを整理しやすくなります。リソースの作成時にタグを適用するか、後でリソースを必要なタグで更新します。タグ適用についての一般情報は、リソース・タグを参照してください。

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

  1. ナビゲーション・メニューを開き、「コンピュート」をクリックします。「コンピュート」で、「インスタンス」をクリックします。
  2. 関心のあるインスタンスをクリックします。

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

セキュリティ・ゾーン

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

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

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

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

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

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

ヒント

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

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

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

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

ポリシーを初めて使用する場合は、ポリシーの開始共通ポリシーを参照してください。インスタンス、クラウド・ネットワークまたは他のCore Services APIリソースのポリシーを作成するための参照資料については、コア・サービスの詳細を参照してください。

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

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

開始する前に

管理者の場合: インスタンスのコンテキスト通知を設定するには、次のポリシーを使用します。

allow group ContextualNotificationsUsers to manage alarms in tenancy
allow group ContextualNotificationsUsers to read metrics in tenancy
allow group ContextualNotificationsUsers to manage ons-topics in tenancy
allow group ContextualNotificationsUsers to manage cloudevents-rules in tenancy

インスタンス・メタデータ・サービス(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>'}