14
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 1

NRI xPalette Advent Calendar 2025

@yomitsuiin株式会社野村総合研究所

リージョンを跨いだOCICLIの実行方法

14
Last updated at Posted at 2025-12-15

はじめに

OCIのシステム運用ではサービス操作のためにOCICLIを実行する場面が多々あります。
例：Computeインスタンスを再起動する
　　オブジェクトストレージにファイルをアップロードする

インターネット接続を持たないプライベートVCNでOCICLIを実行する場合はServiceGateway(以下、SGW)経由でCLIが実行可能ですが、リージョンを跨いで実行する場合は設定に工夫が必要です。
最近、上記が実現するための検証を行ったので本記事では筆者の実装方法をご紹介します。

今回の検証のゴール

以下の構成で東京リージョンのComputeから大阪リージョンのSGW宛にCLIを実行します。
ゴール.png

※前提

  • CLI実行に必要なIAMポリシーや動的グループは設定済みで今回はインスタンスプリンシパルで認証しています。
    インスタンスプリンシパルはリージョン間でも利用可能で、今回はどちらのリージョンも同じコンパートメントを利用しているので以下のようなポリシーを記載しています。
Allow dynamic-group [動的グループ名] to manage instance-family in compartment [コンパートメント名]
  • 東京リージョンと大阪リージョン間はリモートピアリング済みでhttpsで通信できる状態。
  • 東京リージョンのComputeインスタンスはCLI実行に必要な設定を登録済み。
  • CLI実行時はprofileで東京リージョンと大阪リージョンに投げ分けができるよう$HOME/.oci/configを構成します。
    具体的には以下のようにconfig内にprofileを2つ作成します。
[ap-tokyo-1]
tenancy=[tenancyのOCID]
region=ap-tokyo-1

[ap-osaka-1]
tenancy=[tenancyのOCID]
region=ap-osaka-1

CLIを実行する際には--profileをオプションを指定して以下のように使い分けます。

  • 東京リージョン
 oci --auth instance_principal --profile ap-tokyo-1 ~
  • 大阪リージョン
 oci --auth instance_principal --profile ap-osaka-1 ~

それでは追加した設定を見ていきましょう。

追加した設定

設計ポイント.png

今回追加した設定は以下の3つになります。

  • ポイント1：東京リージョンのVCNに大阪リージョンのSGW宛のルートルールを追加する。
  • ポイント2：大阪リージョンのDRG Attachmentに大阪リージョンのSGW宛のルートルールを追加する。
  • ポイント3：大阪リージョンのSGWに東京リージョン宛のルートルールを追加する。

それでは1つずつ見ていきましょう。

ポイント1：東京リージョンのVCNに大阪リージョンのSGW宛のルートルールを追加する。

まずはCLI実行時に大阪リージョンにルーティングされる設定が必要不可欠です。
しかし、以下の画面のようにルートルールの登録で別リージョンのSGW宛のルールは直接登録できません。
(赤枠はどちらも東京リージョンのサービスを指しています)
東京リージョンのルートルール登録画面.png

そこで今回は大阪リージョンへの通信のため以下のような設定を入れました。
これにより東京リージョンのサービス以外の通信は大阪リージョンとピアリングしているDRGにルーティングされます。
東京追加したルートルール.png

ポイント2：大阪リージョンのDRG Attachmentに大阪リージョンのSGW宛のルートルールを追加する。

次に大阪リージョンのDRG Attachmentの設定を追加します。
この設定が今回の肝だと考えています
この設定は東京リージョンのDRGに大阪リージョンのSGW宛のルート情報を広報するために設定しています。
大阪リージョン内の設定であれば、ルートルールの設定で大阪リージョンのSGWを選択することが可能です。
これにより、大阪リージョンのSGW宛のルートルールを東京リージョンに流してあげます。
具体的には以下の設定を追加します。
大阪DRGAttachement追加設定.png

ポイント3：大阪リージョンのSGWに東京リージョン宛のルートルールを追加する。

最後に大阪リージョンのSGWに設定を追加します。
これは大阪リージョンのSGWから、東京リージョンに戻るための設定になります。
通信元のCIDRはわかっていることから、ここではCIDRを指定して登録してます。
(今回の検証では通信元になるComputeインスタンスは10.0.0.0/24のVCN内に構築しています)
大阪SGW設定追加.png

実際にCLIを実行してみた

東京リージョンと大阪リージョンにそれぞれComputeインスタンスを用意してCLIを実行してみます。
CLIはComputeインスタンスの情報を取得するコマンドを使います。
東京リージョンのComputeインスタンスからCLIを実行して各リージョンのComputeインスタンスの情報を取得します。

まず、設定を追加する前の実行結果です。
東京リージョン宛の実行結果

oci --auth instance_principal --profile ap-tokyo-1 compute instance get --instance-id ocid1.instance.oc1.ap-tokyo-1.[OCID] | grep display;date
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
    "display-name": "tokyo_vm",

grepで絞っていますが東京リージョンに用意したcomputeインスタンス名が取得できました
(tokyo_vmは東京リージョンのComputeインスタンス名です)

