HN公開: Proxmox VEヘルパースクリプト

 (community-scripts.github.io)
3 ポイント 投稿者 GN⁺ 2024-11-14 | 1件のコメント | WhatsAppで共有
  • Proxmox VE運用者は、コンテナとVM のデプロイ・管理を反復作業として処理することが多く、単一コマンドベースのコミュニティスクリプトハブがhomelabと仮想化運用の手間を減らしてくれる
  • このサイトは 604本のスクリプト、4,497,254回のインストール、26カテゴリを掲げ、Proxmox環境向け自動化スクリプトを1か所で探せるようにしている
  • 直近30日間の最多インストール一覧には、Docker、Debian、Immich、Nginx Proxy Manager、Jellyfin Media Serverのようなhomelabでよく使われるサービスが含まれる
  • 新たに追加されたスクリプトはLXC、ARM LXC、PVEタイプに分かれ、Koffan、Etherpad、Flame、PVE Disk Health Tool、Pinchflat、SnapOtterなどが見られる
  • システム上で直接実行されるスクリプトである以上、インストール前に 公式サイトの確認 と スクリプトソースの確認 は必須

Proxmox VE向けコミュニティスクリプトハブ

  • Proxmox VE Helper-Scripts は、Proxmox VE向けのコミュニティベース自動化スクリプトをまとめて提供している
  • ユーザーはProxmox環境で コンテナとVM を単一コマンドで検索、インストール、管理できる
  • homelabと仮想化ワークフローを簡素化する中央ハブとして機能する
  • サイトの規模は次のとおり

    • 604本のスクリプト

    • 4,497,254回のインストール

      • 26カテゴリ

新ホームページと探索フロー

  • 2026年3月6日の更新で、Proxmox VE Community Scriptsプロジェクトの 新ホームページ が公開された
  • 新しいWebサイトは、Proxmox環境向けの数百本の自動化スクリプトをより簡単に発見、閲覧、デプロイできるよう構成されている
  • コミュニティが作成したプラットフォームであり、homelabと仮想化ワークフローを簡素化するハブとして提供されている

直近30日間の最多インストールスクリプト

  • 人気一覧は 直近30日間のインストール数 を基準に並べられている
  • 上位項目は次のとおり
    • Docker: オープンソースのアプリケーションデプロイ自動化プロジェクト、30,594回インストール
    • Debian: 59,000以上のパッケージを含む無料のオペレーティングシステム、22,397回インストール
    • Immich: セルフホスト型の写真・動画管理ソリューション、18,234回インストール
    • Nginx Proxy Manager: Nginxリバースプロキシ管理のためのWebベースインターフェース、14,049回インストール
    • Jellyfin Media Server: デジタルメディアファイルを整理、管理、共有する無料のオープンソースメディアサーバー、13,707回インストール
    • Hermes Agent: Nous Researchの自己改善AIエージェント、13,233回インストール
    • Frigate: IPカメラ向けのリアルタイムAI物体検出ベースのオープンソースNVR、12,663回インストール
    • AdGuard Home: セルフホスト型のネットワーク全体広告ブロックツール、12,532回インストール
    • Ollama: ローカルコンピュータで大規模言語モデルを実行するツール、11,923回インストール
    • Ubuntu: Debianベースのディストリビューション、10,689回インストール

新たに追加されたスクリプト

  • 最近追加された一覧では、スクリプト名、タイプ、追加時点が一緒に表示される
  • 主な項目は次のとおり
    • iVentoy: 複数マシンでネットワーク経由のOS起動とインストールを同時にサポートするPXEサーバー、本日追加
    • FMD-Server: Androidデバイスの位置確認とリモート制御のための分散型ツール、1日前に追加
    • Koffan: カップルや家族向けのリアルタイム同期ショッピングリストWebアプリ、1日前に追加
    • Etherpad: ブラウザで複数人が同時編集できるリアルタイム共同文書エディタ、1日前に追加
    • Flame: サーバー向けセルフホスト型スタートページ、1日前に追加
    • PVE Disk Health Tool: Proxmox VEホストの物理ディスク状態を報告するツール、2日前に追加
    • Pinchflat: yt-dlp ベースのセルフホスト型YouTubeメディアマネージャー、4日前に追加
    • SnapOtter: ローカル実行ベースの画像処理ツール集、6日前に追加
    • Postiz: 複数のソーシャルプラットフォームへの投稿予約と管理のためのAIベースツール、9日前に追加
    • Plane: イシュー、サイクル、モジュールでソフトウェアプロジェクトを計画・追跡するオープンソースツール、11日前に追加

