GitLab CI/CD如何集成npm、Gradle、Docker完成项目构建部署

services挂载node、gradle镜像失效原因 #

GitLab CI的services机制仅用于启动常驻后台的附属服务（如数据库、缓存、Docker-in-Docker等提供网络访问能力的服务），无法用于提供命令行工具：

• Job主容器与service容器为完全独立的运行环境，仅网络层面互通，文件系统、环境变量、PATH路径完全隔离
• 在主镜像ubuntu:jammy内执行npm、gradle命令时，系统不会跨容器查找可执行文件，必然报命令不存在错误

自定义镜像命令找不到的原因 #

自定义镜像的问题出在环境变量加载逻辑：

• nvm、sdkman均通过写入~/.bashrc的初始化脚本，仅在交互式/登录shell启动时才会将自身路径加入PATH
• Dockerfile中配置的SHELL ["/bin/bash", "--login", "-i", "-c"]仅对构建阶段的RUN指令生效，GitLab CI执行作业脚本时默认使用非交互非登录shell，不会加载.bashrc内的配置，自然无法找到安装的命令
• Dockerfile中每个RUN指令为独立shell会话，前一个RUN中通过source加载的环境变量不会传递到后续步骤，也不会保留到容器启动后的运行环境

方案1：构建专用CI基础镜像（稳定性最高，CI执行速度快） #

不要使用nvm、sdkman这类依赖shell初始化的版本管理工具安装依赖，直接将官方编译好的二进制包解压到系统全局路径，彻底规避PATH加载问题，参考Dockerfile：

FROM ubuntu:jammy

LABEL key=DevOps

# 预装系统基础依赖
RUN apt update && apt upgrade -y && \
    apt install -y curl zip unzip ca-certificates git && \
    rm -rf /var/lib/apt/lists/*

# 安装Node.js 12.20.0：下载对应版本二进制包，解压到/usr/local全局路径
RUN curl -fsSL 对应版本Node二进制包地址 | tar -xJ -C /usr/local --strip-components=1

# 安装JDK8：下载对应版本JDK二进制包，解压到/opt目录
RUN curl -fsSL 对应版本JDK8二进制包地址 | tar -xz -C /opt/
ENV JAVA_HOME=/opt/jdk8u302-b08
ENV PATH=$JAVA_HOME/bin:$PATH

# 安装Gradle 6.3.0：下载对应版本Gradle压缩包，解压到/opt目录
RUN curl -fsSL 对应版本Gradle二进制包地址 -o gradle.zip && \
    unzip gradle.zip -d /opt/ && rm gradle.zip
ENV GRADLE_HOME=/opt/gradle-6.3
ENV PATH=$GRADLE_HOME/bin:$PATH

# 构建阶段验证工具安装正常
RUN node -v && npm -v && java -version && gradle -v

将该镜像构建完成后推送到私有镜像仓库，修改.gitlab-ci.yml中build阶段配置，移除无效的services配置：

build_project:
  stage: build
  image: 自定义构建镜像的私有仓库地址
  before_script:
    - git submodule init && git submodule update --remote --recursive
  script:
    - cd project-server && npm install && gradle clean build -Pprod -Pwar -x test -x integrationTest

方案2：多阶段构建整合流程（无需维护CI基础镜像） #

直接在项目Dockerfile中使用多阶段构建，依次复用官方node、gradle镜像完成构建，最终仅保留运行时需要的文件，完全符合Docker镜像设计理念，不会造成最终镜像体积冗余。这种方案下CI环境不需要预装npm、gradle，可直接移除原build阶段，将构建逻辑合并到镜像构建步骤中。
项目根目录Dockerfile参考结构：

# 依赖安装阶段
FROM node:12.20 AS node-builder
WORKDIR /build
COPY project-server/ ./
RUN npm install

# Gradle构建阶段
FROM gradle:6.3.0-jre8 AS gradle-builder
WORKDIR /build
COPY --from=node-builder /build ./
RUN gradle clean build -Pprod -Pwar -x test -x integrationTest

# 最终运行镜像阶段（根据实际业务需求选择运行时基础镜像）
FROM openjdk:8-jre-slim
WORKDIR /app
COPY --from=gradle-builder /build/build/libs/*.war ./app.war
EXPOSE 8080
CMD ["java", "-jar", "app.war"]

对应简化后的.gitlab-ci.yml配置：

variables:
  IMAGE_NAME: my.registry.production/project
  IMAGE_TAG: $CI_COMMIT_BRANCH
  GIT_SUBMODULE_STRATEGY: recursive

stages:
  - deploy

deploy_image:
  stage: deploy
  image: docker:20.10.17
  services:
    - name: docker:20.10.17-dind
      alias: docker
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
    DOCKER_DRIVER: overlay2
  before_script:
    - git submodule init && git submodule update --remote --recursive
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD my.registry.production
    - docker build -t $IMAGE_NAME:$IMAGE_TAG .
    - docker push $IMAGE_NAME:$IMAGE_TAG

• 禁止使用services机制运行命令行类工具，该机制从设计上不支持这种用法
• 制作CI基础镜像时优先使用全局安装二进制的方式部署工具，避免依赖shell初始化脚本加载环境变量，减少CI环境异常
• 多阶段构建是Docker官方推荐的标准构建方式，构建阶段依赖的工具链不会进入最终运行镜像，不存在违反镜像设计理念的问题

内容的提问来源于stack exchange，提问作者Lord M