企业官网建设流程全解析

导读

本文以 helm/charts 仓库中 stable/hubot 图表为核心，系统讲解如何在 Kubernetes 集群上通过 Helm 部署基于Hubot 3 与 Slack Adapter的聊天机器人。你将掌握该图表的全部可配置参数、ConfigMap/Secret 双通道环境变量注入机制、Redis 持久化脑（hubot-redis-brain）的接入方式、三种自定义脚本分发方案（npm 外部脚本、Git 仓库脚本、内联脚本），以及 Service/Ingress 的暴露方式，并了解从源码模板中反映出的底层实现细节。文章内容以原 README 为骨架，结合图表源码进行纵深印证，可直接用于实际部署与二次开发。

注意：该仓库已于 2020 年 11 月 13 日归档，stable/hubot图表在 Chart.yaml 中标记为deprecated: true，README 中也明确说明该图表已废弃且不再受支持，本文所有内容均基于该归档版本的真实实现展开。

图表概览与依赖

stable/hubot图表（chart 版本1.0.4，应用版本3.3.2）用于在 Kubernetes 集群上创建 Hubot Deployment，默认容器镜像为minddocdev/hubot:3.3.2。其核心依赖通过 requirements.yaml 声明：

dependencies: - name: redis version: ~9.4.0 repository: https://charts.helm.sh/stable condition: redis.enabled

Redis 依赖由redis.enabled条件控制（默认true），用于支撑hubot-redis-brain脚本的持久化存储。依赖锁定版本可参见 requirements.lock。

前置条件：Kubernetes 1.8+，且启用 Beta API（图表中的 Ingress 模板仍使用extensions/v1beta1的Ingress，见 ingress.yaml，在较新集群上需评估 API 兼容性）。

安装与卸载

安装图表

使用默认配置直接安装：

helm install stable/hubot

指定 release 名称安装：

helm install --name my-release stable/hubot

使用--set覆盖参数：

helm install --name my-release \ --set key_1=value_1,key_2=value_2 \ stable/hubot

使用自定义 values 文件（例如 staging 环境）：

helm install --name my-release -f values.yaml stable/hubot

默认配置可参考 values.yaml。

卸载图表

helm delete --purge my-release

该命令会删除与图表关联的所有 Kubernetes 组件（Deployment、Service、ConfigMap、Secret、Ingress 以及随依赖安装的 Redis 资源），并删除对应 release 记录。

配置参数总览

README 给出了完整的参数表，以下结合 values.yaml 与各模板逐项说明：

其中个别参数在源码模板中的实际语义值得说明：

• strategyType直接映射到 Deployment 的spec.strategy.type，见 deployment.yaml，默认RollingUpdate。
• args与extraArgs：在 deployment.yaml 中，args通过toYaml渲染进容器，extraArgs若非空会追加在其后，用于在启动参数层面补充--alias等选项。
• tty：values.yaml 注释说明该参数"只应在 CI 测试期间修改"，开启后会在容器上设置tty: true（deployment.yaml），这与 ci/test-values.yaml 中的 CI 场景一致。
• imagePullSecrets：values.yaml 未列出但模板支持，若设置会为 Deployment 添加imagePullSecrets（deployment.yaml）。

环境变量注入：config 与 secretConfig

图表提供两本字典：config与secretConfig。两本字典中的键值都会以环境变量的形式暴露给 Hubot 进程，供脚本读取。两者的区别在于存储介质：

• config字典保存为ConfigMap对象（config-cm.yaml），通过configMapRef注入容器环境（deployment.yaml）；
• secretConfig的取值保存为Secret对象（config-secret.yaml），通过secretRef注入（deployment.yaml）。

注意：secretConfig的 Secret 与config的 ConfigMap同名（均为<release名>-config），分别属于不同的 Kubernetes 资源类型，互不冲突。Secret 中的每个值在 config-secret.yaml 中通过b64enc进行 base64 编码存储。

示例：

config: HUBOT_STANDUP_PREPEND: '@channel' secretConfig: HUBOT_SLACK_TOKEN: 'xxx-secret-token-xxx'

在 values.yaml 中还有更多可参考的注释示例：

config: {} # HUBOT_URL: "http://hubot.mycompany.internal/" # HUBOT_LOG_LEVEL: 'debug' # HUBOT_CACHE_IMAGE: 'true' secretConfig: {} # HUBOT_SLACK_TOKEN: 'xoxb-somenumbers-someletters'

复用已有 Secret

若不想让图表创建 Secret，可通过existingSecretConfigName引用一个已存在的 Secret，其内容同样以secretRef方式注入（deployment.yaml）。config、secretConfig、existingSecretConfigName三者可以共存，最终都会合并进容器环境。

配置变更自动滚动

