2. すいーとみゅーじっくvol.9すいーとみゅーじっくvol.9
WindowsデスクトップでWeb開発改訂版WindowsデスクトップでWeb開発改訂版
著: setoazusa
刊: ふぃーるどのーつ
1

3. はじめに
Webフロントエンドの開発環境としてのWindowsデスクトップ
つらい理由その1:ネイティブ拡張
つらい理由その2:シンボリックリンクやパーミッション
つらい理由その3:クロスプラットフォームでないビルドスクリプトや
開発ツール
Webフロントエンドの開発環境としてのWindows
Remote Developmentによるリモート開発
VSCodeの説明
VSCodeのインストール時のPATHの設定
VSCodeへのRemote Development 拡張機能の導入
おことわり
VSCodeからのSSHを使用したリモート接続
リモート接続のサポートする環境
リモート接続時のTerminalのキーバインド
リモートとローカルのプラグインの構成を統一する
ssh-agentによる公開鍵認証のパスフレーズ入力省略
ProxyCommandによる多段接続
AWS Systems Manager Session Managerを使用したリモート開発
Windows Subsystems For Linux(WSL)とVSCodeによるリモート開発
WSLのインストール
ディストリビューションのインストールと起動
WSL2の有効化
WSL2のバックポート
シェルの起動オプション
Remote-WSLによるVSCode上でのリモート開発
Remote ExplorerからのWSLのシェルへの接続
WSLから切断する
WSLの使用法
WSL上ののGitとWindows上のGitの区別
WSL2のメモリー制限
wsl-clockによるホストとの時刻同期
WindowsエクスプローラーからのWSLへのアクセス
WSLディストリビューションのリセット
AnsibleによるWSL環境のセットアップ
VSCodeとDockerによるリモート開発
devcontainer.json
5
6
6
6
7
7
9
9
10
11
12
13
16
16
18
18
20
21
23
23
24
25
28
28
28
29
30
30
31
32
32
33
33
34
36
36
2

4. devcontainer.json の各項目について
devContainerのDockerfile
devcontainerのリビルド
Docker DesktopのWSL2 Windows Feature
Vagrant on Hyper-V
Vagrant でのHyper-V仮想マシンの操作
終了・再起動
起動時の仮想マシンへの接続
共有ディレクトリーのマウント
Hyper-Vのbox作成
Linuxディストリビューションインストール時の注意点
CentOS6 の注意点
Vagrant Hyper-V Providerの利点
VSCode Remote DevelopmentとVagrantの連携
あとがき
37
37
40
40
43
44
45
45
45
46
49
50
51
51
54
3

5. はじめにはじめに
本書はWindowsデスクトップ環境でのWebフロントエンド開発について、WindowsSubsystemfor
Linux（WSL)やVisualStudioCode(VSCode)によるリモート開発などのノウハウを紹介します。
この本の想定する読者この本の想定する読者
WindowsデスクトップでWebフロントエンドの開発環境を構築したいWebエンジニア
WindowsデスクトップHyper-Vでの仮想マシンの管理⽅法を知りたいITエンジニア
サポートサポート
本書の内容のサポートについては、以下のサイトで⾏います。
http://pub.fieldnotes.jp/
画⾯のスクリーンショット等、サービスに関する情報については執筆時点での最新のものを使⽤するよ
う努めていますが、継続的にサービス内容の更新が⾏われていますので最新のサービス内容と差異
が出る場合はご容赦ください。
また、プレビュー版の内容を取り上げているものについては、今後仕様が変更となる場合があります。
動作の検証は、以下のバージョンで⾏っています。
MicrosoftWindows Professionalバージョン2004
VisualStudioCode1.45.1
UbuntuUbuntu20.04LTS
CentOSLinuxrelease8.2.2004
Vagrant2.2.7
本書では、WindowsSubsystemforLinuxをWSL、VisualStudioCodeをVSCodeと記述します。
表記関係について表記関係について
本書に記載されている会社名、製品名などは、⼀般に各社の登録商標または商標、商品名です。会社
名、製品名については、本⽂中では©、®、™マークなどは表⽰していません。
免責事項免責事項
本書に記載された内容は、情報の提供のみを⽬的としています。したがって、本書を⽤いた開発、製作、
運⽤は、必ずご⾃⾝の責任と判断によって⾏ってください。これらの情報による開発、製作、運⽤の結果
について、著者はいかなる責任も負いません。
5

