Oci on ポンコツ地方エンジニアの技術ブログ

OCI の Ubuntu インスタンスの初期設定

Fri, 29 May 2026 00:00:00 +0900

swap の設定

以下のように、Ubuntu のイメージにはスワップがありません。

$ free -m
 total used free shared buff/cache available
Mem: 954 343 225 4 538 610
Swap: 0 0 0

2GB のスワップファイル（Swap）を追加します。
すべてのコマンドは、管理者権限（sudo）を付けてターミナルで実行します。

1. スワップファイルの作成

dd または fallocate コマンドで 2GB のファイルを作成します。ここでは確実かつ高速な fallocate を使用します。

sudo fallocate -l 2G /swapfile

⚠️ 警告

もし「fallocate failed: Operation not supported」のようなエラーが出た場合は、以下の dd コマンドを代わりに試してください。
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

2. 適切な権限の設定

セキュリティのため、スワップファイルは root ユーザーのみが読み書きできるように権限を 600 に制限します。

sudo chmod 600 /swapfile

3. スワップ領域の初期化

作成したファイルをスワップ領域としてフォーマットします。

sudo mkswap /swapfile

4. スワップの有効化

システムにスワップファイルを認識させ、有効化します。

sudo swapon /swapfile

5. 設定の確認

スワップが正しく有効化されたか確認します。2GB（約 2.0GiB）のスワップが表示されていれば成功です。

sudo swapon --show
# または
free -h

6. 再起動後も自動で有効化する設定

上記の設定だけでは、インスタンスを再起動するとスワップが解除されてしまいます。再起動後も自動的に有効化されるよう、/etc/fstab に追記します。

6-1. fstab のバックアップ（推奨）

念のため、設定ファイルをバックアップしておきます。

sudo cp /etc/fstab /etc/fstab.bak

6-2. 設定の追記

以下のコマンドを実行して、/etc/fstab の末尾に設定を追記します。

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

【おまけ】カーネルパラメータの最適化（推奨）

Linux には、メモリがどれくらい減ったらスワップを開始するかを決める swappiness という値があります。
初期値は 60 であることが多いですが、クラウド環境（特に SSD ストレージ）では **10〜20** 程度に下げて、できるだけ物理メモリを優先して使うように設定するのが一般的です。

1. 現在の swappiness を確認

cat /proc/sys/vm/swappiness

2. 一時的に `10` に変更

sudo sysctl vm.swappiness=10

3. 永続的に反映

再起動後もこの設定を維持するため、/etc/sysctl.conf の末尾に追記します。

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

これで 2GB のスワップ設定はすべて完了です！

タイムゾーンの変更

# 現在のタイムゾーンを確認
timedatectl
# JST に変更
sudo timedatectl set-timezone Asia/Tokyo
# 変更されたことを確認
timedatectl

nano のインストール

sudo apt update
sudo apt install -y nano

git のインストール

sudo apt update
sudo apt install -y git

glab のインストールと認証

諸事情で GitHub ではなく GitLab を使っているので、glab をインストールします。

1. ダウンロード

apt でインストールできるバージョンは古いので、公式リリースからダウンロードしてインストールします。

詳細は以下を参照してください。

https://blog.ponkotools.com/posts/2026/05/10/glab/

2. GitLab でのアクセストークン（PAT）の発行

CLI から GitLab にアクセスするために、事前にブラウザ側（GitLab のウェブ画面）で Personal Access Token（個人用アクセストークン）を発行しておく必要があります。
WSL を使っているからか、web での認証ではうまくいきませんでした。

GitLab にログインします（SaaS 版の gitlab.com または社内などのオンプレミス版）。
面左上の自分のアイコン＞ Preferences（設定）＞左メニューの Access Tokens の順に開きます。
Add new token をクリックし、以下のように入力します：
Token name: 任意の名前（例: oci-ubuntu-cli）
Expiration date: 空欄（無期限）または任意の有効期限
Scopes（権限）: CLI をフル活用するために、api と write_repository以下にチェックを入れます。

Create personal access token をクリックします。

画面に一度だけトークン（glpat-xxxx…）が表示されるので、必ずコピーして手元に控えておきます。（画面を閉じると二度と見られなくなります）

3. CLI の認証設定（ログイン）

