今回の記事は前回の記事の続きになります。前回はFedora 36 ServerでMicroShiftを動かしてみました。 今回はFedora 36 IoT EditionでMicroShiftを動かしてみます。
Fedora IoT EditionはラズパイのようなARMボード、IoT機器向けにビルドされたFedoraです。 一般的な構成のLinuxよりもIoT機器に特化したLinuxを動かすほうがラズパイには良いと思うので、 今回試してみることにしました。
デバイスの確認
まずはデバイスの確認。microSDブートでFedora Serverを起動して、SDカードリーダーを取り付けています。 図は前回の使いまわしです。
手元の環境ではsdaが該当のデバイスみたいです。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 29.7G 0 disk ├─sda1 8:1 1 501M 0 part ├─sda2 8:2 1 1G 0 part └─sda3 8:3 1 28.2G 0 part mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 600M 0 part /boot/efi ├─mmcblk0p2 179:2 0 1G 0 part /boot ├─mmcblk0p3 179:3 0 5.4G 0 part │ └─fedora_fedora-root 253:0 0 28.1G 0 lvm / ├─mmcblk0p4 179:4 0 1K 0 part └─mmcblk0p5 179:5 0 22.7G 0 part └─fedora_fedora-root 253:0 0 28.1G 0 lvm / zram0 252:0 0 7.6G 0 disk [SWAP]
次はsfdiskを使ったパーティションクリアの例です。デバイスを間違えないように気をつけます。事前にフォーマット済みの場合はスキップします。
$ sudo sfdisk --delete /dev/sda パーティション情報が変更されました。 ioctl() を呼び出してパーティション情報を再読み込みします。 ディスクを同期しています。
イメージの書き込み
コマンドを実行して、Fedora IoTイメージを書き込みます。指定する公開鍵はキーペアを作るか、既存のキーペアの公開鍵を指定してイメージ作成を実行します。 このツールにより、パーティションの拡大までの処理は全部自動で行ってくれます。
$ cd ~/fedoraiot36 $ sudo arm-image-installer \ --target=rpi4 \ --image=Fedora-IoT-36-20220618.0.aarch64.raw.xz \ --resizefs \ --addkey=id_rsa.pub \ --media=/dev/sda ===================================================== = Selected Image: = Fedora-IoT-36-20220618.0.aarch64.raw.xz = Selected Media : /dev/sda = U-Boot Target : rpi4 = Root partition will be resized = SSH Public Key id_rsa.pub will be added. ===================================================== ***************************************************** ***************************************************** ******** WARNING! ALL DATA WILL BE DESTROYED ******** ***************************************************** ***************************************************** Type 'YES' to proceed, anything else to exit now = Proceed? YES = Writing: ... = Installation Complete! Insert into the rpi4 and boot.
ログイン
イメージ書き込みが終わったら、Raspberry Pi 4の電源を切って、microSDを入れ替えて起動します。 ログインはrootユーザーで行います。IPアドレスはDHCPサーバーから供給されるはずです。
% ssh -i ~/.ssh/id_rsa root@192.168.0.55 ... Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.0.55' (ED25519) to the list of known hosts. Script '01_update_platforms_check.sh' FAILURE (exit code '1'). Continuing... Boot Status is GREEN - Health Check SUCCESS
OSのアップデート
最初にOSのアップデートを行います。yumやdnfではなくてrpm-ostreeを使います。 アップグレードが終わると、このコマンドを実行して再起動せよと表示されます。
# rpm-ostree upgrade Staging deployment... done ... Run "systemctl reboot" to start a reboot
再起動することでrpm-ostreeがシステムの変更をコミットするようです（問題があれば復元もできるようです）。 再起動後、新しいソフトウェアの編成でシステムを利用できます。
ホスト名の設定（共通）
起動したら、ログインして以下のようにコマンドを実行してホスト名を設定します。 nmcliコマンドは用意されているようです。
# nmcli general hostname microshift.tooyama.org # hostname -A microshift.tooyama.org
CRI-Oのインストール
CRI-Oのインストールについてもrpm-ostreeコマンドを使います。 CRI-O（と、後で使うのでwget）をインストールします。 その他必要なパッケージがあれば追加しておきますが、ここで重要なポイントは必要ないパッケージは極力いれないという所です。
なお、リポジトリーにmicroshiftパッケージもあるようなのですが、今回はそちらは使いません。 インストール後は再起動が必要です。
# rpm-ostree install cri-o wget ... Changes queued for next boot. Run "systemctl reboot" to start a reboot # systemctl reboot
CRI-Oインストールのポイント
rpm-ostree installを実行した場合は、その時点で最新のパッケージをリポジトリーからダウンロードしてインストールします。
バージョンを指定したい場合は、次のようにパッケージモジュールを追加してインストールすれば良いようです。
目的のバージョンがない場合もありますので、その点は注意です。
[08/23/2022 追記] 手順が抜けていましたので追記しました（前半のcurl部分が追記箇所）。
# curl -L -o /etc/yum.repos.d/fedora-modular.repo https://src.fedoraproject.org/rpms/fedora-repos/raw/rawhide/f/fedora-modular.repo # curl -L -o /etc/yum.repos.d/fedora-updates-modular.repo https://src.fedoraproject.org/rpms/fedora-repos/raw/rawhide/f/fedora-updates-modular.repo # curl -L -o /etc/yum.repos.d/group_redhat-et-microshift-fedora-36.repo https://copr.fedorainfracloud.org/coprs/g/redhat-et/microshift/repo/fedora-36/group_redhat-et-microshift-fedora-36.repo # rpm-ostree ex module enable cri-o:1.23 # rpm-ostree install cri-o cri-tools
CRI-Oの起動
起動後、CRI-Oサービスを起動します。
# systemctl enable --now crio
Created symlink /etc/systemd/system/cri-o.service → /usr/lib/systemd/system/crio.service.
Created symlink /etc/systemd/system/multi-user.target.wants/crio.service → /usr/lib/systemd/system/crio.service.
# systemctl status crio|grep Active
Active: active (running) since Tue 2022-08-09 06:29:11 UTC; 1min 15s ago
このあとの流れは、Fedora 36 ServerでMicroShiftをデプロイする方法と同様です。
- firewall-cmdで必要なポート開放
- MicroShiftバイナリーをダウンロード
- MicroShiftバイナリーに実行権限をつける
- MicroShiftを実行
ちょっと強引なのですが、CRI-O 1.24でOpenShift 4.8 (K8s 1.21ベース)を動かせたようです。
# cat /etc/os-release |grep VERSION= VERSION="36.20220807.0 (IoT Edition)" REDHAT_BUGZILLA_PRODUCT_VERSION=36 REDHAT_SUPPORT_PRODUCT_VERSION=36 OSTREE_VERSION='36.20220807.0' # oc get no -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME microshift.tooyama.org Ready <none> 48m v1.21.0 192.168.0.55 <none> Fedora Linux 36.20220807.0 (IoT Edition) 5.18.16-200.fc36.aarch64 cri-o://1.24.1 # oc get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system kube-flannel-ds-ng2z8 1/1 Running 0 4m15s kubevirt-hostpath-provisioner kubevirt-hostpath-provisioner-jf5b6 1/1 Running 0 4m5s openshift-dns dns-default-d7phk 2/2 Running 0 4m16s openshift-dns node-resolver-jpwbj 1/1 Running 0 4m16s openshift-ingress router-default-85bcfdd948-wxw2q 1/1 Running 0 4m19s openshift-service-ca service-ca-7764c85869-zml2d 1/1 Running 0 7s
パッケージインストール時もまれにありましたが、service-caというPodがCrashLoopBackOffになってしまう場合は、タイミングが問題だった場合はそのPodを削除することで再作成されてRunningになります。何度も同じ現象が発生する場合は、その原因を探る必要がありますが。。
# oc get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system kube-flannel-ds-ng2z8 1/1 Running 0 3m46s kubevirt-hostpath-provisioner kubevirt-hostpath-provisioner-jf5b6 1/1 Running 0 3m36s openshift-dns dns-default-d7phk 2/2 Running 0 3m47s openshift-dns node-resolver-jpwbj 1/1 Running 0 3m47s openshift-ingress router-default-85bcfdd948-wxw2q 1/1 Running 0 3m50s openshift-service-ca service-ca-7764c85869-xfz2h 0/1 CrashLoopBackOff 2 3m51s # oc delete po service-ca-7764c85869-xfz2h -n openshift-service-ca pod "service-ca-7764c85869-xfz2h" deleted # oc get po -n openshift-service-ca NAME READY STATUS RESTARTS AGE service-ca-7764c85869-zml2d 1/1 Running 0 2m56s
適当にPodとサービスを作って、動作確認をしてみます。
# oc create deployment hello-pods --image=docker.io/nginx:stable-alpine deployment.apps/hello-pods created # oc expose deployment hello-pods --type=NodePort --port=80 service/hello-pods exposed # oc get svc hello-pods NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-pods NodePort 10.43.48.65 <none> 80:31943/TCP 24s # curl http://localhost:31943 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> ... # oc delete svc hello-pods && oc delete deployment hello-pods service "hello-pods" deleted deployment.apps "hello-pods" deleted
サービスとしてMicroShiftを実行
OpenShift + Raspberry PiとMicroShift – Part 11: Raspberry Pi 4 with Fedora 35 Serverの内容を参考にすると、バイナリーを実行するのではなくMicroShiftサービスとして実行できそうです。
ポイントはmicroshiftパッケージをインストールするがそのパッケージに含まれるバイナリーは使わず、ダウンロードしたバイナリーを実行するようにサービスファイルを修正する点です。
最後に試してみたいと思います。基本的な流れはこれまでと一緒なので、コマンドのみ列挙していきます。
nmcli general hostname microshiftshift.tooyama.org rpm-ostree upgrade systemctl reboot curl -L -o /etc/yum.repos.d/fedora-modular.repo https://src.fedoraproject.org/rpms/fedora-repos/raw/rawhide/f/fedora-modular.repo curl -L -o /etc/yum.repos.d/fedora-updates-modular.repo https://src.fedoraproject.org/rpms/fedora-repos/raw/rawhide/f/fedora-updates-modular.repo curl -L -o /etc/yum.repos.d/group_redhat-et-microshift-fedora-36.repo https://copr.fedorainfracloud.org/coprs/g/redhat-et/microshift/repo/fedora-36/group_redhat-et-microshift-fedora-36.repo rpm-ostree ex module enable cri-o:1.23 rpm-ostree install cri-o cri-tools microshift systemctl reboot curl -L https://github.com/openshift/microshift/releases/download/4.8.0-0.microshift-2022-04-20-182108/microshift-linux-arm64 > /usr/local/bin/microshift chmod +x /usr/local/bin/microshift cp /usr/lib/systemd/system/microshift.service /etc/systemd/system/microshift.service sed -i "s|/usr/bin|/usr/local/bin|" /etc/systemd/system/microshift.service systemctl daemon-reload systemctl enable crio --now systemctl enable microshift --now
ちなみに、ここで使われるmicroshift.serviceの中身は、次のような内容が書かれていました。
[Unit] Description=MicroShift Wants=network-online.target crio.service After=network-online.target crio.service [Service] WorkingDirectory=/usr/local/bin/ ExecStart=microshift run Restart=always User=root [Install] WantedBy=multi-user.target
しばらく(注1)待っていると、この方法でもMicroShiftが動作することがわかりました。
# oc get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system kube-flannel-ds-bg2p7 1/1 Running 0 16m kubevirt-hostpath-provisioner kubevirt-hostpath-provisioner-nqlzh 1/1 Running 0 11m openshift-dns dns-default-c9k6g 2/2 Running 0 16m openshift-dns node-resolver-v7hv2 1/1 Running 0 16m openshift-ingress router-default-85bcfdd948-f4fz7 1/1 Running 0 16m openshift-service-ca service-ca-7764c85869-4hds8 1/1 Running 0 16m # oc get no NAME STATUS ROLES AGE VERSION minishift.tooyama.org Ready <none> 16m v1.21.0 # oc create deployment hello-pods --image=docker.io/nginx:stable-alpine deployment.apps/hello-pods created # oc expose deployment hello-pods --type=NodePort --port=80 service/hello-pods exposed # oc get svc hello-pods NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-pods NodePort 10.43.220.204 <none> 80:32036/TCP 3m16s
というわけで、今回はFedora 36 IoT Editionを使ってMicroShiftを動かしてみました。
Raspberry Pi 4Bで普通のFedora Serverを使うのと比べて、IoT Editionのほうが安定かつ低メモリーで動作するのを確認しました。 ディスクアクセスランプもあまり頻繁に点灯しないところから見るに、結構デリケートなmicroSDにも優しそうな気がしました。 MicroShiftも特に問題なく動作しましたし。
ラズパイ向けのOSとして「Fedora 36 IoT Edition」は、「Raspberry Pi OS」や「Debian」、「Ubuntu（Not Ubuntu Core）」に次ぐ利用OSの候補として良いのかもしれません。未だちょっと触ったくらいなので、もうちょっと調査は必要ではありますが。
(注1) 結構な時間待っていた間、ps auxとかsystemctl status microshift、crictl podsやcrictl images、topなどのコマンドを使って状況を確認していました。