一个值得注意的实现细节：Deployment 的 Pod 模板注解中写入了多个checksum校验和，分别覆盖 config ConfigMap、secret ConfigMap（指config-secret.yaml渲染结果）、external-scripts.json 以及自定义脚本 ConfigMap（deployment.yaml）。这意味着当这些配置内容发生变化时，Deployment 的 Pod 模板哈希也会变化，从而自动触发滚动更新（RollingUpdate），无需手动kubectl rollout restart。

Redis 集成与 hubot-brain 持久化

默认：随图表部署 Redis

默认情况下图表会通过依赖部署一个 Redis 子图表，用于支撑hubot-redis-brain脚本为 Hubot 提供持久化存储。此时REDIS_URL环境变量会被自动设置（deployment.yaml）：

- name: REDIS_URL value: redis://{{ template "hubot.redis.fullname" . }}-master:{{ .Values.redis.port }}/hubot

Redis 主机名由 _helpers.tpl 中的hubot.redis.fullname定义模板生成，格式为<release名>-redis。

就绪等待：wait-for-redis initContainer

当redis.enabled为true时，Deployment 会附加一个wait-for-redisinitContainer（基于busybox），通过nc -zv循环探测 Redis 的-master服务端口，直到 Redis 可用后才启动主容器（deployment.yaml）：

initContainers: - name: wait-for-redis image: busybox env: - name: HUBOT_REDIS_HOST value: {{ template "hubot.redis.fullname" . }}-master - name: HUBOT_REDIS_PORT value: "{{ .Values.redis.master.service.port }}" command: [ "/bin/sh", "-c", "until nc -zv $HUBOT_REDIS_HOST $HUBOT_REDIS_PORT -w1; do echo 'waiting for redis'; sleep 1; done" ]

复用外部 Redis

如果希望 Hubot 使用已有的 Redis 实例，需要将redis.enabled设为false，并在config或secretConfig中手动设置REDIS_URL：

redis: enabled: false secretConfig: REDIS_URL: "redis://:password@mycompany.redis:6379/prefix"

这种方式下图表不会部署 Redis，也不会注入自动生成的REDIS_URL，完全由用户提供的实例地址决定。Redis 依赖相关的更多参数（如usePassword: false、cluster.enabled: false）可在 values.yaml 中查看。

自定义脚本：三种扩展方式

README 明确指出，可以通过三种途径为 Hubot 扩展脚本：

1. 通过 npm 安装并在external-scripts.json中启用；
2. 使用一个 Git 仓库存放脚本，并设置scriptsRepo.enabled为true（企业普遍使用专用脚本仓库）；
3. 在scripts哈希中内联列出脚本（适合小型脚本）。

此外还可以添加自定义脚本，以.js或.coffee格式放入 scripts 目录。

方式一：external-scripts.json 与 npm 包

externalScripts列表中的包名会被渲染进external-scripts.jsonConfigMap（external-scripts-cm.yaml），并以subPath方式挂载到/home/hubot/external-scripts.json（deployment.yaml）。

该模板会始终追加一组默认内置脚本，即使externalScripts为空也会包含：

[ "hubot-diagnostics", "hubot-help", "hubot-redis-brain", "hubot-rules", "hubot-health" ]

因此一个最小部署即可拥有诊断、帮助、规则、健康检查与 Redis 大脑等基础能力。而extraPackages列表则通过EXTRA_PACKAGES环境变量（以逗号连接）传给 Hubot 启动逻辑，用于安装自定义脚本所需的 npm 依赖：

extraPackages: [] # - aws-sdk # - cron # - underscore externalScripts: [] # - hubot-pugme # - hubot-plusplus

对应的注入逻辑见 deployment.yaml。

方式二：Git 仓库脚本（scriptsRepo）

这是企业内共享自定义脚本的推荐方式。启用后 Deployment 会添加一个基于git-sync镜像的checkout-scripts-repoinitContainer，将指定 Git 仓库 checkout 到共享的 emptyDir 卷（scripts），随后以subPath: scripts挂载到主容器的/home/hubot/scripts（deployment.yaml）。

典型配置：

scriptsRepo: enabled: true image: k8s.gcr.io/git-sync:v3.1.2 repository: "https://git.mycompany.com/hubot-scripts.git" branch: master username: git_username password: mysecretpassword

git-sync 相关环境变量（deployment.yaml）：

• GIT_SYNC_DEST=scripts：同步目标子目录；
• GIT_SYNC_REPO：仓库地址；
• GIT_SYNC_ONE_TIME=true：仅启动时同步一次（Hubot 场景无需持续同步）；
• GIT_SYNC_DEPTH=1：浅克隆；
• GIT_SYNC_BRANCH：指定分支，默认master。