大阪リージョン宛の実行結果

oci --auth instance_principal --profile ap-osaka-1 compute instance get --instance-id ocid1.instance.oc1.ap-osaka-1.[OCID] | grep display;date
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
ConnectTimeout:
{
    "client_version": "Oracle-PythonCLI/3.71.1",
    "logging_tips": "Please run the OCI CLI command using --debug flag to find more debug information.",
    "message": "The connection to endpoint timed out",
    "target_service": "CLI",
    "timestamp": "2025-12-11T06:59:35.216085",
    "troubleshooting_tips": "It looks like a connection timeout, please check your network setting or contact your network administrator. See [https://docs.oracle.com/iaas/Content/API/SDKDocs/clitroubleshooting.htm] for more information about resolving this error. If you are unable to resolve this issue, run this CLI command with --debug option and contact Oracle support and provide them the full error message."

大阪リージョン側はタイムアウトしてしまいました。

次に設定追加後の実行結果です。

東京リージョン宛の実行結果

oci --auth instance_principal --profile ap-tokyo-1 compute instance get --instance-id ocid1.instance.oc1.ap-tokyo-1.[OCID] | grep display
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
    "display-name": "tokyo_vm",

問題なし。

大阪リージョン宛の実行結果

oci --auth instance_principal --profile ap-osaka-1 compute instance get --instance-id ocid1.instance.oc1.ap-osaka-1.[OCID] | grep display
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
    "display-name": "osaka_vm",

今度は大阪側もComputeインスタンスの情報が取得できました。
(osaka_vmは大阪リージョンのComputeインスタンス名です)

まとめ

今回は東京リージョンから大阪リージョンのSGW経由でCLIを実行する方法を検証・まとめてみました。
OCIのシステム運用ではCLIは欠かせないツールです。
使い方を工夫することで更に効果的になりますので、ぜひ使ってみてください。

おまけ

ポイント1について、0.0.0.0/0を別のルートルールに使いたい方向けに別の方法を検討してみます。
具体的には必要なエンドポイント宛のルートルールを個別に設定する方法です。

OCIは以下のページでリージョン毎のパブリックIPのリストを公開しているのでこちらを使ってサブネット単位で大阪リージョンへのルートルールを設定していきます。
IPアドレス範囲

まず、実行したいCLIをデバッグモードで実行してエンドポイントを調べます。

ooci --debug --auth instance_principal --profile ap-osaka-1 compute instance get --instance-id [OCID]
~~中略~~
DEBUG:oci.base_client.xxxxxxxx:Endpoint: https://iaas.ap-osaka-1.oraclecloud.com/20160918

次にエンドポイントのIPアドレスを調べます

nslookup iaas.ap-osaka-1.oraclecloud.com
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
iaas.ap-osaka-1.oraclecloud.com canonical name = splat-api.ap-osaka-1.oci.oraclecloud.com.
Name:   splat-api.ap-osaka-1.oci.oraclecloud.com
Address: 140.204.30.194

先ほどのパブリックIPのリストから該当のサブネット140.204.30.128/25を見つけます。
これを以下のようにルートルールに設定します。
サブネット指定のDRG用ルートルール.png

この状態でポイント2、ポイント3を設定してCLIを実行した結果が以下の通りです。
東京リージョン宛の実行結果

oci --auth instance_principal --profile ap-tokyo-1 compute instance get --instance-id [OCID] | grep display
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
    "display-name": "tokyo_vm",

大阪リージョン宛の実行結果

oci --auth instance_principal --profile ap-osaka-1 compute instance get --instance-id [OCID] | grep display
DEBUG:oci_cli.cli_util:Check if Propagation Enabled: None
DEBUG:oci_cli.cli_util:Is Propagation Enabled: None
    "display-name": "osaka_vm",

どちらも問題なくCLIを実行できました。
ただしこの方法には以下の注意点もありますので利用の際はご注意ください。

  • エンドポイントは実行CLIによって異なるケースがある。
    例えばComputeとObjectstorageの操作では以下の通りエンドポイントが異なります。
    エンドポイントが異なれば指定するサブネットのCIDRも変わりますので注意が必要です。
    Computeの場合
oci --debug --auth instance_principal --profile ap-osaka-1 compute instance get --instance-id [OCID]
~~中略~~
DEBUG:oci.base_client.xxxxxxxx:Endpoint: https://iaas.ap-osaka-1.oraclecloud.com/20160918

　 Objectstorageの場合

oci --debug --auth instance_principal --profile ap-osaka-1 os ns get
~~中略~~
DEBUG:oci.base_client.xxxxxxxx:Endpoint: https://objectstorage.ap-osaka-1.oraclecloud.com
  • エンドポイントのIPアドレスが変更になる可能性がある。
    IPアドレスが変更になるとルートルールで指定するCIDRも変更になります。
    今回の検証中にIPアドレスが変更になることはありませんでしたが今後も変更されないかは不明ですので注意が必要です。

参考

クイックスタート
サービス・ゲートウェイの管理
IPアドレス範囲

14
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
14
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?