開発中のスクリプト

  • 開発中セクションのスクリプトは まだ正式リリースされておらず、活発に開発が進められている状態
  • 表示されている開発中項目は次のとおり
    • Rackula: homelabユーザー向けのドラッグ＆ドロップ式ラックレイアウトデザイナー
    • Umbraco CMS: オープンソースの.NET CMSとFTPサーバー自動設定スクリプト
    • Nexterm: SSH、VNC、RDP向けのオープンソースサーバー管理ソフトウェア
    • Colanode: セルフホスト型Slack・Notion代替となるローカルファースト共同作業ワークスペース
    • ExcaliDash: Excalidraw向けセルフホスト型ダッシュボード兼整理ツール

カテゴリ構成

  • スクリプトはProxmoxとオペレーティングシステム、ネットワーク、セキュリティ、バックアップ、データベース、監視、メディア、IoTなど複数のカテゴリに分かれている
  • 主なカテゴリと総数は次のとおり
    • Proxmox & Virtualization: 40本
    • Operating Systems: 27本
    • Containers & Docker: 10本
    • Network & Firewall: 40本
    • Adblock & DNS: 8本
    • Authentication & Security: 21本
    • Backup & Recovery: 11本
    • Databases: 24本
    • Monitoring & Analytics: 50本
    • Dashboards & Frontends: 17本
    • Files & Downloads: 35本
    • Documents & Notes: 59本
    • Media & Streaming: 58本
    • AI / Coding & Dev-Tools: 35本

スクリプトタイプと例

  • 各スクリプトには LXC、ARM LXC、PVE、Addon、VM、DEV、Privileged などのタイプラベルが付いている
  • Proxmox & Virtualizationカテゴリの例は次のとおり
    • PVE Disk Health Tool: 物理ディスク状態を報告し、必要に応じてsmartmontoolsとnvme-cliをインストールする
    • PVE LXC Execute: Proxmox VEノード上の1つ以上のLXCコンテナ内でユーザー定義コマンドを実行する
    • PVE Startup Dependency Check: VMまたはLXC起動前に必要な依存関係と参照ストレージの可用性を確認する
    • CronMaster: Web UI、リアルタイムログ、認証を提供するセルフホスト型cronジョブスケジューラ
    • All Templates: 複数の無料LXCテンプレートのうち1つを作成するスクリプト

プロジェクトと安全上の案内

  • プロジェクトは GitHub と Discord を通じてつながっている
  • サイト下部には、プロジェクトがコミュニティによって作られた MITライセンス のオープンソースであると表示されている
  • クローンまたは類似Webサイトが存在する可能性があるため、常に公式サイトかどうかを確認する必要がある
  • システム上で実行する前に、すべての スクリプトソース を徹底的に確認する必要がある

関連記事