6. Webフロントエンドの開発環境としてのWindowsWebフロントエンドの開発環境としてのWindows
デスクトップデスクトップ
2019年のstackoverflowの調査によれば*1、開発者が使⽤する環境としてmacOSは26.8%のシェア
を占めています。またLinuxベースが25.8%を占めており、世界規模でみれば、ソフトウェア開発者のお
よそ半数はUnix由来のデスクトップ環境を使⽤していることがわかります。
iOSアプリケーションの開発のようにプラットフォームとしてmacOSに限定されているものはやむを得な
いです。しかし、Webアプリケーションのフロントエンドとしてメインとなる⾔語は
JavaScript/TypeScriptがメインであり、クロスプラットフォームなスクリプト⾔語です。HTMLがクロス
プラットフォームなことは論を待ちません。
Angular、React、Vue.jsのWebフロントエンドの三⼤フレームワークのフレームワークのサポートされ
ているバージョンであれば、Windowsデスクトップ環境での動作に⼤きな問題はなくなってきました。
またWebブラウザー上のオンラインで動作する開発環境StackBlitz*2やVisualStudio
Codespaces *3のように、ローカルにWebブラウザー以外のソフトウェア環境を必要としない開発プラ
ットフォームも近年めざましい進歩をとげています。
しかし、実際の案件を想定して、フレームワークの標準機能の範疇からはずれて、様々なサードパティー
のライブラリーを組み込むようにすると、WindowsデスクトップでのWebフロントエンド開発は茨の道
を進むことになります。次にその理由を三つあげます。
つらい理由その1:ネイティブ拡張つらい理由その1:ネイティブ拡張
JavaScript/TypeScriptそれ⾃体はクロスプラットフォームな⾔語ですが、ミドルウェアとの連携や、パフ
ォーマンスなどの関係で、C⾔語をはじめとするネイティブ寄りのプログラミング⾔語で書かれたnpmラ
イブラリーが存在します。これらをWindowsデスクトップ上でビルドするには、VisualStudioをはじめ
とするビルド環境を開発者がそれぞれセットアップする必要があります。
つらい理由その2:シンボリックリンクやパーミッションつらい理由その2:シンボリックリンクやパーミッション
Windowsのファイルシステムにもシンボリックやパーミッションの機能は存在しますが、Unixのファイ
ルシステムとは提供している機能や、APIの構造が異なります。npmのライブラリーのビルド時にシン
ボリックやパーミッションの操作を⾏っている場合は、Windowsデスクトップ上でビルドを成功させるこ
とは難しくなります。
6
*1 https://insights.stackoverflow.com/survey/2019#technology-_-developers-primary-
operating-systems
*2 https://stackblitz.com/
*3 https://visualstudio.microsoft.com/ja/services/visual-studio-codespaces/

