Tomcat和NGINX 收集常用命令插入折叠面板{collapse}{collapse-item label="NGINX常用命令" open}# 查看 Nginx 版本 /usr/local/nginx/sbin/nginx -v # 检查配置文件 ngnix.conf 的正确性 /usr/local/nginx/sbin/nginx -t # 启动 Nginx 服务 /usr/local/nginx/sbin/nginx # 启动 Nginx 服务，-c 指定配置文件的路径 /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf # 重新加载配置 /usr/local/nginx/sbin/nginx -s reload # 停止 Nginx 服务（快速关闭，不管有没有正在处理的请求） /usr/local/nginx/sbin/nginx -s stop # 安全退出 Nginx 服务（在退出前会完成已经接受的连接请求，比较优雅） /usr/local/nginx/sbin/nginx -s quit{/collapse-item}{collapse-item label="查看/杀死进程"}例如Tomcat#查看 ps -ef | grep tomcat #kill kill -9 进程号 #多的话全kill了 kill -9 `ps -ef|grep tomcat|grep -v grep|awk '{print $2}'`{/collapse-item}{collapse-item label="查看top前十"}ps aux --sort=-%mem | head{/collapse-item}{collapse-item label="测试"}加入卡片描述{card-describe title="卡片描述"}卡片内容{/card-describe}加入默认卡片{card-default label="默认卡片标题" width="100"}卡片内容{/card-default}{/collapse-item}{collapse-item label="折叠标题二"} 折叠内容二{/collapse-item}{/collapse}