OCI の Ubuntu ターミナルに戻り、以下のコマンドを実行して対話型セットアップを開始します。

glab auth login

実行すると、いくつか質問されるので以下のように回答していきます。

┃ What GitLab instance do you want to sign in to?
┃ > gitlab.com
┃ GitLab Self-Managed or GitLab Dedicated instance

gitLab.com（本家）を使っている場合は、そのまま gitLab.com を選択して Enter。
自社サーバーなどの場合は GitLab Self-Managed or GitLab Dedicated instance を選択し、その後 URL（例: https://gitlab.example.com）を入力します。

- Signing into gitlab.com
┃ How would you like to sign in?
┃ > Token
┃ Web

Token を選択します。

- Signing into gitlab.com
┃ What domains does this host use for the container registry and image dependency proxy?
┃ > gitlab.com,gitlab.com:443,registry.gitlab.com

そのまま Enter を押します。

The minimum required scopes are 'api' and 'write_repository'.
Generate a personal access token at https://gitlab.com/-/user_settings/personal_access_tokens?scopes=api,write_repository
┃ Paste your authentication token:
┃ >

先ほど GitLab 画面でコピーしたトークン（glpat-xxxx…）を貼り付けて Enter を押します。

┃ Choose default Git protocol:
┃ SSH
┃ > HTTPS
┃ HTTP

HTTPS を選択します。

セットアップが完了したら、以下のコマンドで無事にログインできているか確認します。

glab auth status

ご自身のユーザー名や「Logged in to gitlab.com」といったステータスが表示されれば、GitLab CLI の設定はすべて完了です！

tmux のインストール

セッションが切れても実行中のプログラムが停止しないよう tmux を使うためにインストールします。

sudo apt update
sudo apt install -y tmux

docker のインストール

1. インストール

公式ドキュメントの Install using the apt repository に従って最新版の docker をインストールします。

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

2. docker の権限を設定 (sudo を不要にする)

sudo gpasswd -a $(whoami) docker
sudo chgrp docker /var/run/docker.sock

不要なサービスの停止

参考: https://qiita.com/ynott/items/4312cb34611d2e462779

systemctl | grep running で稼働中のサービス一覧を出力し、そのうち不要なものを AI に尋ねた結果が以下です。

確実に停止・無効化して良いサービス

サービス名	役割と停止して良い理由
`ModemManager.service`	3G/4G/5G などのモバイルモデムを管理するサービス。クラウドのサーバーでモデムを使うことはないため、完全に不要です。
`fwupd.service`	マザーボードやデバイスのファームウェアをアップデートするデーモン。仮想マシン（VM）のファームウェアは OCI 側が管理するため不要です。
`rpcbind.servicerpcbind.socket`	NFSv3（ネットワークファイルシステム）などで使われる古いポートマップサービス。NFS でストレージをマウントする予定がなければ不要です。
`iscsid.serviceiscsid.socket`	iSCSI ストレージに接続するためのクアドラント。OCI のブロック・ボリュームを iSCSI 経由で直接マウント（手動アタッチなど）していない限り、標準の準仮想化（Paravirtualized）アタッチであれば不要です。
`udisks2.service`	主にデスクトップ環境で USB メモリなどのディスクを自動認識・マウントするためのサービス。サーバー用途では不要です。

停止・無効化のコマンド例
単に stop するだけだと再起動時にまた動いてしまうので、disable –now で自動起動の解除と停止を同時に行います。

sudo systemctl disable --now ModemManager fwupd rpcbind rpcbind.socket iscsid iscsid.socket udisks2

条件付きで停止・削除できるサービス（効果大）

環境によっては不要、あるいは別の手段に切り替えることで大幅に軽量化できる重要ポイントです。

`snapd.service` / `snap.oracle-cloud-agent...` （メモリ節約効果：大）

Ubuntu のパッケージ管理システム「Snap」と、OCI の管理エージェントです。

判断基準
OCI のダッシュボードからインスタンスのメトリック（CPU使用率のグラフなど）を見たり、OS の診断機能を使ったりしない、かつ自分で snap コマンドを使ったアプリ（Nextcloud などの Snap版）を動かす予定がない場合。

