手

Nov 13, 2023

サイモン・ビッソン、コラムニスト、InfoWorld |

Microsoft の CBL-Mariner Linux ディストリビューションは、クラウドとオンプレミスの両方で Azure にとってますます重要になっています。 Windows 11 で WSL 2 の GUI 機能をホストするだけでなく、Azure Kubernetes Service のコンテナー ホストでもあり、Microsoft Container Registry のベース コンテナー イメージとして利用できるほか、Azure 上のディストリビューションのないコンテナーもサポートしています。 そのため、CBL-Mariner に時間をかけてその特徴と機能を学び、それがコードにどのような影響を与えるかを確認する価値があります。

バージョン 2.0 のリリースにより、CBL-Mariner での作業がはるかに簡単になりました。 初期のリリースではゼロから構築する必要があり、Linux 上で実行される Go ベースのツールチェーンが必要でした。 ISO をダウンロードして、選択した仮想サーバー ツールにインストールするだけで済みます。 Windows を使用していたので、インストールのホストに Hyper-V を使用しました。 ホストとして Azure を使用する場合は、独自の仮想マシンをセットアップすることも、Azure の VM ライブラリから事前に構成されたインストールを使用することもできます。 別のアプローチは、Docker を使用して、Microsoft 独自のコンテナ レジストリから基本イメージを直接ダウンロードして実行することです。

CBL-Mariner は、まさに最新の Linux であり、UEFI (Unified Extensible Firmware Interface) システムで動作するように設計されているため、Gen2 Hyper-V 仮想ディスクを使用してインストールを最大限に活用できます。 考えられる落とし穴が 1 つあります。Hyper-V UEFI 環境で正しい証明書が使用されていることを確認する必要があります。 そうしないと、ISO の起動に失敗します。 仮想マシンの Hyper-V 設定の [セキュリティ] セクションで、セキュア ブートにデフォルトの Windows 証明書ではなく Microsoft UEFI 認証局を使用していることを確認してください。

最初の起動時に、テキストベースまたはグラフィカルインストーラーの選択が表示されます。 グラフィカル オプションを使用すると、フル インストールまたはコア インストールを選択できます。 使用するスペースとどのようなサービスがインストールされるかを確認するために、フル インストールを選択しました。

インストールを選択したら、使用するディスクと暗号化するかどうかを選択します。 暗号化は、マルチテナント環境や、誰がシステム ディスクにアクセスできるかわからない環境で役立ちます。 次に、インストーラーは選択したドライブをフォーマットし、CBL-Mariner をインストールします。

グラフィカル インストーラーでは、フル インストールまたはコア インストールを選択できます。

私のテスト システムでは、完全インストールに 85 秒かかり、2.2GB のディスク容量を使用しました。 テキスト インストーラーを使用した CBL-Mariner コアのインストールにはさらに短い時間 (わずか 21 秒) がかかり、必要なスペースは 297 MB だけでした。

CBL-Mariner の完全インストールには 2 分もかかりませんでした。

インストール後、もう一度起動するとログイン プロンプトが表示されます。 Windows Server Core と同様、デスクトップはありません。 それは驚くべきことではありません。 CBL-Mariner は、クラウド サーバー上で実行され、Web UI を備えたクラウドネイティブ アプリケーションをホストするヘッドレス システムであることを目的としています。 ユーザー モード デスクトップはセキュリティ リスクを追加するだけであり、システムがより複雑になります。 Microsoft のような軽量のコンソールのみのディストリビューションで得られる大きな利点は、シンプルさです。 試してみたい場合は、CBL-Mariner パッケージ リポジトリに X11 リリースがあります。これはおそらく、WSL 2 のグラフィック サポートを提供する役割の一環としてのものです。

コンテナーを操作する場合は、このような小規模なインストールが重要です。 これは、基本イメージが迅速に読み込まれることを意味し、デフォルトの Moby-containerd パッケージを使用して、Kubernetes または Azure Container Instances などの軽量のオーケストレーション環境でアプリケーションをスケールするときに、コンテナーの迅速なデプロイを保証します。 そこでコア リリースが登場します。 十分に小さいため、Azure の内部ネットワーク経由で、またはローカル コンテナー レジストリから Azure Stack HCI システムに非常に高速にダウンロードされます。 小さなイメージを使用すると、このようなシステムでさらに高い密度が可能になります。これは、リソースに制約のあるハードウェアをエッジで実行する場合に便利な機能です。

