Glab 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

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク: