Apache OpenWhisk部署中ElasticSearch与Scheduler服务配置问题解析

部署环境准备

在Apache OpenWhisk的部署过程中，使用Ansible进行自动化部署是最常见的方式之一。当在Ubuntu 18.04系统上执行ansible-playbook -i environments/local openwhisk.yml命令时，可能会遇到控制器(Controller)和调度器(Scheduler)服务启动失败的问题。

典型错误现象

部署过程中常见的错误主要包括两类：

1. 控制器服务预热失败：表现为HTTP 404错误，提示请求的资源不存在，具体是/api/v1/namespaces/_/actions/invokerHealthTestAction0端点无法访问。

2. 调度器服务启动失败：表现为连接被拒绝，调度器的健康检查端点/ping无法响应，同时调度器容器日志中会显示ElasticSearch相关的配置错误。

问题根源分析

这些问题的根本原因在于OpenWhisk的默认配置与实际的部署环境不匹配：

1. ElasticSearch激活存储配置缺失：OpenWhisk默认配置了ElasticSearch作为激活存储后端，但部署时没有提供必要的ElasticSearch连接参数，导致调度器服务启动失败。

2. 服务依赖关系：调度器服务依赖于控制器服务的正常运行，而控制器服务又依赖于数据库服务的正确配置，形成了一个复杂的依赖链。

解决方案

方案一：配置ElasticSearch

如果确实需要使用ElasticSearch作为激活存储，需要在Ansible的配置文件中添加以下参数：

db_activation_backend: ElasticSearch
elastic_cluster_name: <集群名称>
elastic_protocol: <协议类型>
elastic_index_pattern: <索引模式>
elastic_base_volume: <数据卷目录>
elastic_username: <用户名>
elastic_password: <密码>

这些配置项需要根据实际的ElasticSearch集群情况进行设置。

方案二：使用替代方案

如果不需要ElasticSearch功能，可以采用以下替代方案：

1. 修改参考配置：在common/scala/src/main/resources/reference.conf文件中，将ElasticSearchDurationCheckerProvider替换为NoopDurationCheckerProvider。

2. 确保正确实现：注意不要混淆NoopDurationCheckerProvider和NoopDurationChecker，错误的实现会导致类型转换异常。

3. 验证服务状态：修改配置后，应该能够看到调度器服务正常启动，Ansible部署过程顺利完成。

部署后验证

成功部署后，需要注意以下几点：

1. CLI配置：使用wsk命令行工具时，正确的API端点应该是https://localhost，而不是standalone模式下的端口。

2. HTTPS支持：由于默认使用自签名证书，需要添加-i参数忽略证书验证：wsk list -i。

3. 服务检查：可以通过docker ps命令确认所有容器都正常运行，包括CouchDB、Kafka、Zookeeper、etcd等依赖服务。

经验总结

1. 配置一致性：确保所有服务的配置参数一致，特别是数据库后端的选择和相关参数。

2. 日志分析：遇到问题时，首先查看相关容器的日志，通常能快速定位问题原因。

3. 依赖管理：理解OpenWhisk各组件之间的依赖关系，有助于快速排查部署问题。

4. 环境隔离：建议在干净的测试环境中进行部署验证，避免已有服务造成端口冲突等问题。

通过以上分析和解决方案，可以顺利完成Apache OpenWhisk的部署工作，为后续的函数计算服务开发和测试奠定基础。