我正在尝试使用 docker 将我们的 java web 应用程序部署到 aws elastic beanstalk,其想法是能够在本地运行容器以进行开发和测试,并最终使用 git 将其推送到生产环境。
我创建了一个安装了 tomcat8 和 java8 的基础镜像,执行 gradle 构建的镜像继承自这个基础镜像,加快了构建过程。
一切都很好,除了使用 docker 构建的继承应用程序容器似乎没有缓存 gradle 依赖项,它每次都会下载它,包括 gradlew。我们使用以下命令构建我们的 Web 应用程序:
./gradlew war
有什么方法可以缓存 ~/.gradle
中的文件,这将大大加快我的构建速度。
这在 beanstalk 上不是什么大问题,但对于尝试在本地构建和运行的开发人员来说是一个大问题,因为这确实需要很多时间,正如您可以想象的那样。
基础镜像dockerfile:
FROM phusion/baseimage
EXPOSE 8080
RUN apt-get update
RUN add-apt-repository ppa:webupd8team/java
RUN apt-get update
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections
RUN apt-get -y install oracle-java8-installer
RUN java -version
ENV TOMCAT_VERSION 8.0.9
RUN wget --quiet --no-cookies http://archive.apache.org/dist/tomcat/tomcat-8/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz -O /tmp/catalina.tar.gz
# Unpack
RUN tar xzf /tmp/catalina.tar.gz -C /opt
RUN mv /opt/apache-tomcat-${TOMCAT_VERSION} /opt/tomcat
RUN ln -s /opt/tomcat/logs /var/log/tomcat
RUN rm /tmp/catalina.tar.gz
# Remove unneeded apps
RUN rm -rf /opt/tomcat/webapps/examples
RUN rm -rf /opt/tomcat/webapps/docs
RUN rm -rf /opt/tomcat/webapps/ROOT
ENV CATALINA_HOME /opt/tomcat
ENV PATH $PATH:$CATALINA_HOME/bin
ENV CATALINA_OPTS $PARAM1
# Start Tomcat
CMD ["/opt/tomcat/bin/catalina.sh", "run"]
应用程序dockerfile:
FROM <tag name here for base image>
RUN mkdir ~/.gradle
# run some extra stuff here to add things to gradle.properties file
# Add project Source
ADD . /var/app/myapp
# Compile and Deploy Application, this is what is downloading gradlew and all the maven dependencies every time, if only there was a way to take the changes it makes to ~/.gradle and persist it as a cache layer
RUN cd /var/app/myapp/ && ./gradlew war
RUN mv /var/app/myapp/build/libs/myapp.war /opt/tomcat/webapps/ROOT.war
# Start Tomcat
CMD ["/opt/tomcat/bin/catalina.sh", "run"]
最佳答案
我遇到了这个问题。正如您可能同意的那样,在构建 docker 镜像时单独下载依赖项是一个单独的步骤,这是一个最佳实践。使用 gradle 变得有点棘手,因为没有直接支持仅下载依赖项。
选项 1:使用 docker-gradle Docker 镜像
我们可以使用预先构建的 gradle docker 镜像来构建应用程序。这确保它不是本地系统构建,而是在干净的 docker 镜像上完成的构建。
docker volume create --name gradle-cache
docker run --rm -v gradle-cache:/home/gradle/.gradle -v "$PWD":/home/gradle/project -w /home/gradle/project gradle:4.7.0-jdk8-alpine gradle build
ls -ltrh ./build/libs
- gradle 缓存在这里作为一个卷加载。因此后续构建将重用下载的依赖项。
- 在此之后,我们可以有一个 Dockerfile 来获取这个工件并生成应用程序特定的镜像来运行应用程序。
- 这样,构建器图像就不是必需的。应用程序构建流程和应用程序运行流程分开。
- 由于挂载了 gradle-cache 卷,我们可以在不同的 gradle 项目中重复使用下载的依赖项。
选项 2:多阶段构建
-- Dockerfile -----
FROM openjdk:8 AS TEMP_BUILD_IMAGE
ENV APP_HOME=/usr/app/
WORKDIR $APP_HOME
COPY build.gradle settings.gradle gradlew $APP_HOME
COPY gradle $APP_HOME/gradle
RUN ./gradlew build || return 0
COPY . .
RUN ./gradlew build
FROM openjdk:8
ENV ARTIFACT_NAME=your-application.jar
ENV APP_HOME=/usr/app/
WORKDIR $APP_HOME
COPY --from=TEMP_BUILD_IMAGE $APP_HOME/build/libs/$ARTIFACT_NAME .
EXPOSE 8080
CMD ["java","-jar",$ARTIFACT_NAME]
在上面的 Dockerfile 中
- 首先我们尝试单独复制项目的 gradle 文件,例如 build.gradle、gradlew 等,
- 然后我们复制 gradle 目录本身
- 然后我们尝试运行构建。在这一点上,没有其他 源代码文件存在于目录中。所以构建会失败。但 在此之前它将下载依赖项。
- 由于我们期望 构建失败,我尝试了一种简单的技术来返回 0 并允许 docker 继续执行
- 这将加快后续构建流程,因为所有依赖项都已下载并且 docker 缓存了这一层。相比之下,卷挂载 gradle 缓存目录仍然是最好的方法。
- 以上示例还展示了 multi-stage docker image构建,它避免了多个 docker 构建文件。
关于java - Docker 缓存 gradle 依赖项,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25873971/