管理Docker终端可视化面板 使用 Docker 容器docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/.config/lazydocker:/.config/jesseduffield/lazydocker lazyteam/lazydocker:latest或者docker run --rm -it \ -v /var/run/docker.sock:/var/run/docker.sock \ -v ~/.config/lazydocker:/.config/jesseduffield/lazydocker \ lazyteam/lazydocker:latest第一步：把 alias 写进 ~/.bashrcecho "alias lzd='docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock -v /root/.config/lazydocker:/.config/jesseduffield/lazydocker lazyteam/lazydocker:latest'" >> ~/.bashrc第二步：让它立即生效source ~/.bashrc{alert type="success"}lzd{/alert} 即可唤起 lazydocker。

10 服务器安全加固：别让你的服务器裸奔，5 步搞定基础防护 导语：新买的服务器，默认状态等于"裸奔"——门没锁、钥匙人人能配。5 步基础防护，30 分钟做完，安稳一整年。上一篇文章我们给服务器配了安全组，但很多新手会问："安全组配了，系统防火墙还要配吗？这俩到底啥关系？" 还有更隐蔽的一层——数据库端口，大多数人部署完网站就忘了它，等于把保险柜敞着门。这篇把三件事讲透：5 步防护清单、安全组和防火墙的区别、数据库端口怎么守住。01先看清：你的服务器现在有多危险刚买的新服务器，默认状态是这样的：默认状态意味着什么root 账号允许密码登录等于把大门钥匙挂在门口SSH 端口 22 对外开放全网扫描器 24 小时在试密码防火墙没配所有端口对所有 IP 敞开数据库端口裸奔数据库（如 3306）全网可连、弱口令可猜系统补丁没人更新已知漏洞无人修补经验：网上有大量自动扫描程序，买下服务器几分钟内就会被扫到并开始被尝试登录。这不是你"被针对"，是所有公网 IP 的日常——所以防护不是可选项，是基础配置。02第 1 步：禁用 root 密码登录，改用 SSH 密钥为什么：密码可以被猜，密钥几乎不可能被猜。密钥是"指纹锁"，别人捡到密码也没用。做什么（三小步）：1. 在你自己的电脑上生成密钥：ssh-keygen -t ed25519一路回车，会生成一对钥匙：公钥（给别人）和私钥（自己留好）。1. 把公钥拷到服务器：ssh-copy-id root@你的服务器IP这条命令会要你输一次密码，之后服务器就认识你的"指纹"了。1. 在服务器上关掉密码登录：sudo nano /etc/ssh/sshd_config找到两行改成：PermitRootLogin no（root 不允许密码登录）、PasswordAuthentication no（所有账号都关密码），保存后重启服务：sudo systemctl restart ssh经验：第 3 步之前，先新开一个终端窗口，用密钥重新登录一次——确认密钥能登录，再关密码登录。不然密钥没配好就把密码关了，你只能去控制台重置。03第 2 步：改 SSH 默认端口为什么：全网扫描器只盯着常见端口（22 是头号目标）。把 SSH 挪到别的端口，等于把门牌号换了，扫描器找不到你。做什么：在刚才那个配置文件里，把 #Port 22 改成 Port 2222（或你喜欢的任意高端口），保存重启。经验：改端口和配防火墙的顺序不能反——先在防火墙放行新端口，再改配置重启。顺序反了，新端口被防火墙挡着，旧端口又关了，你直接进不了服务器。真进不去了，用云厂商控制台的网页终端（VNC）救。04第 3 步：配防火墙——先搞懂安全组和它的关系这是新手最容易懵的地方："云厂商的安全组，和服务器里的防火墙（ufw），不是一回事吗？" 不是。它们是一道门的两道锁，缺一不可。对比安全组（云厂商）系统防火墙（ufw/iptables）在哪一层服务器外面，云厂商网络层服务器里面，操作系统层谁在管云厂商控制台网页配置服务器上命令行配置生效方式改完立即生效，不用重启改完立即生效（服务级）比喻小区门口的门卫你家门上的锁特点拦"进小区的人"，看得见、好排查拦"到你家门口的人"，更细、可控进程流量是怎么过的：访问请求先到安全组（门卫点头放行）→ 进到服务器系统 → 再被系统防火墙检查（锁认不认这把钥匙）→ 最后才到你的程序。两层都放行，请求才进得来。所以正确姿势是两层都配：· 安全组：放行 22/80/443 等必要端口（上篇文章讲过）。· 系统防火墙（Ubuntu 用 ufw）：sudo ufw allow 2222/tcp    # 放行你的新 SSH 端口sudo ufw allow 80/tcp      # 放行网页sudo ufw allow 443/tcp     # 放行 HTTPSsudo ufw enable            # 开启防火墙三个高频坑：· 只配了一层：以为安全组放行了就万事大吉，结果系统防火墙默认全拒，网站还是打不开——排查半天才发现是 ufw 没配。· 配了 ufw 忘了开服务：ufw enable 之后新开服务（比如数据库），记得回来放行对应端口，不然"服务起来了但外面连不上"。· 把两层混为一谈：安全组在云控制台改，ufw 在服务器上改，别在网页上找不到设置就以为"没有防火墙"。05第 4 步：装 fail2ban，防暴力破解为什么：就算关了密码登录，其它服务（比如网站后台）可能还有登录接口。fail2ban 像一个"记仇的门卫"：谁连续登录失败，直接拉黑它的 IP 一段时间。做什么：sudo apt install fail2bansudo systemctl enable fail2ban默认配置已经保护 SSH，够用。经验：fail2ban 默认"连续失败几次就 ban"——你自己输错密码太多次，也会被自己的服务器 ban 掉。被 ban 了不用慌，等几分钟自动解封，或者把家里宽带 IP 加进白名单（配置文件里 ignoreip）。06第 5 步：定期更新补丁为什么：系统漏洞一直在被修补，不更新等于"带着已知的洞裸奔"。大部分入侵，靠的就是没打补丁的旧系统。做什么：sudo apt update && sudo apt upgrade -y想更省心，装自动更新：sudo apt install unattended-upgrades经验：别攒着半年更新一次——安全补丁有时效，晚一天就是多暴露一天。设个习惯：每周看一次系统更新（或者开自动更新，每月手动检查一次）。07数据库端口：最容易裸奔的"保险柜"网站部署完，大多数人会漏掉这一层：数据库还开着大门。默认状态有多危险：MySQL（端口 3306）、Redis（端口 6379）安装后默认监听所有网卡——全网任何 IP 都能试着连。扫描器扫到开放端口，就开始猜弱口令（root/123456 这种），猜中就拖库。数据库一旦被拖走，你网站的全部数据就没了。怎么判断自己有没有裸奔：登录服务器跑一条命令看端口监听：ss -tlnp看到 0.0.0.0:3306 或 *:3306，就是"对所有 IP 开放"，需要处理。三层防护，从紧到松：层级做法效果1. 限制来源防火墙/安全组：数据库端口只允许"服务器内网 IP"或"你的固定 IP"别人根本连不上2. 改默认端口把 3306 改成不常见的端口减少被扫描命中的概率3. SSH 隧道访问本地开发时通过 SSH 隧道连数据库，不开放数据库端口最安全，端口对外完全关闭经验：· Redis 比 MySQL 更危险：Redis 默认无密码，配置不当可以直接写服务器文件，等于送人一把万能钥匙。Redis 务必设密码，且绝不监听公网。· 别用 root 跑数据库：给数据库建独立账号，权限最小化——即使被攻破，损失也有限。· "改端口"只是拖延不是防护：真正拦住人的是"限制来源"和"SSH 隧道"这两层，别指望改个端口就高枕无忧。· SSH 隧道是"数据库端口完全关闭"也能安全访问的方法，下一篇《常用客户端工具》会详细讲怎么配。08三条救命经验（先看这条再动手）1. 改任何 SSH 配置前，先开一个新终端测试登录：密钥能进、新端口能连，再关旧通道。顺序错了最多就一次进不去的教训。2. 防火墙永远"先放行再关闭"：改端口、开新服务都按这个顺序，不然把自己锁外面。3. 所有操作问 AI 之前，先告诉它你的系统版本：cat /etc/os-release 看一眼，命令适配你的系统，别照抄别家的。总结· 新服务器默认=裸奔：root 密码登录、端口全开、数据库裸奔、无防护，扫描器几分钟就找上门。· 5 步防护：SSH 密钥登录 → 改默认端口 → 安全组 + 系统防火墙（两道锁都要配）→ fail2ban → 定期补丁。· 安全组是"小区门卫"（云厂商，外层），ufw 是"家门锁"（系统，内层），流量先过安全组再过防火墙，两层都放行才进得来。· 数据库端口是最常被漏的保险柜：默认 0.0.0.0 监听 = 全网可连；用"限制来源 + 改端口 + SSH 隧道"三层守住，Redis 务必设密码。· 核心纪律：先放行再关闭、先测试再切换；命令让 AI 生成，但每步在做什么、为什么，你要能说出来。10 分钟小任务：登录你的服务器，跑 ss -tlnp 看看哪些端口对外开着——重点找有没有 0.0.0.0:3306（MySQL）或 6379（Redis）；再跑 sudo grep "Failed password" /var/log/auth.log | tail -20 看看有没有人试图登录过。然后按清单从第 1 步开始做。下一篇，我们讲讲连服务器、数据库的客户端工具，以及 SSH 隧道怎么用。下一篇：常用客户端工具：SSH、数据库、Redis 客户端，小白装哪几个就够。