解説
oracle-cloud-agent は便利ですが、メモリが 1GB 以下の環境ではかなりの重荷になります。これらを Snap ごと削除すると、数十MB〜100MB 以上のメモリが浮きます。

完全に削除する場合のコマンド

sudo snap remove oracle-cloud-agent
sudo apt purge snapd -y

メモリ使用量の変化

上記のサービスをすべて停止した場合の比較です。

サービス停止前

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 360Mi 72Mi 4.9Mi 677Mi 594Mi
Swap: 2.0Gi 21Mi 2.0Gi

サービス停止後

$ free -h
 total used free shared buff/cache available
Mem: 954Mi 299Mi 313Mi 4.9Mi 483Mi 655Mi
Swap: 2.0Gi 10Mi 2.0Gi

OCI Bastion 経由でプライベート・サブネット内の Ubuntu インスタンスに SSH で接続

Wed, 27 May 2026 00:00:00 +0900

前回、Oracle Linux インスタンスへ OCI Bastion 経由で SSH 接続する手順を書きました。

今回は、前回記事で触れた基本的な構成を前提に、Ubuntu インスタンスを対象とした OCI Bastion 経由の SSH 接続手順だけをまとめます。
Oracle Linux と共通する VCN / Bastion の作成や一般的なネットワーク設定は省略し、Ubuntu 固有の注意点に絞って解説します。

前提

ターゲット OCI インスタンスには Ubuntu のイメージを使う
インスタンスは プライベートサブネット に配置し、パブリックIPなし で作成する
Bastion サービスは事前に作成済みで、プライベートサブネットをターゲットにしている

Ubuntu でのインスタンス作成時のポイント

1. イメージに Ubuntu を選択する

インスタンス作成画面のイメージ選択で、Ubuntu を選びます。
OCI の無料枠対象であれば Always Free 適格 のマークを確認してください。
私は今回 Ubuntu 24.04 Minimal を選択しました。

2. ネットワーキング設定

ここは Oracle Linux のときと同じく以下のように設定します。

プライベートサブネットを選択する
パブリックIP の割当てはなしにする

SSH キーについても同様です。

Ubuntu での Bastion セッション作成

Bastion 自体は、Oracle Linux のときに作成済みなのでそれを使います。
ただ、セッションの作成方法が異なり、Ubuntu の場合は 管理対象 SSH セッションではなく、SSHポート転送セッションを使う のが一般的です。

Bastion セッションの設定

OCI コンソールで「アイデンティティとセキュリティ」 > 「要塞（Bastion）」に移動する
作成した Bastion を選択し、「セッションの作成」をクリックする
以下のように設定する

項目	内容
セッション・タイプ	SSHポート転送セッションを選択します。
ターゲット・ホスト	Ubuntu インスタンスをIPアドレスまたはインスタンス名で指定します。
SSH キー	ご自身のPCにある SSH 公開鍵をアップロード or ペーストするか、新規に生成します。

「セッションの作成」を実行し、状態が アクティブ になるまで待つ

鍵のパーミッション

Linux の SSH では秘密鍵の権限が緩いと接続が拒否されます。以下のように chmod 600 で制限しておきます。

# 例
chmod 600 ~/.ssh/<Ubuntuの秘密鍵>
chmod 600 ~/.ssh/<セッションの秘密鍵>

SSH での接続方法

方法１

Bastion セッションがアクティブになったら、右側のメニューから「SSH コマンドのコピー」を使います。以下のようなコマンドがコピーされます。

ssh -i <privateKey> -N -L <localPort>:10.0.1.203:22 -p 22 ...

項目	内容
`<privateKey>`	セッション作成時の秘密鍵のパスを設定します。
`<localPort>`	基本的には「（1024番〜65535番の間であれば）あなたのPCで現在使われていない任意のポート番号」なら何番でも自由です。よく使われるのは、覚えやすい 12345 や 2222、50022 などだそうです。

上記を踏まえたうえで、まずは以下のようにコマンドを時刻します。

# 例
ssh -i ~/.ssh/bastion_id_rsa -N -L 12345:10.0.1.143:22 -p 22 ...

すると画面が止まった（待機状態）になります。
これでトンネルが維持されている状態ですので、このターミナル画面は閉じずにそのまま放置してください。

