
【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载导读本文以 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: trueREADME 中也明确说明该图表已废弃且不再受支持本文所有内容均基于该归档版本的真实实现展开。图表概览与依赖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.enabledRedis 依赖由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_1value_1,key_2value_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 与各模板逐项说明ParameterDescriptionDefaultfullnameOverride覆盖完整资源名称replicaCount期望 Pod 数量1strategyTypeDeployment 更新策略类型RollingUpdateimage.repository容器镜像仓库minddocdev/hubotimage.tag容器镜像标签3.3.2image.pullPolicy镜像拉取策略IfNotPresentservice.type创建的 Service 类型NodePortservice.porthttp 服务端口80configHubot 配置以环境变量注入{}secretConfig敏感环境变量以 Secret 注入{}existingSecretConfigName引用已有的包含敏感环境变量的 Secretargs传给 Hubot 二进制的参数[--name, ${HUBOT_NAME}, --adapter, --slack]extraArgsHubot 二进制的附加参数[]scripts自定义 hubot 脚本{}scriptsRepo.enable是否 checkout 一个脚本仓库falsescriptsRepo.image携带 git-sync 的镜像k8s.gcr.io/git-sync:v3.1.2scriptsRepo.repository要 checkout 的 Git 仓库scriptsRepo.branch仓库中要 checkout 的分支masterscriptsRepo.usernameGit 仓库用户名nullscriptsRepo.passwordGit 仓库密码nullscriptsRepo.existingSecretName如果 Git 凭据已存于某个 Secret 中则设置此项nullextraPackagesHubot 启动时要额外安装的 npm 包列表通常是脚本依赖[]externalScriptsexternal-scripts.json 的内容列出的包都会在启动时安装[]redis.enabled安装依赖图表 Redishubot-brain 需要trueingress.enabled是否添加 ingress 功能falseingress.annotationsingress 负载均衡注解Alwaysingress.path代理路径/ingress.hosts代理主机[ hubot.local ]ingress.tlstls 证书 secret[]resources资源请求与限制{}extraConfigMapMounts额外挂载的 ConfigMap适合附加文件、证书[]extraLabels添加到资源的额外标签{}nodeSelector节点选择逻辑{}tolerations资源容忍度{}affinity节点亲和性{}其中个别参数在源码模板中的实际语义值得说明strategyType直接映射到 Deployment 的spec.strategy.type见 deployment.yaml默认RollingUpdate。args与extraArgs在 deployment.yaml 中args通过toYaml渲染进容器extraArgs若非空会追加在其后用于在启动参数层面补充--alias等选项。ttyvalues.yaml 注释说明该参数只应在 CI 测试期间修改开启后会在容器上设置tty: truedeployment.yaml这与 ci/test-values.yaml 中的 CI 场景一致。imagePullSecretsvalues.yaml 未列出但模板支持若设置会为 Deployment 添加imagePullSecretsdeployment.yaml。环境变量注入config 与 secretConfig图表提供两本字典config与secretConfig。两本字典中的键值都会以环境变量的形式暴露给 Hubot 进程供脚本读取。两者的区别在于存储介质config字典保存为ConfigMap对象config-cm.yaml通过configMapRef注入容器环境deployment.yamlsecretConfig的取值保存为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 以及自定义脚本 ConfigMapdeployment.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 }}/hubotRedis 主机名由 _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.yamlinitContainers: - 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_URLredis: enabled: false secretConfig: REDIS_URL: redis://:passwordmycompany.redis:6379/prefix这种方式下图表不会部署 Redis也不会注入自动生成的REDIS_URL完全由用户提供的实例地址决定。Redis 依赖相关的更多参数如usePassword: false、cluster.enabled: false可在 values.yaml 中查看。自定义脚本三种扩展方式README 明确指出可以通过三种途径为 Hubot 扩展脚本通过 npm 安装并在external-scripts.json中启用使用一个 Git 仓库存放脚本并设置scriptsRepo.enabled为true企业普遍使用专用脚本仓库在scripts哈希中内联列出脚本适合小型脚本。此外还可以添加自定义脚本以.js或.coffee格式放入 scripts 目录。方式一external-scripts.json 与 npm 包externalScripts列表中的包名会被渲染进external-scripts.jsonConfigMapexternal-scripts-cm.yaml并以subPath方式挂载到/home/hubot/external-scripts.jsondeployment.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/scriptsdeployment.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: mysecretpasswordgit-sync 相关环境变量deployment.yamlGIT_SYNC_DESTscripts同步目标子目录GIT_SYNC_REPO仓库地址GIT_SYNC_ONE_TIMEtrue仅启动时同步一次Hubot 场景无需持续同步GIT_SYNC_DEPTH1浅克隆GIT_SYNC_BRANCH指定分支默认master。凭据处理遵循两条分支若同时提供username/password且未设置existingSecretName图表会创建名为release名-scripts-repo的 Secretscripts-repo-secret.yaml并以secretKeyRef方式注入GIT_SYNC_USERNAME/GIT_SYNC_PASSWORD若设置了existingSecretName则直接引用该已有 Secret 中的username与password键deployment.yaml。注意values.yaml 中该字段名称为enabledREADME 表格中写作enable以 values.yaml 与实际模板判断条件为准。方式三内联脚本scriptsscripts哈希以文件名: 脚本内容的形式直接写入scriptsConfigMapscripts-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 humanvalues.yaml 中也保留了相同结构的注释示例values.yaml。该方式适合少量、与部署绑定的快速脚本脚本编写规范可参考官方 Hubot Scripting 文档。网络暴露Service 与 IngressService默认创建NodePort类型的 Service端口80targetPort指向容器内的http端口容器实际监听8080见 deployment.yaml实现见 service.yaml。Ingress设置ingress.enabled: true后启用 Ingress支持注解、多个 host、路径与 TLSingress: 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.yamlTLS 段遍历ingress.tls中的secretName与hosts路由规则为每个 host 建立一条到 Service 名为http端口servicePort: http的路径转发。安装完成后的访问指引由 NOTES.txt 根据 Service/Ingress 类型动态输出Ingress 启用输出http(s)://hostpathNodePort通过kubectl get ... services获取nodePort与节点 IP拼出http://$NODE_IP:$NODE_PORTLoadBalancer输出SERVICE_IP并提示可用kubectl get svc -w观察 IP 就绪状态ClusterIP提示使用kubectl port-forward pod 8080:80本地转发访问。资源与调度图表支持 Kubernetes 标准的资源与调度配置values.yamlresources请求与限制默认留空推荐交给用户按环境决策以适配 Minikube 等小资源环境模板通过toYaml渲染进容器deployment.yamlnodeSelector/affinity/tolerations节点选择、亲和性与容忍度均有对应模板段deployment.yamlextraLabels会附加到 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/namehubot kubectl logs -l app.kubernetes.io/namehubot --tail50总结stable/hubot图表为在 Kubernetes 上运行 Slack 聊天机器人提供了一套完整的开箱即用方案通过config/secretConfig双通道实现环境变量分级管理通过 Redis 依赖自动获得持久化大脑通过三种脚本扩展机制灵活适配从个人玩具到企业级脚本仓库的各类需求并通过 checksum 注解、initContainer 等待与健康探针保证了配置变更与依赖就绪场景下的平滑运维。尽管该图表已随仓库归档而废弃其模板实现中体现的 Helm 图表设计模式配置哈希滚动、initContainer 依赖等待、Secret 凭据注入分支等在今天仍具有直接的参考价值。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐终极指南如何让老旧Mac重获新生支持最新macOS系统终极指南如何让老旧Mac重获新生支持最新macOS系统 还在为2012 2015年的MacBook Pro或iMac无法升级到最新macOS而烦恼吗Ope操作系统固件驱动开发如何将gte-base集成到生产环境完整部署指南与最佳实践如何将gte base集成到生产环境完整部署指南与最佳实践 gte base是一款高性能的文本嵌入模型在MTEB基准测试中表现出色为语义搜索、文档检索和文Hubot 部署实战在 Heroku 上部署你的机器人含环境变量、Redis 与 Dyno 保活完整指南Hubot 部署实战在 Heroku 上部署你的机器人含环境变量、Redis 与 Dyno 保活完整指南 Hubot 是 GitHub 开源的可定制聊天机后端交互助手上一篇HAJIMI Gemini API代理架构设计构建高可用AI服务网关的技术实现下一篇TapTap安装与配置全攻略从下载到完美运行的完整流程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考