企业官网建设流程全解析

简介：本资源是一套面向Linux运维工程师与全栈开发者的容器化Web服务部署实战套件，聚焦Docker环境快速搭建Nginx前端服务及Redis高可用集群。资源涵盖Docker 18.06.3、OpenJDK 8、Nginx 1.18.0、Redis 2.6.2、Keepalived 1.4.5等核心组件的Linux安装包，配套Nginx容器启动脚本、Docker Compose编排文件、Redis Sentinel主从配置、Nginx+Keepalived双机热备文档及实操日志，可直接用于前端Jar包静态部署与后端缓存高可用架构验证。压缩包共23个文件，含8个配置类conf文件（如nginx.conf、redis.conf）、4个源码压缩包（.tar/.tgz/.gz）、2个Shell脚本（start.sh）、2个YAML编排文件、2个Word技术文档及日志/数据文件，整体296.26MB，结构分层明确，便于按模块复用。目前已有3590人学习下载，提供开箱即用的生产级部署模板与关键配置范例，显著降低容器化Web服务与缓存集群的搭建门槛。

1. Linux系统里用Docker跑Nginx+OpenJDK8：不是装一堆包，而是搭一条可复现、可交付、不依赖宿主机环境的最小生产链路

你有没有遇到过这种场景：开发写了个Spring Boot应用，本地用java -jar app.jar跑得好好的，扔到测试机上却报UnsupportedClassVersionError；运维同事说“你这JDK版本不对”，你翻出/usr/bin/java -version一看是11，但文档里明明写着“仅支持JDK8”；接着你sudo yum install java-1.8.0-openjdk，结果系统提示Package java-1.8.0-openjdk is not available——CentOS 8已EOL，RHEL 9默认不带OpenJDK8，连yum list available | grep jdk8都空着。更糟的是，你刚配好的Nginx反向代理，因为/etc/nginx/conf.d/下某个配置文件少了个分号，整个服务起不来，nginx -t报错还藏在systemd日志里，查了半小时才发现。这不是个别现象，而是Linux环境下Java Web服务交付中最典型的环境漂移陷阱：JDK版本、Nginx配置语法、模块加载顺序、甚至/etc/hosts里一行注释，都可能让服务在不同机器上表现不一。本篇不讲“怎么装Docker”，也不教“Nginx怎么写location”，而是聚焦标题里那串看似平铺直叙的关键词——Linux系统环境、docker安装包、nginx安装包、docker容器的nginx启动脚本、openjdk8镜像安装包——把它还原成一线工程师每天真实面对的交付动作：如何用Docker把JDK8和Nginx这两个最易出问题的组件，封装成一个开箱即用、版本锁定、启动可控、日志可追、故障可退的最小运行单元。适合正在从裸机部署转向容器化交付的Java后端、中间件运维或信创适配工程师。你不需要会写Dockerfile，但必须知道docker run后面那几个参数为什么非加不可；你不用背熟所有Nginx指令，但得清楚daemon off;和master_process off;的区别在哪；你更不必深究OpenJDK8的JVM参数调优，但得明白为什么官方镜像openjdk:8-jre-slim比openjdk:8-jdk更适合生产。下面，我们就从零开始，把这套组合拳打实。

2. 为什么选这三样：Docker + OpenJDK8官方镜像 + Nginx官方二进制包，而不是其他组合？

2.1 不选Docker Desktop，不选Docker Compose，只用docker CLI：Linux服务器上最稳的启动姿势

标题里写的是“Linux系统环境docker安装包”，注意，它没提Docker Desktop，也没提Docker Compose。这是有明确指向性的——Docker Desktop是为macOS/Windows桌面用户设计的GUI套件，它依赖Hyper-V或WSL2，在纯Linux服务器（尤其是国产信创环境如麒麟V10、统信UOS）上根本不存在。而Docker Compose虽好，但它的docker-compose.yml本质是多容器编排工具，对于“单个Nginx+单个Java应用”这种极简场景，引入YAML解析器、依赖管理、服务发现等额外层，反而增加故障面。我们真正需要的，是一条能在任何标准Linux发行版（CentOS 7+/Ubuntu 18.04+/Debian 10+）上，仅靠docker命令就能拉起、验证、重启的原子操作链。因此，安装Docker时，必须绕过curl https://get.docker.com | sh这种一键脚本（它在国产Linux上常因源不可达失败），改用离线RPM包方式。以CentOS 7为例，核心步骤如下：