嫌 Docker 命令太难记？试试这款超惊艳的终端可视化面板 GEEK-NETSTATUS:ONLINE// NODE: 0x24万物开源，皆可部署|Connecting Intelligence.日常在 Linux 服务器或 NAS 上管理 Docker 容器时，很多开发者经常陷入“两难境地”：敲命令行效率低下：查日志要打一长串 docker logs -f --tail 100，进容器要手敲长串 ID，清理悬空镜像更是记不住过滤参数；Web 管理面板太臃肿：装个 Portainer 或图形面板，不仅多占几十兆甚至上百兆内存，还得单独映射端口、配置公网访问与账号权限；SSH 终端来回切换割裂：在远程终端连着服务器，还得额外开个浏览器去点点点，无法保持纯粹的沉浸式工作流。如果你想要一款无需开 Web 端口、直接在当前 SSH 终端窗口秒级唤起、纯键盘流操作且资源开销低到极致的 Docker 管理面板，那么在 GitHub 拥有 30,000+ Star 的开源神器——LazyDocker，就是终端极客的最佳利器。什么是 LazyDocker？LazyDocker 是一款用 Go 语言 编写的开源终端用户界面（TUI）Docker 管理工具。它将所有 Docker 实体（容器、镜像、数据卷、网络、Docker Compose 项目）收拢进一个类似 htop 的高颜值终端多栏布局中，让你只靠几个键盘快捷键，就能秒级完成监控、排错与运维清理。亮点功能1. 纯 TUI 现代化终端面板，开箱即用采用多分栏响应式设计：左侧显示容器、镜像、数据卷、网络状态；右侧实时展示选定目标的资源占用（CPU/内存实时波动图）、环境配置与运行详情。支持鼠标滚轮点击交互，更支持纯键盘 h/j/k/l 极速上下切换。2. 秒级日志流与一键进入容器终端光标停留在任意容器上，右侧立即实时滚动输出容器日志，按 f 键直接全屏追踪。选中容器直接按下 e 键，秒级调起交互式 Shell（进入容器终端），再也不用去复制冗长的 Container ID。3. 一键可视化 Compose 项目纳管自动识别当前目录或宿主机上的 docker-compose 服务栈。支持以项目为维度，一键对整套服务执行 Restart、Stop、Pause 或 Rebuild。4. 极致清爽的无用资源“一键大扫除”界面单独整理出所有处于 Exited（已停止）状态的容器、Dangling（悬空无标签）镜像和无主数据卷。按下快捷键 d 或 b 即可一键安全清理垃圾，给服务器磁盘腾出宝贵空间。安装与上手方式一：使用 Docker 容器无需在宿主机编译安装任何环境，直接用一行别名运行：docker run --rm -it \   -v /var/run/docker.sock:/var/run/docker.sock \   -v ~/.config/lazydocker:/.config/jesseduffield/lazydocker \   lazyteam/lazydocker:latest小技巧：在 ~/.bashrc 或 ~/.zshrc 中添加一行 alias lzd='docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock lazyteam/lazydocker:latest'，以后在终端输入 lzd 即可瞬间唤起控制台！方式二：一键脚本直接安装单二进制文件curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash选型建议评估维度原生 Docker CLIPortainer (Web 面板)LazyDocker (终端 TUI)内存与资源占用0 MB50MB ~ 100MB+约 10MB（即开即关）网络端口要求无需暴露端口必须开放 Web 端口完全无需额外端口操作效率敲长命令慢、易拼错鼠标点击、适合新手极客键盘流、秒级响应适用场景脚本自动化批处理团队协作、远程可视化托管单机调试、SSH 远程排障、NAS总结真正的效率提升，往往来自于把最繁琐的高频动作缩短到极致。LazyDocker 将原本需要几十次敲击键盘、复制 ID 的 Docker 排障工作，浓缩成了一个个优雅的快捷键。如果你经常通过 SSH 连服务器修 Bug、看日志，这款终端神器一定会让你直呼“相见恨晚”！GitHub 项目：jesseduffield/lazydocker平时管理 Docker 容器时，你最常用的命令是哪一条？你更喜欢图形网页端还是终端键盘流？欢迎在评论区留言交流！往期推荐 · RECENT NODES↘ VPS/NAS 玩家必备！可视化 Nginx 面板，证书自动续期↘ 运维开发者实测！几分钟搭建私有密码库，告别年费订阅网域极客GEEK-NETCONNECTING INTELLIGENCE.↘ 探索互联，点亮推荐  ❤[ JOIN CLOUD ]云端同步中...求点赞求分享求喜欢

