Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

「WindowsデスクトップでWeb開発 改訂版」サンプル

技術書典9「WindowsデスクトップでWeb開発 改訂版」サンプルです。
販売サイト: https://techbookfest.org/product/5013670885064704

  • Be the first to comment

  • Be the first to like this

「WindowsデスクトップでWeb開発 改訂版」サンプル

  1. 1. すいーとみゅーじっくvol.9すいーとみゅーじっくvol.9 WindowsデスクトップでWeb開発改訂版WindowsデスクトップでWeb開発改訂版 著: setoazusa 刊: ふぃーるどのーつ 1
  2. 2. はじめに 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
  3. 3. 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
  4. 4. はじめにはじめに 本書は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
  5. 5. 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/
  6. 6. つらい理由その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
  7. 7. 本書では、VSCodeのリモート開発機能がサポートする、WSL、SSH、Containersの三つのリモート環 境について紹介します。また、Windowsデスクトップ上で開発者向けの最新機能を活⽤するのに必要 な、Hyper-V上での仮想マシンを⽤いた開発についても取り上げます。 8
  8. 8. 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
  9. 9. 図.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
  10. 10. 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
  11. 11. 図.3:RemoteDevelopment拡張機能 コマンドラインから「RemoteDevelopment」拡張機能をインストールする場合は、コマンドプロンプト からコード.1の通り⼊⼒します。 コード.1:RemoteDevelopment拡張機能のインストール code --install-extension ms-vscode-remote.vscode-remote-extensionpack おことわりおことわり 本書では以下でVSCodeの画⾯を収録するにあたり、配⾊を「VisualStudioLight」に設定していま す。 12
  12. 12. 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
  13. 13. 図.4:アクティビティバーの「RemoteExplorer」アイコン 図.5:RemoteExplorerビュー 14
  14. 14. 図.6:統合ターミナルからのRubyonRailsの起動 仮想マシンに接続すると、ステータスバー及びタイトルバーにリモートホスト名が表⽰されます。後は通 常の開発と同様に編集ができ、「Ctrl+Shift+@」から、リモートの端末を開いて操作することができま す。 図.6は、VSCodeの統合ターミナルから、RubyonRailsを起動している様⼦です。 VSCodeの統合ターミナルからアプリケーションを起動すると、VSCodeでリモートでListenしているポ ートを認識して、「RemoteExplorer」ビューの「FORWARDEDPORTS」ビューでポート転送の候補が 表⽰されます。ポートの表⽰の「+」アイコンを選択すると、ホストからポート転送ができます。(図.7) 図.7:ポート転送の設定 15
  15. 15. 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
  16. 16. なお、以前の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
  17. 17. 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
  18. 18. 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
  19. 19. ] } 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/
  20. 20. 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/
  21. 21. 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
  22. 22. 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
  23. 23. コード.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

×