7. つらい理由その3:クロスプラットフォームでないビルドスクリプトつらい理由その3:クロスプラットフォームでないビルドスクリプト
や開発ツールや開発ツール
Webフロントエンドにおいては、npmの依存性管理のファイルであるpackage.jsonに、ビルドのため
のスクリプトやコマンドを記述する⼿法(npm-scripts)が主流です*4。多くの場合、記述されるスクリプ
トやコマンドはUnix由来のコマンドやシェルスクルプトに依存していて、クロスプラットフォームではあり
ません。
著者はJavaプラグラマー出⾝であるため、プラットフォーム依存なビルドスクリプトというのは⼤いに違
和感があるのですが、現状のWebフロントエンドのエコシステムにおいてはnpm-scriptsが主流にな
っています。
また、npmライブラリーとして提供される開発ツールの中で、ファイルシステム内の変更に応じて能動
的に処理を⾏うツールでは、UnixとWindowsのファイルシステムの違いを吸収する実装コストの⾯か
ら、Windowsデスクトップのサポートに積極的でない場合があります。
これらの理由から、今⽇*5現在では、JavaScript/TypeScriptを主とするWebアプリケーションのフロ
ントエンドの開発においては、開発環境のデスクトップ環境はmacOSを使うことが現実的な選択肢とな
っています。
Webフロントエンドの開発環境としてのWindowsWebフロントエンドの開発環境としてのWindows
Microsoftは、世界規模でのオープンソースコミュニティーのプラットフォームであるGitHubを2018年10
⽉に買収したことに象徴されるように、開発者向けのエクスペリエンス(DeveloperExperience:DX)
を重視し、その中のフロントエンドとなるWindowsデスクトップやVisualStudioCode(VSCode)など
の環境に対し、積極的な投資を⾏っています。
その中で2016年8⽉のWindows のAnniversaryUpdateで、「BashonUbuntuonWindows」
としてWindowsデスクトップ上でのLinux環境が提供されるようになりました。「BashonUbuntu
onWindows」はその後「WindowsSubsystemsforLinux」(WSL)と名称を改め、順調に機能の
拡充を続けています。
そしてVSCodeで現在Previewとして開発が⾏われているRemoteDevelopment*6との組み合わ
せにより、Linux上の開発環境と、WindowsおよびmacOSのデスクトップ環境を、シームレースに連携
することができるようになってきました。
このことにより、ここまでで述べてきたWindowsデスクトップでWebフロントエンドの開発を⾏う上での
問題を解決することができます。Unixネイティブな洗練された開発環境と、Windowsの完成されたデ
スクトップ環境の、両⽅の⻑所を⽣かして開発が⾏うことができるのです。
7
*4 https://docs.npmjs.com/misc/scripts
*5 2020年9⽉
*6 https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-
extensionpack

8. 本書では、VSCodeのリモート開発機能がサポートする、WSL、SSH、Containersの三つのリモート環
境について紹介します。また、Windowsデスクトップ上で開発者向けの最新機能を活⽤するのに必要
な、Hyper-V上での仮想マシンを⽤いた開発についても取り上げます。
8

9. RemoteDevelopmentによるリモート開発RemoteDevelopmentによるリモート開発
VSCodeでは、「RemoteDevelopment」拡張機能 *7を使⽤して、リモートの開発を⾏うことができま
す。
「RemoteDevelopment」拡張機能は、以下の三種類のリモート接続先に接続できます。
SSH
Container(Docker)
WSL(WindowsSubsystemForLinux)
VSCodeによるリモート開発には、次の利点があります。*8
デプロイ先と同じオペレーティングシステム(OS)を使⽤する
ローカルよりも性能が上位、ないし固有のハードウェアを使⽤する
開発環境をサンドボックス化すうことにより、ローカルの環境に影響を及ぼさないようにする
ローカルのOSで提供されていないツールや実⾏環境を使⽤する
複数のツールや実⾏環境を使い分ける
WSLを使⽤して、LinuxにデプロイするアプリケーションをWindows上で開発する
リモートにある既存の環境にローカルの環境からアクセスする
顧客のサイトやクラウド環境で稼働しているアプリケーションに接続してデバッグを⾏う
VSCodeの説明VSCodeの説明
VSCodeでのリモート開発を説明するにあたり、各画⾯の構成 *9について⽰します。VSCodeの使⽤
法については、本間咲来著「徹底解説VisualStudioCode」(CR研究所)などをご参照ください。
9
*7 https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-
extensionpack
*8 https://code.visualstudio.com/docs/remote/remote-overview
*9 https://code.visualstudio.com/docs/getstarted/userinterface

