Ubuntu日和

【第48回】脱ESXi?UbuntuとCockpitで仮想化プラットフォームを構築しよう

 本連載でも何度か言及しているが、仮想マシンはとても便利だ。1台のPCで複数のOSを併用したり、ホストOSの環境を汚さずにアプリの検証を行なったりと、便利に活用している方も多いのではないだろうか。

 無料で使える仮想化ソフトウェアと言えば、なんといってもVirtualBoxだ。WindowsユーザーがUbuntuデスクトップを体験してみたい時などは、筆者もまず最初にVirtualBoxの利用を勧めている。

 VirtualBoxは確かに便利なのだが、基本的にはデスクトップアプリだ。初心者でも使いやすい反面、「サーバー用途で仮想マシンを複数同時に動かしたい。それも自動的に」といった用途には向かない部分もある。そのためサーバー運用の分野では、専用の仮想化ハイパーバイザーが使われることが多い。

 そしてオンプレミスにおける仮想化ハイパーバイザーの定番とも言えるのが、VMware ESXiだ。詳しくはESXiのページを見ていただきたいのだが、簡単に言えばOSのかわりにハードウェアに直接インストールすることで、仮想マシンを動かす基盤を構築するソフトウェアだ。ESXiは無償版が用意されていたことから、サーバーが複数動いているような誤家庭であれば、1台くらいは存在したのではないだろうか。

 ところが最近、VMware社の買収にともなうさまざまな変更があり、ESXi無償版の提供は終了してしまった。有償版を使うほどではないホビーユーザーにとっては大ピンチである。

 ESXiの代替候補となるソリューションは、いくつか存在する。たとえば本サイトの姉妹サイトであるINTERNET Watchでもたまに紹介されるProxmox VEだ。これはDebian GNU/Linuxをベースとした仮想化プラットフォームで、実は筆者も10年以上前から利用している。そのためProxmox VEを紹介しようか……と思ったのだが、「それUbuntu関係ないやろ」とツッコミが入ってしまった。

 というわけで今回は、Ubuntu上で動作する別の仮想マシン管理ソリューションを紹介しようと思う。

Cockpitとは

 そこで今回紹介するのが「Cockpit」だ。実はCockpitは、WebブラウザからLinuxのシステム管理を行なうためのソフトウェアで、仮想マシン管理用のソフトウェアではない。ただしプラグインによる機能拡張をサポートしており、仮想マシンの管理を任せることもできる、というわけだ。インターネットのベテラン(多方面に配慮した表現)ならば「Webminのなんかすごいやつ」と言えば、その雰囲気は伝わるのではないだろうか。

NetworkManagerでネットワークを管理する

 それではここからは、実際にUbuntuにCockpitをインストールして、仮想マシンを動かすまでを紹介しよう。なお原稿執筆時期の都合上、来月リリース予定のUbuntu Server 24.04 LTSの開発版]を使って動作確認を行っていることをご了承いただきたい。また開発版のUbuntu Serverのインストール手順については省略させてもらう。基本的には第26回と同じなので、こちらを参照していただきたい。

 サーバーのインストールが完了したら、最初にやっておきたいのがIPアドレスの固定化だ。OSのインストール時に作成された設定が「/etc/netplan/50-cloud-init.yaml」に保存されているので、このファイルを以下のように書き換えてほしい。

/etc/netplan/50-cloud-init.yamlの変更内容
network:
    renderer: NetworkManager
    ethernets:
        NIC名(enp1s0など):
            addresses:
            - 設定したいIPアドレス(192.168.1.20/24など)
            routes:
              - to: default
                via: デフォルトゲートウェイのアドレス(192.168.1.1など)
            nameservers:
              addresses:
              - ネームサーバーのアドレス(192.168.1.1など)
              search: []
    version: 2

 基本的には【第29回】で紹介した方法と同じなのだが、「renderer: NetworkManager」という1行を追記している所がポイントだ。Netplanは暗黙的に、systemd-networkdによってネットワークを設定する。だがCockpitはNetworkManager経由でNICを管理するため、NetplanのrendererをNetworkManagerに変更しておきたいのがその理由だ。

 ちなみにUbuntu Serverでは、デフォルトでNetworkManagerはインストールされていないため、パッケージのインストールも必要になる。設定ファイルの書き換えが完了したら、以下のコマンドを実行して、正しくIPアドレスが設定されていることを確認しよう。

