Alpine Linux的核心价值是用不到5MB基础镜像支撑完整容器环境，依赖musl libc与BusyBox精简组合实现极致轻量，关键在选对方式、避开陷阱。
Alpine Linux 的核心价值，就是用不到 5MB 的基础镜像支撑起完整可用的容器运行环境。它不靠功能堆砌，而靠 musl libc + busybox 的精简组合实现极致轻量——部署本身不复杂，但关键在选对方式、避开常见陷阱。
直接拉取官方镜像启动容器
这是最常用也最推荐的入门方式，适合开发测试和多数生产服务：
- 执行 docker pull alpine:latest 获取当前稳定版（如 3.20.x），镜像体积通常为 4.8–5.2MB
- 运行临时交互容器：docker run -it --rm alpine:latest /bin/sh，可立即验证环境
- 若需后台长期运行，用 docker run -d --name myapp alpine:latest sleep infinity，再通过 docker exec -it myapp /bin/sh 进入管理
- 注意：默认镜像不含 ifconfig、netstat、ps 等命令，需按需用 apk add --no-cache iproute2 procps 安装，且务必加 --no-cache 防止缓存膨胀
构建自定义小体积应用镜像
真正把体积压到 50MB 以内，靠的不是“用 Alpine”，而是构建策略：
- 采用多阶段构建：第一阶段用 alpine:latest 编译代码（如 Go/Rust），第二阶段只 COPY 编译好的二进制文件，不带任何源码、编译器或中间产物
- 所有 apk add 命令必须带 --no-cache，例如：RUN apk --no-cache add ca-certificates nginx
- 避免分多次 RUN 安装包，合并依赖到单条指令中，减少镜像层数量和残留缓存
- 构建完成后检查体积：docker history your-image-name，确认无冗余层；用 docker image ls 查看最终大小
适配 musl libc 的兼容性要点
Alpine 轻量的前提是 musl，但这也带来一些隐性约束，绕过就能稳定运行：
- Java 应用不能直接用 Oracle JDK 或 OpenJDK 官方包（依赖 glibc），需安装 glibc 兼容层（如 sgerrand/alpine-pkg-glibc）或改用 OpenJDK Alpine 版本（如 azul/zulu-openjdk-alpine）
- MySQL 官方镜像不兼容 musl，推荐用 linuxserver/mysql 或原生 mariadb（apk add mariadb 即可启动服务端）
- DNS 解析行为与 glibc 不同：musl 忽略 /etc/resolv.conf 中的 search 和 domain 字段，Kubernetes 场景下建议显式配置 FQDN 或使用 CoreDNS 策略
进阶：用 Distroless 进一步瘦身
当 Alpine 仍不够轻（比如只跑一个静态二进制），可切换至更底层的运行时：
- 将 Dockerfile 中的 FROM alpine:latest 替换为 FROM gcr.io/distroless/base-debian12（musl 版本需确认支持）
- 前提是应用必须是静态编译（Go 默认开启，Rust 加 -C target-feature=+crt-static）
- 该镜像不含 shell、apk、甚至 /bin/sh，无法 exec 进入调试，但体积可压至 2–3MB，攻击面趋近于零
