Flask Docker容器体积过大引发AWS Elastic Beanstalk部署失败

一、容器体积过大的核心原因 #

• Docker构建缓存残留：之前添加Java安装步骤的镜像层仍被缓存，即使后续移除相关代码，docker build默认复用旧缓存层，导致冗余的Java环境和旧依赖层保留，体积未减小。
• 冗余依赖未彻底清理：最初用非虚拟环境pip freeze生成的requirements.txt包含大量无关依赖，后续修改后未强制重新构建依赖层，缓存中的旧依赖依然存在。
• 基础镜像选择冗余：使用全量python:3.9镜像（包含大量系统工具和库），而非轻量版镜像，本身就增加了基础体积。
• 未清理构建残留：pip install后未清理pip缓存，且未排除本地冗余文件（如venv、__pycache__），这些文件被复制到容器中额外占用空间。

二、解决容器体积过大的步骤 #

1. 强制清理Docker缓存，重新构建
   构建时跳过缓存，确保所有层重新生成：

   docker build --no-cache -t your-image-name .
   

   同时清理本地无用镜像和缓存：

   docker system prune -a
   

2. 生成精准的requirements.txt

   • 创建并激活虚拟环境，仅安装项目实际需要的依赖：

     python -m venv venv
     source venv/bin/activate  # Linux/macOS
     # 或 venv\Scripts\activate  # Windows
     pip install flask gunicorn apache-tika[all]  # 替换为你的实际依赖
     pip freeze > requirements.txt
     

   • 或使用pipreqs工具扫描源码自动生成最小依赖列表：

     pip install pipreqs
     pipreqs /path/to/your/project --force
     

3. 换用轻量基础镜像
   将Dockerfile的基础镜像替换为slim或alpine版本：

   # 兼容优先选slim
   FROM python:3.9-slim
   # 极致轻量化选alpine（注意部分依赖需额外安装系统库）
   # FROM python:3.9-alpine
   

4. 在Dockerfile中清理构建残留
   安装依赖后立即清理pip缓存，减少层体积：

   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt \
       && rm -rf /root/.cache/pip
   

5. 添加.dockerignore文件
   排除无需复制到容器的冗余文件，示例内容：

   venv/
   __pycache__/
   .git/
   *.log
   *.pyc
   tests/
   local-data/
   

6. 采用多阶段构建（可选）
   分离构建和运行环境，仅复制必要文件：

   # 第一阶段：构建依赖
   FROM python:3.9 as builder
   COPY requirements.txt .
   RUN pip install --user -r requirements.txt
   
   # 第二阶段：运行环境
   FROM python:3.9-slim
   COPY --from=builder /root/.local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages
   COPY . /app
   WORKDIR /app
   EXPOSE 5000
   CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]
   

三、解决AWS EB部署失败的方法 #

1. 验证镜像体积并重新推送ECR
   构建完成后查看镜像大小：

   docker images
   

   确保体积控制在500MB以内（EB拉取超时通常因镜像过大），然后重新推送到ECR：

   docker tag your-image-name:latest <ecr-repo-uri>:latest
   docker push <ecr-repo-uri>:latest
   

2. 检查EB配置正确性

   • 确认EB环境的容器端口配置为5000，与Dockerfile的EXPOSE一致。
   • 核对EB配置的ECR镜像URI和标签是否正确，确保指向最新构建的镜像。

3. 排查网络与实例问题

   • 检查EB所在VPC的网络配置：确保EC2实例有访问ECR的权限（通过IAM角色），且网络带宽足够拉取镜像。
   • 若使用小规格实例（如t2.micro），可临时升级实例类型（如t2.small）测试是否因资源不足导致超时。

4. 获取更详细的启动日志

   • 在EB控制台开启“增强型日志”，下载完整日志包查看容器启动细节。
   • 登录EC2实例，执行docker ps -a查看容器状态，用docker logs <container-id>查看应用启动日志，排查是否有隐藏的启动错误。

内容的提问来源于stack exchange，提问作者Math