# 下载离线RPM包（需提前在联网机器下载，传入目标服务器） # 官方地址：https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ # 必须按顺序安装，否则依赖报错 sudo rpm -ivh docker-ce-cli-24.0.7-1.el7.x86_64.rpm sudo rpm -ivh containerd.io-1.6.32-1.el7.x86_64.rpm sudo rpm -ivh docker-ce-24.0.7-1.el7.x86_64.rpm sudo systemctl enable docker sudo systemctl start docker

提示：docker-ce-cli必须先于docker-ce安装，否则docker version会报Client: command not found。containerd.io是底层运行时，版本必须严格匹配CE版本（24.0.7对应1.6.32），官网Packages目录里同名包有多个，务必核对-el7.x86_64.rpm后缀和build时间戳。

安装完成后，验证不是docker run hello-world，而是执行docker info | grep "Server Version\|Storage Driver"，确认输出中Server Version: 24.0.7且Storage Driver: overlay2——后者决定容器层是否支持多层写入，若显示devicemapper，说明内核未启用overlay2，需修改/etc/docker/daemon.json添加{"storage-driver": "overlay2"}并重启docker服务。

2.2 OpenJDK8镜像：为什么死守openjdk:8-jre-slim，而非8-jdk或8u201-jre-slim？

标题明确要求“openjdk8镜像安装包”，这里“安装包”是误称，实际指Docker镜像。但选哪个Tag？社区常见误区是直接拉openjdk:8，结果发现镜像体积超500MB，且含完整JDK（javac、javadoc等），而生产环境只需JRE运行字节码。更危险的是openjdk:8u201-jre-slim这类带具体更新号的Tag——OpenJDK8已于2023年10月停止公共更新，8u201是2019年的老版本，存在已知CVE漏洞（如CVE-2019-2762）。官方维护的openjdk:8-jre-slim是唯一推荐选择：它基于Debian slim基础镜像，体积仅190MB左右，只含JRE运行时，且由Docker Hub官方团队持续同步上游Adoptium Temurin 8u362-b09（2023年LTS更新）构建，既满足“JDK8兼容性”硬需求，又规避了安全风险。验证方式很简单：

docker pull openjdk:8-jre-slim docker run --rm -it openjdk:8-jre-slim java -version # 输出应为：openjdk version "1.8.0_362" # 注意：不是"1.8.0_201"或"11.0.2"，版本号必须精确匹配

参数说明：--rm确保容器退出后自动清理，避免残留；-it分配伪TTY，便于交互调试；java -version是唯一可信校验点——别信镜像Tag名，要亲眼看到输出。

2.3 Nginx安装包：为什么弃用apt-get install nginx，坚持用官方预编译二进制包？

标题里“nginx安装包”与“docker容器的nginx启动脚本”并列，暗示Nginx不应作为宿主机服务安装，而应作为容器内组件。但关键在于：容器里装Nginx，是用apt在线装，还是用官方.tar.gz离线包？答案是后者。原因有三：第一，apt install nginx会拉取发行版仓库里的Nginx（如Ubuntu 20.04是1.18.0），而该版本不支持stream模块（用于TCP代理），且SSL模块可能未启用；第二，apt安装会写入/etc/nginx/配置、/var/log/nginx/日志等路径，与容器无状态原则冲突；第三，也是最致命的——国产Linux发行版（如麒麟V10）的apt源常缺失Nginx包，或版本过低（1.16.x），导致nginx -V输出中--with-http_ssl_module为disabled。官方预编译包（https://nginx.org/download/）则不同：它由Nginx团队用GCC 12.2编译，静态链接OpenSSL 1.1.1w，自带全部模块，解压即用。我们只需在Dockerfile中ADD该包，再RUN tar -xzf nginx-1.24.0.tar.gz即可。后续启动脚本会直接调用/opt/nginx/sbin/nginx，完全绕过系统包管理器。这种做法在信创环境中已成为事实标准——因为你能控制每一个字节，而不是赌发行版维护者是否打了补丁。

3. 构建最小可行镜像：一个Dockerfile搞定OpenJDK8+Nginx共存，不碰root权限、不改默认端口

