懐かしの映画、1997年に制作され、日本での公開は1998年という「フェイス/オフ（監督：ジョン・ウー）」。顔を入れ替えるっていう、当時としては、なかなか斬新な内容でしたが、あ、どうもボクです。
「face off/face-off」はもとはホッケー用語で、向かい合った二人の選手のあいだにパックを落として試合を開始することですが、そこから1対1で対決する、にらみ合うという意味で使われるようになりました。
⇧ へぇ～、へぇ～、へぇ～、フェイスオフってそんな意味があったとは。
そして、最近、Facebook から、
⇧ 「ディープフェイク」検出ツールを開発していこうって話が出てると。
というわけで、脱線しましたが、今回は、Visual Studio Code で、Scala環境 を構築の最後までを目指して。レッツトライ～。
環境の全体像
今回の作業の全体像は、こんな感じになるかと。
ちなみに、環境は、Windows 10 Home なので、Docker ToolBox を使っています。
Docker Hub からコンテナのイメージを取得
Scala 環境のコンテナ を作成するために、docker image をDocker Hub からプルしたいと思うのですが、Scala の動作確認ができているJDKのバージョンは、
⇧ 2019年9月08日（日）現在、JDK 11 までは大丈夫そうであると。
正確には、sbt の動作確認らしいですが。
というわけで、Docker Hub の公式のリポジトリから、Open JDK 11 のdocker image をプルするということで。
⇧ 上記サイト様を参考に、 プルします。事前に仮想マシンとかは起動しておきましょう。
docker pull openjdk:11
マウント用のディレクトリを作成
適当な場所に、ゲストOSのディレクトリとマウントさせるためのディレクトリをホストOS側に作成で。
コンテナを作成・起動
それでは、プルしてきたdocker image を使って、コンテナを作成・起動します。その際、ゲストOSと ホストOSのディレクトリをマウントします。
docker run -d --restart=always --name [コンテナ名] -h [ホスト名] -p [ホストOS側のポート]:[ゲストOS側のポート] -v [ホストOS側のディレクトリ]:[ゲストOS側のディレクトリ] [REPOSITORY]:[TAG]
んで、コンテナに入ろうとしたら、
無限ループっぽく、再起動が繰り返されるという...
⇧ どうやら、Windows 特有のバグらしい。再起動のオプションと、マウントのオプションは同時に使えないらしい？
というわけで、一旦、コンテナを削除で。
再起動のオプションを削って、
docker run -d --name [コンテナ名] -h [ホスト名] -p [ホストOS側のポート]:[ゲストOS側のポート] -v [ホストOS側のディレクトリ]:[ゲストOS側のディレクトリ] [REPOSITORY]:[TAG]
駄目でした...今度は、起動すらしないという
⇧ どうやら、「-i」「-t」のオプションを付けて上げれば良いそうな。docker image によっては、このへんが変わってくるのかな？
（シェルのような）インタラクティブなプロセスでは、コンテナのプロセスに対して tty を割り当てるために、 -i -t を一緒に使う必要があります。 後の例で出てきますが -i -t は -it と書けます。 クライアント側の標準出力を echo test | docker run -i busybox cat のようにリダイレクトやパイプする場合 -t は指定できません。
tty って何ぞ？
ttyとは、標準入出力となっている端末デバイス(制御端末、controlling terminal)の名前を表示するUnix系のコマンドである。元来ttyとはteletypewriter（テレタイプライター）のことを指す。
⇧ よく分からんのだけれど、tty の割り当てが無いと、コンテナが起動してもすぐに停止してしまうらしい、たぶん...。
というわけで、
docker run --name [コンテナ名] -h [ホスト名] -p [ホストOS側のポート]:[ゲストOS側のポート] -d -it -v [ホストOS側のディレクトリ]:[ゲストOS側のディレクトリ] [REPOSITORY]:[TAG]
あ、なんか、コンテナにもOSインストールされてたっぽい。Linuxディストリビューションとしては、Debian 9 っていってますね。
なので、
Debian のパッケージ管理ツールである、apt-get を使って、コンテナに直接、sbt のインストールができそうです。
とりあえず、上記サイト様の通り、コマンドを実行してみる。
⇧ はい、エラー。
インストールしようとしているパッケージが配置されているURLが、httpsである場合に、起こるようです。
というわけで、
apt-get install apt-transport-https
その後に、「apt-get update」して、「apt-get install sbt」で。
とりあえず、sbt インストールされたのかな？
Visual Studio Code のリモートでScala
そしたらば、Visual Studio Codeで、Remote - SSHします。
のアイコンをクリックし、「Remote - SSH: Connect to Host...」をクリック。
前回、設定したホスト「192.168.99.100」を選択で。
仮想マシン側のVisual Studio Code が起動されたら、拡張機能の追加で。「Scala（Metals）」ってのをインストールします。
注意する点としては、
Make sure to disable the extensions Scala Language Server and Scala (sbt) if they are installed. The Dotty Language Server does not need to be disabled because the Metals and Dotty extensions don't conflict with each other.
GitHub - scalameta/metals-vscode: Visual Studio Code extension for Metals
「Scala Language Server」「Scala（sbt）」の拡張機能とバッティングしてしまうので、 「Scala（Metals）」を使う場合は、「Scala Language Server」「Scala（sbt）」の無効化が条件らしい。
再読み込みで。
とりあえず、Scala プロジェクト（「build.sbt」ファイルを含んだディレクトリ）を作成しなければいけないようです。
「表示(V)」>「ターミナル」で、コンテナにログインし、「/root/work」に移動し、sbt new でScalaプロジェクトのスケルトンを作成。
プロジェクト名を適当に入力します。今回は、hello で。
マウントしていたホストOS側のディレクトリからも見えてますね。
サーバ側のVisual Studio Codeのターミナルで、作成されたScalaプロジェクトのディレクトリ「/root/work/hello」に移動し、「sbt」とコマンドを入力。
sbt のシェルにログインされたら、「run」と入力。
無事、Scalaファイルが実行されました。
ということで、sbt シェルを終了。
実行されたScalaファイルは、「/root/work/hello/src/main/scala/example/Hello.scala」ですね。
⇧ Hello.scalaの内容は、トレイトを継承したオブジェクトですかね。
Scala を実施はできたんですが、ターミナルからではなく、Visual Studio Codeのエディターからアクセスしたかったですね...
というわけで、厳密には、Visual Studio Codeで、Scala 環境を作れたとは言い切れない感じですが、一応、Visual Studio Code内蔵のターミナルで動いたということで...許してちょんまげ。
Docker ToolBox で可能なのか、時間があるときに調査していきたいですね。今日もモヤモヤ感が満載ですな...
今回はこのへんで。