この状態で新しく別のターミナル画面を開き、以下のコマンドを実行して Ubuntu インスタンスにログインします。

ssh -i ~/.ssh/Ubuntu作成時の秘密鍵 -p 12345 ubuntu@localhost

📝 注記

あなたのPCの 12345 番ポート（localhost:12345）に接続することが、そのままトンネルを通じて向こう側のUbuntuに繋がるため、接続先は localhost となります。
OCI の Ubuntu インスタンスのユーザー名は ubuntu なので、それを指定します。

方法２

前述の方法だとターミナルを２つを使わないといけません。
これをコマンド一発でやる場合、以下のように打ちます。

ssh -i <Ubuntuの秘密鍵> -o ProxyCommand="ssh -i <セッションの秘密鍵> -W %h:%p -p 22 ... ubuntu@10.0.1.143

方法３

上記のコマンドも結局めちゃくちゃ長いので、自分のPCの ~/.ssh/config に設定を書いてしまうのが最もスマートです。

~/.ssh/config をテキストエディタで開き、以下のように追記します。

# 1. Bastion（要塞）自体の設定
Host oci-bastion
 HostName host.bastion.....oci.oraclecloud.com
 Port 22
 # ★セッションを作成するたびに、以下のUser（ocid...の部分）だけ書き換える
 User ocid1.bastionsession.oc1.....amaaaaaa...
 IdentityFile ~/.ssh/セッション作成時の秘密鍵

# 2. ターゲットとなるUbuntuの設定
Host oci-ubuntu
 HostName 10.0.1.143
 User ubuntu
 IdentityFile ~/.ssh/Ubuntu作成時の秘密鍵
 ProxyCommand ssh oci-bastion -W %h:%p

設定した後は以下のコマンドだけで接続できます。

ssh oci-ubuntu

また、3時間ごとにセッションを作り直した際も、上の User の部分（ocid1.bastionsession…）だけを書き換えるだけで済みます。

VS Code の Remote SSH もこれで使えるようになります。

Ubuntu へのログイン後に確認すること

接続に成功すると、プロンプトが次のようになります。

ubuntu@<hostname>:~$

参考

OCI Bastion 経由でプライベート・サブネット内のインスタンスに SSH で接続

Tue, 26 May 2026 00:00:00 +0900

日本語では要塞と訳されています。

手元の PC からこの Bastion（踏み台の役割）を経由させることで、インスタンス自体にパブリックIPを一切持たせないまま、手元の PC のターミナルから直接 SSH 接続できるようになります。

設定には、ネットワーク（VCN）の構築段階からいくつか重要なポイント（ルーターやセキュリティ・リストの設定など）があり、結構はまったのでメモとして残しておきます。

仕組みとメリット

完全無料で、自分で踏み台用のサーバー（EC2など）を1台管理・維持する必要がありません。
接続が必要なときだけ、手元のPCから「3時間だけ有効な一時的な接続セッション（トンネル）」を発行して侵入します。時間が経てば自動で完全に閉じられるため、セキュリティが非常に強固です。

環境

ホストPC: Ubuntu 22.04
インスタンス: Oracle Linux 9

📝 注記

インスタンスが Oracle Linux の場合と、Ubuntu などの他の OS の場合とで方法が一部異なります。
今回は Oracle Linux 9 の場合で、Ubuntu についてはまた別で書きます。

Step1: VCN とサブネットの作成

まずは土台となる仮想クラウド・ネットワーク（VCN）を作成します。
手動で細かく作ることもできますが、「VCNウィザード」を使うのが一番簡単で確実です。
インターネットに出るための「インターネット・ゲートウェイ」だけでなく、プライベートVMがアップデート等で外と通信するための「NATゲートウェイ」や「サービス・ゲートウェイ」も自動で作成・紐付けされます。

OCIコンソールメニューから「ネットワーキング」 > 「仮想クラウド・ネットワーク」に移動します。

アクションから「VCNウィザードの起動」をクリックします。

「インターネット接続性を持つVCNの作成」を選択し、「VCNウィザードの起動」をクリックします。

以下の情報を入力・確認して「次へ」進み、作成します。

