Corredor

ウェブ、プログラミングの勉強メモ。

WSL2 をもっと使っていくための構成を考える

WSL をもっと使い込んでいきたく、環境を考えたりする。

コレまでの自分の開発環境

コレまで自分が Windows で構築してきた開発環境はこんな感じ。

  • GitSDK (GitBash の上位互換・pacman が使える)
  • VSCode
  • Docker Desktop For Windows
    • Windows10 Home の時は Docker Toolbox を使っていた
  • Chocolatey

ターミナルは GitSDK に同梱される mintty を利用。元々そんなにタブを作らないし、pacman で Tmux を入れれば不便しない。もっというとコーディングを始めたら VSCode 上の統合ターミナルで GitSDK を開く方が快適なのでコチラで事足りる。

パッケージ関連は pacman か Chocolatey を使う。Chocolatey を操作する際は PowerShell で作業するようにしている。Windows 向けのパッケージが落とせるので助かるが、もう少し Linux 寄りになる GitSDK のターミナルから当該パッケージを使おうとすると、文字化けしたりすることがあり、ここらへんの連携に違和感はあった。

Chocolatey で入れられないようなモノは Windows に直接入れちゃうか、Docker コンテナを使っていた。そんなに複雑なことをしないように心がけているので、Docker Toolbox でもそこまで不便はしなかった。

Windows Terminal と Remote WSL で気持ちが変わってきた

WSL2 が登場し、システム的なことはともかく、使う際に何が変わったのかなーという感じだったのだが、Windows Terminal が結構便利で、さらに VSCode 拡張機能の Remote WSL を試したら WSL との連携が超簡単で、しまいにはエクスプローラに WSL のツリーが表示されファイル連携もより簡単になっていて、こりゃもう WSL 使うしかないなとなってきた次第。

neos21.hatenablog.com

neos21.hatenablog.com

↑ Remote WSL や Remote Containers を使ってみた様子。

というワケで、WSL を前提とした環境構築を考えてみる。

ホスト環境にインストールするモノ

Windows 側にインストールすべきモノを考えてみる

  • WSL2
    • まずは WSL 本体。Ubuntu 18.04 あたりを入れておく感じ
  • Windows Terminal
    • ようやく正式版が出たので使う
  • VSCode
    • Remote Development:Remote - WSLRemote - Containers を入れる
    • その他拡張機能は Remote WSL で連携してから入れると良いかも (後述)
  • Docker Desktop For Windows
    • Docker を使う場合は、Windows ホスト側に入れる
    • v2.2.2 以降で、WSL2 との統合ができるヤツを入れる
  • VcXsrv
    • WSL2 にデスクトップ環境をインストールした場合はコレで GUI を表示する
    • 今回はデスクトップ構築については触れない。以下を参考にされたし
    • neos21.hatenablog.com

コレをベースにする。あとは WSL2 内 = Ubuntu の環境構築なので、いかようにもできると思う。

なお、作業ディレクトリは WSL 側に配置すること。/mnt/c/ などの Windows 側に配置してそれを参照しようとすると、ファイルシステムが異なる都合上、動作が遅かったり、ホットリロードが効かなかったりする。WSL に引きこもるつもりで、WSL 内にファイルを置くようにしよう。

ホスト環境にインストールしなくて良いモノ

WSL を前提とした環境で開発を進めるとしたら、次の要素はホスト側にインストールしなくて済むと考えられる。

  • GitBash・GitSDK
    • mintty は全面不要。Git 操作も WSL 側で行うので apt でインストールすれば良い。ホスト側には究極 Git 不要w
    • GitSDK すらインストールしていなければ、WSL 側の dotfiles との二重管理みたいなことも発生しないので、環境構築がシンプルになる
  • Chocolatey
    • 開発関連のツールは Chocolatey でインストールする必要がなくなる。コレも WSL 内で apt を使うことになる
  • 言語ごとのランタイム
    • Node.js も Nodist も、Ruby も、Windows 環境にはインストールしなくて良い
    • WSL 側で動かしている開発サーバを、Windows 側のブラウザで参照すれば良い

…ということで、Windows 環境はホントに「Ubuntu 環境を覗くガワ」として捉えて、スッカラカンで良いと思う。

Windows Terminal の設定

WSL2 へのアクセスは Windows Terminal を使う。カラースキームを調整したりしておくと良いだろう。以下の記事を参考に。

neos21.hatenablog.com

VSCode の設定

VSCode には Remote WSL 拡張機能を入れ、WSL 側と接続して使うことを前提とする。

ターミナルで WSL 内にいる時、code コマンドを実行すると、ホスト側の VSCode とちゃんと連携できるので、Linux マシンを使っているつもりで作業すれば良い。

大抵の拡張機能はホスト側にインストールしておけば動作するのだが、一部拡張機能は WSL 側にも再度インストールが必要なことがある。Windows 側では作業しないんだ!と決めるとしたら、WSL に接続している時に必要な全ての拡張機能をインストールしてあげることで二度手間がなくなるだろう。

WSL 上にアレコレインストールするのが嫌なら、Remote Containers 拡張機能もインストールして、WSL2 上の作業ディレクトリをベースに Remote Containers を立ち上げると良いだろう。

  • Windows VSCode → WSL2 (Remote WSL) → Docker (Remote Containers)

という入れ子構造になり、ポートの接続作業が必要になるかもしれない (未検証)。

WSL 内の環境構築

WSL 内に言語ランタイムをインストールしたりするのは、Ubuntu における環境構築と原則同じなので、特筆することはないかと。

大抵は apt でインストールできるし、Homebrew on Linux が WSL にも対応しているので、Homebrew を入れてしまうことで MacOS と同様の操作感で環境構築ができるだろう。

以前は Linuxbrew と呼ばれていたのでその文言が残るが、同じモノ。コチラについてはまた試してみて記事にする。

wsltty は使わなくなった

以下は過去情報。

wsltty は、GitBash や GitSDK でおなじみの mintty をベースに、WSL を開くためのターミナルエミュレータ。

Chocolatey でインストールでき、インストールしたディストリに対応したショートカットを生成したりしてくれて便利。

ターミナルは普段使う GitSDK と同じ感覚で使えるので違和感なし。カラーテーマは ~/.minttyrc を用意すれば調整可能。

mintty の仕組み上、どうしても動作がモッサリしているので、Windows Terminal に切り替えて止めた。

似たようなモノに wsl-terminal というモノもあるが、やはり Windows Terminal で事足りるというか。

以上

なんだかマジで WSL 前提の開発を考えていけそう。こねこねしていって、ハマりどころとかを調整するスクリプトが自分の中で出来上がれば上手く行きそうだ。

WSL構築と利用―Windows10で利用するLinux環境

WSL構築と利用―Windows10で利用するLinux環境