Windows ServerにWSL・Podman環境を構築し、オフライン環境でLinuxコンテナを運用してみた

クラウドサービスが普及した現在では、システム基盤としてAWSやGCP、Azureなどを利用するケースが一般的になっています。

一方で、製造業や公共分野などでは、インターネットへ接続できないオンプレミス環境でシステムを構築・運用するケースも依然として存在します。

今回、「既存の Windows Server を利用したい」、「インターネット接続ができない」という制約の中で、Linuxコンテナを利用したシステムを構築する機会がありました。

そこで、Windows Server 2025上にWSL2とPodmanを導入し、TCPサーバーをコンテナとして常駐運用できる環境の構築を検証しました。

本記事では、構築手順を細かく説明するというよりも、実際に構築して分かったことや苦労した点をお話します。

検証環境

今回利用した環境は以下の通りです。

また、サーバーはインターネットへ接続できない環境を想定しています。

そのため、

• WSL
• Podman
• コンテナイメージ

はすべてオンライン環境で取得し、USBメモリ経由で持ち込む構成としました。

ゴール

Windows Serverを再起動しても、自動的にLinuxコンテナが起動し、TCPサーバーとして待ち受けを継続できる環境を構築すること

最終的には次のような構成になりました。

また、

• Windows起動時にタスクスケジューラでPodman Machineを自動起動
• コンテナはsystemd管理
• コンテナ障害時は自動再起動
• メンテナンス時は明示的にコンテナを停止可能

という、実運用を意識した構成を実現できました。

構築手順

構築の流れは次のようになります。

太字表記の工程は、インターネット接続環境であればコマンド１つで完了する手順ですが、オフラインの場合は工夫が必要です。

1. Windows ServerでWSL2を有効化
2. WSLを更新
3. Podman for Windowsをインストール
4. Podman Machineを構築
5. コンテナイメージをインストール
6. コンテナ起動
7. systemdサービス化
8. タスクスケジューラでWindows起動時にPodman Machineを起動

今回特に便利だと感じたのは、

podman machine init --image-path

がrootfsを指定して初期化できる点でした。

オンライン環境で取得しておいたrootfsを利用することで、インターネット接続がない環境でもPodman Machineを構築できます。

( オンライン環境で Podman Machine を作成して、machine イメージダンプをオフラインサーバに持ち込む... という手順を踏むと、沼に溺れます )

構築中にハマったこと

一番時間を使ったのは、ネットワーク周りでした。

Windows起動後、

• WSLは正常起動
• コンテナも正常起動
• portproxy設定も存在

しているにも関わらず、TCPサーバーに接続できない問題が発生しました。

netstat

を確認すると

• 127.0.0.1 は 常時 LISTEN
• NIC側IP は LISTENしていないことがたまにある

という現象が発生しました。

再現率が100%ではない問題は、わたしのエンジニア魂に火がつきます。

原因を切り分けるため、

• WSL
• Podman
• Windows ファイアウォール
• portproxy
• IP設定

を順番に確認しましたが問題は見つかりませんでした。

最終的に、portproxy を管理している IP Helperサービス を再起動することで、NIC側IPがLISTENしました。

Restart-Service iphlpsvc

現時点では、

Windows起動時のIP Helperサービス初期化タイミングが影響している可能性が高い

と考えています。

暫定対応として、

1. Windows起動後 WSL(podman machine) 起動
2. 約60秒待機
3. IP Helperサービスを再起動

というタスクをタスクスケジューラ登録することで安定して動作しました。

わかったこと

今回の検証で感じたことは3つあります。

Windows + WSLは考慮事項が多い

Linuxだけで完結する環境とは異なり、

• Windows
• Windows ファイアウォール
• WSL
• Podman
• systemd

という複数のレイヤーが存在します。

障害が発生した場合も、どのレイヤーの問題なのか切り分けが重要でした。

ネットワーク構成は理解が重要

TCP通信一つを取っても、

という経路になります。

Linux単体よりも、通信経路を把握しておく必要があると感じました。

オフライン環境は準備がすべて

クラウド環境では当たり前に取得できる

• インストーラー
• コンテナイメージ
• Linux rootfs

も、オフラインでは事前に準備しておかなければなりません。

「インターネットが使える前提」がいかに多いかを改めて実感しました。

今後やってみたいこと

今回の構築は一通り実現できましたが、まだ改善したい点があります。

• PowerShellとシェルスクリプトによる環境構築の自動化
• systemdサービス生成の簡略化
• Windows起動時の処理をさらに安定化
• portproxy周りの挙動を継続調査

まとめ

クラウドネイティブなツールが前提になりがちですが、今回は 「既存資産を活かす」、「インターネットに繋がらない」 という達成すべき要件が先にあり、その要件を満たす手段としてWSL2+Podmanを選びました。

今回の検証を通じて、Windows Server上でも、WSL2とPodmanを組み合わせることで、オフライン環境においてLinuxコンテナを実運用できる構成を構築できました。

一方で、Windows・WSL・Linuxの境界部分では、ネットワークや起動順序など、Linux単体では意識しない課題にも遭遇しました。

今後も自動化や運用改善を進めながら、オフライン環境でも再現性の高いコンテナ実行基盤を目指していきたいと思います。