VSCodeのDev ContainerとRemote Development
104名前が似ている以下の2つを比較
DevContainer
元々はRemote Containerという名前だった。
拡張機能の説明を要約すると以下の通り。
- Dev ContainerとはDockerコンテナ内の環境を開発環境として利用するためのプラグインである。
- Dockerコンテナを開発環境として扱うことにより、チームメンバー間や開発・本番環境で一貫性を保つことができる。
Remote Development
拡張機能の説明を要約すると以下の通り。
- Remote Containerとはコンテナやリモートマシン、WSL内の任意のフォルダを開いてVSCodeの機能を利用することができる。つまりリモート環境での開発ができる。
- リモート環境での開発が実現することによって、ローカルマシンにソースコードを置く必要がなくなったり、ローカルマシンよりも高いスペックの別マシンでソースコードを実行できる。
- この拡張機能をインストールすると以下の4つが含まれる。
- Remote - SSH - SSH を使用してリモート マシン/VM 上のフォルダーを開いて、任意の場所にあるソース コードを操作する。
- Remote - Tunnels - SSH の代わりにVS Code トンネルを使用してリモート マシン/VM 上のフォルダーを開いて、任意の場所にあるソース コードを操作する。
- Dev Containers - コンテナ内またはコンテナ内にマウントされているフォルダを開いて、別のツールチェーンまたはコンテナ ベースのアプリケーションを操作する。
- WSL - inux 用 Windows サブシステム内の任意のフォルダーを開いて、Windows の快適さから Linux を活用した開発エクスペリエンスを実現する。
つまり、Dev ContainerはRemote Developmentの1手法であり、開発環境をセットアップしたコンテナに接続を行うことによってローカルと開発環境を分離する。
104DevContainerを使う
- 手元で作成したDockerイメージを作成することもできるが、MicrosoftがDevContainer用に用意したいくつかのイメージからセットアップすることもできるので今回はその方法を取る。
コマンドパレットからDevContainerのコマンドを立ち上げる
F1キーを押すとコマンドパレットが立ち上がり、「dev container configuration file」まで入力して設定ファイルの新規作成項目をあぶり出す。
「Add Development Container Configuration Files...」をクリックすると以下のように設定ファイルに関するオプションをいくつか聞かれる。
最初に定義された構成のうちどれを使用するか聞かれるのでJavaを選択。
Javaのプロジェクトを開いている場合はおそらく選択肢の中にJavaが表示される。
Javaが選択肢にないときは「すべての定義を表示」を開いて辿っていけばJavaを見つけられる。
次にJavaのバージョンを選択。今回は現時点のLTSで最新の21-bullseyeを選択。
今回はGradleのプロジェクトを用意したので、2つ目の選択肢を選ぶ。
イメージに追加する機能を聞かれるが、今回は特にないのでそのまま「OK」。
このような画面が新しく開けばDevContainerで開けている。
HelloWorldのサンプルコードをビルドする
まずプロジェクトにsrc/main/javaの階層でディレクトリを作成し、HelloWorld.javaを以下のように作成。
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
次にgradleで上記ソースをビルド〜実行する。
Javaプログラムを実行する方法の1つとして、ビルドしたソースを.jar形式のファイルとしてアウトプットしてそれをjavaコマンドで直接指定して実行する方法がある。
gradleでビルドを行う場合はあらかじめbuild.gradleというスクリプトファイルを定義しておく必要があるのだが、eclipceで新規gradleプロジェクトを作成したときには存在しないので手動で作成する。
plugins {
id 'java'
}
// JARファイルの作成
jar {
// マニフェストにメインクラスを指定
manifest {
attributes 'Main-Class': 'HelloWorld'
}
}
mavenがjava向けのビルドツールなのに対してGradleは必ずしもJava向けとは限らないので、そもそもjavaのプラグインを明示して使用する必要がある模様。
// Macの場合
./gradlew clean build
// windowsの場合
gradlew.bat clean build
build.gradleを保存したらプロジェクトルートでgradleのビルドコマンドを実行する。
先ほど構成ファイル作成時にgradleをインストールしたはずだが、結局インストールされていないのでローカルでgradleを実行。
ビルドに成功すると今回の構成の場合はbuild/libsディレクトリに{アプリケーション名}.jarファイルが作成される。
これをjavaコマンドで実行すると、、、
Hello World!が表示されるので、一旦VSCodeのDevContainerにJava開発環境を作成するミッションは成功したということになる。
dev container mkdir: cannot create directory ‘/home/vscode/.vscode-server’: No space left on device のエラーが発生する場合
docker system prune
を実行すれば解決するっぽい。
ビルドに失敗する場合
./gradlew build
・
・
・
Welcome to Gradle 8.1.1!
Here are the highlights of this release:
- Stable configuration cache
- Experimental Kotlin DSL assignment syntax
- Building with Java 20
For more details see https://docs.gradle.org/8.1.1/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Could not open cp_settings generic class cache for settings file '/workspaces/gradle_development/settings.gradle' (/home/vscode/.gradle/caches/8.1.1/scripts/1en43omyaxmkkiczjvbzrftux).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
上記のの場合はシンプルにJavaのバージョンがGradleの実行要件を満たしていない。
今回はEclipce内で空のGradleのプロジェクトを作成したが、依存するJavaのバージョンの設定等がなかったのでこのようなことになった。
gradle-wrapper.propertiesを開いてdistributionUrlを書き換えれば良い。
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.4-bin.zip // ここを8.1.1から8.4にした
networkTimeout=10000
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists