OpenWhisk中使用自定义Ubuntu镜像创建Action的技术实践

背景与需求场景

在Serverless架构中，Apache OpenWhisk允许用户通过自定义Docker镜像来扩展运行时环境。某开发者遇到一个典型需求：希望基于自定义Ubuntu镜像创建Action，以执行特定的bash脚本任务。这种场景常见于需要特定系统依赖或定制化环境的函数计算场景。

核心问题分析

通过案例交流发现，开发者最初遇到的问题表现为Action调用超时并返回"Request accepted, but processing not completed yet"错误。经排查，这并非OpenWhisk框架本身的问题，而是源于镜像构建过程中的一个常见陷阱：

当开发者通过交互式方式（如先运行bash再commit）构建镜像时，会意外覆盖Dockerfile中定义的默认CMD指令。而OpenWhisk运行时依赖的actionProxy服务正是通过这个CMD指令启动的，这导致容器无法正常响应函数调用请求。

正确实现方案

1. 基础镜像构建规范

必须严格遵循OpenWhisk的docker运行时规范：

• 保持Dockerfile中定义的ENTRYPOINT和CMD不变
• 所有自定义软件包应通过Dockerfile的RUN指令安装
• 业务脚本建议放置在固定目录（如/app）

示例Dockerfile关键部分：

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y \
    your-custom-packages
COPY your-script.sh /app/

2. Action打包要点

• 将可执行脚本与必要的依赖一起打包
• 确保脚本具有可执行权限（chmod +x）
• 通过OpenWhisk CLI创建Action时正确指定入口点

3. 本地验证流程

建议的调试方法：

1. 使用docker run测试镜像基础功能
2. 通过actionProxy工具验证OpenWhisk兼容性
3. 逐步添加业务逻辑，每步进行验证

经验总结

1. 不可交互式commit：这会破坏OpenWhisk的容器启动机制
2. 分层构建原则：系统依赖与业务逻辑应分不同层处理
3. 最小化镜像：仅包含必要组件以减少冷启动时间
4. 日志输出：确保业务脚本有适当的日志输出机制

进阶建议

对于复杂场景，可以考虑：

• 使用多阶段构建减少镜像体积
• 通过OpenWhisk的序列化参数传递机制
• 结合Kubernetes调度实现大规模部署
• 设置合理的memory和timeout参数