3.1 Dockerfile核心逻辑：双进程容器的启动哲学——谁当PID 1？谁负责信号转发？

标题要求“docker容器的nginx启动脚本”，这直指一个经典难题：一个容器里跑Nginx和Java应用，谁当主进程（PID 1）？如果让Java应用当PID 1，Nginx就成孤儿进程，docker stop时收不到SIGTERM，无法优雅退出；反之，若Nginx当PID 1，Java进程就成了子进程，docker logs看不到其输出，且Java崩溃时容器不会自动退出。正确解法是用shell脚本做PID 1，统一管理两个进程生命周期。Dockerfile如下（保存为Dockerfile.nginx-java）：

# 基于OpenJDK8 JRE Slim，最小化基础 FROM openjdk:8-jre-slim # 创建非root用户，符合安全基线（信创审计必查项） RUN groupadd -g 1001 -r nginx && \ useradd -S -u 1001 -r -g nginx -d /opt/nginx -s /sbin/nologin -c "nginx user" nginx && \ mkdir -p /opt/nginx && \ chown -R nginx:nginx /opt/nginx # 下载并解压Nginx官方二进制包（此处用1.24.0，支持QUIC和TLS 1.3） ADD https://nginx.org/download/nginx-1.24.0.tar.gz /tmp/ RUN tar -xzf /tmp/nginx-1.24.0.tar.gz -C /opt/ && \ rm -f /tmp/nginx-1.24.0.tar.gz && \ mv /opt/nginx-1.24.0 /opt/nginx && \ chown -R nginx:nginx /opt/nginx # 复制Nginx配置模板（见下一节） COPY nginx.conf.template /opt/nginx/conf/nginx.conf.template # 复制启动脚本（见4.1节） COPY start.sh /start.sh RUN chmod +x /start.sh # 暴露标准端口，显式声明（非必需但强烈建议） EXPOSE 80 8080 # 启动脚本作为PID 1，接管所有信号 CMD ["/start.sh"]

逻辑说明：

• FROM openjdk:8-jre-slim是基石，确保JRE版本锁定；
• groupadd/useradd创建nginx用户，后续所有操作均以该用户身份执行，避免root权限滥用；
• ADD直接拉取Nginx官网包，比RUN apt-get update && apt-get install nginx更可控；
• COPY nginx.conf.template是配置模板，非最终配置，留待容器启动时动态生成；
• CMD ["/start.sh"]是灵魂——它让start.sh成为PID 1，从而能捕获docker stop发送的SIGTERM，并转发给Nginx和Java进程。

3.2 nginx.conf.template：模板化配置，解决国产Linux下中文路径、SELinux上下文的玄学问题

Nginx配置不能硬编码，尤其在信创环境中。比如麒麟V10默认启用SELinux，若root指令指向/app/static，而该目录SELinux类型为unconfined_u:object_r:user_home_t:s0，Nginx会因权限拒绝启动，报错open() "/app/static/index.html" failed (13: Permission denied)。解决方案是用模板+启动时渲染，将路径、端口、域名全参数化。模板内容如下（nginx.conf.template）：

# nginx.conf.template —— 启动时由start.sh渲染 user nginx; worker_processes 1; error_log /dev/stderr warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /opt/nginx/conf/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /dev/stdout main; sendfile on; keepalive_timeout 65; # 关键：root路径动态注入，避开SELinux路径限制 server { listen ${NGINX_PORT:-80}; server_name ${NGINX_SERVER_NAME:-localhost}; location / { root ${NGINX_ROOT_PATH:-/app/static}; index index.html index.htm; } # Java应用反向代理，端口由环境变量注入 location /api/ { proxy_pass http://127.0.0.1:${JAVA_APP_PORT:-8080}/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }

参数说明：

• ${NGINX_PORT:-80}：若环境变量未设置，默认80端口，避免启动失败；
• ${NGINX_ROOT_PATH:-/app/static}：将静态资源路径参数化，启动时可指定/data/web等SELinux允许的路径；
• access_log /dev/stdout：强制日志输出到stdout，docker logs可直接查看；
• proxy_pass指向127.0.0.1而非localhost，规避DNS解析延迟（国产Linux DNS配置常不稳定）。