10. 図.1:VSCodeの各画⾯
①アクティビティーバー(ActivityBar)/②サイドバー(SideBar)①アクティビティーバー(ActivityBar)/②サイドバー(SideBar)
アクティティーバーを選択することにより、「ソース管理」「拡張機能」などのビューの呼び出しを⾏いま
す。サイドバーにビューの項⽬が表⽰されます。
③コマンドパレット(CommandPalette)③コマンドパレット(CommandPalette)
VSCodeの画⾯から「Ctrl+Shift+P」のショートカットを⼊⼒することにより、コマンドパレットを表⽰しま
す。
④統合ターミナル(IntegratedTerminal)④統合ターミナル(IntegratedTerminal)
VSCodeの画⾯からショートカット(Windows:Ctrl+Shift+@)を⼊⼒することにより、統合ターミナルの
ビューを表⽰します。統合ターミナルは、リモート接続先のLinuxのシェルを表⽰し、操作することができ
ます。
⑤ステータスバー⑤ステータスバー
VSCodeからリモート接続している場合は、ステータスバーの左下にリモート接続先が表⽰されます。
VSCodeのインストール時のPATHの設定VSCodeのインストール時のPATHの設定
10

11. WSLとVSCodeを連携させるには、WSLのシェルから、ホスト側のVSCode(Windowsではcode.exe)
を実⾏します。このため、WindowsではVSCodeのインストール時に、インストーラーの「PATHへの追
加」にチェックを⼊れる必要があります。(図.2)
図.2:VSCodeのインストール時のPATHの設定
VSCodeへのRemoteDevelopment拡張機能の導⼊VSCodeへのRemoteDevelopment拡張機能の導⼊
VSCodeへのRemoteDevelopmentはWSL/SSH/Container向けの機能の拡張機能をまとめたも
のが「RemoteDevelopment」拡張機能として提供されています。(図.3)
11

12. 図.3:RemoteDevelopment拡張機能
コマンドラインから「RemoteDevelopment」拡張機能をインストールする場合は、コマンドプロンプト
からコード.1の通り⼊⼒します。
コード.1:RemoteDevelopment拡張機能のインストール
code --install-extension ms-vscode-remote.vscode-remote-extensionpack
おことわりおことわり
本書では以下でVSCodeの画⾯を収録するにあたり、配⾊を「VisualStudioLight」に設定していま
す。
12

13. VSCodeからのSSHを使⽤したリモート接続VSCodeからのSSHを使⽤したリモート接続
VSCodeのRemoteDevelopmentはデスクトップ環境のOpenSSHの設定を使⽤してリモート接続を
⾏います。
OpenSSHクライアントの設定ファイルのデフォルト配置は、%USERPROFILE%.sshconfig です。
Windows ではOctober2018Update( )から標準でOpenSSHクライアントが提供されて
います。
WindowsにOpenSSHがインストールされていない場合は、[設定]を開始し、[アプリ][アプリ
と機能][オプション機能の管理]の順に選択します。ページの上部にある[機能の追加]を選択
し、次のようにします。[OpenSSHクライアント]を⾒つけて[インストール]を選択します。*10
コード.2は、外部のLinuxサーバーに接続するための~/.ssh/configの設定です。
コード.2:.ssh/configの記述
Host dev
HostName 192.168.10.15
User azusa
Port 22
VSCodeは、この設定を読み込んで、接続先のホストを管理します。アクテビティバーの「Remote
Explorer」アイコン(図.4)をクリックして、「RemoteExplorer」ビューを表⽰します。ビュー上部のプル
ダウンで「SSHTargets」を選択して、リモートホストの⼀覧を表⽰します。(図.5)
13
*10 https://docs.microsoft.com/ja-jp/windows-
server/administration/openssh/openssh_install_firstuse

14. 図.4:アクティビティバーの「RemoteExplorer」アイコン
図.5:RemoteExplorerビュー
14

15. 図.6:統合ターミナルからのRubyonRailsの起動
仮想マシンに接続すると、ステータスバー及びタイトルバーにリモートホスト名が表⽰されます。後は通
常の開発と同様に編集ができ、「Ctrl+Shift+@」から、リモートの端末を開いて操作することができま
す。
図.6は、VSCodeの統合ターミナルから、RubyonRailsを起動している様⼦です。
VSCodeの統合ターミナルからアプリケーションを起動すると、VSCodeでリモートでListenしているポ
ートを認識して、「RemoteExplorer」ビューの「FORWARDEDPORTS」ビューでポート転送の候補が
表⽰されます。ポートの表⽰の「＋」アイコンを選択すると、ホストからポート転送ができます。(図.7)
図.7:ポート転送の設定
15