滨江 Docker 容器端口访问控制方案总结 背景服务器：10.32.26.41服务：Docker 容器运行2121 → vsftpd（容器内端口 21）25432 → MySQL（容器内端口 3306）需求：拒绝任意 IP 访问 10.32.26.41:2121/25432允许 10.32.26.100、172.18.77.254 访问问题排查过程尝试方案结果原因DOCKER-USER 链 + -d 10.32.26.41❌ 不生效Docker 做 DNAT 后目标 IP 已变为容器内网 IP，规则匹配不上DOCKER-USER 链 + conntrack --ctorigdst❌ 不生效pkts 始终为 0，流量未走到 DOCKER-USERINPUT 链顶部插入 DROP/ACCEPT❌ 不生效服务器上运行的第三方安全软件（nfExtRuleIn 等）在 INPUT 之前已放行流量mangle PREROUTING✅ 生效这是 netfilter 中比 INPUT 更早的 hook 点，第三方软件尚未介入该服务器上存在第三方安全/防火墙产品（如深信服、奇安信等），注册了 nfExtRuleIn、nfExtRuleForward 等自定义链，导致常规 INPUT / DOCKER-USER 拦截失效。最终生效方案核心思路在 mangle 表的 PREROUTING 链中拦截：白名单 IP → RETURN（放行，继续后续处理）其他所有 IP → DROP（直接丢弃，不进入后续链）执行命令# 1. 白名单放行（RETURN = 不处理，继续后续流程） iptables -t mangle -I PREROUTING -s 10.32.26.100 -p tcp -m multiport --dports 2121,25432 -j RETURN iptables -t mangle -I PREROUTING -s 172.18.77.254 -p tcp -m multiport --dports 2121,25432 -j RETURN # 2. 其他所有 IP 拒绝 iptables -t mangle -I PREROUTING -p tcp -m multiport --dports 2121,25432 -j DROP验证规则顺序iptables -t mangle -L PREROUTING -n -v --line-numbers正确输出：num pkts bytes target prot opt in out source destination 1 0 0 RETURN tcp -- * * 10.32.26.100 0.0.0.0/0 multiport dports 2121,25432 2 0 0 RETURN tcp -- * * 172.18.77.254 0.0.0.0/0 multiport dports 2121,25432 3 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 2121,25432注意顺序：RETURN 必须在 DROP 的上面（行号更小），否则白名单也会被拒绝。策略效果来源 IP访问 10.32.26.41:2121 (vsftpd)访问 10.32.26.41:25432 (MySQL)10.32.26.100✅ 允许✅ 允许172.18.77.254✅ 允许✅ 允许其他任意 IP❌ 拒绝（连接超时）❌ 拒绝（连接超时）持久化保存重启后规则会丢失，务必保存：# CentOS / RHEL iptables-save > /etc/sysconfig/iptables # Ubuntu / Debian iptables-save > /etc/iptables/rules.v4后续维护新增白名单 IP# 插入到 DROP 规则之前（假设 DROP 在第 3 行） iptables -t mangle -I PREROUTING 3 -s <新IP> -p tcp -m multiport --dports 2121,25432 -j RETURN移除白名单 IP# 先查看行号 iptables -t mangle -L PREROUTING -n -v --line-numbers # 按行号删除 iptables -t mangle -D PREROUTING <行号>完全移除本策略iptables -t mangle -D PREROUTING -s 10.32.26.100 -p tcp -m multiport --dports 2121,25432 -j RETURN iptables -t mangle -D PREROUTING -s 172.18.77.254 -p tcp -m multiport --dports 2121,25432 -j RETURN iptables -t mangle -D PREROUTING -p tcp -m multiport --dports 2121,25432 -j DROP关键教训Docker userland-proxy 模式：外部访问映射端口时，流量先到达宿主机的 docker-proxy 进程，再走 INPUT 链，不一定经过 DOCKER-USER。第三方安全软件干扰：企业服务器常安装主机安全 Agent，会在 netfilter 多个 hook 点注册规则，可能提前放行或丢弃流量，导致自定义规则失效。排查方法：如果规则 pkts 始终为 0，说明流量根本没走到这条链，需要向上游（更早的 hook 点）排查。netfilter 处理顺序为：raw PREROUTING → mangle PREROUTING → nat PREROUTING → mangle FORWARD → filter FORWARD → mangle POSTROUTING → nat POSTROUTING对于本机接收的流量，在 nat PREROUTING 之后进入 INPUT 链。新加入端口# 白名单放行（-I 会插到最顶部） iptables -t mangle -I PREROUTING -s 10.32.26.100 -p tcp -m multiport --dports 65519,65520 -j RETURN # 拒绝其他所有 IP iptables -t mangle -I PREROUTING -p tcp -m multiport --dports 65519,65520 -j DROP 验证规则 iptables -t mangle -L PREROUTING -n -v --line-numbers[root@ZHJB-WEB-01 ~]# iptables -t mangle -L PREROUTING -n -v --line-numbers Chain PREROUTING (policy ACCEPT 51316 packets, 15M bytes) num pkts bytes target prot opt in out source destination 1 630 147K RETURN tcp -- * * 10.32.26.100 0.0.0.0/0 multiport dports 65519,65520 2 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 65519,65520 3 604 34393 RETURN tcp -- * * 10.32.26.100 0.0.0.0/0 multiport dports 2121,25432 4 22267 1791K RETURN tcp -- * * 172.18.77.254 0.0.0.0/0 multiport dports 2121,25432 5 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 2121,25432 | 行号 | 动作 | 来源 IP | 端口 | 说明 | | -- | -------- | ------------- | ----------- | ------ | | 1 | `RETURN` | 10.32.26.100 | 65519,65520 | 白名单放行 | | 2 | `DROP` | 0.0.0.0/0 | 65519,65520 | 其他全部拒绝 | | 3 | `RETURN` | 10.32.26.100 | 2121,25432 | 白名单放行 | | 4 | `RETURN` | 172.18.77.254 | 2121,25432 | 白名单放行 | | 5 | `DROP` | 0.0.0.0/0 | 2121,25432 | 其他全部拒绝 | | 来源 IP | 2121 (vsftpd) | 25432 (MySQL) | 65519 | 65520 | | ------------- | :-----------: | :-----------: | :---: | :---: | | 10.32.26.100 | ✅ 允许 | ✅ 允许 | ✅ 允许 | ✅ 允许 | | 172.18.77.254 | ✅ 允许 | ✅ 允许 | ❌ 拒绝 | ❌ 拒绝 | | 其他任意 IP | ❌ 拒绝 | ❌ 拒绝 | ❌ 拒绝 | ❌ 拒绝 | {card-describe title="卡片描述"}# ========== 1. 从大到小删除现有 5 条规则 ========== iptables -t mangle -D PREROUTING 5 iptables -t mangle -D PREROUTING 4 iptables -t mangle -D PREROUTING 3 iptables -t mangle -D PREROUTING 2 iptables -t mangle -D PREROUTING 1 # ========== 2. 重新插入（先 DROP 后 RETURN，RETURN 会顶到上面）========== # --- 2121,25432 --- iptables -t mangle -I PREROUTING -p tcp -m multiport --dports 2121,25432 -j DROP iptables -t mangle -I PREROUTING -s 172.18.77.254 -p tcp -m multiport --dports 2121,25432 -j RETURN iptables -t mangle -I PREROUTING -s 10.32.26.100 -p tcp -m multiport --dports 2121,25432 -j RETURN # --- 65519,65520 --- iptables -t mangle -I PREROUTING -p tcp -m multiport --dports 65519,65520 -j DROP iptables -t mangle -I PREROUTING -s 172.18.77.254 -p tcp -m multiport --dports 65519,65520 -j RETURN iptables -t mangle -I PREROUTING -s 10.32.26.100 -p tcp -m multiport --dports 65519,65520 -j RETURN{/card-describe}

