こんにちは、サイオステクノロジー技術部 武井です。私は、マイクロソフトが実施しているテクニカルカンファレンス「Ignite」に参加するためにフロリダのオーランドということろに来ております。Igniteが実施している期間中に、「ほぼ」リアルタイムレポートをお届けしたいと思います。今回は「Create Linux apps from your Windows PC with Visual Studio Code」について記載します。
本セッションは以下のような方向けです
WindowsでLinux上で動作するアプリを開発したい！！
はい、これはWSLの出番ですね。
セッションでは、Visual Studio CodeにWSLでRemote Developmentの拡張機能により、node.jsで稼働するWebアプリケーションのデバッグを行っておりました。ここで「WSL」「Visual Studio Code」「Remote Development」について説明します。(本セッションではそこは説明されていませんでした)
WSLとは？
Windows Subsystem for Linux(以降、WSL)は、平たく言うとWindows内でLinuxを実行できる仕組みです。これによりWindowsでの開発環境は劇的に改善します。
開発環境としてのWindowsは、そのインターフェースの親しみやすさから、言わずもがな使いやすいです。また、Windowsは音楽や動画などのメディア系ファイルを扱うOSとしては、秀逸です。一方で、シェルの扱いやすさは、Linuxに軍配が上がります。ログをgrepしながらtailしたりなどの操作はWindowsでは中々にハードルが高いのが事実です(出来なくはないですが)。そんなLinuxとWindowsのいいとこ取りをしたいというエンジニアは数多いらっしゃると思います。
例えば、WindowsよりLinuxが優れている例として、先程もご説明した「シェルの操作性」があります。以下のような、重複した行が散在するテキストファイルから、重複した行だけを取り出してソートするという例を考えてみます。
banana
apple
peach
apple
banana
banana
tomato
banana
Windows、Linuxそれぞれの場合で、上記の内容を実現するシェルは以下のとおりです。
■ Windowsの場合
PS> Get-Content test.txt | Group-Object | Where-Object {$_.Count -gt 1} | Select-Object -ExpandProperty Name | Sort-Object
■ Linuxの場合
$ sort test.txt | uniq -d | sort
やはり、Linuxの方に軍配が上がりますね。Windowsの場合より、シンプルな方法で実現が可能です。
いずれのコマンドも結果は同じで、以下のとおりとなります。
apple
banana
確かに今までも、CygwinやVirtual Boxなどの仮想化ソフトウェアによるLinux on Windowsの実現方式がありました。今回ご紹介するWSLとそれらの決定的な違いは、「導入の容易さ」「高速起動」「Windowsとの親和性」です。
導入の容易さ
まず、導入の容易さについて、ご説明致します。Virtual Boxを始めとした仮想環境は、ネットワークやストレージ、メモリを始めとした各種リソースの設定、それからOSのインストールと、かなりの手間と時間を要します。
それと比べて、WSLを導入するまでは数ステップ、時間にすれば10分程度で、OSインストール済みの環境が出来上がり、しかも全てGUIで完結します(後述するWSL2は一部CLIが必要)。本当に簡単で、あっという間です。
高速起動
WSLの起動は、ほぼ一瞬です。それは、Windowsのコマンドプロンプトを起動するのと同じような感覚といっても過言ではありません。
Virtual Boxなどの仮想環境は、昨今のOSの起動が早くなったとはいえ、WSLには遠く及びません。bashなどのシェルが使いたい時に、たとえ5秒待たされるのさえストレスに感じます。
使いたい時にさっと使えるのは、大きなアドバンテージになるのではないでしょうか？
Windowsとの親和性
WSLは非常にWindowsとの親和性が高いことが、大きなメリットです。その一例として、Windows⇔Linux間の相互ファイルアクセスです。
Virtual Boxでも、SambaなどのCIFSプロトコルに対応したサーバーを立てれば、もちろん可能です。しかし、Sambaのインストールや設定といった煩雑な作業が待っていますし、アクセス権の設定やファイル名の文字コードなど、頭を悩ませることがありますよね。
WSLであれば、とても簡単です。WindowsからLinux上にあるファイルにアクセスするには、「\\wsl$\[ディストリビューションの名前]」というパスにアクセスすればOKです。ディストリビューションがUbuntuの場合は「\\wsl$\Ubuntu」となります。
LinuxからWindowsの場合は、「/mnt/[ドライブ名]」というパスにアクセスすると、Windowsの指定したドライブ直下にアクセスが出来ます。Cドライブにアクセスする場合は、「/mnt/c」となります。
Windows上でLinuxを使う場合、WSLは従来の方法に比べて、たくさんのメリットがあることがご理解頂けたかと思います。
Visual Studio Code
今、人気絶頂のソースコードエディタです。マイクロソフトによって開発され、Windows、Mac、Linuxなど様々な環境で動作します。また、動作も軽量で、プラグインが豊富であり、デフォルトの状態でも開発に必要なほとんどのものがビルトインされているので、カスタマイズなしで大抵の開発は出来てしまいます。筆者のお気に入りエディタです。
Visual Studio Codeには、Remote Development という拡張機能があり、これをインストールすると、リモートサーバー上のコードを直接編集が可能です。SSHで接続可能なリモートサーバーやコンテナ、WSL上にあるファイルをVisual Studio Codeから直接編集できるのです。つまり、ローカルマシンにソースコードを持つ必要がありません。リモートサーバー上のファイルを、あたかもローカルマシンにあるファイルのように扱うことができます。
Remote Development
また、Remote Developmentを使うと、Visual Studio Codeの拡張機能をリモートサーバーにインストールし、リモートサーバー上で動作させることができます。
例えば、Visual Studio CodeのPHPの拡張機能であるPHP IntelliSenseはPHP7以上が必要になります。この場合、従来の方法では、ローカルマシンにPHP7をインストールする必要がありました。しかし、せっかくソースコードは、リモートサーバーに隔離出来たのに、プラグインを動作させるために、ローカルマシンにPHPインストールするなんて、ちょっとナンセンスだと思いませんか？
そこで、Visual Studio CodeのRemote Developmentを使うと拡張機能をリモートサーバー上にインストールできます。つまり、先程のPHP IntelliSenseはリモートサーバー上で動作するので、リモートサーバー上にPHP7が動作していればよいのです。
このように、Remote Developmentを使うと、ソースコードや拡張機能の実行環境を完全にリモートサーバー側に分離が可能であり、ローカルマシン側にはVisual Studio Code以外、何もインストールする必要がありません。ローカルマシンの環境を一切汚さず、開発環境を構築できるのはVisual Studio Codeの強みです。
デモ
さて、説明はここまでにして、ここからは実際に行われたデモのお話をいたします。デモはRemote Developmentの機能を使って「SSHによるリモートサーバーへの接続」「コンテナへの接続」の両方のケースが行われました。
SSHへのリモートサーバーへの接続
SSHへのリモートサーバーへの接続のデモでは、WSL上にnode.jsで開発したserver.js(ハロワのような、Helloなんとかを表示する単純なプログラム)を動かし、Visual Studio CodeからRemote Developmentでssh接続をして、直接サーバー側のソースコードをデバッグしていました。
※画面がなくてすみません(><)
コンテナへの接続
Remote Developmentにはコンテナへの接続も可能です。
こちらではWSL上ではなくて、コンテナ上で先程のserver.jsを動作させ、Remote Developmentのコンテナ接続機能を使って、直接Visual Studio Codeからコンテナに接続し、拡張プラグインなども全てコンテナ上で動作させ、コンテナ上のソースを修正・デバッグしているでもが披露されました。
まとめ
やはり来ましたね、Visual Studio Code + Remote Development + WSLあーんどVisual Studio Code + Remote Development + コンテナ！！これからのアプリケーション開発は劇的に変わりつつあります。そんなことを予感させるデモでした。