凭据处理遵循两条分支：

• 若同时提供username/password且未设置existingSecretName，图表会创建名为<release名>-scripts-repo的 Secret（scripts-repo-secret.yaml），并以secretKeyRef方式注入GIT_SYNC_USERNAME/GIT_SYNC_PASSWORD；
• 若设置了existingSecretName，则直接引用该已有 Secret 中的username与password键（deployment.yaml）。

注意：values.yaml 中该字段名称为enabled（README 表格中写作enable），以 values.yaml 与实际模板判断条件为准。

方式三：内联脚本（scripts）

scripts哈希以"文件名: 脚本内容"的形式直接写入scriptsConfigMap（scripts-cm.yaml），随后每个脚本文件以subPath方式单独挂载到/home/hubot/scripts/<文件名>（deployment.yaml）。README 给出的示例：

scripts: hithere.coffee: | # Description # A hubot script that is an example for this chart module.exports = (robot) -> robot.respond /hi my bot/i, (msg) -> msg.send 'Hi there my human'

values.yaml 中也保留了相同结构的注释示例（values.yaml）。该方式适合少量、与部署绑定的快速脚本；脚本编写规范可参考官方 Hubot Scripting 文档。

网络暴露：Service 与 Ingress

Service

默认创建NodePort类型的 Service，端口80，targetPort指向容器内的http端口（容器实际监听8080，见 deployment.yaml），实现见 service.yaml。

Ingress

设置ingress.enabled: true后启用 Ingress，支持注解、多个 host、路径与 TLS：

ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" path: / hosts: - hubot.local tls: [] # - secretName: hubot-tls # hosts: # - hubot.local

渲染逻辑见 ingress.yaml：TLS 段遍历ingress.tls中的secretName与hosts，路由规则为每个 host 建立一条到 Service 名为http端口（servicePort: http）的路径转发。

安装完成后的访问指引由 NOTES.txt 根据 Service/Ingress 类型动态输出：

• Ingress 启用：输出http(s)://<host><path>；
• NodePort：通过kubectl get ... services获取nodePort与节点 IP，拼出http://$NODE_IP:$NODE_PORT；
• LoadBalancer：输出SERVICE_IP并提示可用kubectl get svc -w观察 IP 就绪状态；
• ClusterIP：提示使用kubectl port-forward <pod> 8080:80本地转发访问。

资源与调度

图表支持 Kubernetes 标准的资源与调度配置（values.yaml）：

• resources：请求与限制，默认留空（推荐交给用户按环境决策，以适配 Minikube 等小资源环境），模板通过toYaml渲染进容器（deployment.yaml）；
• nodeSelector/affinity/tolerations：节点选择、亲和性与容忍度，均有对应模板段（deployment.yaml）；
• extraLabels：会附加到 Deployment、ConfigMap、Secret、Service、Ingress 等所有资源上（各模板中均有{{ toYaml .Values.extraLabels | indent 4 }}）；
• extraConfigmapMounts：额外挂载已有 ConfigMap（适合证书、附加文件等），每项包含name、mountPath、configMap、readOnly字段，示例见 values.yaml。

健康检查与探针

主容器配置了 liveness 与 readiness 探针，均通过 HTTP GET 请求/health路径、使用名为http的容器端口（deployment.yaml）。配合默认脚本列表中的hubot-health，可保证：Pod 在 Hubot 健康接口未就绪前不会被纳入 Service 端点，故障时会被自动重启或摘除。

验证与 CI

仓库提供了 CI 冒烟测试配置 ci/test-values.yaml：

# CI values for Hubot. args: - --name - "test-bot" tty: true

它展示了如何通过覆盖args将机器人名称改为test-bot，并开启tty: true（配合 CI 环境下的交互输出）。tty参数在 values.yaml 中被明确标注为"仅在 CI 测试期间修改"，生产环境不建议开启。

部署完成后可通过以下方式验证运行状态：

helm status my-release kubectl get pods -l app.kubernetes.io/name=hubot kubectl logs -l app.kubernetes.io/name=hubot --tail=50

总结

stable/hubot图表为在 Kubernetes 上运行 Slack 聊天机器人提供了一套完整的开箱即用方案：通过config/secretConfig双通道实现环境变量分级管理，通过 Redis 依赖自动获得持久化大脑，通过三种脚本扩展机制灵活适配从个人玩具到企业级脚本仓库的各类需求，并通过 checksum 注解、initContainer 等待与健康探针保证了配置变更与依赖就绪场景下的平滑运维。尽管该图表已随仓库归档而废弃，其模板实现中体现的 Helm 图表设计模式（配置哈希滚动、initContainer 依赖等待、Secret 凭据注入分支等）在今天仍具有直接的参考价值。