OpenWhisk项目中Invoker组件更新与部署实践

问题背景

在分布式OpenWhisk环境中，当我们需要对Invoker组件进行代码修改时，往往会遇到修改后的代码无法在日志中体现的问题。这种情况通常发生在多机部署环境中，特别是当Controller和Invoker分别部署在不同服务器时。

问题现象

开发者修改了FunctionPullingContainerProxy.scala文件中的日志输出内容，重新构建了Invoker镜像并部署后，发现日志中仍然显示旧的输出内容。具体表现为：

• 修改了日志消息从"No more run activation..."变为"No more run Activation --testing-- is coming..."
• 通过gradlew命令重新构建了Invoker镜像
• 使用Ansible重新部署了OpenWhisk环境
• 检查日志发现修改未生效

根本原因分析

经过深入排查，发现问题源于以下两个方面：

1. 镜像部署机制问题：在多机环境中，Ansible配置文件中可能被临时修改为总是拉取nightly版本的Invoker镜像，导致本地构建的镜像被覆盖。

2. 镜像分发问题：在Controller机器上构建的Invoker镜像没有正确同步到运行Invoker的其他机器上，导致实际运行的仍然是旧版本镜像。

解决方案

方案一：手动镜像分发

1. 构建镜像：在Controller节点上执行构建命令

   ./gradlew :core:invoker:clean :core:invoker:distDocker
   

2. 导出镜像：将构建好的镜像导出为tar文件

   docker save -o invoker.tar whisk/invoker:latest
   

3. 传输镜像：将tar文件传输到所有运行Invoker的节点

   scp invoker.tar user@invoker-machine:~/
   

4. 加载镜像：在各Invoker节点上加载镜像

   docker load -i ~/invoker.tar
   

5. 重新部署：使用Ansible重新部署OpenWhisk

   cd ansible
   sudo ansible-playbook -i environments/local openwhisk.yml
   

方案二：自动化镜像分发

通过修改Ansible的deploy.yml文件，可以实现镜像分发的自动化：

- name: Save invoker Docker image
  command: docker save -o /tmp/invoker.tar whisk/invoker:latest
  delegate_to: localhost
  run_once: true

- name: Copy invoker image to all Invoker machines
  copy:
    src: /tmp/invoker.tar
    dest: /tmp/invoker.tar

- name: Load invoker Docker image on Invoker machines
  command: docker load -i /tmp/invoker.tar

方案三：使用私有镜像仓库

更专业的做法是搭建私有Docker镜像仓库，在构建镜像时指定私有仓库地址：

1. 构建时指定仓库：通过gradle参数指定目标仓库

   ./gradlew distDocker -PdockerRegistry=your.private.registry/
   

2. 配置Ansible使用私有仓库：修改Ansible配置，从私有仓库拉取镜像

最佳实践建议

1. 环境一致性：确保所有节点的Docker环境配置一致，特别是镜像仓库配置

2. 版本控制：为自定义镜像打上明确的版本标签，避免与官方镜像混淆

3. 构建验证：在构建完成后，立即验证镜像是否包含预期的修改

4. 部署前检查：在部署前确认各节点上的镜像版本

5. 日志监控：部署后立即检查日志，确认修改是否生效

总结

在OpenWhisk的分布式环境中更新Invoker组件需要特别注意镜像的分发机制。相比单机环境，多机部署需要额外的步骤来确保所有节点都使用更新后的镜像。通过建立规范的镜像分发流程，可以显著提高开发效率和部署可靠性。对于生产环境，建议采用私有镜像仓库方案，这不仅能解决镜像分发问题，还能提供更好的版本管理和安全控制。