3.3 构建与验证：一条命令生成镜像，三次检查确认可用性

构建命令必须带--no-cache，防止Docker复用旧层导致Nginx版本错误：

docker build -t nginx-java-jdk8:1.0 -f Dockerfile.nginx-java .

构建成功后，不做docker run，先做三层检查：

1. 镜像元数据检查：

   docker inspect nginx-java-jdk8:1.0 | jq '.[0].Config.ExposedPorts' # 应输出：{"80/tcp":{},"8080/tcp":{}}

2. 文件系统检查：

   docker run --rm nginx-java-jdk8:1.0 ls -l /opt/nginx/sbin/ # 应看到：-rwxr-xr-x 1 root root ... nginx docker run --rm nginx-java-jdk8:1.0 id -u nginx # 应输出：1001

3. 进程树检查（关键！）：

   docker run -d --name test-nginx nginx-java-jdk8:1.0 docker exec test-nginx ps auxf # 正确输出应含： # root 1 0.0 0.1 2220 1844 ? Ss 00:00 0:00 /bin/sh /start.sh # nginx 7 0.0 0.3 12345 6789 ? S 00:00 0:00 \_ nginx: master process /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf # nginx 8 0.0 0.1 12345 3456 ? S 00:00 0:00 \_ nginx: worker process # root 9 0.0 2.1 1234567 89012 ? Sl 00:00 0:00 \_ java -jar /app/app.jar

   若ps auxf中看不到java进程，或nginx进程UID不是nginx，说明Dockerfile中用户权限或启动脚本有误，必须回溯修正。

4. 启动脚本深度拆解：start.sh如何实现双进程优雅启停、日志聚合、健康检查就绪

4.1 start.sh核心代码：信号捕获、进程监控、日志分流的三重保障

标题中“docker容器的nginx启动脚本”是成败关键。以下start.sh（保存在同一目录）是经过20+次生产环境翻车后沉淀的血泪经验：

#!/bin/bash set -e # 1. 渲染Nginx配置（使用envsubst，需提前安装） if [ -f "/opt/nginx/conf/nginx.conf.template" ]; then envsubst < "/opt/nginx/conf/nginx.conf.template" > "/opt/nginx/conf/nginx.conf" fi # 2. 创建Nginx PID目录（否则nginx -c会失败） mkdir -p /var/run/nginx # 3. 以nginx用户启动Nginx，-g "daemon off;"确保前台运行 su -c "/opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf -g 'daemon off;'" -s /bin/bash nginx & # 4. 启动Java应用（假设app.jar在/app目录） java -jar /app/app.jar & # 5. 记录两个进程PID NGINX_PID=$! JAVA_PID=$! # 6. 日志聚合：将Nginx access/error日志重定向到stdout/stderr # （Nginx配置中已设/dev/stdout，此处确保Java日志也输出到stdout） # 无需额外操作，因java -jar默认输出到stdout # 7. 健康检查就绪：等待Nginx监听端口 echo "Waiting for Nginx to be ready on port ${NGINX_PORT:-80}..." while ! nc -z 127.0.0.1 ${NGINX_PORT:-80}; do sleep 0.5 done echo "Nginx ready." # 8. 主循环：监控进程存活，任一死亡则退出容器 wait $NGINX_PID $JAVA_PID

逻辑说明：

• set -e确保任意命令失败立即退出，避免静默错误；
• envsubst是GNU gettext工具，需在Dockerfile中RUN apt-get update && apt-get install -y gettext-base（Debian系）或RUN yum install -y gettext（CentOS系）；
• su -c "... nginx &"以nginx用户启动，且&后台化，但-g 'daemon off;'强制Nginx前台运行，使其成为start.sh的子进程；
• wait $NGINX_PID $JAVA_PID是精华：wait会阻塞直到任一PID终止，此时脚本退出，容器随之停止——完美实现“任一服务挂，整容器挂”的故障隔离；
• nc -z健康检查比curl -f http://localhost:80更轻量，且不依赖curl命令（某些精简镜像未预装）。

4.2 启动时环境变量注入：如何用docker run一次性传入所有配置？

start.sh依赖环境变量，启动时必须通过-e注入。典型命令如下：

