Jack Wallenは、最新のコンテナ固有のOSであるopenSUSE Microのタイヤを蹴り、彼の考え（良い点と悪い点）をあなたと共有します。
openSUSE Microは、自動化された管理とパッチ適用により、コンテナ化されたワークロードをホストすることを目的とした新しいLinuxディストリビューションです。このオープンソースの専用オペレーティングシステムを使用すると、トランザクションの更新の恩恵を受けるワークロード用に特別に設計された環境を利用できます。このローリングリリースの配布は、あなたの会社が必要としているものかもしれません。
openSUSE Microは、予測可能で、スケーラブルで、信頼性が高く、柔軟性があることを目指しています。コンテナ化された展開に関するこの新しい考え方により、新しいパッケージ形式を学ぶ必要がなくなり（標準のopenSUSE RPMを使用するため）、サイズの制限がなく、簡単に繰り返し展開できます。
openSUSE Microをインストールして、何が何であるかを確認しました。私の印象は混合バッグでしたが、このプラットフォームがかなり新しいことを考えると、それは予想されることです。飛び込みましょう。
システムの役割
通常のopenSUSEからの最初の逸脱の1つは、システムロールの逸脱です。インストール中に、OSが果たす役割を選択できます。ただし、一見すると、これらの役割は少し混乱します。
- MicroOS ：単一目的システム用に設計され、大規模な展開用に最適化されています。デフォルトではサービスを提供しません。これにより、デスクトップ環境なしでOSがインストールされます。
- MicroOSコンテナホスト ：コンテナ用に最適化され、Podmanをインストールします。これもデスクトップ環境なしでインストールされますが、コンテナのデプロイに必要なすべてのものがインストールされます。
- MicroOSデスクトップ（GNOME） ：MicroOS Container Hostと同じですが、デスクトップ環境、自動更新、およびロールバックがあります。このシステムの役割はベータ版です。
- MicroOSデスクトップ（KDE） ：MicroOS Container Hostと同じですが、デスクトップ環境、自動更新、およびロールバックがあります。このシステムの役割はアルファ版です。
- リモート認証付きMicroOS（エージェント） ：MicroOSと同じですが、リモート認証エージェントを使用します。リモートアテステーションは、ホストがリモートサーバーに対してハードウェアとソフトウェアの構成を認証する方法です。これにより、エージェント部分がインストールされます。
- リモート認証付きMicroOS（ベリファイア） ：MicroOSと同じですが、リモート認証ベリファイアを備えています。リモートアテステーションは、ホストがリモートサーバーに対してハードウェアとソフトウェアの構成を認証する方法です。これにより、ベリファイア部分がインストールされます。
私はMicroOSDesktop（GNOME）システムの役割をインストールすることを選択しました。主に、それがどのように機能したかを確認するためです。最初の試行でいくつかのパッケージをインストールできなかったため、再試行を押し続ける必要があったため、インストールは完璧ではありませんでした。
オープンソース：必読の記事
結局、私はバニラGNOMEデスクトップ環境で完全に機能するインストールを行うことになりました。 openSUSEMicroをVirtualBoxVMとしてインストールしたため、Guest Additionsを正常にインストールしたり、別のグラフィックスコントローラーでVMを実行したりできませんでした。つまり、デスクトップの解像度がかなり小さかったのです。このため、仮想ルートを計画している場合の最善の策は、デスクトップ環境なしでインストールすることです。
私が門外で発見したもう1つの問題は、ファイルシステムが読み取り専用としてマウントされているため、ソフトウェアをインストールすることはできないということです。ただし、Podmanコンテナランタイムライブラリを使用すると、期待どおりに機能するというのは朗報です。
説明させてください。読み取り専用ファイルシステムは、セキュリティ上の目的で意図的に作成されています。 openSUSE Microは、標準のオペレーティングシステムとして使用することを目的としたものではなく、コンテナ化された同様の展開を目的としていることを覚えておく必要があります。そのため、ファイルシステムを読み取り/書き込みモードでマウントする必要はありません。実際、ファイルシステムを読み取り専用以外の方法でマウントする必要はありません。ですから、すぐに、openSUSEMicroをコンテナのプラットフォームとして使用しても安全だと感じています。
しかし、落とし穴があります。 GUIを使用してコンテナを管理することを好みますが、私の頼りになるマネージャーであるPortainerはまだPodmanをサポートしていません。また、システムが読み取り専用モードで起動するため、Cockpitをインストールできませんでした。それを回避する方法があります。
openSUSE Microを起動したら、次のコマンドでfstabを編集します。
vi /etc/fstab
roで終わる行を探す必要があります それをrwに変更します 。それが完了したら、ファイルを保存し、マシンを再起動して、次のコマンドを使用してPodmanサポート付きのコックピットをインストールします。
sudo zypper install cockpit cockpit-podman
それはうまくいくはずだった。しかし、OSのインストール中に経験したのと同じように、コックピットブリッジパッケージは理由がわからずにインストールできませんでした。どのようにインストールしようとしても、それは失敗でした。
コマンドラインからPodmanを操作できるので、問題ありません。さらに、スケーラブルなコンテナのデプロイを目的としたプラットフォームに余分なものをインストールする必要はありません。これは可能な限り最小限に抑える必要があります。私の唯一の目的は、openSUSEMicroで何ができるかを確認することでした。そのため、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をデプロイしました：
p odman 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の展開の応答性に驚きました。これは、デスクトップがインストールされている場合でも、openSUSEMicroのパフォーマンスがいかに優れているかを証明するものです。
結局、openSUSE Microは、コンテナ化されたアプリケーション専用のOSを展開しようとしている人にとって優れたオプションだと思います。小さく、非常に高速で安全です。
openSUSE MicroのISOをダウンロードして、試してみてください。コンテナ展開のための頼りになるプラットフォームになる可能性があると感じています。