openSUSE Microは次世代のコンテナOSになるかもしれない - TechRepublic

カラフルな背景のオープンソースカード — 画像: gustavofrazao/Adobe Stock

openSUSE Microは、コンテナ化されたワークロードのホスティングと、自動化された管理およびパッチ適用に特化した新しいLinuxディストリビューションです。このオープンソースの専用オペレーティングシステムは、トランザクションアップデートのメリットを享受できるワークロード向けに特別に設計された環境を実現します。このローリングリリース方式のディストリビューションは、まさにあなたの企業に必要なソリューションとなるかもしれません。

openSUSE Microは、予測可能性、拡張性、信頼性、柔軟性を兼ね備えることを目指しています。コンテナ化されたデプロイメントのこの新しいアプローチでは、標準のopenSUSE RPMを使用しているため、新しいパッケージ形式を習得する必要はなく、サイズ制限もなく、簡単に繰り返し展開できます。

openSUSE Micro をインストールして、どんなものか確かめてみました。感想は賛否両論でしたが、このプラットフォームが比較的新しいことを考えると、それも当然と言えるでしょう。それでは早速見ていきましょう。

参照: 知っておくべきオープンソースと Linux の用語 40 選 (TechRepublic Premium)

システムロール

通常のopenSUSEとの違いとして最初に気づくのは、システムロールです。インストール時に、OSがどのような役割を担うかを選択できます。しかし、一見すると、これらの役割は少し分かりにくいかもしれません。

MicroOS：単一用途のシステム向けに設計され、大規模な導入向けに最適化されています。デフォルトではサービスは提供されません。デスクトップ環境なしでOSがインストールされます。
MicroOS Container Host：コンテナ向けに最適化されており、Podmanをインストールします。これもデスクトップ環境なしでインストールされますが、コンテナのデプロイに必要なものはすべてインストールされます。
MicroOS Desktop (GNOME) : MicroOS Container Host と同じですが、デスクトップ環境、自動アップデート、ロールバック機能のみを備えています。このシステムロールはベータ版です。
MicroOS Desktop (KDE) : MicroOS Container Host と同じですが、デスクトップ環境、自動アップデート、ロールバック機能を備えています。このシステムロールはアルファ版です。
MicroOS with Remote Attestation (Agent) : MicroOS と同じですが、リモート認証エージェントが搭載されています。リモート認証とは、ホストがリモートサーバーに対してハードウェアとソフトウェアの構成を認証する方法です。これにより、エージェント部分がインストールされます。
MicroOS with Remote Attestation (Verifier) : MicroOS と同じですが、リモート認証検証機能が搭載されています。リモート認証とは、ホストがリモートサーバーに対してハードウェアとソフトウェアの構成を認証する方法です。これにより、検証機能部分がインストールされます。

MicroOS Desktop (GNOME) システムロールをインストールすることにしました。主に動作確認のためでした。インストールは完璧ではなく、最初の試行でいくつかのパッケージのインストールに失敗し、何度も「再試行」を繰り返す必要がありました。

最終的には、バニラのGNOMEデスクトップ環境を搭載した、完全に動作するインストールができました。openSUSE MicroをVirtualBox VMとしてインストールしたため、Guest Additionsを正常にインストールできず、別のグラフィックコントローラでVMを実行できませんでした。そのため、デスクトップの解像度がかなり低くなっていました。そのため、仮想ルートでインストールする場合は、デスクトップ環境なしでインストールするのが最善策です。

すぐに発見したもう一つの問題は、ファイルシステムが読み取り専用でマウントされているため、ソフトウェアをインストールできないことです。しかし、幸いなことに、Podmanコンテナランタイムライブラリの使用は期待通りに動作します。

説明させてください。読み取り専用ファイルシステムは、セキュリティ上の理由から意図的に採用されています。openSUSE Microは標準的なオペレーティングシステムとしてではなく、コンテナ化された環境などで使用されることを想定していることにご留意ください。そのため、ファイルシステムを読み書きモードでマウントする必要はありません。実際、ファイルシステムは読み取り専用以外の方法でマウントされるべきではありません。そのため、openSUSE Microはコンテナのプラットフォームとして安心して使用できます。

でも、落とし穴があります。コンテナはGUIで管理したいのですが、いつも使っているコンテナ管理ソフトのPortainerはまだPodmanをサポートしておらず、システムが読み取り専用モードで起動するため、Cockpitをインストールできませんでした。しかし、これを回避する方法があります。

openSUSE Micro を起動したら、次のコマンドで fstab を編集します。

vi /etc/fstab

roで終わる行を探して、に変更してくださいrw。変更したら、ファイルを保存し、マシンを再起動して、次のコマンドでPodmanサポート付きのCockpitをインストールします。

sudo zypper install cockpit cockpit-podman

うまくいくはずだった。しかし、OSのインストール時と同じように、cockpit-bridgeパッケージがインストールに失敗し、原因も示されなかった。どうやってインストールを試みても、全くダメだった。

Podmanはコマンドラインから操作できるので、問題ありません。それに、スケーラブルなコンテナデプロイメント向けのプラットフォームには、余分なものをインストールしたくないですよね。これは可能な限り最小限に抑えるべきです。私の唯一の目的は、openSUSE Microで何ができるかを確認することでした。そのため、GUIに頼るのではなく、簡単なデプロイメントを試してみることにしました。正直に言うと、PodmanはDockerほどユーザーフレンドリーではありません。例えば、Dockerを使えばWordPressサイトを簡単にデプロイできますが、Podmanではそうではありません。

それでも、私は次のコマンドを使って、Podman でシンプルな NGINX デプロイメントを実行することを選択しました。

podman pull docker.io/nginx

podman run -d --name docker-nginx -p 8080:80 docker.io/nginx

デプロイは問題なく完了しましたが、非常に基本的なものです。さらに一歩進んで、以下のコマンドを使ってPodmanでJoomlaをデプロイしました。

podman pod create --name mypod --publish 8080:80

podman run -dit --pod mypod -e MYSQL_DATABASE=joomla -e MYSQL_USER=joomlauser -e MYSQL_PASSWORD=joomlapassword -e MYSQL_ROOT_PASSWORD=rootpw --name mariadb docker.io/library/mariadb

podman run -dit --pod mypod -e JOOMLA_DB_HOST=127.0.0.1 -e JOOMLA_DB_USER=joomlauser -e JOOMLA_DB_PASSWORD=joomlapassword -e JOOMLA_DB_NAME=joomla --name joomla docker.io/library/joomla

JoomlaはGUIインストールに対応しており、非常にスムーズに動作しました。Joomlaの導入のレスポンスの良さには驚きました。これは、デスクトップをインストールした状態でもopenSUSE Microがいかに高性能であるかを物語っています。