Docker

镜像过大的危害 很多团队在容器化初期不太关注镜像体积，一个 Spring Boot 应用镜像动辄 800MB-1.2GB，一个 Go 应用也常有 700MB+。镜像过大带来的问题远不止"占点磁盘"： 拉取慢，部署延迟高：在 CI/CD 流水线或弹性扩容场景下，节点需要先拉取镜像再启动容器。1GB 的镜像在百兆内网下载需要 80 秒以上，而 50MB 的镜像仅需 4 秒。对于 HPA 自动扩容场景，这意味着故障恢复窗口被拉长。 安全攻击面大：基础镜像里包含了大量你根本用不到的系统工具（curl、wget、gcc、bash 等）。攻击者一旦拿到容器 shell，这些工具就是横向移动的跳板。镜像越小，攻击面越窄。 存储成本累积：一个镜像 1GB，每天构建 5 次、保留 30 天就是 150GB。10 个微服务就是 1.5TB。 Harbor / Registry 的存储成本和备份成本随之飙升。 构建缓存效率低：大镜像的每一层都更大，构建缓存命中后的加载也更慢，拖慢整体 CI 流水线。 本文参考 Docker 官方多阶段构建文档 多阶段构建（Multi-stage Build） 为什么需要多阶段构建 传统 Dockerfile 的关键问题是：构建工具和运行时环境混在同一个镜像里。 以 Go 应用为例，编译需要 go 工具链和 gcc，但运行时只需要一个二进制文件。如果用 golang:1.22 做基础镜像，最终镜像里会带上整个 Go SDK（约 800MB+），而你的应用二进制可能只有 15MB。 多阶段构建允许在一个 Dockerfile 中定义多个 FROM，每个 FROM 开始一个新阶段，最终镜像只保留最后一个阶段的内容。 多阶段构建语法 # ===== 阶段1：构建阶段 ===== FROM golang:1....

方案架构 Exporter → Prometheus（存储） → Grafana（可视化） ↓ Alertmanager（告警分发） Docker Compose 部署 version: '3.8' services: prometheus: image: prom/prometheus:v2.52.0 ports: ["9090:9090"] volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./rules:/etc/prometheus/rules - prom_data:/prometheus command: - '--storage.tsdb.retention.time=30d' restart: unless-stopped grafana: image: grafana/grafana:10.4.2 ports: ["3000:3000"] volumes: [grafana_data:/var/lib/grafana] restart: unless-stopped alertmanager: image: prom/alertmanager:v0.27.0 ports: ["9093:9093"] volumes: [./alertmanager.yml:/etc/alertmanager/config.yml] restart: unless-stopped node-exporter: image: prom/node-exporter:v1.8.1 ports: ["9100:9100"] restart: unless-stopped volumes: prom_data: grafana_data: 核心配置 # prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s rule_files: - "rules/*.yml" alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] scrape_configs: - job_name: 'node' static_configs: - targets: ['node-exporter:9100'] 常用 PromQL # CPU 使用率 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) # 内存使用率 (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 # 磁盘使用率 (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 告警规则示例 groups: - name: host-alerts rules: - alert: HighCPU expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "CPU 使用率过高 ({{ $labels....

概述 很多团队对 Docker Compose 的认知停留在"本地开发环境编排工具"。但事实上，在中小规模生产场景（单节点或少量节点）下，Compose 依然是性价比极高的方案。它语法简洁、学习成本低、不需要一整套 K8s 集群运维能力，就能完成多服务编排、依赖管理、健康检查、资源限制等核心工作。 本文不重复 Compose 基础语法，而是聚焦生产环境中的真实痛点：服务依赖怎么管才不会启动雪崩、健康检查怎么写才靠谱、密钥怎么不硬编码进 compose 文件、日志怎么不把磁盘写满、什么时候该从 Compose 迁移到 K8s。 本文基于 Docker Compose V2（docker compose 子命令），V1（docker-compose 独立二进制）已停止维护。参考 Compose 规范 多服务编排 生产级 Compose 文件结构 一个典型的生产环境应用至少包含：应用服务、数据库、缓存、反向代理。下面是一个完整的 Web 应用编排示例： # docker-compose.yml name: myapp services: # ========== 反向代理 ========== nginx: image: nginx:1.25-alpine container_name: myapp-nginx restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./nginx/conf.d:/etc/nginx/conf.d:ro - cert_data:/etc/letsencrypt:ro - log_data:/var/log/nginx depends_on: web: condition: service_healthy networks: - frontend logging: driver: json-file options: max-size: "10m" max-file: "3" # ========== 应用服务 ========== web: build: context: ....