Docker数据持久化的五种方式 一、绑定挂载（Bind Mount）将宿主机目录直接挂载到容器中。优点：数据直接保存在宿主机；可以使用宿主机工具直接查看和修改文件；方便备份和迁移。缺点：强依赖宿主机目录结构；容器跨机器迁移不方便；存在权限问题。适用场景：开发环境；配置文件挂载；日志目录挂载。docker run -d \  --name mysql8 \  -p 39306:3306 \  -e MYSQL_ROOT_PASSWORD="Admin@2026#" \  -e MYSQL_DATABASE=toolbox \  -e MYSQL_USER=appuser \  -e MYSQL_PASSWORD="Abc@123456" \  -v /datah/mysql:/var/lib/mysql \  mysql:8docker exec -it mysql8 bashmysql -h 127.0.0.1 -P 3306 -uroot -p'Admin@2026#'二、数据卷（Volume）Docker 官方推荐的数据持久化方式。优点：生命周期独立于容器，易于备份和迁移，Docker 自动管理，性能较好。缺点：数据位置不直观，需要 Docker 命令管理。适用场景：MySQL，PostgreSQL，Redis，生产环境推荐优先使用 Volume。2.1、创建名称为 mysql-data 的docker管理卷docker volume create mysql-data2.2、查看创建的数卷docker volume ls2.3、使用数据卷启动mysql8容器docker run -d \  --name mysql8 \  -p 39306:3306 \  -e MYSQL_ROOT_PASSWORD="Admin@2026#" \  -e MYSQL_DATABASE=toolbox \  -e MYSQL_USER=appuser \  -e MYSQL_PASSWORD="Abc@123456" \  -v mysql-data:/var/lib/mysql \  mysql:82.4、查看数据卷详细挂载路径docker volume inspect mysql-data2.5、卸载并删除docker stop mysql8docker rm mysql8docker volume lsdocker volume rm mysql-data三、内存挂载（tmpfs Mount）将数据存放在内存中，不落盘。特点：数据保存在 RAM 中、容器停止后数据丢失、速度非常快。优点：高性能、提高安全性（不写磁盘）。缺点：不是真正意义上的持久化、重启即丢失。适用场景：缓存、临时文件、敏感数据。3.1、 宿主机创建挂载目录和配置文件mkdir -p /opt/nginx/{conf.d,logs}cat > /opt/nginx/nginx.conf <<'EOF'user  nginx;worker_processes  auto;error_log  /var/log/nginx/error.log warn;pid        /var/run/nginx.pid;events {    worker_connections  10240;}http {    include       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  /var/log/nginx/access.log  main;    sendfile        on;    tcp_nopush     on;    keepalive_timeout  65;    # ========== tmpfs 内存临时缓存目录配置 ==========    client_body_temp_path /var/nginx/client_temp;    proxy_temp_path       /var/nginx/proxy_temp;    fastcgi_temp_path     /var/nginx/fastcgi_temp;    uwsgi_temp_path       /var/nginx/uwsgi_temp;    scgi_temp_path        /var/nginx/scgi_temp;    # 静态资源内存缓存配置    proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=nginx_cache:100m inactive=7d max_size=1G;    gzip  on;    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;    include /etc/nginx/conf.d/*.conf;}EOF3.2、conf.d 站点配置（http + https）cat > /opt/nginx/conf.d/demo.conf <<'EOF'server {    listen 80;    server_name demo.dashboard.com;    return 301 https://$host$request_uri;}server {    listen 443 ssl http2;    server_name demo.dashboard.com;    ssl_certificate     /etc/nginx/conf.d/certs/dashboard.com.crt;    ssl_certificate_key /etc/nginx/conf.d/certs/dashboard.com.key;    location / {        proxy_pass http://192.168.100.200:31080;        proxy_http_version 1.1;        proxy_set_header Upgrade $http_upgrade;        proxy_set_header Connection "upgrade";        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto https;    }}EOF3.3、Docker 启动命令  # tmpfs 内存挂载Nginx所有临时目录，限制最大2G，权限700  --tmpfs /var/nginx:size=2G,mode=700 \  # 配置、日志持久化挂载  -v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf \  -v /opt/nginx/conf.d:/etc/nginx/conf.d \  -v /opt/nginx/logs:/var/log/nginx \docker run -d \  --name nginx-gateway \  --restart always \  -p 80:80 \  -p 443:443 \  --tmpfs /var/nginx:size=2G,mode=700 \  -v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf \  -v /opt/nginx/conf.d:/etc/nginx/conf.d \  -v /opt/nginx/logs:/var/log/nginx \  nginx:stable-alpine3.4、访问域名查看界面3.5、卸载docker stop nginx-gatewaydocker rm nginx-gateway四、数据卷容器（Data Volume Container）通过一个专门的容器管理数据。优点：多容器共享数据方便。缺点：已经比较老旧、被 Named Volume 基本替代。适用场景：有老项目还在使用维护。4.1、创建数据卷容器（只做数据存储，不启动业务）docker create \--name nginx-data \-v /etc/nginx \-v /var/log/nginx \busybox4.2、把宿主机现有的证书、配置拷贝到数据卷容器中# 拷贝宿主机配置目录到数据卷容器docker cp /opt/nginx/nginx.conf nginx-data:/etc/nginx/nginx.confdocker cp /opt/nginx/conf.d/. nginx-data:/etc/nginx/conf.d/4.3、Nginx 业务容器通过 --volumes-from 挂载数据卷容器# 从数据卷容器挂载所有声明的卷，不用再写宿主机-v路径--volumes-from nginx-data \docker run -d \--name nginx-gateway \-p 80:80 \-p 443:443 \--volumes-from nginx-data \nginx4.4、访问验证4.5、多容器共享同一份数据（扩展）如果后续部署多个 Nginx 实例，直接复用数据卷容器即可：两个 Nginx 共用一套配置、证书、日志目录。docker run -d \--name nginx-gateway2 \-p 8080:80 -p 8443:443 \--volumes-from nginx-data \nginxhttps://demo.dashboard.com:8443/4.6、卸载docker stop nginx-gateway nginx-gateway2docker rm -f nginx-gatewaydocker rm -f nginx-gateway2docker rm -f nginx-data五、网络存储（NFS,分布式存储）可以把 Volume 映射到远程存储。优点：多节点共享数据、容器迁移方便、支持高可用。缺点：网络依赖、配置复杂、适用场景：集群部署、Kubernetes。Docker 原生支持创建 NFS Volume，比直接挂载 /mnt/nfs 更优雅，容器迁移也方便。[root@nfs-server logs]# exportfs -v/datah/nfs_share 192.168.100.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash)5.1、创建NFS挂载docker volume create \  --driver local \  --opt type=nfs \  --opt o=addr=192.168.100.205,nolock,soft,rw \  --opt device=:/datah/nfs_share \  nfs_data5.2、查看docker volume lsdocker volume inspect nfs_data5.3、在 NFS 服务端创建目录mkdir -p /datah/nfs_share/nginx/conf.dmkdir -p /datah/nfs_share/nginx/htmlchmod -R 777 /datah/nfs_share/nginx5.4、创建两个 volumedocker volume create \--driver local \--opt type=nfs \--opt o=addr=192.168.100.205,nolock,soft,rw \--opt device=:/datah/nfs_share/nginx/conf.d \nginx_confdocker volume create \--driver local \--opt type=nfs \--opt o=addr=192.168.100.205,nolock,soft,rw \--opt device=:/datah/nfs_share/nginx/html \nginx_html5.5、启动nginxdocker run -d \--name nginx \-p 80:80 \-v nginx_conf:/etc/nginx/conf.d \-v nginx_html:/usr/share/nginx/html \nginx:latest5.6、访问验证http://192.168.100.203/5.7、卸载[root@node ~]# docker stop nginxnginx[root@node ~]# docker rm nginxnginx[root@node ~]# docker volume rm nginx_htmlnginx_html[root@node ~]# docker volume rm nginx_confnginx_conf[root@node ~]# docker volume rm nfs_datanfs_data[root@node ~]# docker volume ls总结方式数据保存位置容器删除后数据推荐程度Bind Mount宿主机目录保留⭐⭐⭐VolumeDocker 管理目录保留⭐⭐⭐⭐⭐tmpfs内存丢失⭐数据卷容器Docker 管理保留⭐⭐NFS/Ceph网络存储保留⭐⭐⭐⭐⭐原文来源：运维攻坚

xj_gateway 日志配置与 Docker 部署 xj_gateway 日志配置与 Docker 部署指南配置日志文件输出在 Jar 包同目录下放 application.yml，配置日志输出：logging: file: name: /app/log/xj_gateway.log level: root: INFO com.xj.gateway: DEBUGDocker 启动docker run -d \ --name xj_gateway \ -v /usr/local/tomcat/gateway:/app \ -v /usr/local/tomcat/gateway/log:/app/log \ -w /app \ -p 8085:8085 \ openjdk:17 \ java -jar xj_gateway-1.0.0.jar应用启动后，日志就会写入到 /app/log/xj_gateway.log 文件。或者也可以把配置文件放在 /data/vdb/docker/compose/web/nginx/html/gateway/ 目录下：logging: file: name: /app/log/xj_gateway.log level: root: INFO com.xj.gateway: DEBUG两种方式效果一样，选择适合你部署习惯的即可。后续修改使用 --network host 模式docker run -d \ --name xj_gateway \ --network host \ -v /usr/local/tomcat/gateway:/app \ -v /usr/local/tomcat/gateway/log:/app/log \ -w /app \ openjdk:17 \ java -jar xj_gateway-1.0.0.jar

在NAS上部署Hermes｜手把手教程&踩坑总结 Hi，我是执着于持续分享NAS、AI、数码、家电、软件技巧相关知识，坚持创作有深度、高质量作品的博主 设计虱聊科技。期待您的关注。*NAS 应用中心的 Hermes 总是不更新，这对于我这种喜欢尝试点新版本功能的人不能忍。加上运行久了，总感觉不顺手了。于是一不做二不休，放弃应用中心版本，重新在 NAS 上 通过 Docker Compose 部署官方镜像。顺便，把网评挺不错的 Hermes-web-ui 也一并部署了。本以为很容易就跑通了，没想到，还踩了几个坑。好在最后都顺利解决。正好趁此机会，写一篇 手把手喂饭 和 避坑 的 NAS 部署攻略，给需要的朋友。*✿ 为什么要把AI助手部署在NAS上？简单说：24 小时在线、省电、方便依托 NAS 扩展其他功能。我把 Hermes 部署在 NAS 上后，它就变成了一个本地 AI 服务：★ 24 小时不间断运行，低功耗省电★ 任何设备随时接入，不担心因为关机掉线，轻松布置凌晨定时任务★ OCR、向量化、对话摘要等简单任务用NAS本地部署的小模型，节省Token★ 运行在沙箱中，不乱动沙箱外的文件而且因为跑在自己的NAS上，敏感数据不会泄露。*✿ 准备工作你需要：○ 一台NAS支持 Docker 的 x 86 平台的 NAS（ARM 平台我没试过）○ 最好有 Docker Compose 管理如果没有，可以先部署一个，管理 Docker 会方便很多。○ 获得一个大模型 API Key如果暂时不想花钱，可以先去例如 小米MiMo、阿里、硅基流动、智谱、MiniMax、百度千帆 等等大模型的官方网站看看，注册送一定的 API 试用额度，足够把 Hermes 配置好并体验一段时间。*✿ docker-compose 配置注： 如果你想和 NAS 应用商店的 Hermes 同时使用，可以把新部署的 Hermes 名称改一下，比如我就把目录名、服务名、容器名都改成了 hermesopt，这样就避免了和 NAS 应用商店的那个 Hermes 冲突。以下我都按这个思路部署，这样不管是哪种情况，都可以正常使用。如果你看着不顺眼，也可以把下面教程中的所有 hermesopt 的字段全部改回 hermes。在 NAS 存放 Docker 数据的目录新建一个文件夹，比如 /docker/hermesopt，然后创建 docker-compose.yaml。我们把 Hermes 和 hermes-webui 在同一个 Compose 中一并部署，方便内部打通。 services: hermesopt: image: nousresearch/hermes-agent:latest container_name: hermesopt restart: unless-stopped command: gateway run networks: - Agents-Network environment: - TZ=Asia/Shanghai - UMASK=000 - API_SERVER_ENABLED=true - API_SERVER_HOST=0.0.0.0 - API_SERVER_PORT=8642 - API_SERVER_KEY=你的API密钥 stdin_open: true tty: true volumes: - ./opt/data:/opt/data ports: - "8642:8642" deploy: resources: limits: memory: 4G cpus: "2.0" healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8642/health"] interval: 10s timeout: 5s retries: 5 hermes-webui: image: ekkoye8888/hermes-web-ui:latest container_name: hermes-webui restart: unless-stopped networks: - Agents-Network ports: - "6060:6060" environment: - PORT=6060 - HERMES_HOME=/home/agent/.hermes - HERMES_BIN=/opt/hermes/.venv/bin/hermes - HERMES_WEB_UI_MANAGED_GATEWAY=1 - TZ=Asia/Shanghai volumes: - ./opt/data:/home/agent/.hermes - ./hermes_webui_data:/home/agent/.hermes-web-ui depends_on: hermesopt: condition: service_healthy deploy: resources: limits: memory: 512M cpus: "0.5" networks: Agents-Network: driver: bridge 这段 yaml 中，有几处需要注意的地方：（1）创建了预留的 Docker 内部网络我顺便创建了Docker内部网络Agents-Network，方便与其他 Docker 间通信。这是个预留措施，如果不需要，也可以删掉。（2）Hermes 的密匙记得改一下，以后如果用官方的 Dashboard 登录时会用到。（3）Hermes 的映射目录设置Hermes 的 volumes 字段是目录映射，冒号前面是本地 NAS 路径，冒号后面是容器内路径。./opt/data 代表把容器的 /opt/data （默认用户数据目录）映射到 NAS 的 Docker 数据目录/opt/data 下，这样可以使数据持久化写到本地，不然容器一旦重启所有数据就没了。. 代表你设置的 Docker 数据目录，是简写方式，完整的写法也可以，比如我的就是：/volume1/docker/hermesopt/opt/data。现在，我们只映射了/opt/data 目录，Hermes 就只能访问这个目录。如果有其他协作目录需要 Hermes 能读写，也可以按这个写法加进去（可选）。比如，我专门添加了另一个目录/volume2/AgentWork。（4）hermes-webui 的配置hermes-webui 的 volumes 字段需要注意挂载 Hermes 的数据目录 ./opt/data（注意是容器内路径，不是映射的 NAS 路径），这样，webui 才能读写 hermes 的数据。配置完成后，点击 立即部署。两个镜像都比较大，会下载很长时间，不要着急，挂着慢慢等。*✿ 部署成功后，初始化Hermes看到这个界面，就是部署成功了。我们转到容器界面，找到 hermesopt 这个容器，进入 /bin/bash 终端，点击确认。在终端输入 hermes setup，回车，开始初始化设置。会让我们选择初始化方式。第一个 Quick Setup 是快速初始化，会让我们跳转到官方的网页授权，官方会帮你配齐包括模型、AI 搜索在内的几乎所有工具。有钱又不想手动配置的同学可以直接用这个。当然他也有免费模式。点击合适的套餐，就能自动配置好。只是速度有点慢。但我是个想要自己动手折腾的用户，所以我选择第二个 Full Setup，完整初始化。第一步是选择大语言模型，我们刚才准备了哪个供应商的 API Key，就选哪个。我有 MiMo 送的 Token Plan，所以我这里演示的模型供应商选择的是 Xiaomi MiMo。选择供应商后，会让我们输入 key, 我们直接复制供应商提供的 key，然后在终端点击鼠标右键，选择粘贴。然后选择这个模型供应商提供的模型，每个模型的能力和计价方式可能不同，选择适合自己的。这里我选择 mimo-v2.5。大语言模型配置好，选择一个“终端后端”（Terminal Backend）。简单来说，就是告诉 Hermes：当它需要执行一个 Shell 命令时，应该把这个命令送到哪里去运行。最安全、最简单的选择是：Keep current (local) 。因为容器内部就是一个完整的 Linux 环境，Hermes 已经可以正常使用 local 模式执行命令（比如读写我刚才挂载的 /volume2/AgentWork 目录）。！！！这里 不要 因为 Hermes 通过 Docker 部署就选择 Docker，因为 Hermes 可能会尝试去连接不存在的资源，导致执行命令失败。下一步是选择一个通信终端，用来随时联系 Hermes 。目前我觉得常用 IM 中，飞书对 Hermes 的支持最好，我也建议你选择飞书。但是如果你不喜欢飞书，也可以选择自己喜欢的平台，常见的微信、QQ、钉钉、iMessage 等也都支持。选择后会进入鉴权流程，跟着流程走很快就能连接好。下面选择 CLI 工具，这是 Hermes 的能力来源。上下键选择，空格键激活/取消，回车键全部确认。这里我建议保持默认，因为默认覆盖了大多数使用场景，以后如果需要调整，可以再回到终端用 Hermes setup 命令重新改。下一个是选择 Hermes 内置浏览器，第一个无头浏览器是最简单轻量的，不需要任何配置，可以先选它体验。Camofox 功能更完整但更重一些（抓网页更好用点）。其他的是一些收费的云浏览器，以后可以再根据自己需求选用。下一个选择图像生成功能的服务商，建议先跳过。需要的时候再选。语音模型，建议选第一个免费的，不用配置。我没用过，如果你需要且觉得推荐的 Microsoft Edge TTS 效果不好，以后再试其他的。下一个选 AI 搜索服务商，建议先选 Tavily，每月有 1000 次免费 API 额度，够用了。需要去 Tavily 官网先注册一下，获得一个 API Key，复制后在这里选择 Tavily，粘贴 Key，回车，搞定。到这里就全部配置完成了。我们可以直接在命令行输入 hermes 进入 对话界面，试一试说句“你好”。需要退出聊天时按 Ctrl+C 就可以回到命令行。或者直接关掉终端窗口，从飞书联系 Hermes。*✿ 如何访问和使用 Hermes WebUI正常来说，刚才部署成功后，Hermes WebUI 会和 Hermes 容器一起启动。在浏览器打开 http://你的NAS IP:6060，输入默认账号 admin / 123456，就可以进入主界面了。第一次登录建议改掉默认密码。这是个非常全面的 Hermes 前端控制台，在这里可以轻松查看和修改对话、记忆、用量、定时任务、模型、技能等信息，再也不用去配置文件里敲代码了。整个界面很直观，我就不详细介绍了。*✿ 写在最后到这里，就可以与 Hermes 正常对话和设置了。 但是，NAS 端其实还有一个问题要解决好，就是人机协作的问题。NAS 的底层通常是 Debian 一类的 Linux 系统，对用户权限设置的要求很高。这个问题反映到 Hermes 这里，就成了大问题。因为 Hermes 的权限和我们用户的权限是不一样的，如果我们手动修改了 Hermes 的文件，Hermes 就会失去对这个文件的读写权限，造成配置出错、任务终止的问题。所以，我们还需要把协作问题处理好。这个咱们下篇文章再说。*坚持创作有深度、高质量的作品、致力于分享干货、抵制标题党和网络垃圾，是我的座右铭。关注我，蹲后续。您的支持对我真的很重要O(∩_∩)O）。让我们共同打造互联网内容创作和知识分享的一股清流！ヾ(◍°∇°◍)ﾉﾞ#NAS #Docker #Hermes #WebUI #Compose #Docker部署原文来源：设计虱聊科技

Docker Compose 用了这么久，这些骚操作你可能一个都没用过  Compose 都进化到 V2 了，很多人还在用最基础的功能，那些真正能提效的特性根本没碰过。今天就把我在生产环境里实际用到的一些 Compose 进阶配置掏出来，都是踩过坑之后总结的。启动顺序这个坑，你一定踩过最经典的场景：Web 应用依赖 MySQL，Compose 文件里写了 depends_on: db，以为万事大吉了。结果一跑 docker compose up，应用容器启动了，数据库容器也启动了——但 MySQL 还在初始化，应用连不上数据库直接报错退出。很多人的解决方案是在应用启动脚本里加 sleep 15 或者写个 wait-for-it.sh 脚本去循环检测端口。能用，但丑。Compose 其实早就给了优雅解：healthcheck + depends_on 条件等待。services:  db:    image: mysql:8.0    environment:      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}      MYSQL_DATABASE: myapp    healthcheck:      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]      interval: 5s      timeout: 3s      retries: 10      start_period: 30s    volumes:      - db_data:/var/lib/mysql  web:    build: .    ports:      - "8080:8080"    depends_on:      db:        condition: service_healthy    environment:      DB_HOST: db      DB_PORT: 3306关键就在 depends_on 里面的 condition: service_healthy。有了这个，Compose 会一直等到 db 的 healthcheck 通过了才去启动 web 容器。不用 sleep，不用额外脚本，干干净净。start_period: 30s 这个参数容易被忽略——它的意思是容器启动后的前30秒内，healthcheck 失败不算数，不会把容器标记为 unhealthy。MySQL 这种启动慢的服务，这个参数一定要给够，不然容器还在初始化就被判定不健康了。除了 MySQL，Redis 的 healthcheck 可以这么写：  redis:    image: redis:7-alpine    healthcheck:      test: ["CMD", "redis-cli", "ping"]      interval: 3s      timeout: 2s      retries: 5PostgreSQL 的：  postgres:    image: postgres:16    healthcheck:      test: ["CMD-SHELL", "pg_isready -U postgres"]      interval: 5s      timeout: 3s      retries: 10      start_period: 20s养成习惯，每个基础设施服务都配上 healthcheck，后面不管是本地开发还是 CI/CD 流水线里跑集成测试，都能省不少事。Profiles：一份文件管多套环境以前我管一个项目，本地开发要跑 app + db + redis，测试环境还要多一个 Selenium 做 E2E 测试，生产环境又要挂上监控的 Prometheus + Grafana。三套环境三份 compose 文件，改一个配置要同步好几个地方，烦得要死。后来发现 profiles 这个功能，一份文件全搞定：services:  app:    build: .    ports:      - "8080:8080"    depends_on:      db:        condition: service_healthy  db:    image: postgres:16    environment:      POSTGRES_PASSWORD: ${DB_PASSWORD}    healthcheck:      test: ["CMD-SHELL", "pg_isready -U postgres"]      interval: 5s      timeout: 3s      retries: 10  redis:    image: redis:7-alpine    healthcheck:      test: ["CMD", "redis-cli", "ping"]      interval: 3s      retries: 5  # 只在测试时启动  selenium:    image: selenium/standalone-chrome:latest    profiles:      - testing    ports:      - "4444:4444"  # 只在需要监控时启动  prometheus:    image: prom/prometheus:latest    profiles:      - monitoring    volumes:      - ./prometheus.yml:/etc/prometheus/prometheus.yml    ports:      - "9090:9090"  grafana:    image: grafana/grafana:latest    profiles:      - monitoring    ports:      - "3000:3000"    depends_on:      - prometheus用的时候：# 本地开发，只启动核心服务docker compose up# 跑集成测试，带上 seleniumdocker compose --profile testing up# 需要看监控面板docker compose --profile monitoring up# 全都要docker compose --profile testing --profile monitoring up没有指定 profile 的服务默认启动，标记了 profile 的服务只有在显式激活时才会起来。这样一份文件就覆盖了所有场景，维护成本直接砍掉三分之二。Watch 模式：告别无尽的 rebuild做本地开发最痛苦的是什么？改了一行代码，要重新 docker compose build，等镜像构建完再 up，一来一回半分钟就没了。如果你的 Dockerfile 写得不好没有利用缓存，那更是每次都要重新安装依赖，一次 build 两三分钟。Compose V2 的 watch 功能直接终结了这个痛苦。它能监控你本地文件的变化，自动同步到容器里或者触发重建：services:  web:    build: .    ports:      - "3000:3000"    develop:      watch:        # 源代码变了，直接同步进容器（热加载）        - action: sync          path: ./src          target: /app/src        # package.json 变了，重新构建镜像        - action: rebuild          path: ./package.json        # 配置文件变了，重启容器就行        - action: sync+restart          path: ./config          target: /app/config然后跑：docker compose watch这样一来，你改 src/ 下面的代码，文件直接同步进容器，配合应用自己的热加载（比如 nodemon、Spring DevTools）立刻生效；改了 package.json 新增依赖，Compose 自动触发 rebuild；改了配置文件，容器自动重启加载新配置。三种 action 的区别搞清楚就行：• sync：只同步文件，不重启容器。适合有热加载能力的应用。• sync+restart：同步文件后重启容器。适合需要重启才能加载配置的场景。• rebuild：重新构建镜像并替换容器。适合依赖变更、Dockerfile 本身变了的情况。我现在本地开发项目全用这个，基本告别了手动 build 的操作。Secrets：别再把密码明文写在 yml 里了看过太多项目把数据库密码、API Key 直接写在 docker-compose.yml 或者 .env 文件里，然后整个文件提交到 Git 仓库。虽然 .env 一般会 gitignore，但 compose 文件本身经常有人直接把值硬编码进去。Compose 支持 secrets 管理，虽然不像 Kubernetes Secrets 或者 HashiCorp Vault 那么重量级，但对于小团队和开发环境来说足够了：services:  db:    image: postgres:16    secrets:      - db_password    environment:      POSTGRES_PASSWORD_FILE: /run/secrets/db_password  app:    build: .    secrets:      - db_password      - api_key    environment:      DB_PASSWORD_FILE: /run/secrets/db_password      API_KEY_FILE: /run/secrets/api_keysecrets:  db_password:    file: ./secrets/db_password.txt  api_key:    environment: "MY_API_KEY"secrets 会以文件的形式挂载到容器的 /run/secrets/ 目录下，而不是通过环境变量暴露。很多官方镜像（PostgreSQL、MySQL、MariaDB）都支持 *_FILE 后缀的环境变量，会自动从文件读取值。当然你的应用代码也需要支持从文件读取密钥，这个改动其实很小，伪代码大概就是：import osdef get_secret(name):    # 优先从 secrets 文件读    secret_file = f"/run/secrets/{name}"    if os.path.exists(secret_file):        with open(secret_file) as f:            return f.read().strip()    # 降级到环境变量    return os.environ.get(name.upper())这样密码文件不进 Git，compose 文件里没有敏感信息，干净多了。网络隔离：别让所有容器都能互相访问默认情况下 Compose 会创建一个网络，把所有服务都扔进去，每个服务都能访问其他所有服务。对于简单项目无所谓，但如果你的项目稍微复杂一点，比如有前端、后端、数据库三层，让前端容器能直接连数据库这件事本身就不合理。手动划分网络其实很简单：services:  frontend:    build: ./frontend    ports:      - "80:80"    networks:      - frontend_net  backend:    build: ./backend    ports:      - "8080:8080"    networks:      - frontend_net      - backend_net  db:    image: postgres:16    networks:      - backend_net    volumes:      - db_data:/var/lib/postgresql/datanetworks:  frontend_net:  backend_net:volumes:  db_data:这样 frontend 只能访问 backend，访问不了 db；backend 能同时访问 frontend 网络和 db 所在的 backend 网络。最小权限原则，减少攻击面。多文件组合和 override还有一个很实用的特性：Compose 支持多文件叠加。你可以有一个基础的 docker-compose.yml，然后针对不同环境写 override 文件：# 文件结构docker-compose.yml           # 基础配置docker-compose.override.yml  # 本地开发覆盖（自动加载）docker-compose.prod.yml      # 生产环境覆盖docker-compose.override.yml 这个文件名是约定俗成的，Compose 会自动加载它来覆盖主文件的配置，不用你手动指定。# docker-compose.yml（基础）services:  app:    image: myapp:latest    environment:      LOG_LEVEL: info# docker-compose.override.yml（开发环境自动覆盖）services:  app:    build: .    volumes:      - ./src:/app/src    environment:      LOG_LEVEL: debug      DEBUG: "true"    ports:      - "8080:8080"      - "5005:5005"  # debug 端口本地开发直接 docker compose up 就会合并两个文件；部署生产时用：docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d这个模式的好处是基础配置只写一份，各环境的差异通过 override 文件表达，不用维护多份完整的 compose 文件。资源限制：别让一个容器把服务器吃死线上跑 Compose 的话，一定要给容器加资源限制。不加限制的后果我见过——一个 Java 应用内存泄漏，把整台机器 32G 内存吃光，连 SSH 都登不上去，最后只能强制重启。services:  app:    image: myapp:latest    deploy:      resources:        limits:          cpus: '2.0'          memory: 2G        reservations:          cpus: '0.5'          memory: 512M    restart: unless-stoppedlimits 是硬限制，超了就 OOM Kill；reservations 是预留资源，Docker 调度时会保证这些资源可用。另外 restart: unless-stopped 也别忘了加，容器崩了能自动拉起来。和 restart: always 的区别是，如果你手动 docker compose stop 停掉了容器，unless-stopped 不会在 Docker 重启后自动拉起来，而 always 会。一个实际项目的完整示例最后给一个我自己在跑的项目配置，算是把前面讲的东西串起来。一个典型的 Web 应用 + API + PostgreSQL + Redis + Nginx 的架构：services:  nginx:    image: nginx:alpine    ports:      - "80:80"      - "443:443"    volumes:      - ./nginx/conf.d:/etc/nginx/conf.d:ro      - ./nginx/ssl:/etc/nginx/ssl:ro    networks:      - frontend    depends_on:      api:        condition: service_healthy    restart: unless-stopped    deploy:      resources:        limits:          memory: 256M  api:    build:      context: .      dockerfile: Dockerfile    secrets:      - db_password      - redis_password    environment:      DB_HOST: postgres      DB_PORT: 5432      DB_NAME: myapp      DB_USER: appuser      DB_PASSWORD_FILE: /run/secrets/db_password      REDIS_URL: redis://:${REDIS_PASSWORD}@redis:6379/0    healthcheck:      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]      interval: 10s      timeout: 5s      retries: 3      start_period: 40s    networks:      - frontend      - backend    depends_on:      postgres:        condition: service_healthy      redis:        condition: service_healthy    restart: unless-stopped    deploy:      resources:        limits:          cpus: '2.0'          memory: 2G        reservations:          memory: 512M    develop:      watch:        - action: sync          path: ./src          target: /app/src        - action: rebuild          path: ./requirements.txt  postgres:    image: postgres:16-alpine    secrets:      - db_password    environment:      POSTGRES_DB: myapp      POSTGRES_USER: appuser      POSTGRES_PASSWORD_FILE: /run/secrets/db_password    healthcheck:      test: ["CMD-SHELL", "pg_isready -U appuser -d myapp"]      interval: 5s      timeout: 3s      retries: 10      start_period: 20s    volumes:      - postgres_data:/var/lib/postgresql/data      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro    networks:      - backend    restart: unless-stopped    deploy:      resources:        limits:          memory: 1G  redis:    image: redis:7-alpine    command: redis-server --requirepass ${REDIS_PASSWORD}    healthcheck:      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]      interval: 3s      timeout: 2s      retries: 5    volumes:      - redis_data:/data    networks:      - backend    restart: unless-stopped    deploy:      resources:        limits:          memory: 512M  # 监控组件，需要时才启动  prometheus:    image: prom/prometheus:latest    profiles:      - monitoring    volumes:      - ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro    networks:      - backend    ports:      - "9090:9090"  grafana:    image: grafana/grafana:latest    profiles:      - monitoring    volumes:      - grafana_data:/var/lib/grafana    networks:      - frontend    ports:      - "3000:3000"    depends_on:      - prometheusnetworks:  frontend:  backend:volumes:  postgres_data:  redis_data:  grafana_data:secrets:  db_password:    file: ./secrets/db_password.txt  redis_password:    file: ./secrets/redis_password.txt这份配置覆盖了：健康检查和启动顺序、网络隔离、Secrets 管理、资源限制、Profiles 按需启动监控、Watch 模式开发热加载、自动重启策略。基本上是一个生产可用的模板了。Docker Compose 这个东西吧，入门门槛低，但上限比大多数人想象的高。很多人用了好几年还停留在最基础的阶段，其实多花半小时翻翻官方文档的 How-to 部分，能发现不少直接提升工作效率的东西。不是所有场景都需要上 K8s 的。对于中小团队、开发测试环境、甚至一些流量不大的生产服务，一份写得好的 Compose 文件配合 CI/CD 就已经很够用了。关键是要把它用好、用全，别只会 image + ports 三板斧。希望今天这些配置对你有用。如果你也有什么 Compose 的骚操作，欢迎留言交流。觉得有收获的话，转发给还在 sleep 10 的同事看看吧。公众号：耕云躬行录个人博客：躬行笔记 原文来源：微信公众号 - 耕云躬行录