項目	内容
VCN名	任意の名前（例: my-bastion-vcn）
VCNの構成 CIDRブロック	10.0.0.0/16（デフォルトのままでOK）
パブリック・サブネットのCIDR	10.0.0.0/24
プライベート・サブネットのCIDR	10.0.1.0/24

Step2: インスタンスの作成

次に、パブリックIPを持たない接続先のインスタンスを作成します。
「コンピュート」 > 「インスタンス」から「インスタンスの作成」をクリックします。
インスタンスの作成については別記事でも書いているので詳細は割愛しますが、イメージは Oracle Linux 9 を選びます。

そして、ネットワーキングセクションで以下を選択します。

プライベート・サブネット（Step 1で作成したもの）を選択。
「パブリックIPアドレスの割当て」で「パブリックIPなし」を選択。

SSHキーのセクションでは、ご自身のPCで作成した公開鍵（.pub）をアップロード、または新規で生成して秘密鍵を保存してください。

設定したら「作成」をクリックします。

Stes3: Bastion プラグインの有効化 (Oracle Linux の場合のみ)

作成したインスタンスの詳細画面に入り、管理タブの「Oracle Cloud エージェント」で要塞を探し、有効化します。

要塞のステータスが停止済となります。
OSの内部でプログラムのダウンロードや配置が行われており、ステータスが「実行中」になるまでには5分〜10分ほどかかることがあります。

📝 注記

ここで要塞を有効にしておかないと、後述の管理対象SSHセッションの作成で API エラーとなります。

Step4: Bastionの作成

「アイデンティティとセキュリティ」 > 「要塞」（Bastion）に移動します。

「要塞の作成」をクリックし、以下のように設定します。

項目	内容
要塞名	任意の名前
ターゲット仮想クラウド・ネットワーク	Step 1で作成したVCN
ターゲット・サブネット	ターゲットVMがいる「プライベート・サブネット」を選択します。
CIDRブロックの許可リスト	0.0.0.0/0 （特定のIPだけに絞るとより安全です）

「要塞の作成」をクリックします（アクティブになるまで数分かかります）。

Step5: セッションの作成

作成した Bastion の詳細画面に入り、「セッションの作成」をクリックします。

以下のように設定します。

項目	内容
セッション・タイプ	Oracle Linux の場合は管理対象SSHセッションを選択します。
ユーザー名	Oracle Linux の場合は `opc` です。
ターゲット・コンピュート・インスタンス	Step2 で作成したプライベートVMを選択します。
SSHキー	ご自身のPCにある SSH 公開鍵をアップロード or ペーストするか、新規に生成します。VM作成時に使ったものと同じ、またはペアになるものをアップロードしても OK です（後述）。

「セッションの作成」をクリックします。
状態が作成中となり、しばらく経つとアクティブになります。

Step6: SSH接続の実行

セッションが「アクティブ」になったら、いよいよ接続です。作成したセッションの右側にある「3つの点」メニューから「SSHコマンドのコピー」をクリックします。

コピーされるコマンドは以下のような形をしています。

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1..." opc@10.0.1.x

<privateKey> 2箇所ありますので、それぞれ VM インスタンス作成時の秘密鍵、Bastion セッション作成時の秘密鍵のパスに変更して実行します。

# 例
ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

📝 注記

セッション作成時の SSH キーを VM 作成時と同じものにした場合は、2箇所とも同じ秘密鍵のパスを指定します。

📝 注記

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまいます。この場合、以下のコマンドでパーミッションを変更します。
chmod 600 ssh-key-xxxx.key

実行すると、Bastionを経由してパブリックIPのないプライベートVMに直接SSHログインが完了します。

SSH キーについての補足

セッション作成時のSSHキーはVM作成時と同じでも別のものでも大丈夫です。

OCI の Bastion サービスは、接続時に「2枚の壁（認証）」を通過するイメージになります。

Bastionセッション作成時のSSHキー（壁1：入口の鍵）

ローカルPCから、OCIのBastionサービス（要塞）に侵入するための鍵です。
Bastionサービス自体が「あなたは本当にこのセッションを作った本人ですか？」を確かめるために使います。

VM作成時のSSHキー（壁2：奥の部屋の鍵）

Bastionを通り抜けたあと、ターゲットのプライベートVMにログインするための鍵です。
VM（OS）側が「あなたはログインを許可されたユーザーですか？」を確かめるために使います。

