DEV Community

Cover image for Spring Boot Development Environment with Docker and VS Code
Leandro Boeing Vieira
Leandro Boeing Vieira

Posted on

Spring Boot Development Environment with Docker and VS Code

"It works on my machine."

If you're a developer, chances you've heard, and said, it at least once in your life are huge. There can be tons of reasons for that: your processor architecture, your operational system, your compiler version, may be different from your colleague's. Even worse scenario is when you deploy your applications in cloud environments and they crash. But how? It worked on my machine!

The old way

In a recent past, for Java projects - more specifically Spring Boot ones, I used to install sdkman and tried to arrange with the whole team to use the very same vendor and version of the JDK. Problem is, it depends on human actions to work. And humans can fail.

With that in mind, I'd like to introduce to you a whole new world: development of a Spring Boot application in Visual Studio Code and compile, test and run in a Docker container. I know you just turned up the nose about Java and VS Code, but trust me, it's gonna work and be worth it.

The new Era

So, no need for a JDK installed on your machine. But you'll need VS Code and Docker, of course. After you install them, open your VS Code. In the Extensions menu, search for "Remote - Containers" and install it:

Remote - Containers Extension

Then, head to Spring Initializr, scaffold a new project, download and extract the files on your machine:

Spring Boot Initializr

Remember to add Spring Web and Spring Boot DevTools.

Now, in your VS Code, open the Command Palette (usually Ctrl or Command + Shift + P) and type ">Remote-Containers: Open Folder in Container", select it and choose the location of your extracted Spring Boot application:

Open Folder in Container

Now, it's time to configure your development environment container.

Select "Java - Develop Java applications":

Java Image

Select your Java version, in my case, 11:

Java version

Select "Install Maven":

Install Maven

By now, your VS Code should have created a new folder in your project, called .devcontainer with a Dockerfile and devcontainer.json. You don't need to worry about them for now. Since this will be the first time your VS Code will run your application in a Docker container, it can take some time to download the images. Be patient. Once it is finished, you will be notified.

Select the Run menu, click on "Open a file" and navigate to your Main class, in my case HelloFromContainerApplication:

Alt Text

Now, if you click on the button "Run and Debug" it will run the application. Optionally, clicking on "No Configuration" and then "Add Configuration", VS Code will create a launch.json configuration file.

Finally, if you hit http://localhost:8080/ in your browser you will see that the application is up and running in Debug mode, perfect to install some breakpoints and start your awesome solution. And remember DevTools? Go ahead and add a new endpoint to your application. It will live-reload in the container as well.

Push config to Github?

Now comes the controversy part. Although it's recommended that you do not push specific IDE configuration files to your repository, I believe that if the whole team agrees to work in that manner, the .devcontainer could reside remotely. By doing this, you will mitigate the human failures and there will be no more "it works on my machine" excuses. Every environment, regardless of operational system, processor architecture or previous JDK installations, will behave similarly. This may even improve the speed of newcomers to the project for it will require less guidance and hit fewer issues related to environment setup.

Dockerfile for production environment

As a final hint, if you look closely to the Dockerfile created by VS Code inside .devcontainer folder, you will see a comment like:

// See here for image contents:

This can be your guidance to creating your own Dockerfile, based on your local working environment. In this case, the Java image being used is the openjdk:11-jdk-buster and I would most likely want to use the same in production.

Top comments (0)