16. WindowsSubsystemsForLinux(WSL)とVSCodeWindowsSubsystemsForLinux(WSL)とVSCode
によるリモート開発によるリモート開発
この章では、WSLとVSCodeの機能拡張である「Remote-WSL」との組み合わせで、Webフロントエ
ンドを開発する⽅法を述べます。
WSLのインストールWSLのインストール
WSLはWindowsのオプションとして提供されています。WSLの機能を有効にするには、管理者権限
でPowerShellのプロンプトを開き、以下のコマンドを実⾏します。(コード.6)
コード.6:WSLの機能を有効にする
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-
Subsystem-Linux
GUIからは、「Windowsの機能の有効化または無効化」のウィンドウから、「Linux⽤Windowsサブシ
ステム」の機能を選択します。(図.14)
図.14:Windowsの機能の有効化または無効化
23

17. なお、以前のWindows のアップデートでは、WSLを使⽤するのにOSの「開発者モード」を有効にす
る必要がありましたが、2017年10⽉にリリースされた「FallCreatorsUpdate」から、WSLの動作に開
発者モードは必要なくなっています。
ディストリビューションのインストールと起動ディストリビューションのインストールと起動
WSLで動作するUbuntu等のLinuxディストリビューションは、Microsoftストアから⼊⼿します。
本書では、Microsoftストアから配布されているUbuntuディストリビューションを⽤いて、説明を⾏いま
す。
Windowsのスタートメニューから「MicrosoftStore」を起動し、「Ubuntu」と検索します。
または、Web上のMicrosoftストアから*16Ubuntuの製品ページを表⽰します。(図.15)
図.15:Ubuntuの製品ページ
ページ内の「⼊⼿」ボタンを選択すると、ディストリビューションのダウンロードが始まります。ダウンロード
が完了すると、「起動」というボタンが表⽰されるので、選択するとディストリビューションが起動し、
Ubuntuの場合は、コード.7のようにユーザーとパスワードを設定するプロンプトが表⽰されます。⼊
⼒が終わるとbashのプロンプトが使⽤できるようになります。
コード.7:WSLディストリビューションのセットアップ
Installing, this may take a few minutes...
Please create a default UNIX user account. The username does not need to
match your Windows username.
For more information visit: https://aka.ms/wslusers
24
*16 https://www.microsoft.com/ja-jp/p/ubuntu/9nblggh4msv6?activetab=pivot:overviewtab

18. Enter new UNIX username: azusa
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Installation successful!
To run a command as administrator (user root), use sudo command.
See man sudo_root for details.
⼆回⽬の起動以降はスタートメニューから「Ubuntu」を選択するか、コマンドプロンプトからubuntu コ
マンドを実⾏することでシェルを起動できます。
Microsoftが製品として扱う「Debian」Microsoftが製品として扱う「Debian」
MicrosoftストアではWSLのLinuxディストリビューションとして「Debian」*17が扱われていま
す。DebianはGPLをはじめとするフリーソフトウェアの精神を尊重することをうたっているLinux
ディストリビューションです。ハロウィーン⽂章 *18に代表されるように、かつてフリーソフトウェア
のコミュニティーと対⽴する姿勢を明らかにしていたMicrosoftが、フリーソフトウェアの精神を具
現しようとするプロジェクトであるDebianを⾃社ストアのラインアップに⼊れていることには、著者
には感慨深いものがあります。
WSL2の有効化WSL2の有効化
「Linux⽤Windowsサブシステム」の導⼊直後では、コード.8のようにWSL がデフォルトのサブシス
テムとして選択されるようになっています。
コード.8:WSL1がデフォルトの状態
wsl -l -v
NAME STATE VERSION
* Ubuntu-18.04 Stopped 1
Ubuntu Stopped 1
WSL の仮想マシン(ディストリビューション)をWSL に変換するには、コード.9wsl --set-version
(仮想マシン名) 2を実⾏します。
実⾏時に「WSL2を実⾏するには、カーネルコンポーネントの更新が必要です。」というメッセージが表
⽰される場合は、メッセージ出⼒に従い、WSL2Linuxカーネルの更新*19 のサイトから、x マシン
⽤の最新のWSL Linuxカーネル更新プログラムパッケージをダウンロードし、インストールします。
25
*17 https://www.microsoft.com/ja-jp/p/debian/9msvkqc78pk6?activetab=pivot:overviewtab
*18 https://cruel.org/freeware/halloween.html

