Buildpacks + SpringBoot:Docker 镜像的端口和配置问题

Pat*_*Pat 5 java spring-data buildpack docker spring-boot

关于将 SpringBoot 项目的构建 Docker 映像从 Dockerfile 迁移到 BuildPacks 的小问题。

我有一个非常简单的 SpringBoot 应用程序,需要容器化。为此,我有一个非常简单的 Dockerfile:

FROM my-custom-java-base-image

RUN install -d -o some-user -g some-user /var/log/supervisor
RUN chmod -R 755 /usr/local/some-user/

EXPOSE 9999
Run Code Online (Sandbox Code Playgroud)

请注意,在这个 Dockerfile 中,有一个自定义的 java 基础镜像,需要运行一些 RUN 命令(以及运行一些其他命令),并公开一个自定义端口,而不是通常的 8080。

这个图像构建得很好,一切都与它配合,非常高兴。

现在,从 SpringBoot 2.3 开始,有了 Buildpacks 集成的新功能,人们可以简单地运行./mvnw spring-boot:build-image并构建一个非常漂亮的分层 Docker 镜像。

这个 Layered Docker 镜像确实非常酷。热门会议上的许多演讲都展示了这种构建图像的新方法的好处:

参考:

https://www.youtube.com/watch?v=44n_MtsggnI

https://www.youtube.com/watch?v=EVHHyiypiY0

然而,在我在网上找到的所有演示中,最初的 Dockerfile 非常简陋,没有自定义端口,没有自定义命令,好像只能用于基本功能

FROM alpine
WORKDIR /tmp
COPY target/myapp.jar myapp.jar
ENTRYPOINT [java -jar blablabla]
Run Code Online (Sandbox Code Playgroud)

到目前为止我尝试的是在插件配置中找到一种从 Dockerfile 中配置我需要的东西的方法

<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <!-- Configuration to push the image to our own Dockerhub repository-->
                <configuration>
                    <image>
                        <name>docker.io/2013techsmarts/${project.artifactId}:latest</name>
                    </image>
some configuration for the port, some commands to run, etc
                </configuration>
            </plugin>
        </plugins>
    </build>
Run Code Online (Sandbox Code Playgroud)

但没有运气。

大家都在谈论的这种构建镜像的新方法只适用于非常基本的 Dockerfile 吗?

使用 Buildpack 时如何更改端口、基础映像、添加我自己的命令等?

谢谢

Dan*_*usa 4

尝试挑选并回答您的问题,如果我遗漏了什么,请告诉我。

  1. 您通常不需要设置入口点。Buildpack 将自动检测并为您设置正确的包。这应该适用于 99% 的 Spring Boot 应用程序。它也比标准 Docker 更加灵活ENTRYPOINT,请参阅有关启动容器的文档。如果您仍然觉得需要设置一个入口点,则必须提供有关原因以及您想要做什么的更多信息(可能对新问题有好处)。

  2. 构建包中没有类似的东西EXPOSE,但它并不像你想象的那么重要。EXPOSE 只是设置元数据

    EXPOSE指令实际上并不发布端口。它充当构建映像的人员和运行容器的人员之间的一种文档,有关要发布哪些端口。

    如果没有EXPOSE,您将无法运行docker run -P,但您仍然可以运行docker run -p port:port并且它的工作原理是一样的。

    如果您需要记录端口信息(基本上就是这样)EXPOSE,您可以添加带有端口信息的标签。Buildpack 支持在生成的图像上设置任意标签

  3. 回答:

    大家都在谈论的这种构建镜像的新方法只适用于非常基本的 Dockerfile 吗?

    不会。Dockerfile 是构建镜像的通用方法,适用于许多不同的情况。Buildpack 不会尝试针对每个用例替换 Dockerfile。buildpack 的目标区域是将应用程序打包到容器映像中。如果您使用 Docker 或 Kubernetes 或其他一些容器编排器进行部署,那么 Buildpack 应该非常适合您。

  4. 回答:

    我如何更改基本图像

    使用构建包,您将拥有一个基本构建映像和一个基本运行映像。基础构建镜像是构建包运行和应用程序编译时使用的基础容器镜像。基本运行映像是应用程序执行时使用的映像。构建通常比基础更大,因为那里有更多的开发工具和库。

    You can change both. To change the build image, you must change the builder. That is the <builder> tag in your Spring Boot build tools configuration or the -B flag for pack build. The builder contains the base build image plus all of the buildpacks. It also has metadata to indicate the run image that pairs with the build image. If you make a custom builder image, you can control all of those things in as much detail as you want, you just need to ensure that the buildpacks you're using are compatible with the build and run image you create. Instructions for creating a builder can be found here.

    If you only need to change the run image, that can be done a little easier. You can set the <runImage> config setting in your Spring Boot build tools and it'll override the run image suggested by the builder.

    You need to be careful when doing this because you need to ensure that the application built with the build image will run on the run image you specify. The two are usually paired so that any libraries necessary to run the application are present at runtime. For Java apps, this is generally easy since there are not a lot of system dependencies. However, you could not set the run image to scratch because the JVM does have a couple of system dependencies.

    You might be thinking, "how would I create these images?" and the answer is a Dockerfile. As mentioned before, Buildpacks are not attempting to completely replace Dockerfiles, just make certain use cases easier. This is a use case, making base images, where Dockerfiles work fine, so you can docker build your own base builder and run images. See here for more detailed instructions.

    The process to create your own build/run images is not technically difficult or time consuming, but it does require automation because you must keep those images up-to-date so you are getting relevant security fixes.

    Having said all that, you may not need to create custom images. I don't know what you're specific needs are here, so I would encourage you to take a look at this SO post, which has some possible ways to customize the container images generated by Spring Boot.

    I would also suggest that you try to take a step back and rethink the problem you have to solve. It is often the case that converting a Dockerfile to Buildpacks can be more complicated and produce awkward results because you're trying to reimplement your Dockerfile solution to the problem. If you instead think about how you could solve the actual problem using Buildpacks, you might come out with a more elegant solution.