Docker Compose 链式依赖启动（depends_on） {message type="success" content="1. 链式依赖启动（depends_on）"/}1.1 基础用法在 docker-compose.yml 中使用 depends_on 控制服务启动顺序。示例：严格链式启动（c → b → a）version: '3.8' services: c: image: nginx:20260805 container_name: nginx # 无依赖，最先启动 b: image: some_service:latest depends_on: c: condition: service_started # 等 c 容器启动后再启动 b a: image: ixjkj/tomcat9-jdk8:1.0 container_name: tomcat9-jdk8 depends_on: b: condition: service_started # 等 b 容器启动后再启动 a1.2 链式依赖 vs 并列依赖写法效果a depends_on: [b, c]b 和 c 同时启动，都就绪后才启动 ab depends_on: c + a depends_on: b串行：先 c → 再 b → 最后 a1.3 condition 详解depends_on: service_name: condition: service_started # 容器启动即可（默认） # condition: service_healthy # 等健康检查通过（推荐用于数据库/服务） # condition: service_completed_successfully # 等容器运行结束且 exit 0（用于初始化任务）condition前提条件等待时机适用场景service_started（默认）无容器启动即可简单依赖，不关心服务是否就绪service_healthy必须配置 healthcheck健康检查通过数据库、API 服务等需要真正就绪service_completed_successfully无容器运行结束且 exit 0一次性初始化/迁移任务注意：service_healthy 需要 Docker Compose v2.20+ 或较新的 docker compose CLI。如果版本太旧，只支持 depends_on: [service_name]（仅等待容器启动）。{message type="success" content="2. Healthcheck 健康检查详解"/}2.1 参数含义healthcheck: test: ["CMD-SHELL", "curl -f http://localhost:8086/actuator/health || exit 1"] interval: 5s # 每隔 5 秒检查一次 timeout: 3s # 单次检查最多等 3 秒，超时就当这次失败 retries: 5 # 连续失败 5 次后，容器状态标记为 unhealthy参数作用示例值test执行什么命令来判断健康curl 请求接口，成功返回 0，失败返回 1interval检查频率5s = 每 5 秒查一次timeout单次检查超时3s = 命令 3 秒没响应就视为失败retries容错次数5 = 连续失败 5 次才判为 unhealthy2.2 状态流转容器启动 ↓ 第一次检查（interval 后）→ 成功 → healthy ✅ ↓ 失败（但 < retries 次）→ 继续检查 ↓ 连续失败 retries 次 → unhealthy ❌2.3 service_healthy 的前提condition: service_healthy 必须配合被依赖服务的 healthcheck 使用。services: nginx: image: nginx:20260805 healthcheck: test: ["CMD-SHELL", "curl -f http://localhost:8086 || exit 1"] interval: 5s timeout: 3s retries: 5 tomcat: image: ixjkj/tomcat9-jdk8:1.0 depends_on: nginx: condition: service_healthy # ← 读取 nginx 的 healthcheck 状态如果没有给 nginx 配 healthcheck，service_healthy 会报错或永远等待。2.4 service_completed_successfully这是给一次性任务用的，不是持续运行的服务。典型场景：数据库初始化services: init-db: # 一次性任务，跑完就退出 image: postgres:15 command: ["sh", "-c", "psql -h db -U postgres -f /init.sql"] depends_on: db: condition: service_healthy app: # 主应用，等初始化完成后再启动 image: myapp depends_on: init-db: condition: service_completed_successfully # 等 init-db 容器退出且 exit code = 0问题答案是等容器关闭吗？是的，等容器运行结束并退出退出码必须是 0 吗？是的，只有成功完成（exit 0）才算通过如果 exit 1 呢？depends_on 会判定失败，不会启动下游服务适合什么场景？数据迁移、初始化脚本、备份任务等跑完就停的容器{message type="success" content="3. 各数据库 Healthcheck 示例"/}数据库不是 HTTP 服务，不能用 curl，要用各自的客户端命令或 TCP 端口探测。3.1 PostgreSQL / VastBase（兼容 PG）healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d your_database"] interval: 10s timeout: 5s retries: 5VastBase 是 PG 兼容的，所以用 pg_isready。如果镜像里没有该命令，用 psql：psql -U postgres -d your_database -c "SELECT 1" || exit 13.2 Oraclehealthcheck: test: ["CMD-SHELL", "sqlplus -s / as sysdba <<< 'SELECT 1 FROM DUAL;' || exit 1"] interval: 30s timeout: 10s retries: 5如果镜像精简没有 sqlplus，用 TCP 端口探测：bash -c 'cat < /dev/null > /dev/tcp/localhost/1521' || exit 13.3 MySQL / MariaDBhealthcheck: test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root -p$$MYSQL_ROOT_PASSWORD || exit 1"] interval: 10s timeout: 5s retries: 53.4 Redishealthcheck: test: ["CMD-SHELL", "redis-cli ping | grep PONG || exit 1"] interval: 5s timeout: 3s retries: 53.5 MongoDBhealthcheck: test: ["CMD-SHELL", "mongosh --eval 'db.adminCommand({ ping: 1 })' || exit 1"] interval: 10s timeout: 5s retries: 53.6 通用兜底：TCP 端口探测如果镜像精简到没有客户端命令，可以用 nc（netcat）或 Bash 内置的 /dev/tcp：healthcheck: test: ["CMD-SHELL", "nc -z localhost 5432 || bash -c 'cat < /dev/null > /dev/tcp/localhost/5432' || exit 1"] interval: 10s timeout: 5s retries: 5数据库端口推荐命令PostgreSQL / VastBase5432pg_isready / nc -z 5432Oracle1521sqlplus / nc -z 1521MySQL3306mysqladmin ping / nc -z 3306Redis6379redis-cli ping / nc -z 6379MongoDB27017mongosh --eval / nc -z 27017核心原则：用什么数据库，就用它的原生客户端做探测，最准确。没有客户端再用 nc 或 /dev/tcp 做端口探测兜底。