NetworkManagerをインストールしてから、ネットワーク設定を適用する
$ sudo apt update
$ sudo apt install -y network-manager
$ sudo netplan apply

Cockpitのインストール

 Cockpit自体はAPTでインストールできる。以下のコマンドを実行しよう。

cockpitパッケージのインストール
$ sudo apt install -y cockpit

 これだけでCockpitが動きだす。いや、厳密に言えばポートを待ち受けているのはsystemdで、アクセスがあった際に初めてCockpitが動き出すのだが、細かいことはどうでもいいだろう。Webブラウザから「https://サーバーのIPアドレス:9090」にアクセスしてみよう。インストール直後のCockpitは自己署名証明書を使用しているため、ブラウザが警告を出す。本来であれば正式な認証局が発行した証明書を使うべきだが、本題から外れてしまうため、ここでは無視する。

Firefoxであれば「詳細へ進む」→「危険性を承知の上で使用」をクリックしよう

 Cockpitのログイン画面が表示されるので、Ubuntuのユーザー名とパスワードを入力してログインしよう。

Cockpitは、Ubuntu上のユーザーアカウントを使ってログインする

 Cockpitはページの左側に管理項目が、右側にその内容が表示される。よくあるタイプの画面なので、特に迷うことはないだろう。たとえば「ログ」ではホストのログを確認できる。日次やエラーレベルでフィルタすることもできるため、SSH越しにlessやgrepで検索するより便利だろう。

 「ネットワーキング」ではホストのネットワークを管理できる。VPNやNICチーミングといった設定も可能だ。「ユーザー」ではユーザーアカウントの管理が行なえる。本記事の主題からは外れるため解説は省くが、とりあえずいろいろとクリックしてみてほしい。

Cockpitの概要画面
「端末」をクリックすると、ホストのシェルを使うことができる。ちょっとしたコマンドをブラウザ上から実行でき、別途SSHクライアントを用意する必要がなくなるのは、地味に便利かもしれない

Ubuntu ServerとLVMの話

 ところで、このスクリーンショットを見てほしい。まっさらのUbuntu ServerにCockpitをインストールし、ストレージの情報を表示したものだ。

お分かりいただけただろうか……

 OSがインストールされているのが、「nvme0n1」というSSDで、容量は見ての通り1TBだ。だが実際に作成されているext4ファイルシステムは、なんと110GBしかないのだ。この例では、1TBのうち約900GB弱の領域は、このままでは使えない。

 これだけ聞くと「欠陥だ!」と思うかもしれないが、まあちょっと落ち着いて聞いてほしい。

 Ubuntu Serverはデフォルトで、LVMという機能を使ってボリュームを管理する。LVMについては【第34回】で少し触れたが、高度で柔軟なボリューム管理を行なうための機能だ。複数のディスクを束ねて巨大な1つのボリュームを作成したり、任意の時点のスナップショットを作成し、後からの巻き戻しを可能にする。

 PCのストレージを、大容量のものに引越しをしたことがある人は理解できると思うが、パーティションの拡張というのはそれほど難しくない。それに対して縮小は少々面倒だ。LVMの特徴は柔軟なボリューム管理なのだが、ストレージに空き容量がないと、新規ボリュームの追加やスナップショットの作成ができなくなってしまう。そこでUbuntuでは、敢えてデフォルトのボリュームサイズを小さく抑えることで、将来のための空き容量を確保しているというわけだ。どのようにサイズを決定しているかは、興味があったらインストーラーのソースコードを見てみてほしい。

 とはいえ、今回は仮想マシンを大量に動かす予定のサーバーのため、ストレージは大きいに越したことはない。そこで空き容量すべてを使って、ボリュームを拡張してしまおう。以下のコマンドは、Ubuntuがインストールされている論理ボリュームを、ボリュームグループの100%まで拡張した上で、ファイルシステムをリサイズするコマンドだ。