このように鍵の役割が独立しています。
ただ、「同じ鍵」を使った場合と「別の鍵」を使った場合で、最後に実行するSSHコマンドの書き換え方が少し変わります。

① 同じ鍵を使った場合（一番シンプル）

すべて1つの秘密鍵（例: id_rsa）で開くので、コピーしたコマンド内の2箇所の <privateKey> に同じ秘密鍵のパスを指定すればOKです。

ssh -i ~/.ssh/id_rsa -o ProxyCommand="ssh -i ~/.ssh/id_rsa -W %h:%p ..." opc@10.0.1.x

② 別の鍵を使った場合（それぞれ指定が必要）

コマンドの「前半」と「後半」で、それぞれの秘密鍵を指定する必要があります。

前半の -i: VM作成時の秘密鍵を指定
中間の ProxyCommand内の -i: Bastionセッション作成時の秘密鍵を指定

ssh -i ~/.ssh/VM用の秘密鍵 -o ProxyCommand="ssh -i ~/.ssh/Bastion用の秘密鍵 -W %h:%p ..." opc@10.0.1.x

管理やコマンドの書き換えをシンプルにしたい場合は、「同じ鍵（ペア）」を使ってしまうのが一番迷わなくてラクです。

セキュリティ的な問題は？

個人開発や一般的な社内検証環境レベルであれば、同じ鍵を使い回しても実用上のセキュリティリスクは非常に低い（実質的に問題ない）と言えます。

ただし、厳格なエンタープライズ（企業）の運用基準や、セキュリティの理想論（ベストプラクティス）の観点から見ると、いくつか「知っておくべきリスクと理由」があります。
なぜ分けるのが理想とされるのか、その理由は以下です。

1. 鍵が漏洩した際の影響範囲（爆発半径）が広がる

これが最も大きな理由です。

鍵を分けている場合： もしBastion用の鍵が外部に漏れても、攻撃者はBastionの入り口までしか来られません。ターゲットVMの鍵が無事なら、中のデータにはアクセスできません。

同じ鍵を使っている場合： その1つの秘密鍵が漏洩した瞬間、Bastionの突破からターゲットVMへのログインまで、すべての防御壁が同時に崩壊します。

ひとつの鍵にすべての権限を持たせることは、セキュリティの世界で嫌がられる「単一障害点（Single Point of Failure）」を作ることになってしまいます。

2. 「誰が・どこに」アクセスしたかの監査（ログ）が曖昧になる

本番環境やチーム開発において重要な視点です。

Bastion（要塞）の本来の目的は、「いつ、誰が、どのサーバーに入ったか」を厳密に記録・コントロールすることです。

Bastion用の鍵：「あなたがクラウド環境のネットワークに入った」ことを証明する
VM用の鍵：「あなたが特定のサーバーの opc ユーザーとしてログインした」ことを証明する

これらを同じ鍵にしてしまうと、鍵の管理者が同一人物である前提になってしまい、「Bastionを通過した人と、実際にVMを操作した人が本当に同一人物か？」という厳密なトレース（監査ログの信頼性）が担保しにくくなります。

参考

OCI (Oracle Cloud Infrastructure) で VM インスタンスを作成する

Thu, 21 May 2026 00:00:00 +0900

OCI (Oracle Cloud Infrastructure)

OCI には Always Free（永久無料枠） という非常に強力な特典があり、4 OCPU / 24 GB メモリ という、他社クラウドであれば有料級のハイスペックな Arm サーバー（Ampere A1）を無料で 24時間365日動かすことができます。

OCI のコンピュート環境：VM とコンテナインスタンスの違い

OCI でアプリケーションを動かすアプローチとして、主に 「VM Compute（仮想マシン）」 と 「コンテナインスタンス（Container Instances）」 の 2つがあります。

どちらも Docker コンテナを動かせますが、その管理レイヤーと仕様には明確な違いがあります。

比較項目	VM Compute (仮想マシン)	コンテナインスタンス
管理の単位	OS（Linux / Windows）	コンテナ（Dockerイメージなど）
インフラ管理	必要（OSアップデート、SSH管理）	不要（サーバーレス。オラクルが基盤を管理）
起動スピード	数分（OSのブート時間必要）	数秒（コンテナの起動のみ）
永続ストレージ	ブロック・ボリュームを自由に追加・マウント可能	エフェメラル（一時的。再起動でデータ消滅）
永久無料枠	あり（4 OCPU / 24 GBメモリまで無料）	なし（秒単位の従量課金）

