BFT名古屋 TECH BLOG

日々の業務で得た知識を所属するエンジニアたちがアウトプットしていきます。

【WSL2】WSL2がインフラエンジニアに向かない3つの理由

f:id:bftnagoya:20210225184622j:plain

はじめに

こんにちは!BFT名古屋支店・インフラ女子(?)のやまぐちです。
2021年に入ってWindows Subsystem for Linux 2(以後、WSL2)を触ることがあって記事を書きました。

bftnagoya.hateblo.jp

今回は折に触れて触ったり調べたり…その中で気づいた、WSLがサーバ構築には向かないということについて3つの理由を挙げます。とはいえ不便な点を理解した上で使う分にはとっても便利なのでガンガン使っていこう!と思っています。

WSL2がインフラエンジニアに向かない理由

理由1.systemdが使えない

まずは以下のコマンド実行結果をご覧ください。

root@DESKTOP-AC9R8UJ:~# systemctl status apache2
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

systemctlコマンドを実行したら、systemdはPID 1で起動されるはずなのにしてないよ?とエラーを吐かれました。どうやらWSLのinitはMicrosoft社がWSL用に開発した独自のものを利用しているらしくLinuxで現状標準となっているsystemdは実装されていないようです。

ちなみに実行環境は以下の通り、Ubuntu 20.04.01 LTSです。

root@DESKTOP-AC9R8UJ:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"

なお、サービスの自動起動を設定するのも手作りが必要です。

root@DESKTOP-AC9R8UJ:~# chkconfig --list
chkconfig: command not found

例としてsystemdを挙げたのですが、デーモンというデーモンが起動していません。cronもrsyslogも何もかもです。もちろん起動させる方法はあります。しかしそもそもデーモンを使うような用途でWSLが作られていない以上、無理に起動させて使わない方がベターだと思っています。通常利用するLinux OSとその他どんな違いがあるのかを把握できていないので、そこにかかる工数を考えると通常の利用の想定内で使うというのが一番いい、ということです。

理由2.「開発者向けツール」として提供されている

理由1が分かってからそもそもどういう想定でWSL(またはWSL2)が提供されているのかを確認しました。

よく寄せられる質問 (FAQ) | Microsoft Docsから抜粋します。

Windows Subsystem for Linux (WSL) とは何ですか。
Windows Subsystem for Linux (WSL) は、ネイティブ Linux コマンド ライン ツールを Windows で直接実行できる Windows 10 の新機能です。これは、従来の Windows デスクトップや最新のストア アプリと共存します。

コマンドラインツールと書いてあります。コマンドラインツールなんです。

WSL の対象ユーザーは誰ですか。
これは、主に開発者向けのツールです。特に Web 開発者と、オープン ソース プロジェクトで作業している開発者が対象です。 これにより、Bash、一般的な Linux ツール (sedawk など)、および多くの Linux ファースト ツール (RubyPython など) を使用する必要があるユーザーは、Windows でそれらのツールチェーンを使用できます。

サーバの設計構築をするようなエンジニア向けではなく開発者向けと明記してあります。

たとえば、Windows ではなく Linux 上で Ruby を使用するのはなぜですか。
一部のクロスプラットフォーム ツールは、それらが実行される環境が Linux のように動作することを前提として構築されました。 たとえば、一部のツールでは、非常に長いファイル パスにアクセスできることや、特定のファイルまたはフォルダーが存在することを前提としています。 これにより、Linux とは動作が異なる事が多い Windows で問題が発生することがよくあります。


現状WindowsでもRubyなどの言語がうまく動くようになっているけど問題が発生することもある。だから

MicrosoftCanonical と提携して、ネイティブ BashLinux コマンド ライン ツールを Windows で実行できるようにすることになりました。

ということだそうです。軽量な環境で開発し、CI/CD(継続的インテグレーション / 継続的デリバリー)を実現させるためのコマンドラインツール・それがWSL(WSL2)です。

理由1のデーモン不要というのもこれで納得がいきます。単なる開発環境であればcronもsyslogも不要です。(/var/log/syslogさえない…)

理由3.1ディストリビューションで1つしか使えない

同じUbuntuのバージョンをインストールしようとすると「インストールされています」と表示されます。別のバージョンなら可能です。しかしインストールするとおかしな現象が発生します。

  • 同じIPアドレスが振られる
    • 二つ同時に起動はできている
    • 片方のIPアドレスを変更するともう片方も連動して変わる
    • IPが同じなので例えば同じポートでサービスを起動できない

これをどうにか解決できないかと調べていたら以下のことが判明しました。

f:id:bftnagoya:20210225175009p:plain:w600
WSLと通信するためのネットワークアダプタ

結局これも「開発用途」だからIPアドレスなんて何でもよいということです。もちろんバックアップの機能はありますし、アップグレードなんかも可能です。が、同じディストリビューションは同時に起動して使わないとか、使うとしてもローカルからやWSL間の通信は発生させない・サーバ用途として使うにはポート番号を変えるなどひと工夫する必要がありそうです。

それでもたくさんあるインフラエンジニアがWSL2を使うメリット!

今までネガティブな話を書いてきました。しかしサーバの設計構築の用途として使おうとしなければとても使いやすいので、個人的にオススメの使い方を記載していきます。

  • LinuCなどの資格取得のための勉強に使う
    • 上述したようにデーモン起動していないとかLinuxの基礎の部分で動きが違う部分はありますが、それでも実際にコマンドが実行できる環境というのはかなり魅力的です。
  • Ansibleのローカル開発に使う
    • ローカルPC上でyml書いて(しかもVSCodeで)そのまま実行確認できる環境はありがたい!
    • ちょっとした誤差なら修正も楽
  • dockerを試す・使う
    • docker for WindowsではなくWSLでdockerを使う方が軽量でいいとの記事が多数

最後のdockerについては私も試していないので実際に触ってまた記事に書こうと思います。

終わりに

ちょっとしたことなんですけどね。実際の環境でLinuxのコマンドとかパスとか確認したいことってありませんか?インターネットで調べて出てくる情報はディストリビューションやバージョンが限定的だからちゃちゃっと調べちゃった方が楽、なんてことがよくあります。

AWSの管理コンソールに接続して、EC2起動して、SSHで接続して確認して…ってのがローカルで完結するならそれに越したことないですよね。そんなわけでこれからもWindows Subsystem for Linux 2を使っていろいろ試していきたいと思います!

参考:
WSLのアーキテクチャ - roy-n-roy メモ

systemd超入門 | DevelopersIO