background

In our development process, in order to support Docker containerization, Maven is generally used to compile and package and then generate images, which can greatly provide online efficiency, fast dynamic expansion and fast rollback, which is really convenient. The Docker-Maven-plugin is designed to help us automatically generate images and push them to the repository through simple configuration in Maven project.

Generally, fabric8

  • There are two main plugins used here: Spotify, Fabric8,… – Configures a Dockerfile defined by XML or mounts an external Dockerfile to build an image by calling the Docker remote API

  • All containerization of the PIG microservices platform [1] is built on this basis



<plugin>

  <groupId>com.spotify</groupId>

  <artifactId>docker-maven-plugin</artifactId>

. - Configure to define dockerfiles through XML or to mount external dockerfiles

</plugin>





<plugin>

  <groupId>io.fabric8</groupId>

  <artifactId>docker-maven-plugin</artifactId>

. - Configure to define dockerfiles through XML or to mount external dockerfiles

</plugin>



Copy the code
  • Execute the corresponding plug-in cyclemvn docker:build && mvn docker:push

jib

  • The amount of code that the project actually changes in each release is small, especially the possibility of changing the jar that depends on is small. If the first two plug-ins are used to build the image, it will lead to the full build every time, resulting in the waste of storage and bandwidth resources.

  • Jib is a tool for building images for Java applications (supporting Maven and Gradle) released by Google in July, 2018. The advantage of JIB is that it can reuse the build cache, speed up the build and reduce the transfer volume

<! Dockerfile is defined in XML. It is essentially the same as Dockerfile.

<plugin>

    <groupId>com.google.cloud.tools</groupId>

    <artifactId>jib-maven-plugin</artifactId>

</plugin>



mvn jib:dockerBuild

Copy the code

The problem of the above three schemes

  • In actual development, most Spring Boot projects build dockerfiles the same way, and do not require XML or a plug-in to redefine the Dockerfile

  • The above plug-ins require a relative knowledge of the definition of Dockerfile which is not development-friendly

  • There is no good reason for Jar layering after Spring Boot 2.3.

The solution

  • Spring Boot 2.4[2]Launched its own Docker build tool integrated in the originalspring-boot-maven-plugin, you only need to configure the target warehouse and host information to complete image construction.

  • The following configuration can be completed through the development machine without installing Docker192.168.0.10Docker Remote API to complete the image build and publish to192.168.0.20Mirror warehouse
 <plugin>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-maven-plugin</artifactId>

    <configuration>

        <image>

            <name>192.168.0.20 / pig4cloud / ${project. ArtifactId}</name>

            <! Build automatic push -->

            <publish>true</publish>

        </image>

        <! -- Configure the build host information, do not configure the host -->

        <docker>

   <host>http://192.168.0.10:2375</host>

            <tlsVerify>false</tlsVerify>

            <publishRegistry>

                <username>username</username>

                <password>password</password>

                <url>192.168.0.20</url>

            </publishRegistry>

        </docker>

    </configuration>

</plugin>

Copy the code
  • Run the following command to build an image and release it automatically
mvn spring-boot:build-image

Copy the code

Other instructions

The docker host configuration does not take effect

  • In the following figure, nodes are configured. However, an error message is displayed indicating that hosts are inconsistent

  • Check whether the $DOCKER_HOST environment variable is configured locally.
⋊ > ~echo $DOCKER_HOST                                                  11:07:51

TCP: / / 172.17.0.111:2375

Copy the code

Network support

  • To intercept some logs during the build process, the following requires about 100 MB of dependencies to be downloaded from Github. This process is likely to fail. You are advised to configure a proxy or use a foreign ECS.
 :: Spring Boot ::                (v2.4.0)

[INFO]  > Running creator

[INFO]     [creator]         Downloading from https://github.com/bell-sw/Liberica/releases/download/8u275+1/bellsoft-jre8u275+1-linux-amd64.tar.gz

[INFO]     [creator]       JVMKill Agent 1.16.0: Contributing to layer

[INFO]     [creator]         Downloading from https://github.com/cloudfoundry/jvmkill/releases/download/v1.16.0.RELEASE/jvmkill-1.16.0-RELEASE.so

[INFO]     [creator]         Downloading from https://repo.spring.io/release/org/springframework/cloud/spring-cloud-bindings/1.6.0/spring-cloud-bindings-1.6.0.jar

[INFO]     [creator]         Verifying checksum

[the INFO] [creator] 192.168.0.20 / pig4cloud/demo: the latest

[INFO]

[INFO] Successfully built image 'latest' 192.168.0.20 / pig4cloud/demo.

[INFO]  > Pushing image 'latest' 192.168.0.20 / pig4cloud/demo. 100%

[INFO]  > Pushed image 'latest' 192.168.0.20 / pig4cloud/demo.

[INFO] BUILD SUCCESS

Copy the code

The resources

[1]

Pig micro service platform: https://gitee.com/log4j/pig


[2]

Spring Boot 2.4 Docker: https://docs.spring.io/spring-boot/docs/2.4.0/maven-plugin/reference/htmlsingle/#build-image-example-publish