Microsoft は、私がダウンロードした ISO や独自のコンテナー イメージなどの事前構築済みイメージを推奨しています。 ソースを取得してカスタマイズして自分で構築することはできますが、Microsoft 独自のリリースの作成に使用される検証プロセスは通過していません。

話を簡単にするために、CBL-Mariner は他のテキストモード Linux と同じように見えます。 実行されているサービスはそれほど多くなく、主に基本的なファイル システム、ネットワーク、ログの処理です。 これは、このようなプラットフォームに期待されるものであり、攻撃対象領域を最小限に抑えるための最小限のサービス セットです。 インストールの管理方法を理解するために、基本的なドキュメントに時間を費やす価値があります。

CBL-Mariner に関する重要な哲学的ポイントは、これは一度インストールされ、その後継続的に更新される Linux ディストリビューションではありません。 Microsoft からセキュリティ更新プログラムを入手できますが、まったく新しいバージョンをインストールする場合にのみ変更されるインフラストラクチャの一部として扱う方がはるかに適切です。 ユーザーランドに存在する必要があるものはすべてコンテナとしてインストールする必要があります。 ベース OS は毎月更新され、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスに新しいリリースを追加するスケジュールが決まります。

独自のプロジェクトに合わせてカスタマイズできないというわけではありません。 Microsoft は、パッケージを追加したり独自のフォークを構築したりするためのドキュメントとツールを提供しています。 独自のバージョンを構築している場合は、安全でないバージョンの CBL-Mariner に取り残されないように、git rebase を使用して自分のコードと Microsoft のコードをセキュリティ更新プログラムやリリースと同期させて、Microsoft のコードのフォーク上に構築する必要があります。 。

これで、基本インストールにパッケージを追加できるようになりました。 Microsoft は、基本リリースの一部としてインストールされる TDNF パッケージ マネージャーを使用して、RedHat の RPM パッケージ形式をサポートしています。 これまで TDNF を使用したことがない場合は、TDNF を使い慣れた yum ツールの更新バージョンと考えてください。 CBL-Mariner の TDNF は、Microsoft 独自のリポジトリを使用するように構成されています。このリポジトリには、CBL-Mariner でテストされたパッケージのセキュリティ パッチが適用されたバージョンが含まれています。 Microsoft では、パッケージにパッチを適用するためのサービス レベル アグリーメントを締結しており、これは脆弱性の重大度レベルに基づいています。

厳選されたパッケージのディレクトリはオンラインで見つけることができます。 これは RedHat や Ubuntu に比べて比較的短いリストですが、Azure で実行されるコンテナー イメージに期待されるものです。 Microsoft 固有のパッケージには、.NET および ASP.NET Core (Kestrel Web サーバーとともに)、Microsoft の OpenJDK リリースおよび SQL Server ツール (ODBC コネクタを含む) が含まれます。 CBL-Mariner リポジトリには、Microsoft 独自のツールに加えて、Python 3、Kubernetes、node.js などの一般的な Linux ツールとプログラミング環境の長いリストが含まれています。 パッケージは基本コレクションと拡張コレクションに分割されているため、ほとんどのアプリケーションをホストでき、結果として得られるユーザーランドにより、Azure で使用するコンテナーを構築および管理できます。

Microsoft が Azure の一部として ARM ベースのサーバーを展開しているため、多くの CBL-Mariner パッケージの ARM ビルドを見るのは良いことです。 これらの新しいサーバー上で実行することを目的としたコンテナーを構築している場合は、使用するパッケージのサポートされている ARM バージョンを確認することが重要です。

コンテナーがクラウド ネイティブ開発の基盤であるため、Microsoft が、CoreOS の喪失に伴う問題を回避するためだけにでも、Azure 用の独自のホスト OS を必要としていたことは明らかです。 Kinvolk の買収により Flatcar が社内に導入されましたが、Kubernetes プラットフォームだけでなく、Azure のニーズをターゲットにした CBL-Mariner のような、厳密に焦点を絞った OS が依然として必要とされています。 CBL-Mariner を Kestrel および YARP と組み合わせて ARM 上で実行すると、より少ないエネルギーで、より多くのアプリケーションをより少ないサーバーで実行できるようになります。 これは、Microsoft 独自の Linux に慣れるのに十分な理由です。

次にこれを読んでください：

InfoWorld の Enterprise Microsoft ブログの著者である Simon Bisson は、学術および電気通信の研究に携わり、新興企業の CTO を務め、UK Online の技術面を運営し、コンサルティングとテクノロジー戦略を行ってきました。

著作権 © 2022 IDG コミュニケーションズ株式会社