1件のコメント

 
GN⁺ 2024-11-14
Hacker News のコメント

  • 投稿者とともに、tteck がホスピスに入るという悲しい知らせを伝えた後、このプロジェクトのメンテナンスを手伝うことを志願したメンテナーチームに加わっている
    チームメンバーは皆、tteck の遺産を引き継ごうという強い意志と情熱を持っている
    透明性を持って進めており、質問があれば喜んで答える
    (1) https://news.ycombinator.com/item?id=42016605

    • 本当に悲しい知らせだ
      最近になってようやくホームラボ／セルフホスティングを始めたところで、コンテナのほとんどを tteck スクリプトで設定した

  • ここ数年 Proxmox VE を使っており、ほとんどのサービスを 1 つの VM 内の Docker コンテナとして動かしていた
    個々のサービスやバックアップ作業を Proxmox のインターフェースから制御したいとずっと思っていたが、これらのスクリプトを見て Caddy といくつかの WireGuard を LXC コンテナへ移し、とても簡単にできたので感心した
    このスクリプトを作ったすべての人のおかげで、第一印象は非常に良かった

    • 注意が必要。自分も同じことを考えたが、Docker コンテナには LXC スクリプトよりもメジャーバージョン間の更新と自動アップグレードで利点がある
      通常はソフトウェアを作った開発者がコンテナも作るため、サポート対象の環境であり、アプリケーションと今後のアップグレードをよく理解している分、各バージョンに合わせて環境が正しく構成されている
      目的を達成するには、アプリごとに好みの Linux ディストリビューションを載せた LXC + Docker + アプリコンテナの組み合わせを勧める。同じ効果を得つつ、上記の利点も維持できる

  • 少し横道にそれるが、Terraform で libvirt と Unraid を管理しようとして問題に何度も遭遇し、ほとんど諦めて VM を手動管理しようとしているところだ
    Proxmox の仮想化技術が何なのか気になる
    こうしたツールを Terraform、SaltStack、Ansible のようなものの代わりに使う利点も知りたい

    • Proxmox が ZFS を使うのでスナップショットが速く、バックアップシステムも非常に優れている点にも触れる価値がある
      セルフホスティングのアプリケーションを「家畜」のように扱いたいなら、Terraform や Kubernetes などのほうが良い選択肢だ
      しかし問題が起きたときにバックアップやスナップショットから手動復旧してもよい、あるいはクラスタがあるときに LXC コンテナが別のハードウェアへ自動移動してほしいなら、Proxmox が向いている。実際の家庭環境では、「ペット」を維持する時間は「農場」を運営する時間と同じくらいか、それより少なく済む
      (1) ニュージーランドで使われる言葉遊び
    • Proxmox はホストとその上のリソース管理をより重視している。ホスト間の VM ライブマイグレーション、一部の高可用性、フェイルオーバー対応が含まれる
      望むなら、Proxmox と併せて Terraform のようなツールで VM 内部の設定を管理することもできるだろう
    • Proxmox は仮想化に KVM、コンテナに Linux Containers(LXC) を使う
      Infrastructure as Code のデプロイなら Terraform や Ansible のようなもののほうが理にかなう、という点には同意する。ホームラボで Proxmox を使う人たちは、たいてい手動管理を好み、Infrastructure as Code の実装はあまり気にしない傾向がある
      仕事では、再現可能な環境と Infrastructure as Code を強く信じている。実際に Vagrant、libvirt、KVM の組み合わせでローカルクラスタを素早く立ち上げ、テストと開発に使っており、かなりうまく動いている。ただ、自分のホームラボは Terraform/Ansible を設定するほど複雑ではない。サーバーが壊れたら考えが変わるかもしれないが
    • Terraform 用の Proxmox プロバイダーで折衷できる[1]
      流れとしては、Terraform で VM をプロビジョニングし、Ansible のようなもので VM を設定／維持する形になる
      LXC を対象にしたいなら、このプロバイダーで LXC も予約できる
      [1]: https://github.com/Telmate/terraform-provider-proxmox

  • 初めての Proxmox マシンを構成しようと調べている立場から見ると、ごく基本的で一般的な構成にしたかった
    モデム > Proxmox マシン > OPNsense VM > オンボード 10Gb NIC 経由の物理 Wi-Fi ルーター + OMV のような内部ネットワーク VM という構成。目的は、OPNsense でネットワーク全体にフィルターを追加し、内部ネットワークからメディアサーバーやバックアップなどにアクセスできるようにすること
    ところが OPNsense のスクリプトは見当たらず、OMV のスクリプトは LXC コンテナではなく VM であるべきなので、実質的には推奨されない形になっている。また、VM 同士を通信させるための接着剤的なスクリプトも見当たらない。この部分は Proxmox の設定で重要なので、シンプルなホームサーバー向け基本構成スクリプトを改善または追加する余地がありそう

    • それは基本的でも一般的でもない構成です。私にとってはそうですが、おそらくあなたにとってもそうではないかもしれませんし、大多数にとっては間違いなくそうではありません
      ルーターとファイアウォールを仮想化しようとするのは問題ありません。pfSense のファイアウォール/ルーターを VM と物理マシンで約200台デプロイしたことがあり、OPNSense も似ているので手伝えると思います
      少なくとも物理インターフェースが2つ必要です。1つでも可能ではありますが、自分が何をしているのか正確に理解している必要があります。「WAN」と「LAN」が必要です。OPNSense はまだ FreeBSD ベースのはずなので、当然 Linux の LXC コンテナでは動きません
      最後の段落は少し混乱しています。「接着剤的なスクリプト」が何を意味するのか分かりません。VM はネットワークで通信します
      仮想化をきちんと理解するには、いくつか実験してから進めることをお勧めします。具体的な問題があれば Proxmox フォーラムに来れば手伝いますが、結局は本気で飛び込むか、そうしないかのどちらかです
    • Proxmox を使っていて、VLAN も設定済みです
      ルーターから Proxmox マシンへ行くポートは、出入りするトラフィックを分離するタグ付きパケット用に設定しています
      その後、VM とコンテナは1つ以上のネットワークに「属する」よう簡単に設定できます
      私の場合、ルーターのファイアウォールルールが VLAN 間でどのトラフィックを中継するかを決めています
      OPNSense をコンテナや VM として立ち上げても、同じように VLAN 間のトラフィックを選択的に通す構成にできると思います
    • OPNSense スクリプトがなかったのは、設定ミス1つで Proxmox インスタンスがインターネットに露出してしまう可能性があるからだったのだと思います
      上級ユーザーなら ISO から VM を立ち上げるのは十分簡単です。最近も OPNSense スクリプトのリクエストがありました
      OMV については同意します。そのまま使うことはできますが、普通の人が望む使い方ではありません。数日前にスクリプトへ注釈が追加されました
      VM 同士を通信させる接着剤的なスクリプトがないとのことですが、技術的には Tailscale 経由で互いに通信できるよう支援する Tailscale スクリプトがあります :)
      これらのスクリプトは、自己完結型の LXC コンテナを設定するように設計されています。独自の Kubernetes を作ろうとするのは避けています
    • Proxmox で OPNSense VM を使っており、NIC も複数あります。そのうち1つは光回線の ONT 専用です
      外部 Wi-Fi メッシュも使用中です
      他にも VM がいくつかあります。過去互換性のために SATA カードのパススルーで Docker をホストしている unRaid VM、Home Assistant OS 用の VM、そして多数の LXC があります。非常にうまく動作しています
    • 「VM 同士を通信させる接着剤的なスクリプト」が何を意味するのか分かりません
      普通のコンピューターと同じようにネットワークを使えばよいのでは？
      VM 同士を通信させるために特別な設定をしたことはありません

  • Docker LXC と Home Assistant VM は必ず見てみるつもりです
    これまでは Proxmox の VM 内で Docker を問題なく使っていましたが、もしかするとさらに効率を引き出せるかもしれません

    • Proxmox で HAOS を VM として動かすとうまく動作します
      tteck のヘルパースクリプトをいくつか使って MQTT と zigbee2mqtt の LXC コンテナを設定し、USB Zigbee デバイスをパススルーして使っていました
    • この2つのプロジェクト用のスクリプトは非常によく動作します
      Home Assistant には LXC や Docker より HAOS VM をおすすめします

  • ホームラボで Kubernetes の代わりに Proxmox を動かすことにしたが、ある程度後悔している
    LXC は素晴らしいが、LXC や QEMU VM だけに縛られるのは、私のすべての要件には合わない。Kubernetes なら Kata のようなプロジェクトで Firecracker ハイパーバイザーやユニカーネルのような軽量 VM サポートを追加できたはずだが、Proxmox は拡張性に欠ける
    また、Kubernetes のような実績ある Pod マネージャーほど、自動化や再現可能なビルドに向いていない。私が調べた限りでは Terraform サポートもなく、ディスク全体のバックアップと Chef/Ansible/Puppet 系のツールに頼る必要があるが、それらを改めて学ぶことに投資したくない
    それでも、リソース管理とパススルーモデルは非常に良く、設定と保守が簡単で、コントロールパネルも悪くない

    • 確かにデプロイモデルが違う。欠点はあるが、私は気に入っている
      ただし、コミュニティ製の Terraform モジュールがある: https://registry.terraform.io/providers/Telmate/proxmox/late...
      自分で使ったことはなく、たいていは Ansible を選ぶ
      簡単にセットアップできる ZFS のおかげで、他のものを試すよう自分を説得するのも難しい。Kubernetes で遊びたければ、VM を1つまたは複数立ち上げればよい
    • 私はかなり徹底的に NixOS にはまっている
      しばらく複数のシングルボードコンピューターで Docker Swarm を動かし、その後 Kubernetes、Ubuntu + Cockpit を動かす大きなサーバー、Proxmox を経て、最終的に NixOS に落ち着いた
      NixOS は必要ならコンテナ対応も十分だが、宣言的な性質のおかげで、コンテナをほとんど使わなくなった。何かを「削除」するのも、たいていは設定ファイルから外して再ビルドすれば終わりだ。メモリ管理のような用途で cgroup 的なことをするのも難しくない
      NixOS の nginx DSL も素晴らしいと思う。自分でスクリプトを書く代わりに、プロキシ設定と Let’s Encrypt を設定環境が直接、しかも正しく管理してくれるのは本当に良い
      分散 NixOS 関連のツールがあるかは分からないが、Flakes の上に面白いものを作れそうだと思う
      私のホームラボは今が最もシンプルで、満足度も最も高い
    • この Terraform プロバイダー[1] と Talos[2] ディストリビューションを組み合わせて Kubernetes クラスターをデプロイしてみた
      Proxmox が提供する API が完全ではないという点には同意するが、私の用途には十分だ
      廃棄寸前の SFF マシン4台でクラスターを動かし、LVM スナップショットを自作の TrueNAS ストレージにバックアップしているが、この構成全体を気に入っている
      [1] https://github.com/Telmate/terraform-provider-proxmox
      [2] https://factory.talos.dev/
    • Proxmox を使うからといって Kubernetes が使えないわけではない
      Proxmox で VM を作り、その上に Kubernetes をインストールして、アプリケーションワークロードを Kubernetes で動かせばよい
      Proxmox VM は自動化がより難しいので「家畜ではなくペット」のように扱う必要があるが、ベアメタルで Kubernetes ホストを管理するときも同じだ。ただし Proxmox 上の VM なら、VM 全体のバックアップとマイグレーションを Proxmox で行えるため、Proxmox と Kubernetes の両方の利点を得られる
    • 技術ごとに適したアプローチと用途が異なる
      Proxmox では pve コマンドラインユーティリティで VM を作成したり変更したりするのは比較的簡単だ
      とはいえ、この記事の出発点は、管理をより簡単で保守しやすくしてくれる有用なスクリプトが多くあり、創設者が身を引かざるを得ない状況で、その助けに対する感謝があるという点にある

  • 素の KVM にはなく、Proxmox にはある機能とは何か。ただの Web インターフェースだけなのか？

    • ぱっと思いつくだけでも クラスタリング、マイグレーション、高可用性、バックアップ、Ceph 統合、最近の仮想ネットワーク、VM だけでなくコンテナ対応がある
      Web インターフェースも選択肢の一つだ。詳しくは Proxmox の Web ページを見るのがよい
    • KVM はカーネル側のコンポーネントにすぎず、それ自体で完全な 仮想マシンマネージャーではない。常にユーザー空間アプリケーションが必要だ
      Firecracker、QEMU、Cloud-Hypervisor は KVM の上に作られた仮想マシンマネージャーだ
      QEMU が KVM を使う一般的な方法だが、QEMU を直接実行するのはかなり面倒だ。そのため、QEMU を包む libvirt や Proxmox のようなツールを使うことになる

  • 素晴らしいコミュニティだ。すでにスクリプトをいくつか使っており、Pi-hole と Paperless の LXC コンテナを動かしている
    Appflowy も楽しみにしている

  • 残念ながら Proxmox は Web サイトの最初の段落で「Enterprise」という言葉を使っているにもかかわらず、いまだに ディスク全体暗号化を標準サポートしていない
    もちろん、自分で暗号化済みの Debian にインストールする方法はあるが、重要な機能を失うことになり、自分で面倒を見る必要がある。結局のところ、ZFS がディスク全体暗号化を一級機能として扱っていないことに起因している
    非常に残念な状況だ