19. VSCodeとDockerによるリモート開発VSCodeとDockerによるリモート開発
VSCodeでは、「Remote-Container」拡張機能を使⽤することにより、Dockerコンテナー上で起動す
るVSCodeにリモート接続して開発を⾏えます。
「Remote-Container」の拡張機能では、devcontainerという仕様にもとづいて、コンテナーを作成し
ます。このことにより、アプリケーションのソースコードと開発環境を単⼀のレポジトリー上でコード化で
きます。
devcontainer.jsondevcontainer.json
devcontainerを作成するには、プロジェクトの.devcontainer/devcontainer.json に設定を記述し
ます。
devcontainer.json を含んだディレクトリーを開いて、ステータスバー左下の「Openaremote
Window」のアイコンをクリックします。次にコマンドパレットから「RemoteContainers:Reopenin
Container」を選択します。devcontainerが起動すると、コンテナー内でVSCodeが起動します。
コード.19:devcontainer.json
{
name: Ruby on Rail Sample,
dockerFile: Dockerfile,
// Comment out the next line to run as root instead. Linux users,
// update Dockerfile with your user's UID/GID if not 1000.
runArgs: [-u, vscode],
// Use 'settings' to set *default* container specific settings.json
values on container create.
// You can edit these settings after create using File Preferences
Settings Remote.
settings:{
terminal.integrated.shell.linux: /bin/bash
},
// Uncomment the next line if you want to publish any ports.
// appPort: [],
// Uncomment the next line to run commands after the container is
created.
// postCreateCommand: java -version,
forwardPorts: [3000],
extensions: [
wingrunr21.vscode-ruby,
bung87.rails
36

20. ]
}
devcontainer.jsonの各項⽬についてdevcontainer.jsonの各項⽬について
コード.19はdevcontainer.jsonのサンプルです。それぞれの項⽬を以下に説明します。
dockerfile :devcontainer.jsonからの、Dockerfileへの相対パスです。
runArgs :devcontainerを実⾏するdocker run *29 コマンドへの引数です。devcontainerで
はシェルをroot以外で実⾏することが推奨されているため、通常Dockerfile内で作成するユー
ザーを指定します。
settings :devcontainer内で実⾏するVSCodeの設定です。コード.19の例では、VSCodeの
統合ターミナル内で起動するシェルを指定しています。
appPort :devcontainerが公開(expose)するためのポートです。VSCodeのリモート接続で
は、コンテナーが公開しているポートを検出してポート転送することによりデスクトップ環境から
アクセスを⾏うため、ポートの公開はDockerfile上の記述で⾏い、後述するforwardPortsを使
⽤します。
forwardPorts :デスクトップ環境から転送するポートを指定します。
extensions :devcontainer上のVSCodeに組み込む拡張機能を指定します。
devContainerのDockerfiledevContainerのDockerfile
devContainerで使⽤するDockerイメージには、以下の条件があります。Dockerfileのパスは
.devContainer/Dockerfile が推奨です。
Linuxディストリビューションが以下のいずれかであり、
アーキテクチャーがx _ /ARMv l(AArch )/ARMv l(AArch )のDebian9以降,
Ubuntu16.04以降,CentOS/RedHatEnterpriseLinux(RHEL)7以降
x _ AlpineLinux3.7+
他のglibcベースのLinux
加えて、コンテナー内でシェルを起動するためのユーザーが作成されていることが必要です。
GitHubに各⾔語ごとのdevcontainerのサンプルが公開されています。これをベースにしてカスタマ
イズしていきます。
https://github.com/Microsoft/vscode-remote-try-node
https://github.com/Microsoft/vscode-remote-try-python
https://github.com/Microsoft/vscode-remote-try-go
https://github.com/Microsoft/vscode-remote-try-java
https://github.com/Microsoft/vscode-remote-try-dotnetcore
37
*29 https://docs.docker.com/engine/reference/commandline/run/

