KVM上にopenSUSE MicroOSをインストールする

ちょっと前にopenSUSEファミリーに加わったニューフェイス、openSUSE MicroOS

openSUSE Kubicのベースとして位置づけられている、とにかく小さくて堅牢なやつ。

 

ちょっと前に興味が出て試してみたので、

「KVM上にそれをインストールする方法」を主軸に、記事としてまとめてみました。

スポンサーリンク

openSUSE MicroOSの特徴

openSUSE MicroOS(以下MicroOSと表記)はなんといっても、Immutable OSとして設計されているのが特徴。

具体的にはこういう感じです。

 

  • パッケージ更新/追加を行う際には直接システム変更が行われるのでなく、「パッケージを追加した新しいsnapshot」が作成される
  • そのため、システム変更がすぐに適用されず、再起動することで適用される
  • もしシステム変更でトラブルが発生した場合、すぐに元のsnapshotに巻き戻せる

 

このシステム状態判別と巻き戻し処理は、起動時に自動で行われます。

(手動でももちろん可能)

 

なので、「アプデして問題が起きたら取りやめて、後日違うアプデを適用する」といったことが容易。

ダメだったら巻き戻す仕組みで、システムの安定性が担保されているわけですね。

 

類似したOSを挙げるとするなら、Fedora CoreOSになるでしょう。

 

コンテナホスト用途を主軸にしているところも、Immutable OSであるところも同じ……。

というより、「MicroOSが目指しているところがCoreOSの対抗馬」な気もしますが。

 

「SUSE系の使い心地なImmutable OS」を求めている人なら、MicroOSは一考の余地がある代物ではないでしょうか。

用意されている環境種別

公式ダウンロードページを見てもらえばわかるように、いろいろなプラットフォーム向けに種別違いが用意されています。

 

公式の表で書かれているBase SystemとContainer Hostの違いはこういった感じ。

種類 特徴
Base System 基本システムのみ
Container Host podmanなどコンテナを扱うパッケージがプリインストール済み

 

ISO Image版はBase Systemの枠に入っていますが、これはちょっと違う立ち位置。

単純に「LeapやTumbleweedにおける通常インストールディスク版」みたいなものなので、ISO版はインストール時にContainer Host版も選択可能です。

 

また、ISO版にはデスクトップ環境を構築するための試験的な選択肢も用意されています。

ISO版インストール時の選択画面

(このスクリーンショットで上から数えて3番目と4番目がその選択肢)

 

「一度環境構築したら、システム変更は行わずずっと使い続けたい」タイプのものぐささんなら、普段遣いとして便利に使えるかも?

KVM上にMicroOSをインストールする

さて、ここからが本題。

  • ISO Imageでのインストール
  • qcow2イメージのインポート

この二つの方法について、それぞれ軽く説明することにします。

ISO Imageを用いてインストール

いわゆる「インストールディスクからbootしてインストール作業をする」タイプの方法がこちら。

KVMの導入方法や基本的な使い方については省略させていただくとして、MicroOS特有の部分についてをば。

 

まず先程も示したスクショの通り、どういう形式でインストールするかを選べること。

ISO版インストール時の選択画面

 

次に重要なことは、インストール時にはrootユーザーしか設定されないこと。

インストール中にrootパスワード設定画面は出てきますが、Leap/Tumblewedインストール時に出てくるようなユーザー設定画面は出てきません。

 

もしもパスワード設定時に打ち間違えてたりするとどうしようもない状態になってしまうので、

rootパスワード設定画面では注意しておきましょう。(一敗)

 

その他に表示される設定画面はLeap/Tumbleweedとそう変わらないはずです。

virt-installコマンドでqcow2ディスクをインポート

KVMらしい方法がこちら。

 

公式が配布している「すでにMicroOSがインストールされたディスクイメージ」をインポートするやり方なので、

当然ながらインストール画面などはありません。

 

インポートする上でも様々な設定がありますが、

ここではカレントディレクトリにこういったファイルを用意してからインポートすることにします。

ファイル ここでの表記
公式からダウンロードしてきたqcow2イメージ opensuse-microos-src.qcow2
公式イメージから生成した新ディスクイメージ my-opensuse-microos.qcow2
ignitionコンフィグ config.ign

 

ignitionコンフィグを用意することは実質的に必須項目であることには注意してください。

iso版以外ではrootにデフォルトパスワードが設定されてないので、何かしらのログイン手段を確保しなければどうしようもない置物になってしまうのです……。

 

ディスクイメージを生成についてはおまけです。

個人的にこっちのほうが管理しやすいというだけなので、他の形になるよう変更しても構いません。

 

ともあれ、ここでは以下コマンドで新しいディスクイメージを生成。

sudo qemu-img create -f qcow2 -b opensuse-microos-src.qcow2 my-opensuse-microos.qcow2

 

次にconfig.ignを作成し、以下のような内容を記述。

{
  "ignition": {
    "version": "3.2.0"
  },
  "passwd": {
    "users": [
      {
        "name": "root",
        "passwordHash": "$6$s7pqJ748jRSdA./s$Wvrmz/jLhTphkPknm3CZyHaCUzRD1Vn.pTQXPTqnrZ37cFkDiuxCQqDJ5Ne2GPXZ1obQI5umw0kwNyc.oTC8G."
      }
    ]
  },
  "storage": {
    "files": [
      {
        "overwrite": true,
        "path": "/etc/hostname",
        "contents": {
          "source": "data:,tutorial%0A"
        },
        "mode": 420
      }
    ]
  }
}

このコンフィグはこういった処理を行うものです。

  • rootパスワードをopensuseに変更
  • hostnameをtutorialに変更

 