どちらを選ぶべきか？

コンテナインスタンスはサーバーレスで運用が手軽ですが、永久無料枠（Always Free）の対象外となります。また、コンテナの再起動によって内部のデータが消去される特性を持ちます。

そのため、「24時間いつでも無料で動かし続けたい」「生成されるログやデータをローカルディスクに安全に保持（永続化）したい」という場合は、VM Compute を選択するのが最適です。

OCI への登録

https://www.oracle.com/jp/cloud/free/ にアクセスして「無料で始める」をクリックして各種情報を入力します。
ちょっとした注意事項として、住所は英語で入力する必要があります。

参考

インスタンスの作成

ホームより インスタンス を選択します。

ホームにない場合は、左上のメニューから コンピュート > インスタンス でも OK です。

続いて インスタンスの作成 を選択します。

基本情報

イメージ

デフォルトでは Oracle linux になっています。
Oracle Linux は Red Hat Enterprise Linux（RHEL）をベースにした OS だそうです。

セキュリティの「保護インスタンス」は、仮想マシン（VM）の乗っ取りや、悪意のあるプログラムによるOS改ざんを防ぐための「セキュリティ強化機能が有効になっている状態」を指すそうですので、保護インスタンスになっているものを選択しておいたほうが良さそうです。

シェイプ

Always Free 対象のものとして以下の２つがあります。

項目	Ampere (A1.Flex)	AMD (E2.1.Micro)
最大リソース	4 OCPU / 24 GB（分配可能）	1 OCPU / 1 GB × 2台
アーキテクチャ	Arm (aarch64)	x86_64
主な用途	開発環境、Docker、高負荷な処理、Webサーバー	軽量なスクリプト実行、VPNサーバー、検証用

VM.Standard.A1.Flex

現在OCIで提供されている中で最もハイスペックかつ使い勝手の良い無料枠インスタンスです。
Ampere を選択し、VM.Standard.A1.Flex をチェックします。

シェイプ名横の ▼ を押すと CPU と RAM の設定ができます。

「4 OCPU / 24 GB」までは無料で使えるらしいです。

VM.Standard.E2.1.Micro

Ampere A1 は人気のため、空きがなくて作成できないことが多いです。
また、システムが Arm（Aarch64）アーキテクチャに対応しておらず、どうしても従来の x86_64 環境が必要な場合もあったりします。
そのような場合はこちらを選びます。
ただし、スペックは Ampere A1 に比べて大幅に低くなります。

専門と前世代 を選択し、VM.Standard.E2.1.Micro をチェックします。

上記のうち好きな方を選び、次へを押します。

セキュリティ

保護インスタンスの設定ができますが、予期せぬエラーや「動かない」トラブルの原因になりやすいそうなので、今回は OFF のままとしました。

ネットワーキング

プライマリVNIC

初めて OCI を使うので、まだ「既存のネットワーク」が存在しないため、新しく 新規仮想クラウド・ネットワーク を選択します。サブネットも自動的に 新規パブリック・サブネットの作成 に切り替わり、名前などが自動入力されます。

２回目は既存のネットワークを選択すれば OK です。

パブリックIPv4アドレス割当て

今回は外部からの通信（インバウンド）を受ける必要はないため、 パブリックIPv4アドレスの割当て は OFF にしておきました。

SSHキーの追加

キー・ペアを自動で生成 を選択し、秘密キーのダウンロード を押して秘密鍵をダウンロードしておきます。

📝 注記

SSH キーなしを選択すると、後述するように Cloud Shell からもインスタンスにアクセスできませんでした。外部から SSH でアクセスする予定がなくても SSH キーは作成しておかないといけないようです。

ストレージ

ここは全てデフォルトのままとしました。

「カスタム・ブート・ボリューム・サイズ…」について チェックがOFF（デフォルト）の場合、標準サイズである 46.6 GB のディスクが自動で割り当てられます。
OCIの無料枠では最大で合計200GBまでストレージが使え、ここにチェックを入れて数値を 100 や 200 に増やすことも可能です。
ただ、後からでもディスクサイズは簡単に拡張できるため、最初はデフォルトのままで様子見するのが安全です。