21. https://github.com/Microsoft/vscode-remote-try-php
https://github.com/Microsoft/vscode-remote-try-rust
https://github.com/Microsoft/vscode-remote-try-cpp
これらのサンプルで共通する部分を参考にして、RubyonRails向けのdevcontainerを作成したのが
コード.20です。*30
①対話処理の無効化①対話処理の無効化
Dockerfileの先頭で⾏っているDEBIAN_FRONTEND=noninteractiveの環境変数の設定は、Debianお
よびUbuntuをベースとするイメージで、aptコマンドによる処理時の対話処理を無効にするためのワ
ークアラウンドです。
②apt-utilsのインストール②apt-utilsのインストール
docker buildの処理の最後でapt-get autoremoveおよびapt-get cleanを実⾏するためにapt-
utilsをインストールします。
③必要なパッケージのインストール③必要なパッケージのインストール
Debian/Ubuntuベースのコンテナーでは、devcontainerには以下のパッケージが必要です。
apt-utils
dialog
iproute
procps
git
lsb-release
curlは必須のパッケージではないですが、開発環境のセットアップ時にダウンロード処理を⾏う際に必
要となるため追加します。
④RubyonRailsのビルドに必要なパッケージのインストール④RubyonRailsのビルドに必要なパッケージのインストール
以下のパッケージをRubyonRailsのビルドおよび実⾏のためにインストールします。このためこの部
分は各⾔語・フレームワークごとに異なります。
build-essential
libsqlite -dev
nodejs
sqlite
⑤ユーザーの追加⑤ユーザーの追加
38
*30 https://github.com/azusa/vscode-remote-rails/

22. VagrantonHyper-VVagrantonHyper-V
WSL を使⽤するには、Windows のHyper-Vの機能を有効にする必要があります。Hyper-Vが提
供されていないWindows のHomeエディションにも、Hyper-Vの機能サブセットが⽤意されていま
す。
そのWSL に限らず、DockerforWindowsやWindowsサンドボックスなど、Windowsの⼤型アップ
デートで提供される開発者向けの新機能は、Hyper-Vを前提としています。
Hyper-Vは、IntelのVT-xなどの仮想化⽀援機能を使⽤します。このことは、他のアプリケーションに
対して排他の関係となります。開発者向けの仮想化ソフトウェアの標準であるOracleVMVirtualBox
が動作しない場合があります。このことはWindowsデスクトップ上でHyper-Vを導⼊する上での障壁
になっています。
Hyper-V上でVirtualBoxは「動く」のかHyper-V上でVirtualBoxは「動く」のか
VirtualBoxはバージョン6.0より、実験的機能としてHyper-Vを仮想化プラットフォームとしてサ
ポートしています。*31
バージョンを重ねるごとにHyper-V上でのVirtualBoxの動作も実装が進み、Linuxディストリ
ビューションによってはインストールに成功する例も出てきました。しかし、ディストリビューション
によっては、エラーが発⽣しインストールに失敗するものや、Vagrantの動作に必要な
VirtualBoxGuestAdditionsの組み込みに失敗するものなどがあり、Hyper-V環境での
VirtualBoxの動作は、常⽤できる⽔準には未だ達していないのが現状です。
アーキテクチャー上の制約からWebアプリケーションの開発環境にWSLやDockerによるリモート開発
を使⽤できない場合は、仮想マシン上の使⽤を検討することになります。
その中で、Webアプリケーションの開発環境として必要な要件を整理すると、必要なものは、
VirtualBoxそのものでなく、仮想マシンを統⼀したコマンドで容易に操作できることの出来るコマンド
ラインインターフェース(CLI)である、ということなります。
そこで選択肢としてあがってくるのが、開発環境として仮想マシンを管理するソフトウェアであるVagrant
のHyper-VProviderです。Vagrantを使⽤することにより、macOSなど他のOS上でVirtualBoxを使
⽤する開発者とも、Ansible等による仮想マシンのプロビジョニングのスクリプトを共有できるメリットが
あります。
この章では、Vagrantが使⽤する仮想プラットフォームとしてHyper-Vを使⽤する上でのポイントについ
て書きます。
43
*31 https://docs.oracle.com/cd/E97728_01/F12469/html/hyperv-support.html