ignitionコンフィグにさらなるカスタマイズ(ssh key追加等)を行う場合は以下のページを参照するとよいでしょう。

openSUSE Wikiのignition項目ではfcctについて記載がありませんが、fcctで生成したコンフィグも問題なく使えます。

 

前準備が終われば、次はvirt-installコマンドを用いてのインストール。

sudo virt-install --name="microos" \
  --vcpus="2" --memory="2048" \
  --os-variant="opensusetumbleweed" \
  --network network=default --noautoconsole \
  --import --graphics spice,listen=127.0.0.1 \
  --disk path=${PWD}/my-opensuse-microos.qcow2 \
  --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=${PWD}/config.ign"

上コマンドはbashを用いて叩くことを推奨しておきます。

僕がfish環境でvirt-installコマンドを使用すると、正確なファイルパスを指定していてもなぜかインストール失敗してしまったので……。

 

後はKVMのGUIから仮想マシンを開いてみて、

ignitionコンフィグが正常に適用され、ログインに成功したCUI画面

上のスクリーンショットのようにhostnameがtutorialと表示されていて、

rootユーザーでログインできたならばインストール成功です。

 

下のスクリーンショットのように、

“health checker emergency mode”なる表記が出てしまうとインストール失敗。

health checker emergency modeとなり、インストール失敗してしまったCUI画面

このモードになった際に「boot成功した過去のsnapshot」が存在すれば、そのsnapshotにロールバックされるのでしょうが。

初回インストール時にこうなってしまえばロールバックできるわけもなく。

 

こうなってしまったらGUIからForce Offするなりvirsh destroyコマンドを叩くなりして強制終了させてから、

問題発生理由を取り除いて再度インストールし直すのが一番手っ取り早いと思います。

ISOイメージ経由でignitionコンフィグを読み込ませる

openSUSE Wikiのignition解説ページにもありますが、iso形式でignitionコンフィグを出力して読み込ませることもできます。

virt-installを使うなら前述した方法で良いので、GUI経由でインストールする際に便利な方法と言えるでしょう。

 

この方式でignitionを読み込ませる上で必要な条件は二つ。

<disk root directory>
└── ignition
    └── config.ign
  • 当該isoのVolume IDがignitionになっていて
  • 上記ディレクトリ構造を持っている

 

以上の条件を満たしたISOイメージを生成するやり方が、

mkdir -p disk/ignition
touch disk/ignition/config.ign

# "config.ign"に設定を記述してから、
# 下のコマンドでISOイメージを生成
mkisofs -o ignition.iso -V ignition disk

先程リンクを貼った解説ページでも説明されている、こういった方法であるわけですね。

 

こうして生成されたISOイメージをセットした上でVM初回起動を行えば、自動でconfig.ignが読み込まれるようです。(KVMで確認済み)

似たものとしてUSB flash drive経由でignitionを読み込ませる方法も用意されているそうですが、これは試すのがめんどくさかったので割愛。

ignitionではなくcombustionスクリプトを読み込ませる

他にも、combustionというスクリプトを読み込ませる方法があります。

combustionとは初耳だったのですが、どうやらMicroOS用に作成されたbootスクリプトらしい? です。

 

ignitionのように特別な記法は使わず、

#!/bin/bash

# combustion: network

# rootパスワードを"opensuse"に変更
echo 'root:$6$EnJAUnsAyg28yjuX$DAVGv.CLf9zp/USgGDHHU.hhJOJHRp1e8aejY6CpW8YYajkqQNBVol9I69rSpY5Uwr4wYdEpxayrI9SjiJwLO.' | chpasswd -e

こういったよくあるbashスクリプトとして書けるのが特徴。

 

これも前述したvirt-installコマンドを用いる際に、

-fw_cfg name=opt/org.opensuse.combustion/script,file=${PWD}/combustion-script

こういった引数を付け足せば同様に読み込まれます。

ここでは${PWD}/combustion-scriptを指定していますが、ファイルパスについてはもちろん変更可能。

 

このスクリプトを記述する上で注意すべきなのは、# combustion: networkというコメント行には特別な意味があること。

これは「このスクリプトにはネットワークが必要だ」と示す、いわゆるmagic commentだそうで。

2020/12/25現在でのcombustionのソースを見た所、「ネットワークが繋がるまでスクリプト実行を遅らせる」感じかな?

 

ちなみに、ソース内で使われてる正規表現から見て、

#combustion: network
#   combustion: network
  # combustion: network

上コードブロックのように書き方が少し違うと認識されない可能性高いです。ご注意あれ。

余談: 初めにダウンロードしたQemuイメージにバグがあった話

チラ裏内容ですが、こういうハマり例もあるということで一つ。

僕が始めにダウンロードしたMicroOS qcow2イメージだと、

これらの通りにしても、どうにもignitionを読み込んでくれませんでした。

 

なぜかと調べ回った最終的な結論としては、

どうやらそのビルドにたまたま初回boot時にignitionを読み込まない不具合があったようで……。

 

別の日にビルドされたバージョンを試したらすんなり上手く行ったのですが。

最初にダウンロードしたビルドが偶然ハズレだったのつらい。そりゃどうやっても上手くいかないわけですわ……。

 

Tumbleweedは不安定なビルドがちらほらあるからこそ、「ダメなビルドに当たったら即ロールバックする」のがMicroOSのウリなんですが。

「初回インストール時に選んだビルドがハズレ」だと残念賞。

 

こういうこともあるので、問題発生時には別ビルドを優先して試したほうがいいかもしれませんね。

どっとはらい。