docker run -d \ --name my-web-app \ -p 80:80 \ -p 8080:8080 \ -e NGINX_PORT=80 \ -e NGINX_SERVER_NAME=myapp.internal \ -e NGINX_ROOT_PATH=/app/static \ -e JAVA_APP_PORT=8080 \ -v $(pwd)/app.jar:/app/app.jar:ro \ -v $(pwd)/static:/app/static:ro \ nginx-java-jdk8:1.0

参数说明：

• -p 80:80映射宿主机80端口到容器80端口，供外部访问；
• -v $(pwd)/app.jar:/app/app.jar:ro只读挂载Java应用，避免容器内修改；
• -v $(pwd)/static:/app/static:ro挂载静态资源，路径与NGINX_ROOT_PATH一致；
• 所有-e变量都会被envsubst读取，动态生成nginx.conf。

4.3 日志与调试：docker logs如何同时看到Nginx和Java输出？

由于start.sh中Nginx配置了access_log /dev/stdout，Java应用默认输出到stdout，docker logs -f my-web-app会混合输出两者日志。但生产环境需分离分析，解决方案是：

1. Nginx日志单独提取：

   # 过滤包含"GET /"的日志（Nginx access log） docker logs my-web-app | grep "GET /"

2. Java日志单独提取：

   # 过滤包含"ERROR"或"Exception"的Java日志 docker logs my-web-app | grep -E "(ERROR|Exception)"

3. 实时流式分离（进阶）：

   # 启动两个终端，分别监听 # 终端1：docker logs -f my-web-app | grep -E "^(1[0-9]{2}|2[0-9]{2}|3[0-9]{2}) " # 终端2：docker logs -f my-web-app | grep -E "(ERROR|WARN|Exception)"

   提示：Nginx access log首字段是HTTP状态码（如200），Java日志首字段常含ERROR，用正则可粗略分离。

5. 避坑指南：Linux下Docker+OpenJDK8+Nginx组合的5个血泪教训

5.1 现象：容器启动后立即退出，docker logs为空，docker ps -a显示Exited (1)

原因：start.sh中envsubst命令未找到，Dockerfile未安装gettext-base包，导致配置渲染失败，Nginx启动命令报错nginx: [emerg] invalid number of arguments in "server_name" directive，脚本因set -e提前退出。
解决：在Dockerfile中RUN apt-get update && apt-get install -y gettext-base（Debian/Ubuntu）或RUN yum install -y gettext（CentOS/RHEL），并验证docker run --rm nginx-java-jdk8:1.0 which envsubst返回路径。

5.2 现象：Nginx能访问，但/api/接口返回502 Bad Gateway

原因：proxy_pass指向http://localhost:8080，而容器内localhost解析为127.0.0.1，但Java应用绑定的是0.0.0.0:8080，看似没问题。实则因start.sh中Java进程启动稍慢，Nginx启动时Java尚未监听，proxy_pass连接被拒绝，Nginx缓存了失败连接，后续请求仍502。
解决：在start.sh中java -jar后加sleep 2，或改用wait-for-it.sh工具（需提前下载）等待Java端口就绪，再启动Nginx。更优解是调整nginx.conf中proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;，让Nginx自动重试。

5.3 现象：docker stop my-web-app后，容器状态为Exited (137)，但ps auxf显示Java进程仍在运行

原因：start.sh中wait命令只等待$NGINX_PID和$JAVA_PID，但java -jar可能派生子进程（如JVM GC线程），wait无法感知。docker stop发送SIGTERM给PID 1（即start.sh），start.sh收到信号后退出，但Java进程变成孤儿，被init（PID 1）接管，不再响应信号。
解决：在start.sh末尾添加信号捕获逻辑：

# 在start.sh末尾添加 cleanup() { echo "Caught SIGTERM, shutting down..." kill -TERM $NGINX_PID $JAVA_PID 2>/dev/null wait $NGINX_PID $JAVA_PID 2>/dev/null } trap cleanup TERM INT wait $NGINX_PID $JAVA_PID

5.4 现象：国产Linux（如麒麟V10）上docker run报错standard_init_linux.go:228: exec user process caused: exec format error

原因：Docker镜像架构与宿主机不匹配。openjdk:8-jre-slim默认是amd64镜像，但麒麟V10运行在ARM64（鲲鹏）或LoongArch（龙芯）平台，需拉取对应架构镜像。
解决：确认宿主机架构uname -m（aarch64或loongarch64），然后拉取适配镜像：