23. VagrantでのHyper-V仮想マシンの操作VagrantでのHyper-V仮想マシンの操作
VagrantのHyper-VProviderを使⽤して仮想マシンを起動するには、コマンドを実⾏するプロンプト
が管理者権限で起動していることが必要です。
管理者権限で起動したコマンドプロンプトないしPowerShellから、vagrant upコマンドで仮想マシンを
起動します。なお、InsiderPreviewで提供されているWindows の次期バージョンのビルドでは、管
理者権限が必要な際にユーザーアカウント制御(UAC)のダイアログが出るようになるため、不要になる
予定です。
Hyper-Vでvagrantを起動する際には、次の⽅法で、providerがHyper-Vであることを指定します。
起動オプション
Vagrantfileの設定
環境変数
起動オプション起動オプション
vagrantで--providerオプションを指定して起動します。オプションを指定しない場合はデフォルトの
providerであるVirtualBoxで起動しようとするので注意が必要です。(コード.25)
コード.25:vagrantの起動
vagrant init hashicorp/bionic64
vagrant up --provider=hyperv
Vagrantfileの設定(推奨)Vagrantfileの設定(推奨)
Vagrantの設定ファイルであるVagrantfileでproviderを指定します。(コード.26)
VagrantはGitなどのバージョン管理ツールを通して設定を共有することが前提のため、著者はこの⽅
法でproviderを指定することを推奨します。
コード.26:Vagrantfileでのproviderの指定
config.vm.provider hyperv
環境変数環境変数
仮想マシンのホスト上で環境変数VAGRANT_DEFAULT_PROVIDERを指定することにより、Hyper-Vを使⽤
することを指定できます。(コード.27)
44

24. コード.27:環境変数の指定
VAGRANT_DEFAULT_PROVIDER=hyperv
終了・再起動終了・再起動
終了・再起動などのオプションはVagrantの標準と同じです。((コード.28))
コード.28:終了・再起動
# 再起動
vagrant reload
# 終了
vagrant halt
# 仮想マシンの破棄
vagrant destroy
起動時の仮想マシンへの接続起動時の仮想マシンへの接続
Hyper-Vでは、仮想マシンのネットワークインターフェース(NIC)と、ホスト側のネットワークを、「仮想ス
イッチ」というインターフェースで接続します。
Hyper-V上に仮想スイッチが複数作成している場合は、Vagrantにより仮想マシンを起動する際に、プ
ロンプト上でどの仮想スイッチに接続するかを選択します。
ホストとなるWindowsデスク上にDockerforWindowsがインストールされている場合は、Docker
forWindowsが「DockerNAT」という仮想スイッチを作成します。この場合は、Vagrantによる仮想マ
シンの起動時のスイッチの選択は必須です。
共有ディレクトリーのマウント共有ディレクトリーのマウント
VagrantのHyper-VProviderは、ホストと仮想マシン間のフォルダーの共有をServerMessage
Block(SMB)によるディレクトリーの共有で⾏います。
このため、仮想マシンからホストの共有フォルダーの認証情報の⼊⼒が必要です。
⼊⼒するアカウントはMicrosoftアカウントの場合は、Microsoftアカウントのメールアドレスとパスワー
ドでActiveDirectory *32アカウントの場合は、ADアカウントのローカルパートとパスワードです。
Vagrantのdotenvプラグインを使⽤すると、アカウントの設定を環境変数で⾏うことができます。(コー
ド.29) *33
45
*32 以下AD