Azure上に自分だけのラボ環境が完成しました。製品の評価や検証をすぐにでも開始できる状態になったわけですが、その前に、製品の評価や機能の検証に欠かせない、周辺環境を準備して行こうと思います。それも、必要なときにVMのローカルにスタンドアロンですぐに用意できるポータビリティがポイントです。

　ポータビリティと言えば、VMよりも、コンテナー技術のほうがサイズが小さく、起動も早いため優れています。しかし、スタンドアロン環境にコンテナー実行環境を準備するのは手間ですし、リソース消費量も気になります。Windows Serverの場合は、Windowsコンテナーに限定されという制限もあります。そこで私が注目したのがWindowsに標準搭載されている新しい「Windows Subsystem for Linux（WSL）バージョン2」、通称「WSL 2」の活用です。

クローズドなメール送受信環境の要件

　電子メールの送受信環境は、稼働状況の把握や異常発生の検知など、サーバー運用管理に欠かせない環境です。弊社主力製品「BOM for Windows」や「Job Director」はメール通知機能を多用します。

　評価、検証のためには、インターネットとやり取り可能な本物のメールサービスを利用するわけにはいきません。完全に閉じた（クローズドな）メール送受信環境である必要があります。外部にメールをルーティングしてはいけませんし、外部から踏み台として悪用されるのも絶対にダメです。また、評価、検証のためには、必要なときにすぐに利用できる、できればスタンドアロン環境でも利用できるポータビリティが重要なポイントになります。

　すぐに導入でき、メール通知テストに利用できるものとしては、ダミーのSMTPサーバー「smtp4dev」がすぐに思いつきました（画面1）。しかし、smtp4devはSMTPでメールを無条件に受信するだけで、テスト要件によっては機能が不十分の場合があります。

smtp4dev
https://github.com/rnwood/smtp4dev

画面1　smtp4devは実行可能ファイルを実行するだけでスタートし、発信元や送信元がデタラメでももただ受信してくれる

　SMTPだけのテストであれば、以前はWindows Serverのサーバーの機能「SMTPサーバー」を設定してテストすることもできましたが、Windows Server 2022からは正常に機能しなくなりました（→旧ブログの記事≪外部サイト≫）。次期バージョン（Windows Server 2025）からはこのサーバーの機能そのものが削除される予定です。

WSL 2で実現する理由

　評価、検証で利用するメール送受信環境を、Windows Server上のソフトウェアで実現するとなると、パッと思いつくものがありません。評価、検証には大げさすぎる（高機能すぎる）製品であれば、いくつか思いつきますが、高価な有料製品ばかりです。例えば、ローカルにExchange Serverをインストールして、評価、検証用のメール送受信環境を作るなんて馬鹿げています（Exchange Serverの評価、検証なら別ですが）。

　私の目的のためには、無料で利用できるLinuxとオープンソースソフトウェア（OSS）の組み合わせがベストでしょう。数十年前に（UNIX上の）sendmailの運用環境をいくつも構築した経験（最初はUUCPによる転送でした）があるので、Linuxでの環境構築は苦ではありません。しかし、いまどきsendmailでなんてほとんど聞きません。インターネットを少し検索してみると、postfixとdovecotの組み合わせが良く利用されているようです。設定方法もたくさん見つかります。

　Linuxのコンテナー環境が利用できれば、簡単に構築できそうです。しかし、Windows ServerのコンテナーサポートはWindowsコンテナー専用のものです。以前は「Linux Containers on Windows（LCOW）」と呼ばれる機能で、Windowsのコンテナーホスト上でLinuxコンテナーを動かすことができましたが（実験的機能として）、数年前にその開発は終了しました（→旧ブログ記事《外部サイト》）。パブリッククラウド上のコンテナーサービスを利用するという手もありますが、クローズドな環境にはクラウド利用は適していません。

　メール送受信環境のためにLinuxのVMを作成しようとは思いません。コンテナーよりもポータビリティが劣りますし、VMを1つ余計に動かすリソースがもったいないからです。幸い、Windows Server 2022（ビルド20348.740以降）では、本物のLinuxカーネルのシェル環境をWindows上で動かすことができるWSL 2（WSLバージョン1ではないことに注意）を利用できます（注：Server Coreではうまくインストールできません→旧ブログの記事≪外部サイト≫）。

　WSL 2を利用すれば、少ないリソースで、スタンドアロン環境で動かすことができます。また、WSL 2にはエクスポート／インポート機能（wsl --export/--import）があるので、カスタマイズしたディストリビューション（.tar形式）を作成しておけば、必要なときに、スタンドアロンのローカル環境にすばやく導入できそうです。WSL 2を利用する方法は、コンテナーを利用するのと非常によく似ています。WSL 2は、LCOW亡き後のLinuxコンテナー環境と言えます。

クローズドなメール送受信環境の実装イメージ

　図1に今回構築しようとしているメール送受信環境の全体像を示します。


図1　WSL 2で実現する、ローカルのクローズドなメール送受信環境

　Windows Server 2022（デスクトップエクスペリエンス）のWSL 2環境に、postfixとdovecotをインストールして設定します。Linuxディストリビューションとしては、特に思い入れはないので、WSL 2既定のUbuntu（現在は20.04）を利用することにします。このUbuntuにローカルユーザーを作成すれば、メールボックスをいくつでも用意でき、Windows Server上のメールクライアント（Thunderbirdなど）やメール通知機能を持つアプリケーション（BOMなど）に対して、メール送受信環境を提供します。

　当面は、スタンドアロン環境の利用を目標としていますが、その後、ラボ環境（クリックで拡大表示）のHyper-Vホスト（Azure VM）に同じメール送受信環境を導入して、内部ネットワークに接続されたHyper-V VMに対してメール送受信環境を提供する予定です。その実現方式については、「メモ.　WSL2へのポートプロキシ設定に“ ”で苦労した話」で画面を少しお見せしました。

　次回は、先に完成した環境を見ていただこうと思います（画面2）。カスタマイズ済みのディストリビューションができてしまえば、簡単かつ素早く導入できることを示したいと思います。


画面2　Windows Server上でメール送受信環境が動いている様子（次回のデモより）