この記事は「Proxmox自動インストール＆CI/CD構築」シリーズの Part 1 です。
👉 Part 2はこちら → パイプライン構築・NanoKVM・Ansible編
はじめに
自宅のテスト用デスクトップPCにProxmox VEを何度も入れ直す機会があり、毎回GUIでポチポチするのが面倒になってきました。
やりたいこと
NanoKVM（またはiLO等のIPMI対応デバイス）を使って、リモートから電源ON → Proxmox無人インストール → ポストインストール設定までを自動化すること。最終的には「ボタン1つでProxmoxが新鮮な状態に戻る」環境を作ります。
正直、シェルスクリプト1本でもできる
Proxmoxの自動インストール自体は大掛かりな仕組みがなくても実現できます。自宅LAN内のマシンに以下のようなスクリプトを置いて実行するだけです。
#!/bin/bash
# reinstall-proxmox.sh
# answer.tomlを生成してHTTPで配信開始
envsubst < answer.toml.template > /tmp/answer.toml
cd /tmp && python3 -m http.server 8080 &
HTTP_PID=$!
# 電源OFF → ON（ipmitoolはiLOでもNanoKVMでも同じコマンド）
ipmitool -H $KVM_HOST -U admin -P $KVM_PASS -I lanplus -C 3 power off
sleep 5
ipmitool -H $KVM_HOST -U admin -P $KVM_PASS -I lanplus -C 3 power on
# SSH待ち
until ssh -o ConnectTimeout=5 root@$PROXMOX_IP 'echo ok' 2>/dev/null; do
sleep 30
done
# ポストインストール（Ansible）
ansible-playbook -i "$PROXMOX_IP," playbooks/post-install.yml
kill $HTTP_PID
echo "Done. https://$PROXMOX_IP:8006"
それでもGitLab CI/CDで組む理由
この記事ではあえてGitLab CI/CDのパイプラインとして構成しています。
| やりたいこと | シェルスクリプトだけ | GitLab CI/CD |
|---|---|---|
| 自動インストール | できる | できる |
| バージョン管理 | GitHub等で別管理 | GitLabに内蔵 |
| WebUIからワンクリック実行 | できない | できる |
| パスワード等のシークレット管理 | .envファイル等で自前管理 | Masked変数 |
| 実行ログの保存 | 自分で仕組む | 自動保存 |
| 複数台・チーム運用へのスケール | 辛い | 容易 |
個人のホームラボで1人で使うだけならスクリプトで十分ですが、CI/CDで組むことで、パイプラインの設計パターンやAnsibleとの連携を実践的に学べます。法人環境（複数台のサーバー管理やチーム運用）へのスケールアップにもそのまま使えます。
GitLabをクラウドに置く理由
GitLabはメモリを4GB以上消費するため、ローカルに常時稼働できるリソースが必要です。自分の環境では以下の理由でローカルに置けませんでした。
- デスクトップPC → Proxmoxの自動インストール対象。GitLabを同居させると再インストール時に共倒れする
- その他の自宅マシン → メモリ等のリソースが足りない
そのため、OCI Always FreeまたはAWSの無料枠にGitLabを立てて、パイプラインの定義とシークレットをローカル環境から分離しています。こうすることで、ローカルを何度壊しても復旧できる構成になります。
gitlab.com（SaaS版）でも同じことができます。
自前でGitLabを立てたくない方は、gitlab.com の無料プランでアカウントを作り、本記事の「GitLab Runnerのセットアップ」セクションからRunner登録を始めてください。リポジトリ・CI/CD変数・パイプライン実行はSaaS版でも同じように使えます。
Part 1（この記事）では、その土台となる GitLabとRunnerをクラウドの無料枠に立てるところまで を扱います。
インストール先は自宅デスクトップPCを前提にしていますが、HPE DL360（iLO搭載サーバー） をお持ちの場合の補足も随所に入れています。iLO環境では「Run pipeline」を押すだけで電源ON〜インストール完了まで完全リモート自動化が可能です。デスクトップPCの場合は NanoKVM-PCIe を追加することで同等の自動化が可能です（詳細はPart 2）。
全体構成（暫定）
以下の構成図はPart 2の内容も含めた全体像です。パイプラインの詳細設計は進行中のため、最終的な構成はPart 2公開時に確定します。
処理の流れをざっくり整理するとこうなります。
WSL（開発PC）
└─ git push → OCI GitLab CE（リポジトリ / CI/CD変数 / WebUI）
│
↓ ポーリング（HTTPS）
自宅マシン（GitLab Runner）
│
├─ Stage 1: answer.toml生成 → HTTP server起動（NanoKVM or Runner上）
├─ Stage 2: ipmitool → NanoKVM経由で電源ON
├─ Stage 3: HTTP server停止 → SSH疎通待ち
└─ Stage 4: Ansible ポストインストール設定
├─ リポジトリ修正（エンタープライズ→コミュニティ）
├─ apt full-upgrade
└─ PVEバージョン・WebUI疎通確認
ISOについて： Proxmoxの自動インストール用ISOは --fetch-from http モードで事前に1回だけビルドし、NanoKVMの仮想USBストレージに格納しておきます。ISOにはanswer fileを埋め込まず、インストーラが起動時にNanoKVM上のHTTPサーバー（10.27.94.1:8080）からanswer.tomlを取得します。
NanoKVM-PCIeはデスクトップPCとUSBで接続されると 10.27.94.x のプライベートネットワークを提供します。インストール中はこのUSB NICしかアクティブでないため、Runner（Raspberry Pi）には届きません。そのため、HTTPサーバーはNanoKVM上で動かします（詳細はPart 2）。
iLO / iDRAC環境の場合： Stage 2の ipmitool コマンドはiLO / iDRACでも同じです。CI/CD変数のIPとパスワードを差し替えるだけで動作します。
GitLab設置先の選び方
GitLabはメモリをそれなりに消費するため、無料枠の選択が重要です。
| OCI Always Free | AWS 無料枠 | |
|---|---|---|
| 無料期間 | 永久 | 12ヶ月のみ |
| スペック | Ampere A1 最大4コア / 24GB RAM | t3.micro（1コア / 1GB RAM） |
| GitLab適性 | ◎（余裕あり） | △（1GBは厳しい、swap必須） |
| 注意点 | リージョンによって空きがない場合あり | 1年後に課金開始 |
長期運用するならOCI Always Freeが断然おすすめです。AWSは1年後に課金が始まるうえ、t3.microの1GBではGitLabがギリギリです。
OCI Always Freeの主要スペック（2026年時点）
| サービス | 内容 |
|---|---|
| Ampere A1 | 合計4コア・24GB RAM（1〜4台のVMに分割して使用可能） |
| AMD VM | 2台、各1/8 OCPU・1GB RAM |
| Block Volume | 合計200GB（ブートボリューム含む）・バックアップ5個 |
| Object Storage | Standard / Infrequent / Archive 合算で20GB |
| Outbound転送 | 最大10TB/月 |
| Email Delivery | 3,000通/月 |
| Load Balancer | 1インスタンス・10Mbps |
| VCN | 2つ（IPv4・IPv6対応） |
GitLab用途であれば A1インスタンスを1台に2コア・12GB 割り当てるのがおすすめです。
Part 1-A：OCIにGitLabを立てる
1. Instancesページを開く
OCIコンソール左メニューから Compute をクリックし、サブメニューの Instances を選びます。
Instancesの一覧ページが開いたら、Create Instance ボタンをクリックします。
2. Basic information（名前・イメージの設定）
「Create compute instance」画面が開きます。まずインスタンス名を分かりやすい名前に変更します（デフォルトは instance-日付-時刻 になっています）。
次に Image and shape セクションまでスクロールし、Change image をクリックしてイメージを変更します。
- Operating system：Canonical Ubuntu
- OS version：22.04
デフォルトはOracle Linux 9になっています。 GitLabのインストールにはUbuntuが必要なので、必ずChange imageでUbuntu 22.04に変更してください。
イメージを選んだら、続けて Change shape をクリックします。
3. シェイプの選択
「Browse all shapes」画面が開きます。
まず Shape series で Ampere を選択します。
一覧に VM.Standard.A1.Flex（Always Free-eligibleバッジ付き）が表示されるので選択し、Select shape をクリックします。
「Don't see the shape you want?」と表示される場合：
Always Free枠ではAmpereシェイプのみが選択できます。表示されているUpgradeボタンは押さなくて大丈夫です。VM.Standard.A1.FlexがAlways Free対象です。
4. OCPU数・メモリの設定
シェイプを選択すると「Image and shape」の画面に戻ります。シェイプ欄に VM.Standard.A1.Flex と Always Free-eligible バッジが表示されていれば正しく設定されています。
デフォルトでは1コア・6GBになっているので、OCPU数を2、メモリを12GB に変更します。
| 項目 | 設定値 | 備考 |
|---|---|---|
| OCPU | 2 | Always Free枠の合計は4コアまで |
| メモリ | 12 GB | Always Free枠の合計は24GBまで |
設定したら Next をクリックします。
5. Networking（VCN・サブネットの設定）
※Securityの「Shielded instance」は必要であればONにしてください
Networkingセクションが開きます。
Primary network の設定は以下のどちらかを選びます。
- 既存のVCNがある場合：Select existing virtual cloud network を選んでVCNとSubnetを選択
- 初めて作成する場合：Create new virtual cloud network を選ぶと自動で作成されます
VCNがまだ存在しない場合：
「Create new virtual cloud network」を選択するとVCNとサブネットが自動作成されます。名前はデフォルトのままで問題ありません。
Warningが表示されますが問題ありません。
「You must select a public subnet to assign a public IPv4 address.」という警告が出ますが、新規VCN作成時に自動でパブリックサブネットが作られるため、作成後にパブリックIPが割り当てられます。そのままNextで進めてください。
6. SSHキーの設定
同じNetworkingページの下部に Add SSH keys セクションがあります。
WSLですでにSSHキーを持っている場合は Paste public key を選択し、公開鍵を貼り付けます。
# WSL上で実行して公開鍵をコピーする
cat ~/.ssh/id_rsa.pub
SSHキーをまだ持っていない場合：
「Generate a key pair for me」を選択し、表示される Download private key ・Download public key ボタンで両方ダウンロードしておきます。秘密鍵はこの画面でしかダウンロードできないので必ず保存してください。
ダウンロードした秘密鍵はWSLの ~/.ssh/ にコピーしてパーミッションを設定します。
# WindowsのダウンロードフォルダからWSLにコピー
cp /mnt/c/Users/<Windowsユーザー名>/Downloads/ssh-key-*.key ~/.ssh/oci_key.pem
chmod 600 ~/.ssh/oci_key.pem
設定が完了したら Next をクリックします。
7. Storage（ブートボリュームの確認）
Storageセクションが開きます。
Boot volume はデフォルト（46.6 GB）のままで問題ありません。
「Specify a custom boot volume size」のトグルをONにすると容量を変更できますが、Always Free枠ではブートボリュームを含む全ブロックボリュームの合計が 200GBまで です。デフォルトのままにしておくのが無難です。
Block volumesは何も追加せず、Next をクリックします。
8. Review（設定内容の確認）
Review画面で設定内容を確認します。
以下のようになっていれば正しく設定されています。
| 項目 | 確認内容 |
|---|---|
| Name | 設定したインスタンス名 |
| Operating system | Canonical Ubuntu 22.04 |
| Shape | VM.Standard.A1.Flex |
| Shape build | Virtual machine, 2 core OCPU, 12 GB memory |
問題がなければ Create をクリックします。
Createを押してエラーが出た場合
① Out of Host Capacity（容量不足）
Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1.
東京リージョンはA1インスタンスの空きが枯渇しがちで、かなりの頻度で遭遇します。
別リージョン（大阪など）への切り替えが定番の対処ですが、Always Freeアカウントでは無料トライアル終了後にサブスクライブできるのが1リージョンのみとなるため、以下のエラーが出て追加できない場合があります。
② リージョン上限エラー
You have exceeded the maximum number of regions allowed for your tenancy.
この場合は AMD VM（VM.Standard.E2.1.Micro） への切り替えが現実的な選択肢です。
Browse all shapesで Specialty and previous generation タブを選ぶと表示されます。スペックは1/8 OCPU・1GB RAMですが、swapを足すことでGitLabが動作します。
E2.1.Microを選択した場合はインスタンス作成後、SSH接続してから最初にswapを設定してください。これをやらないとGitLabインストール中にメモリ不足でフリーズします。
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo nano /etc/fstab
末尾に以下を追記して保存します。
/swapfile none swap sw 0 0
Ctrl+O → Enter で保存、Ctrl+X で終了します。
# 確認（Swap: 4.0G と表示されればOK）
free -h
swap設定後はステップ9（インスタンスの起動確認）から同じ手順で進められます。
③ 時間をおいてリトライ
急がない場合は数時間後に同じ設定のままCreateを押し直すと取れることがあります。
9. インスタンスの起動確認
インスタンスのページに遷移し、しばらくするとステータスが Running になります。
Networking タブ をクリックし、パブリックIPアドレス をメモしておきます（後で使います）。
Work requests タブ でCreate instanceのStateが Succeeded になっていれば正常に作成完了しています。
10. セキュリティリスト（ポート開放）
インスタンスを作成したあと、ネットワークのポートを開放します。
左メニューの Networking → Virtual cloud networks をクリックします。
VCN一覧から、インスタンス作成時に自動作成されたVCN（例：vcn-日付-時刻）をクリックします。
VCNの詳細画面が開いたら、上部のタブから Security をクリックし、Security Lists一覧の Default Security List for vcn-... をクリックします。
Security rules タブ を選択し、Add Ingress Rules ボタンをクリックします。
Add Ingress Rulesのフォームが開きます。以下の3ポートをそれぞれ追加します。+ Another Ingress Rule ボタンで1画面で複数まとめて追加できます。
| Source CIDR | IP Protocol | Destination Port Range | 用途 |
|---|---|---|---|
| 0.0.0.0/0 | TCP | 22 | SSH |
| 0.0.0.0/0 | TCP | 80 | GitLab HTTP |
| 0.0.0.0/0 | TCP | 443 | GitLab HTTPS |
入力したら Add Ingress Rules ボタンをクリックして保存します。
11. インスタンスにSSH接続
# WSL上で実行（パブリックIPはOCIコンソールのNetworkingタブで確認）
ssh ubuntu@<OCI_PUBLIC_IP>
「Generate a key pair for me」でキーをダウンロードした場合は秘密鍵を指定します。
ssh -i ~/.ssh/oci_key.pem ubuntu@<OCI_PUBLIC_IP>
接続できたら以降の作業はすべてこのSSHセッション内で行います。
12. OS側のファイアウォール設定とswap設定
OCIのUbuntuはセキュリティリストとは別に、OS内にもiptablesが動いています。
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
# 永続化（再起動後も設定を保持する）
sudo apt install -y iptables-persistent
sudo netfilter-persistent save
E2.1.Micro（1GB RAM）を使っている場合は、続けてswapを設定します。
A1.Flex（12GB RAM）の場合はこの手順は不要です。
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo nano /etc/fstab
末尾に以下を追記します。
/swapfile none swap sw 0 0
Ctrl+O → Enter で保存、Ctrl+X で終了します。
# 確認（Swap: 4.0G と表示されればOK）
free -h
13. GitLabのインストール
# 必要パッケージのインストール
sudo apt update
sudo apt install -y curl openssh-server ca-certificates tzdata perl
# GitLab公式リポジトリの追加
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
# GitLabのインストール（EXTERNAL_URLをパブリックIPに変えて実行）
sudo EXTERNAL_URL="http://<OCI_PUBLIC_IP>" apt install -y gitlab-ce
インストールには10〜15分ほどかかります（ダウンロード約1.4GB）。
↓デフォルトパスワードは変更済みなのでご安心をw
E: Unable to locate package gitlab-ce が出た場合：
script.deb.sh がリポジトリを正しく追加できなかった場合に発生します。以下の手順で手動でリポジトリを追加してください。
# GPGキーを追加
curl -fsSL https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey | \
sudo gpg --dearmor -o /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg
# リポジトリファイルを手動で作成
sudo nano /etc/apt/sources.list.d/gitlab_gitlab-ce.list
以下を入力します。
deb [signed-by=/usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ jammy main
deb-src [signed-by=/usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ jammy main
Ctrl+O → Enter で保存、Ctrl+X で終了します。
sudo apt update
sudo EXTERNAL_URL="http://<OCI_PUBLIC_IP>" apt install -y gitlab-ce
14. GitLabにアクセス
ブラウザで http://<OCI_PUBLIC_IP> を開きます。
# 初期rootパスワードの確認
sudo cat /etc/gitlab/initial_root_password
ユーザー名 root、上記パスワードでログインします。
ログイン後すぐにrootのパスワードを変更しておきます。
右上アイコン → Edit profile → Password
Part 1-B：AWSにGitLabを立てる（t3.micro）
t3.microはメモリ1GBのため、GitLabの動作は重いです。swap設定が必須です。
また無料枠は12ヶ月限定のため、長期運用にはOCIを推奨します。
1. EC2インスタンスの作成
AWSコンソール → EC2 → インスタンスを起動
| 項目 | 値 |
|---|---|
| AMI | Ubuntu Server 24.04 LTS（64ビット x86） |
| インスタンスタイプ | t3.micro（無料枠対象） |
| ストレージ | 8 GiB gp3（デフォルト） |
| キーペア | 新規作成 or 既存のキーを選択 |
2. セキュリティグループの設定
| タイプ | ポート | ソース |
|---|---|---|
| SSH | 22 | マイIP |
| HTTP | 80 | 0.0.0.0/0 |
| HTTPS | 443 | 0.0.0.0/0 |
3. SSH接続
# WSL上で実行（キーペアの.pemファイルのパスを指定）
ssh -i ~/.ssh/<YOUR_KEY>.pem ubuntu@<EC2_PUBLIC_IP>
4. swap設定（t3.micro必須）
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
再起動後も有効にするため /etc/fstab に追記します。
sudo nano /etc/fstab
ファイルの末尾に以下を追記します。
/swapfile none swap sw 0 0
Ctrl+O → Enter で保存、Ctrl+X で終了します。
# 設定確認
free -h
5. GitLabのインストール
sudo apt update
sudo apt install -y curl openssh-server ca-certificates tzdata perl
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
# EXTERNAL_URLをEC2のパブリックIPに変えて実行
sudo EXTERNAL_URL="http://<EC2_PUBLIC_IP>" apt install -y gitlab-ce
# 初期rootパスワードの確認
sudo cat /etc/gitlab/initial_root_password
Part 1-C：GitLab Runnerのセットアップ（OCI・AWS共通）
CI/CDパイプラインを動かすRunnerを、GitLabと同じVM上に立てます。
このRunnerはGitLabの動作確認用です。Part 2では、自宅LAN内のマシンに別途ローカルRunnerを登録し、NanoKVMやProxmoxへの直接アクセスが必要なパイプラインはそちらで実行します。
1. GitLab Runnerのインストール
# GitLab Runner公式リポジトリの追加
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
# GitLab Runnerのインストール
sudo apt install -y gitlab-runner
# Ansible・sshpass など必要ツールのインストール
sudo apt install -y ansible python3-pip sshpass wget curl
2. GitLabプロジェクトの作成
GitLab → New project → Create blank project
3. RunnerをGitLabプロジェクトに登録
プロジェクト → Settings → CI/CD → Runners → New project runner
Create project runner 画面が開きます。Tagsフィールドに proxmox と入力し、Create runner をクリックします。
Runner作成後に表示されるURLとトークンを使って、VM上で登録します。
sudo gitlab-runner register \
--url http://<GitLab_IP> \
--token <コピーしたトークン>
対話式で以下を入力します。
Enter the GitLab instance URL : [そのままEnter]
Enter a name for the runner : proxmox-runner（任意）
Enter an executor : shell
Invalid executor specified が出た場合：
スペルを確認して shell と入力し直してください。
# 登録確認
sudo gitlab-runner status
sudo gitlab-runner list
GitLabのRunners画面に戻り、緑のActiveマークが付いていれば登録完了です。
ここまでのまとめ
この記事（Part 1）では以下を構築しました。
- OCI または AWS の無料枠に GitLab CE をインストール
- GitLab Runner を登録し、Ansible を使える状態にした
次のPart 2では、自宅LAN内のマシンにローカルRunnerを登録し、NanoKVMのセットアップ・SSH鍵生成・CI/CD変数の設定・answer.toml・パイプラインファイル・Ansibleプレイブックなど、自動インストールの中身を作っていきます。
👉 Part 2はこちら → パイプライン構築・NanoKVM・Ansible編