OCI Cloud Shell

解決する課題

OCI を CLI で操作するには、本来なら手元の端末に oci CLI をインストールし、API 署名鍵を生成して構成ファイルを整える、といった準備が必要です。OCI Cloud Shell は、これらの準備を不要にする、ブラウザ上で動くマネージドなターミナル環境です。

• 端末ごとに oci CLI やツールを導入・更新したくない → 主要ツールが事前導入済みの環境がすぐ使える
• API 署名鍵の生成や構成ファイルの管理をしたくない → ログイン中ユーザーの権限で自動的に認証される
• 共有端末や出先など、手元に開発環境がない状況で操作したい → ブラウザとログインだけで使える
• ちょっとした管理作業や検証を、専用の踏み台やコンピュートを立てずに済ませたい → コンソール内のシェルで完結する
• スクリプトや設定ファイルをセッションをまたいで残したい → 永続ホームディレクトリに保持できる

AWS でいえば、本サービスはブラウザ内のマネージドシェルを提供する AWS CloudShell に近い位置づけです。

主要概念と用語

• Cloud Shell: OCI コンソール上部から開く、ブラウザ内のターミナル。Linux ベースのシェル環境で、コンソールのセッションと連動する
• ホームディレクトリ (Home Directory): ユーザーごとに割り当てられる永続ストレージ。セッションを閉じても保存したファイルやスクリプトが残る
• 事前導入ツール: oci CLI、各種言語ランタイム、kubectl や Terraform 系ツールなど、よく使うツールがあらかじめ入っている
• マシン構成 (シェルセッション): Cloud Shell に割り当てられる小さな計算リソース。利用者はサーバーを意識せず、Oracle 側が管理する
• インアクティビティタイムアウト: 一定時間操作がないとセッションが切断される仕組み。再接続すればホームディレクトリの内容は維持される
• コンパートメント (Compartment): OCI のリソース整理・権限分離の単位。Cloud Shell から操作する対象リソースもコンパートメントの IAM ポリシーに従う
• Cloud Shell 公開ネットワーク / プライベートネットワーク: 既定では公開エンドポイント経由で動くが、自分の VCN（仮想クラウドネットワーク）内のプライベートサブネットに接続して、内部リソースへ到達させる構成も選べる

仕様・制限・クォータ

• 利用には追加料金がかからないのが基本で、テナンシのユーザーであれば使い始められる
• ホームディレクトリには一定容量の永続ストレージ上限があり、超えると保存できなくなる。具体的な容量は変動するため公式ドキュメントで確認する
• 操作がない状態が続くとインアクティビティタイムアウトで切断され、さらに長時間使わないとデータが整理対象になり得る点に注意する（重要ファイルは別途バックアップする）
• セッションに割り当てられる CPU・メモリは小規模で、重いビルドや大規模処理向けではない
• 動作はユーザーが選んだホームリージョン側のサービスとして提供され、操作対象リソースは別リージョンでも CLI から指定できる
• 一部の操作（特定ポートのリッスンや任意の外向き通信など）はサンドボックス的な制約を受ける場合がある。内部リソースへ届かせたいときはプライベートネットワーク接続を使う
• 具体的なツールのバージョンや上限値はメンテナンスで変わるため、断定せず公式の最新情報で確認する

内部の仕組み

Cloud Shell は Oracle が運用するマネージドサービスで、利用者はサーバーを管理しません。コンソールからシェルを開くと、Oracle 側で用意された小さな Linux 環境にブラウザのターミナルが接続され、その環境にユーザー専用の永続ホームディレクトリがマウントされます。

認証の要は、ログイン中の OCI ユーザーの権限がそのままシェルに引き継がれる点です。コンソールにサインインしているユーザーのコンテキストでトークンが発行され、oci CLI はそのトークンを使って API を呼び出します。手元で署名鍵を作って構成ファイルに書く、といった作業は不要です。したがって、Cloud Shell から実行できる操作の範囲は、そのユーザーに付与された IAM ポリシーの範囲と一致します。

ネットワーク面では、既定の Cloud Shell は公開エンドポイント経由で OCI のパブリック API へアクセスします。VCN 内のプライベートサブネットにあるリソース（プライベートな DB やコンピュートなど）へ到達させたい場合は、プライベートネットワーク接続を構成して、自分のネットワーク内からシェルを動かす形にできます。

設計パターン / ベストプラクティス

• 日常の管理・検証はまず Cloud Shell で: 軽い CLI 操作やスクリプト検証は、専用の踏み台やローカル環境を用意せずブラウザで済ませる
• 重要ファイルはホームに置きつつバックアップ: 永続ホームは便利だが、長期未使用での整理やタイムアウトに備え、重要なスクリプトはリポジトリにも保管する
• プライベートリソースにはプライベートネットワーク接続: VCN 内の内部リソースを触るときは公開経路に頼らず、プライベートサブネット接続で到達させる
• 重い処理は別基盤へ: 大規模ビルドや長時間処理は、CPU・メモリが小さい Cloud Shell ではなく専用コンピュートや DevOps のビルドで行う
• 権限は最小限のユーザーで: 強い権限のユーザーで常用せず、必要な操作に応じた IAM 設計のうえで利用する
• 秘密情報をホームに平文で残さない: 資格情報は Vault のシークレットなどで管理し、シェル上のファイルに平文で置きっぱなしにしない

運用・監視

• Cloud Shell から実行した API 操作は、対象サービスへのリクエストとして OCI Audit に記録され、誰がいつ何をしたかを追跡できる
• 接続できない・コマンドが認可されない → サインイン中ユーザーの IAM ポリシー、対象コンパートメントとリージョンの指定、対象リソースの状態を確認する
• ファイルが消えた／保存できない → ホームディレクトリの容量上限、長時間未使用による整理、保存先パスを確認する
• プライベートリソースに届かない → プライベートネットワーク接続の構成、サブネットのルートとセキュリティリスト／NSG、対象リソースの到達性を確認する
• セッションが頻繁に切れる → インアクティビティタイムアウトによる切断であることが多い。再接続でホームの内容は維持される

コスト

OCI Cloud Shell 自体には追加料金がかからないのが基本で、テナンシのユーザーであれば追加課金なしに利用できます。具体的な無料利用の範囲（割り当て時間やストレージ容量）は変動し得るため、公式ドキュメントで最新の条件を確認してください。

• シェル機能そのものではなく、Cloud Shell から作成・操作したリソース側（コンピュートやストレージなど）に通常どおり課金が発生する点に注意する
• 重い処理を Cloud Shell で無理に回すより、適切な専用基盤を使うほうが結果的にコスト効率が良いことがある

セキュリティ

• 認証はログイン中ユーザーのコンテキストで行われ、手元に長命な署名鍵を置かずに API を呼べる。鍵の紛失・流出リスクを抑えられる
• 実行可能な操作はそのユーザーの IAM ポリシーの範囲に限られる。最小権限の原則でユーザー・グループを設計する
• 操作は対象サービス側で Audit に記録され、トレーサビリティを確保できる
• ホームディレクトリはユーザーごとに分離されるが、秘密情報を平文で残さない運用が重要。資格情報は Vault のシークレットで管理する
• 内部リソースへアクセスする際はプライベートネットワーク接続を使い、公開経路への不要な露出を避ける

関連サービス・比較

OCI には、ブラウザ内でコードを編集・実行できる Cloud Shell の Code Editor など隣接機能もありますが、ここでは AWS の相当サービスと位置づけを比較します。

ハンズオン / CLI例

# Cloud Shell はブラウザのコンソール右上のアイコンから起動する。
# 起動後は oci CLI が認証済みで、すぐに以下を実行できる。

# 1) 現在のユーザー・テナンシ情報を確認（認証が通っているかの確認）
oci iam region list --output table

# 2) コンパートメント一覧を取得
oci iam compartment list \
  --compartment-id-in-subtree true \
  --query "data[].{Name:name, Id:id}" \
  --output table

# 3) 指定コンパートメント内のコンピュートインスタンスを一覧
oci compute instance list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --output table

# 4) 別リージョンを対象に操作する（--region で都度切り替え）
oci os ns get --region us-ashburn-1

# 5) スクリプトを永続ホームに保存（次回セッションでも残る）
cat > ~/list-buckets.sh <<'EOF'
#!/usr/bin/env bash
oci os bucket list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --output table
EOF
chmod +x ~/list-buckets.sh
~/list-buckets.sh