「転送中暗号化の使用」について デフォルトでONになっていますが、これは「仮想マシンとストレージの間の通信を暗号化して盗聴を防ぐ」というインフラ側の高度な保護機能です。
パフォーマンスへの影響も無視できるレベルですので、ON（今の状態）のままにしておきましょう。

「自分が管理するキーでこのボリュームを暗号化」について チェックがOFF（デフォルト）の場合、Oracleが管理する標準の暗号鍵で自動的にディスクが暗号化されます。
個人開発で自前の鍵管理（Vault/KMSなど）を入れると管理コストが増えて複雑になるため、OFFのままで問題ありません。

作成

次へ進み、「作成」 を押すとインスタンスが作成されます。
しばらく待つとインスタンスが作成されます（ステータス表示が 実行中 に変わります）。

API エラーが発生した場合

これは設定の間違いではなく、「現在、Oracleのデータセンター側で、無料枠用のArmサーバー（Ampere）の在庫が一時的に切れている」という、OCIの無料枠で最も頻繁に発生する有名な現象です。
世界中で無料枠のAmpereは非常に人気があるため、椅子取りゲームのようになっています。

解決策は以下です。

1：x86の「AMD枠」に切り替えて即時作成する（確実・おすすめ）

Arm（Ampere）の在庫がなくても、もう1つの無料枠であるAMD（VM.Standard.E2.1.Micro）であれば、在庫に余裕がありすんなり作成できるケースが非常に多いです。

2：「フォルト・ドメイン」を変更して再トライする

同じAmpere（Arm）のまま、サーバーが置かれる物理的な区画（フォルト・ドメイン）を変更することで、運よく在庫が引っかかることがあります。

3：数日〜数週間、時間を変えてクリックし続ける

どうしても強力な「Arm（4 OCPU / 24 GBを狙いたいなど）」が良い場合、誰かがインスタンスを削除して在庫が空くのを待つことになります。

インスタンスの起動

コンピュートの画面から インスタンス を選択し、該当のインスタンスをクリックします。

右上から起動を押します。

これでしばらく待つとインスタンスが起動します。

インスタンスへ接続（Cloud Shell で接続）

OCI 上から Cloud Shell でインスタンスに接続してみます。

Cloud Shell の起動

画面右上の 開発者ツール をクリックし、Cloud Shell を選択します。

画面下に端末が表示されますが、まだインスタンスの中には入っていません。
Cloud Shell が単体で起動しただけです。

ネットワークの変更

端末上部の「ネットワーク：パブリック」と表示されたプルダウンから「エフェメラル・プライベートネット・・・」を選択します。

インスタンス作成時に作成した VCN とサブネットを選択し、アクティブなネットワークとして使用 を押します。

秘密鍵ファイルのアップロード

先程ダウンロードした秘密鍵ファイルを端末上にドラッグ＆ドロップしてアップロードします。

Linux のルールとして、秘密鍵の権限が緩いままだとSSH接続が拒否されてしまうため、以下のコマンドでパーミッションを変更します。（※ファイル名はご自身のものに書き換えてください）

chmod 600 ssh-key-xxxx.key

SSH コマンドでログインする

以上で準備は完了です。
以下のコマンドで Cloud Shell インスタンスへと接続します。

ssh -i ssh-key-xxxx.key <username>@<private_ip_address>

<username> は、インスタンスのデフォルトのユーザー名です。
Oracle Linux および Redhat Enterprise Linux 互換イメージの場合、デフォルトのユーザー名は opc、Ubuntu イメージの場合、デフォルトのユーザー名は ubuntu だそうです。

<private_ip_address> は接続先インスタンスのプライベートIPアドレスです。
コンピュート > インスタンス で確認できます。10.0.x.x のような数字を入れてください。

コマンド入力後、Are you sure you want to continue connecting (yes/no)? と聞かれたら、 yes と入力してEnterを押します。

無事にプロンプトが <username>@instance-xxxx:~$ に切り替われば、インスタンスに接続できています。

とりあえずはここまで。