Windows環境をいつでもリストアできるわがまま環境を作りたい
Metadata
Date: September 4th, 2022
Category: わたしの開発環境を充実させたい
定期的にPCを初期化（リストア）したくなる衝動に駆られるときはないですか？
私はあります！
仕事でもプライベートでも同じデスクトップPC（OSはWindows11）を使っています。
普通に生活しているだけでWindowsの設定を変えたり、いろんなツールをインストールしたりするので知らない間に環境がどんどん汚れていきます。
そのうちよくわからない原因でPCが重くなったりすることがあったり、なかったりするので定期的にPCを初期化したくなります。
とはいえ、仕事でも使ってたり、プライベートで使うためのゲームなどのデータもあったりで気軽にはリストアできません；；また、セットアップも時間がかかるので大変です。
なので、開発環境のセットアップなど毎回同じことをする部分は忘れがちなので手順をメモしておいたり、インストールスクリプトや設定ををdotfiles管理してできるだけ気軽にリストアできるような状態を保つように心がけています。
ある程度リストア後のセットアップ周りは私の中で落ち着いていたのですが、最近ノートPCが届いたことをきっかけにその熱が再燃しました。
今回は「Windows環境をいつでもリストアできるわがまま環境を作りたい」という願望をもとに全体的に大幅な見直しをしたので自分が今後参考にするためにもやったことなどを残しておこうと思います。
Windows環境をいつでもリストアできるわがまま環境とは
私の場合、リストアするときに次のことが大体ネックになるのでそこら辺を解決できればいいなと思います。
・PCゲームの再インストールがめんどくさい
→ グラボが積んであってPCゲームができるノートPCとデスクトップPCがあるので、ゲーム環境をポータブルにしたい
・Windows環境のセットアップ手順やインストールするアプリを忘れがち
→ できるだけスクリプト化して手順を自動化したい
・作業環境の構築が大変
→ Dockerfileにして1コマンドで構築できるようにしたい
わがまま環境その１：PCゲーム環境をポータブルにした
すでにこちらは記事にまとめました。SSDにデータを置くことで解決しました！
思った以上に簡単にできて感動しました。これでゲームに関しては影響しないので心置きなくリストアできます。
わがまま環境その２：Windows環境のセットアップをできるだけ楽に
今回は主にWindows11からの手順は整理しきれていなかったので整理したり、キーボード周りの設定をAutoHotkeyに寄せたり、一部をスクリプト化したりと細かい改善を行いました。
キーボード周りの設定をAutoHotkeyに寄せた
キーボードはBAROCCOのMD770という分割キーボードを使っています。
BAROCCOのMD770はキーボード本体にマクロ機能が搭載されており、本体に直接複雑な操作などを登録したりできます。
また、PowerToysやMicrosoft IMEなどにも設定をしていたりと色んなところにキーボード設定が散らばっていて管理が大変でした。
そのため、できるだけ依存先を減らすためにほとんどの設定はAutoHotkeyで実現することができたのでAutoHotkeyに寄せました。設定などは下記記事の最後あたりにまとめています。
ちょっとした設定だけはAutoHotkeyで実現できないのでそこは引き続きMicrosoft IMEで設定していきます。
Windows11からは開発に関わる色んなことが便利に！
Windows11では最初からWindows Terminalが備わっているので別途インストールする必要がなくなりました！セットアップの手順が一つ減るのでとてもありがたいです。
これはWindows11からではないですが、Windows10と11はデフォルトのパッケージ管理マネージャーとしてwingetが備わっています。Chocolateyと比較するとパッケージはまだ充実しているとはいいがたい気がしますが有名なアプリは充実しているのでほとんど困りません。winget本体はインストールする必要がないのでこれまたセットアップの手順が一つ減るのでとてもありがたいです。
一番の目玉はWSLのインストールがwsl --installで1コマンドになったという点です。WindowsのUIでWindowsでしか使えないアプリを使いつつ、開発用で本物のLinux環境が欲しいという開発者にとってWSLはとても便利なのでそのWSLがコマンド1発で導入できるようになったのはとてもうれしい話です。
参考：https://docs.microsoft.com/ja-jp/windows/wsl/installinstall-wsl-command
Windows11～WSL2のセットアップまでの手順
ここまでの内容を踏まえてWindows11～WSL2のセットアップまでの手順を整理しました。
下記のリポジトリのREADEMEにセットアップ手順をまとめています。
今後は、Windows11～WSL2のセットアップまでに関しては下記リポジトリをメンテするだけでよくなりました。
工夫した点として、一部をスクリプト化し、setup.ps1を実行するだけである程度セットアップできるようにしました。
スクリプト化したこと
Windows設定
ソフトウェアインストール
.wslconfigはホームディレクトリにコピーAutoHotkeyの設定ファイルをスタートアップディレクトリにショートカット作成
インストール後のWindows設定、各ソフトウェアの設定、WSL2のセットアップ周りはスクリプト化が難しかったためひとまず手順をまとめることにしました。タイミングを見てスクリプト化できそうなところはスクリプト化していきたいです。
わがまま環境その３：作業環境をDockerfileにまとめてWSL2上で快適な開発ライフを送る
今回の一番のメインであり、一番苦戦したのが作業環境をDockerfileにまとめることです。
そもそもDockerfileにまとめようと思ったきっかけがひのしばさんの記事です。先駆者がいたこと、作業環境をDockerfileにまとめるうえで検討した点が具体的でとても分かりやすかったこと、リポジトリを公開されていたことが決め手となり1か月ほどかけて構築しました。
こちらがDockerfileなどをまとめた私のリポジトリになります。
今までの作業環境
構築したリポジトリの説明の前に 今までの作業環境がどんな作業環境だったのかを紹介します。
ざっくり説明すると次のような感じでWSL2上に作業環境を構築していました。
・OSはWindows11
・作業環境は開発先に合わせて3つのWSLインスタンスを構築
WSLインスタンス1 ・・・ 自分が遊ぶ用の環境
WSLインスタンス2 ・・・ 自社開発のプロダクト開発用環境
WSLインスタンス3 ・・・ 開発支援先のプロダクト開発用環境
・WSLインスタンス毎に開発に必要なアプリ等をインストールしてセットアップ
作業環境のセットアップはdotfilesにまとめては共通化していました。
この構成の良いところは、ほかのWSLインスタンスに影響しないところです。用途に合わせてWSLインスタンスを構築しているので何かあって初期化したいときはそのWSLインスタンスを捨てて構築しなおせばよいだけです。
これで色々やって失敗してもそのWSLインスタンスを捨てて入れなおせばよいと思って喜んでいましたが、実際に運用してみてそのメリットを享受できる場面はほぼなかったです。
どちらかといえばWSLインスタンス毎にセットアップが必要なのでdotfilesで共通化していても結構手間がかかるというデメリットのほうが上回っていました。
また、Windows全体をリストアしたいとなるとWSLインスタンスのセットアップに時間がかかるため、Windows全体を気軽にリストアできないとう状況に陥ってました。
今回の作業環境
今までの作業環境から次の点が大きく変わりました。
WSLインスタンスが3つから1つになりました。
WSLインスタンス内に複数の開発先の環境が混在するようになりましたが、WSLインスタンス自体は1つでよくなるのでセットアップがかなり楽になりました
作業環境がコンテナになりました。
インストール手順や設定など永続的なものはDockerfileにまとめたので今後はDockerfileをメンテするだけでよくなりました。また、コンテナになったことでWSLインスタンス上の環境にいい意味で影響を与えないようになりました。
作業環境をDockerfileにまとめるうえでのポイント
コメントアウトを多めに
dotfilesのメンテしたときはなぜそれをやったのかを覚えているのですが、その後は基本触るタイミングがくるのがだいぶ日が経ってからだったりして忘れてしまって手を加えづらくなるのでコメント多めにして後からでもわかるようにしました。
Makefile
ひのしばさんの構築例をもとに私もdocker起動周りはMakefileにまとめました。
Makefileにまとめたことで
make target="workbench"すれば使えるようになりました。buildし直すときは
make stop target="workbench"してmake build target="workbench"してmake target="workbench"でコンテナにアタッチし直すだけです。複雑なことはすべてMakefileに書いて忘れることができるのですごく使っていて快適なところが良いです。
ユーザー周り
私の場合はシェルスクリプトではなくDockerfile内でユーザー作成して作成したユーザーに切り替えるようにしました。voltaのインストールなどはrootユーザーで行うとrootユーザーのホームディレクトリに必要なディレクトリが作成されてしまうので、作成したユーザーに切り替えたあとに行うなどしています。
また、作成したユーザーのUIDやGIDなどもホスト側と揃えているのでDockerコンテナ内でファイル作成してもホスト側でパーミッションを変更する必要がなくなったりといいことづくめでした。
docker outside of docker
ひのしばさんの構築例をもとに初めてdocker outside of dockerの構成にしました。
コンテナからホスト側のDockerを操作することができるので作業コンテナのCLIの状態を引き継ぎながら、ホスト側と同じようにDockerを操作することができるので作業コンテナに引きこもることがさらに快適になりました。
その他、開発時に気になる点について
Dockerについて
WindowsのDockerをWSL上でも併用して使える(WSLに入れなおさなくて良い)ので、Docker DesktopはWindows側にインストールします。
Docker Desktop for Windows は、Docker でコンテナー化するアプリのビルド、配布、実行のための開発環境を提供します。 WSL 2 ベースのエンジンを有効にすることで、同じコンピューター上の Docker Desktop で Linux と Windows の両方のコンテナーを実行できます。 参考： https://docs.microsoft.com/ja-jp/windows/wsl/tutorials/wsl-containers
Visual Studio Codeについて
WSLとVisual Studio Codeは親和性が高く、設定をすればWindows側のVisual Studio CodeからWSLインスタンス上のソースコードを普段と変わらずに編集できるのでWindows側にインストールします。
また、作業コンテナと共有したいソースコードはWSLインスタンス上の
~/work/配下にあるので普段通りVisual Studio CodeからWSLインスタンス上のソースコードを編集もできます。Visual Studio Code を Remote - WSL 拡張機能と併用することで、WSL をフルタイムの開発環境として VS Code から直接使用できます。 参考：https://docs.microsoft.com/ja-jp/windows/wsl/tutorials/wsl-vscode
SQLクライアントについて
SQLクライアントもWindows側にインストールします。WSLで構築したサーバーはWindows側で構築したときと同じように
localhostでアクセスできます。プロダクトコンテナはWSLインスタンス上に立つので、Windows側からWSLインスタンス上のDBにもlocalhost:3306などでアクセスすることができます。Linux ディストリビューションでネットワーク アプリ (たとえば、Node.js または SQL Server で実行されるアプリ) を構築する場合、(通常の場合と同様に) localhost を使用して (Microsoft Edge または Chrome インターネット ブラウザーなどの) Windows アプリからアクセスすることができます。 参考：https://docs.microsoft.com/ja-jp/windows/wsl/networkingaccessing-linux-networking-apps-from-windows-localhost
まとめ
具体的なコードなども説明できたらよかったのですが記事自体が長くなってしまうのと全体像の説明でだいぶ疲れてしまったので、細かいところはリポジトリを見に行っていただけれと思います！
実際に仕事で使うのはこれからなのでまだはまりポイントやつらいポイントが出てくるかもしれませんが、作業環境がDockerfileにまとまっているので手順や設定を忘れることができるメリットはとても大きいなと思いました。
buildは5分～10分くらいかかりますが頻繁に設定を変えることがなければ初回だけなのであまり気になりませんし、コンテナの起動自体はサクサクでちょっと変なものを間違って入れてしまったときなどはコンテナを削除して建て直せばいいので、今のところDockerfileに移行してよかったなという感想でした。