I had to prepare the environment to touch Spring Boot in a hurry, so I summarized the procedure when I created it and a little thought.

0. Reference article

Docker × Spring Boot environment construction https://qiita.com/A-Kira/items/beaf79a0d39d9839e61e

I tried to execute it almost exactly like this, and there was a change value over time, so it is a lantern article that I added around it. I think it's better to read in parallel.

1. Author environment

Windows 10 Professional(20h4)
VSCode
Git Bash
Docker Desktop

I will omit the details around here (the original article was a Mac, but there should be no problem)

2. Create a file to create by yourself

Since there are many files that are automatically generated, only the files that are manually edited by breaking the original article will be taken up.

docker-compose.yml

`docker-compose.yml`


version: '3.8'
services:
  java:
    image: openjdk:15-slim
    ports:
      - 8080:8080
    tty: true
    volumes:
      - ./server:/srv:cached
    working_dir: /srv

If you write it first, the difference from the original article is --version 3.6 → 3.8 (almost no effect here) --Image version 14 → 15 (important)

As I will explain later, the version of initializr has changed from 14 to 15, so if you continue here as the original article, gradle will be moss.

For the time being, I personally added a follow-up saying that I confirmed that there is "openjdk: 15-slim" on docker hub and wrote it, and that it was not rewritten in the open (case game context). Put. https://hub.docker.com/r/amd64/openjdk/

Gradle project file

Like the original article, create it with spring initializr and expand it under [project directory]/server.

However, since the version is different from that time, only the difference.

-(As I wrote earlier) There is no 14 in Java's selection, and the latest is 15. --2.3.1 is missing in Spring Boot selection (2.4.1 is selected in this procedure)

For Dependencies, I chose "Spring Web" and "Lombok" as in the original article.

Changes to test run the project

Same as the original article, but for the time being. Edit server/src/main/java/com/example/api/ApiApplication.java as follows.

`ApiApplication.java`


package com.example.api;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class ApiApplication {

    @RequestMapping("/")
    public String home() {
        return "Hello World";
    }

    public static void main(String[] args) {
        SpringApplication.run(ApiApplication.class, args);
    }

}

3. Start Docker

It's exactly the same.

Build the Docker environment from the command line

% docker-compose build

Launch Docker in the background

% docker-compose up -d

4. Build Gradle

This is exactly the same.

Enter the Java container * Depending on the person, winpty may or may not be necessary

% winpty docker-compose exec java bash

gradle build (each person is different after root @. For the time being)

root@558036f3cbd0:/srv# sh gradlew build

As I wrote earlier, if you do not set Java in the container to 15, you will end up with a failure (1 loss) as shown below.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not target platform: 'Java SE 15' using tool chain: 'JDK 14 (14)'.

* 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.

* Get more help at https://help.gradle.org

BUILD FAILED in 53s
1 actionable task: 1 executed

5. Execution and operation check

Exactly the same here

root@558036f3cbd0:/srv# java -jar build/libs/api-0.0.1-SNAPSHOT.jar

When you access localhost: 8080, the home () you wrote earlier should be executed and "Hello World" should be displayed.

99. Impressions

Regardless of whether this article is necessary for the world, I think that it is a moderate engineer's power to be able to quickly solve the version difference of this time by itself while moss several times (Konami Kan).

However, I personally think that it is important to moss as expected, or to get the expected result by plunging uncorrected while anticipating that it will moss, so in the future a situation similar to this I think that those who step on it should try it in the same way.

Spring Boot environment construction with Docker (January 2021 version)