この仕様に気づかず「なんかサーバーのディスクの枯渇が早いような……?」と感じているうっかりサーバー管理者は、ストレージのサイズを確認した上で、このコマンドを実行してほしい
$ sudo lvextend -l 100%VG -r /dev/ubuntu-vg/ubuntu-lv
ファイルシステムが無事に拡張された状態。サイズが980GBに増えているのが分かる

Cockpitで仮想マシンを管理する

 Cockpitで仮想マシンを管理できるように、プラグインをインストールしよう。Ubuntuでは「cockpit-machines」パッケージをインストールすればいい

$ sudo apt install -y cockpit-machines

 インストールすると、Web UIの左ペインに「Virtual machines」という項目が増えるので、ここをクリックしよう。

仮想マシン管理用のUIが生えてくる

 VMの作成には管理者権限が必要になる。まず上部にある「制限つきアクセス」という南京錠のアイコンをクリックする。するとパスワード入力ダイアログが表示されるので、ログインしているユーザーのパスワードを入力しよう。

パスワードを入力して管理者権限を取得する。つまるところsudoだ

 管理者に昇格できたら、今度は「仮想マシンの作成」をクリックする。例としてAlmaLinux 9の仮想マシンを作成してみよう。仮想マシン作成ダイアログが開いたら、各項目を埋めていく。「名前」には分かりやすい仮想マシンの名前をつけよう。「接続」は「System」、「インストールタイプ」は「OSをダウンロード」とした。こうすることで、リストから選択できるOSに関しては、ISOイメージなどを用意することなくインストールができる。OSは前述の通り「AlmaLinux 9」、ストレージは「qcow2」を新規作成し、ストレージとメモリのサイズは適当に設定した。

仮想マシンの設定を決めたら、「作成して実行する」をクリックする

 これで仮想マシンが起動する。一覧から仮想マシンの名前をクリックすると、以下のような詳細画面が表示される。「コンソール」の部分に、仮想マシンの画面が表示されているのが見えるだろう。ここにフォーカスを当てると、キーボードやマウスで仮想マシンの操作が可能だ。

小さすぎて操作しにくい場合は「展開」をクリックしよう。仮想マシンのコンソールがウィンドウ内いっぱいに広がって、操作しやすくなる

 なお仮想マシンをサーバーとして運用するのであれば、ホスト起動時に仮想マシンも自動的に起動するようにしておくと便利だ。上記イメージの「自動起動」をオンにしておくといいだろう。

ISOイメージからインストールする

 前述のOSをダウンロードする方法では、インストーラを用意する必要もなく、簡単に仮想マシンにOSをインストールできた。だがよく見てみると分かるのだが、Ubuntuは16.04と18.04しか選択できない。さすがにこれは古すぎる。ではここにリストアップされていないOSはインストールできないのかと言えば、もちろんそんなことはない。ISOイメージファイルからのインストールも、当然サポートされている。

 仮想マシンの新規作成時に「インストールタイプ」を「URL」にしよう。そして「インストールソース」にISOファイルのURLを入力すればいい。

こちらの方法でも、いちいちISOファイルをダウンロードする必要はないため、同様にお手軽だ

 ダウンロード済みのISOイメージファイルを使うこともできる。ISOファイルをホストにコピーした上で、「インストールタイプ」を「ローカルインストールメディア」、「インストールソース」に、ISOファイルのパスを指定しよう。ただしこの際ISOファイルは、Cockpitにログインしているユーザーと、libvirt-qemuユーザーの両方が読み取れるパーミッションになっている必要がある点にだけ注意しよう。

仮想マシンをLANに直接公開する

 Cockpit-machinesをインストールすると、デフォルトでvirbr0という仮想ブリッジが作成される。これは仮想的なL2スイッチとして動作し、各仮想マシンはTAPデバイスを通じて仮想ブリッジに接続される。簡単に言えば、ホストが所属するLANの中に、もうひとつ別の(仮想的な)LANが入れ子になっているイメージだ。

virbr0という仮想ブリッジの下に、192.168.122.0/24のIPアドレスレンジを持つNATネットワークが用意されている。このネットワークに接続した仮想マシンには、DHCPによって192.168.122.2〜254のIPアドレスが割り当てられるというわけだ

 こうした構成は、外部へ出て行く分には問題はないのだが、別のPCから仮想マシンに直接アクセスすることができないという、NAT特有の問題がある。外部からアクセスできないと、サーバーとしての用を成さないため、これはちょっと困った問題だ。そこで仮想マシンを、ホストと同じLANに直接接続する方法を紹介しよう。

 まず左ペインから「ネットワーキング」をクリックする。するとホスト上に存在するインターフェイスの一覧が表示されるので、先ほど固定IPアドレスを設定したホストのNICの名前を覚えておこう。

この例では192.168.1.20の固定IPアドレスを振ってある、enp1s0が対象となる

 「ブリッジの追加」をクリックする。ダイアログが開いたら、ブリッジ名を入力し、ポートとして先ほど控えたNICを選択したら、「追加」をクリックしよう。

ブリッジ名はデフォルトのbridge0のままでも構わない

 するとインターフェイス一覧からNICが消え、代わりに今作成したブリッジが表示されるようになる。

enp1s0が見えなくなり、bridge0が追加された図。なお作成したブリッジは、元のNICの固定IPアドレスを引き継ぐため、SSH接続などができなくなることはない

 続いて今度は、仮想マシンの設定画面に移ろう。「ネットワークインターフェイス」の欄を見ると、仮想マシンのNICは、先ほど調べた「default」という仮想ネットワークに接続していることが分かるはずだ。ここの「編集」をクリックする。

仮想マシンのネットワークを編集する

 仮想ネットワークインターフェイスの設定ダイアログが開く。ここで「インターフェース形式」を「Virtual network」から「Bridge to LAN」に変更しよう。「ソース」は先ほど追加したブリッジ(ここではbridge0)にする。

これで仮想マシンは、ホストと同じLANに直接接続される。DHCPが有効であれば、ホストと同じレンジのIPアドレスが降ってくるはずだ

 なお仮想マシンのNICを編集した際、ゲストOS側でNICのデバイス名が変わってしまうことがある。その場合はゲストOS側のネットワークの設定も、適宜変更してほしい。

Cockpitでコンテナを管理する

 最近であれば、仮想マシンではなくDockerを使いたい人も多いだろう。そしてもちろん、Cockpitにはコンテナ管理用のプラグインも用意されている。ただしCockpitはRed Hatがスポンサードしている都合もあり、公式にはDockerに対応していない。代わりに対応しているコンテナ実行環境はPodmanだ。とはいえPodmanは、Dockerと大きく使用感が変わるわけではないため、それほど問題にはならないだろう。

 CockpitでPodmanを管理するには、「cockpit-podman」パッケージをインストールする。

cockpit-podmanパッケージのインストール。Podman本体も同時にインストールされる
$ sudo apt install -y cockpit-podman

 すると左ペインに「Podman containers」という項目が増え、ここからコンテナの起動や管理が行なえるようになる。

Cockpit上からUbuntuのコンテナを実行してみた例

 だいぶ長い記事になってしまったので、Podmanについての詳しい説明は省略させてもらうが、仮想マシンとコンテナの両方を、まとめていい感じに管理できそうな雰囲気は感じてもらえるのではないだろうか。

 そんなわけで最新のUbuntu 24.04 LTS上でCockpitを使い、仮想マシンとコンテナの運用を試してみたわけだが、筆者の手ごたえとしては「これかなりいいな」であった。冒頭で述べたように、筆者はProxmox VEを長年使っていた。24.04 LTSで家庭内のサーバーをリプレースしたら、余った機材で新しいProxmox VE環境を構築しようと考えていたのだが、現在では予定を変更して、Cockpitを導入しようかなと考えている。まさに「気、変わった。今、変わった」という感じである。