【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载导读本文围绕 Kubernetes 官方 Charts 仓库中 stable/mongodb Chart 的初始化脚本机制展开核心讲解如何通过files/docker-entrypoint-initdb.d目录放置自定义.sh/.js脚本使它们在 MongoDB 容器首次启动first boot时自动执行从而完成建库、建用户、导入种子数据等初始化工作。读完本文你将掌握脚本的放置位置与文件格式约定、Chart 源码中从文件打包到 ConfigMap 再到容器挂载的完整实现链路、以及基于initConfigMap复用外部配置的替代方案并可直接在 Helm 部署 MongoDB 时落地使用。一、机制概述什么是 docker-entrypoint-initdb.d在 stable/mongodb Chart 中files/docker-entrypoint-initdb.d/目录是专门预留给用户的自定义初始化脚本目录。目录内附带的 README.md 明确说明你可以在这里拷贝自定义的.sh或.js文件它们将在镜像的首次启动first boot期间被执行。这一机制源自 Bitnami MongoDB 官方镜像的约定当容器以一个全新的、尚未初始化的数据卷启动时镜像入口脚本会按文件名顺序依次执行该目录下的所有脚本。它适用于以下几类典型场景创建自定义数据库Database与用户User并赋予权限导入初始集合、索引或种子数据执行运维所需的初始化命令例如开启某些功能、写入配置。值得注意的是Chart 的 README.md 在 Initialize a fresh instance 一节对该机制做了进一步说明脚本必须位于 Chart 目录内的files/docker-entrypoint-initdb.d文件夹中以便它们被作为一个 ConfigMap 消费同时允许的扩展名是.sh和.js。这是对docker-entrypoint-initdb.d目录内 README 的官方补充两者共同构成了本主题的文档依据。二、脚本放置位置与格式约定2.1 目录位置在 Helm Chart 的目录结构中初始化脚本必须放在stable/mongodb/files/docker-entrypoint-initdb.d/也就是说Chart 的files目录与templates、values.yaml同级其下的docker-entrypoint-initdb.d子目录专门承载初始化脚本。部署时Helm 会将这些文件打包进发布物并经由 Chart 模板转换为 Kubernetes ConfigMap详见下文第三节。2.2 支持的文件格式根据 README.md 与模板中的匹配规则允许的扩展名包括扩展名用途说明.shShell 脚本可用于调用mongo/mongosh命令行工具执行初始化逻辑.jsJavaScript 脚本直接作为 MongoDB Shell 脚本执行.json模板匹配规则中也包含 json见源码*.sh\|js\|json但文档层面的官方说明以.sh、.js为准2.3 执行时机与执行顺序时机仅在容器首次启动即数据卷为空、尚未初始化时执行一旦数据库目录已被初始化后续重启不会重复执行。这是镜像层面的约定也是 Chart 文档明确写明的行为executed during the first boot of the image。顺序脚本按文件名顺序依次执行镜像入口脚本的标准行为。实战提醒由于只在首次初始化时执行若需要修改初始化逻辑必须在首次部署之前把脚本放入目录事后修改脚本不会对已初始化的实例生效。三、源码级原理从文件到 ConfigMap 再到容器挂载初始化脚本之所以能进入 Pod 并在/docker-entrypoint-initdb.d下被执行背后由 Chart 的三个模板协作完成。下面按数据流逐一剖析。3.1 第一步模板收集脚本文件并生成 ConfigMapinitialization-configmap.yaml 是整个机制的入口{{ if (.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json]) }} apiVersion: v1 kind: ConfigMap metadata: name: {{ template mongodb.fullname . }}-init-scripts labels: app: {{ template mongodb.name . }} chart: {{ template mongodb.chart . }} release: {{ .Release.Name | quote }} heritage: {{ .Release.Service | quote }} data: {{ tpl (.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json]).AsConfig . | indent 2 }} {{ end }}关键点解读(.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json])Helm 的Files.Glob函数会在 Chart 打包的文件范围内匹配files/docker-entrypoint-initdb.d/下以sh、js、json结尾的文件。该表达式同时充当开关只有当目录中存在这类文件时整个 ConfigMap 才会被渲染{{ if ... }}。.AsConfig将匹配到的每个文件内容映射为data字段中文件名 - 文件内容的键值对。tpl函数允许脚本内容中引用模板变量如{{ .Release.Name }}即脚本文件本身可以是模板化的在渲染阶段被展开。由此生成的 ConfigMap 名称遵循{{ template mongodb.fullname . }}-init-scripts的命名规则即release名-mongodb-init-scripts形式。3.2 第二步作为 Volume 挂载到 /docker-entrypoint-initdb.d生成的 ConfigMap 随后以 Volume 形式挂载进 MongoDB 容器。以独立部署standalone模式为例deployment-standalone.yaml 中的挂载逻辑为{{- if or (.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json]) (.Values.initConfigMap) }} - name: custom-init-scripts mountPath: /docker-entrypoint-initdb.d {{- end }}Volume 的定义deployment-standalone.yaml为volumes: {{- if (.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json]) }} - name: custom-init-scripts configMap: name: {{ template mongodb.fullname . }}-init-scripts {{- end }} {{- if (.Values.initConfigMap) }} - name: custom-init-scripts configMap: name: {{ .Values.initConfigMap.name }} {{- end }}可以看到custom-init-scripts这个 Volume 有两种来源Chart 自身files/docker-entrypoint-initdb.d/目录下的文件打包为*-init-scriptsConfigMap用户通过initConfigMap指定的外部 ConfigMap详见第五节。两者均挂载到容器内的/docker-entrypoint-initdb.d路径——这正是镜像入口脚本约定扫描的初始化目录。容器启动后镜像入口脚本即扫描该目录并依次执行其中的脚本。3.3 副本集模式下的等价实现在副本集Replica Set模式下同样的逻辑出现在 statefulset-primary-rs.yamlprimary 节点挂载与 statefulset-secondary-rs.yaml、statefulset-arbiter-rs.yamlsecondary / arbiter 节点中。以 primary 为例{{- if or (.Files.Glob files/docker-entrypoint-initdb.d/*[sh|js|json]) (.Values.initConfigMap) }} - name: custom-init-scripts mountPath: /docker-entrypoint-initdb.d {{- end }}Volume 定义同样支持来自目录打包或initConfigMap两种来源statefulset-primary-rs.yaml。这意味着无论你以 standalone 模式还是 replicaSet 模式部署初始化脚本机制都完整可用。3.4 完整调用链小结files/docker-entrypoint-initdb.d/*.sh|js|json │ Helm Files.Glob 收集 ▼ ConfigMap release-mongodb-init-scripts ← templates/initialization-configmap.yaml │ 以 volume 引用 ▼ Pod volume custom-init-scripts │ mountPath: /docker-entrypoint-initdb.d ▼ 容器首次启动 → 镜像入口脚本按序执行该目录下脚本四、实战示例编写初始化脚本4.1 示例一Shell 脚本创建数据库与用户假设我们要创建一个名为mydb的数据库和myuser用户可以编写如下.sh脚本#!/bin/bash # files/docker-entrypoint-initdb.d/init-user.sh set -e mongosh -- $MONGODB_ROOT_USER $MONGODB_ROOT_PASSWORD EOF use mydb db.createUser( { user: myuser, pwd: mypassword, roles: [ { role: readWrite, db: mydb } ] } ) EOF脚本通过标准输入把 MongoDB Shell 指令送入mongosh这里的MONGODB_ROOT_USER/MONGODB_ROOT_PASSWORD是 Chart 注入到容器环境中的 root 凭据环境变量Chart 的 README.md 与 templates/_helpers.tpl 中描述了首次初始化期间创建自定义用户和数据库的辅助能力其机制与脚本初始化同源互补set -e保证任何一步失败都会终止执行避免半初始化状态。4.2 示例二JavaScript 脚本导入种子数据.js脚本会直接作为 MongoDB Shell 脚本执行// files/docker-entrypoint-initdb.d/seed.js db db.getSiblingDB(mydb); db.products.insertMany([ { name: item-a, price: 100, tags: [new] }, { name: item-b, price: 200, tags: [sale] }, ]); db.products.createIndex({ name: 1 }, { unique: true });该脚本在初始化阶段创建mydb数据库、写入两条种子文档并建立唯一索引。注意初始化脚本运行在数据库首次启动阶段此时 root 凭据已由镜像完成初始化脚本可用其访问 admin 数据库进行授权操作。4.3 放置与部署将脚本放入目录后直接执行 Helm 安装即可生效$ helm install my-release stable/mongodbHelm 渲染时会在templates/initialization-configmap.yaml中自动生成 ConfigMap并把脚本挂载进容器。你可以用如下命令验证 ConfigMap 与 Pod 状态$ kubectl get configmap my-release-mongodb-init-scripts $ kubectl exec -it my-release-mongodb-xxxx -- ls -l /docker-entrypoint-initdb.d五、替代方案通过 initConfigMap 引用外部 ConfigMap除了在 Chart 目录内放置脚本Chart 还提供了initConfigMap参数允许直接引用一个预先创建好的外部 ConfigMap作为初始化脚本来源。在 values.yaml 中定义如下# Define custom config map with init scripts initConfigMap: {} # name: init-config-map使用时填写 ConfigMap 名称initConfigMap: name: init-config-map部署时$ helm install my-release stable/mongodb --set initConfigMap.nameinit-config-map两种来源在模板中属于或关系{{ if or (.Files.Glob ...) (.Values.initConfigMap) }}均可挂载到同一路径/docker-entrypoint-initdb.d。外部 ConfigMap 方案适合以下场景初始化脚本由团队外部或 CI/CD 流程统一维护不希望随 Chart 打包需要跨多个 Chart / Release 复用同一套初始化脚本脚本内容包含环境相关变量希望独立于 Chart 管理。六、使用注意事项与限制仅首次启动生效脚本只在数据卷为空、实例首次初始化时执行。若实例已有数据修改或新增脚本不会触发执行如需重新初始化需清理数据卷属破坏性操作须谨慎评估。格式约束脚本必须使用.sh、.js模板匹配规则同时兼容.json扩展名其他扩展名不会被Files.Glob匹配也就不会进入 ConfigMap。执行顺序多个脚本按文件名字典序执行若脚本之间存在依赖建议通过文件名前缀如00-xxx.sh、10-yyy.js控制执行顺序。脚本权限脚本内容经 ConfigMap 挂载容器以非 root 用户运行时应避免脚本依赖 root 权限操作Chart 默认通过 securityContext 以非 root 运行见 deployment-standalone.yaml 与 values.yaml 中的securityContext配置。失败即中断初始化失败会导致实例启动中断镜像入口脚本在初始化失败时会中止启动流程建议在脚本中显式处理错误并输出可诊断的日志。副本集模式primary、secondary、arbiter 各 StatefulSet 均挂载同一初始化目录初始化动作会按镜像逻辑在副本集环境中执行注意避免各节点执行冲突的初始化操作如重复建库建用户。七、验证与排障初始化完成后可通过如下方式验证效果# 进入 Pod 检查数据库是否创建成功 $ kubectl exec -it my-release-mongodb-xxxx -- mongosh mongodb://myuser:mypasswordlocalhost/mydb --eval db.runCommand({ connectionStatus: 1 }) # 查看初始化脚本是否已挂载 $ kubectl exec -it my-release-mongodb-xxxx -- ls -la /docker-entrypoint-initdb.d # 查看初始化阶段日志首次启动时 $ kubectl logs my-release-mongodb-xxxx --tail100 | grep -i init若初始化脚本未生效优先排查三点文件是否确实位于stable/mongodb/files/docker-entrypoint-initdb.d/且扩展名正确是否存在my-release-mongodb-init-scripts这个 ConfigMapkubectl get configmapPod 的 volume 中是否包含custom-init-scripts且已挂载到/docker-entrypoint-initdb.d。八、小结files/docker-entrypoint-initdb.d是 stable/mongodb Chart 提供的、基于 Bitnami MongoDB 镜像约定实现的首启初始化扩展点。通过 initialization-configmap.yaml 的 ConfigMap 生成、deployment-standalone.yaml 与 statefulset-primary-rs.yaml 的 Volume 挂载用户只需在 Chart 目录放入.sh/.js脚本即可在首次部署时自动完成建库、建用户、导数据等初始化动作也可通过initConfigMap参数引用外部 ConfigMap 实现脚本的集中化管理。理解这条文件 → ConfigMap → Volume → 容器首启执行的完整链路是灵活运用该机制的关键。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐Bitnami MariaDB Galera Helm Chart 初始化脚本指南docker-entrypoint-initdb.d 目录的完整用法Bitnami MariaDB Galera Helm Chart 初始化脚本指南docker entrypoint initdb.d 目录的完整用法 导读云原生容器编排kubernetes-handbook 实战基于 Helm Chart 在 Kubernetes 上部署 MongoDBBitnami MongoDB Chart 深度解析kubernetes handbook 实战基于 Helm Chart 在 Kubernetes 上部署 MongoDBBitnami MongoDB Ch教程云原生容器编排10分钟搞定Docker Windows容器自定义初始化脚本终极指南10分钟搞定Docker Windows容器自定义初始化脚本终极指南 想要在Docker容器中快速部署Windows系统吗Dockur/Windows项目让虚拟化上一篇lm-evaluation-harness 中的 Arab Culture 阿拉伯文化常识推理基准任务配置与评测指南下一篇LifeOS 健康数据层实战指南从 HEALTH.md 模板到可被 DA 推理的个人健康档案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考