# 鲲鹏ARM64 docker pull --platform linux/arm64 openjdk:8-jre-slim # 龙芯LoongArch（需自建镜像，官方无支持） # 或改用支持LoongArch的OpenJDK发行版，如龙芯官方提供的loongnix-jdk8

5.5 现象：docker logs -f my-web-app输出大量2023/10/01 12:00:00 [warn] 7#7: using inherited sockets from systemd

原因：容器启动时，宿主机systemd将socket文件描述符传递给容器内进程，Nginx误以为这是来自systemd的socket继承，发出警告。虽不影响功能，但污染日志。
解决：在start.sh中Nginx启动命令前加exec，强制替换当前shell进程：

# 替换原启动行 exec su -c "/opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf -g 'daemon off;'" -s /bin/bash nginx &

exec使Nginx直接成为PID 1的子进程，切断与systemd socket的关联。

6. 进阶技巧：用docker commit固化运行时状态，生成可审计的交付物镜像

6.1 为什么需要commit？——当配置热更新失效时，镜像就是最后的后悔药

标题里“安装包”一词暗示交付物需可复制、可验证。但docker run -e传参的方式，每次启动都依赖环境变量，一旦变量丢失（如CI/CD流水线配置错误），服务就起不来。更糟的是，某些信创项目要求交付物通过第三方安全扫描，而扫描工具只能检查静态镜像，无法验证运行时注入的配置。此时，docker commit就是救命稻草：它把正在运行的容器文件系统快照，保存为新镜像，所有配置、日志、甚至临时文件都固化其中。

操作流程如下：

1. 启动容器并注入配置：

   docker run -d \ --name temp-app \ -e NGINX_PORT=80 \ -e NGINX_SERVER_NAME=prod.example.com \ -v $(pwd)/app.jar:/app/app.jar:ro \ nginx-java-jdk8:1.0

2. 进入容器，验证配置生效：

   docker exec -it temp-app cat /opt/nginx/conf/nginx.conf # 确认server_name、root路径等已正确渲染 docker exec -it temp-app curl -s http://localhost:80 | head -5 # 确认返回HTML内容

3. 提交为新镜像：

   docker commit \ --author "Ops Team <ops@company.com>" \ --message "Prod config applied: NGINX_SERVER_NAME=prod.example.com" \ temp-app nginx-java-jdk8-prod:20231001

4. 导出为tar包（交付物）：

   docker save nginx-java-jdk8-prod:20231001 > nginx-java-jdk8-prod-20231001.tar # 该tar包可拷贝到离线环境，用docker load导入

提示：docker commit生成的镜像体积会比原始镜像大（因包含运行时日志、临时文件），建议在commit前清理：

docker exec temp-app rm -rf /var/log/nginx/* /tmp/* docker exec temp-app find /app -name "*.log" -delete

6.2 镜像签名与校验：用cosign为交付镜像打数字指纹，满足信创审计要求

国产信创环境普遍要求软件包具备数字签名。Docker镜像可通过cosign工具签名：

# 1. 安装cosign（需Go环境） curl -L "https://github.com/sigstore/cosign/releases/download/v2.1.1/cosign-linux-amd64" -o cosign chmod +x cosign # 2. 生成密钥对（私钥保密，公钥交付） ./cosign generate-key-pair # 3. 对镜像签名 ./cosign sign --key cosign.key nginx-java-jdk8-prod:20231001 # 4. 导出签名（交付时附带） ./cosign verify --key cosign.pub nginx-java-jdk8-prod:20231001 > signature.json

交付时，客户可用cosign verify验证镜像完整性：

cosign verify --key cosign.pub nginx-java-jdk8-prod:20231001 # 输出：Verified OK

6.3 最小化交付清单：一份表格说清你需要交付的全部实物

我的习惯是：每次交付前，用sha256sum计算所有文件哈希值，生成SHA256SUMS文件，和交付包一起提供。客户导入镜像后，执行docker images --digests | grep nginx-java-jdk8-prod，对比Digest值是否与SHA256SUMS中记录一致——这才是真正的“所见即所得”。信创项目里，这个动作比写一百页文档都有力。希望帮到你。

本文还有配套的精品资源，点击获取