后端云原生【免费下载链接】deisDeis v1, the CoreOS and Docker PaaS: Your PaaS. Your Rules.项目地址https://gitcode.com/gh_mirrors/de/deis点击查看免费下载Slug Runner 是 Deis v1基于 CoreOS 与 Docker 的 PaaS构建链路中的核心执行组件它以 Docker 容器形态接收由 Slug Builder 编译出的 gzipped 应用 tarballslug并在应用环境中启动任意命令、交互式 Shell 或 Procfile 中定义的进程类型。读完本文你将掌握 slug 的三种装载方式stdin、SLUG_URL、绑定挂载、start命令与默认进程类型的解析机制、profile.d 环境注入、基于 sdutil 的服务发现配置以及它在 Deis 整体 git push 部署流程中的真实调用位置。Slug 与 Slug Runner 的定位在 Heroku 风格的部署模型中应用源码并不直接在服务器上运行而是先被编译为一个称为slug的产物——一个包含已安装依赖、预编译产物与运行配置的 gzipped tarball。Deis 的 Builder 组件中同时存放着两个配套工具见 builder/rootfs/usr/local/src/ 目录slugbuilder把应用源码 tarball 通过官方及第三方 Heroku buildpack 编译成 slug.tgzslugrunner把编译好的 slug 解压到容器内应用目录并代为执行用户指定的命令或进程。Slug Runner 官方定位是运行由 slugbuilder 产生的 Heroku 风格 slug 的 Docker 容器。它做的事情非常聚焦通过 stdin 或 URL 接收一个 gzipped tarball让你能够在应用环境中运行一条命令或启动应用 Procfile 中定义的进程。获取 Slug Runner 镜像使用前需要先安装 Docker。有两种获取方式方式一直接拉取公共镜像$ docker pull flynn/slugrunner方式二从源码构建$ cd slugrunner $ make仓库中的 Makefile 揭示了构建过程的细节它先通过git clone拉取sdutil工具源码并用godep go build编译出build/sdutil二进制这是服务发现功能所依赖的可执行文件随后执行docker build -t flynn/slugrunner .构建镜像。也就是说make产出的镜像自带 sdutil开箱即可支持下文的服务发现特性。在 Deis 的 Builder 容器内部slugrunner 的源码目录会被注册为可构建标签相关路由定义见 builder/routes.go其中/usr/local/src/slugrunner/目录对应deis/slugrunner镜像标签。运行容器三种装载 Slug 的方式Slug Runner 的入口脚本是 runner/init由 Dockerfile 的ENTRYPOINT [/runner/init]指定。脚本启动后会按以下优先级加载应用 slug绑定挂载优先如果/app应用主目录下已有内容例如通过docker run -v挂载或 ONBUILD 注入则直接使用SLUG_URL 次之通过curl -s $SLUG_URL | tar -xzC $HOME下载并解压随后unset SLUG_URL防止变量泄漏到应用环境stdin 兜底cat | tar -xzC $HOME从标准输入流式解压。方式一stdin 管道传入 slug把本地myslug.tgz通过管道传给容器并执行应用内的 Rake 任务输出附加到 stdout$ cat myslug.tgz | docker run -i -a stdin -a stdout flynn/slugrunner rake mytask-i -a stdin保证 stdin 保持开启且被附加slug 二进制流才能被runner/init的cat正确读取。方式二SLUG_URL 环境变量加载通过 URL 加载 slug 是目前唯一能交互式运行的方式例如启动 Bash$ docker run -e SLUG_URLhttp://example.com/slug.tgz -i -t flynn/slugrunner /bin/bash-i -t分配伪终端。脚本内部unset SLUG_URL之后应用环境里不会再残留该变量。方式三结合 ONBUILD 的镜像化 slugDockerfile 末尾定义了三条 ONBUILD 指令ONBUILD RUN mkdir -p /app ONBUILD WORKDIR /app ONBUILD ADD slug.tgz /app这意味着你可以构建一个把 slug.tgz 直接打进镜像的派生镜像——这正是 Deis 在 builder/rootfs/etc/confd/templates/builder 中的做法当应用仓库没有 Dockerfile 时Builder 先用 slugbuilder 编译出 slug再生成一个仅含FROM deis/slugrunner的 Dockerfile最终docker build时 slug.tgz 通过 ONBUILD 被注入/app。此时 slugrunner 走的是第一种绑定挂载/预置内容分支无需 stdin 或 URL。命令执行环境不只是解压那么简单README 明确说明命令在应用环境中执行、工作目录是应用根目录、带有默认环境变量并且会 source 应用.profile.d目录下的脚本。runner/init脚本具体实现了这套环境准备逻辑export HOME/app mkdir -p $HOME ... ## Load profile.d and release config shopt -s nullglob mkdir -p .profile.d # If a file is created in slugbuilder with the wrong UID, change it. find . -user 1000 -exec chown slug:slug {} \; if [[ -s .release ]]; then ruby -e require yaml;(YAML.load_file(.release)[config_vars] || {}).each{|k,v| puts \#{k}#{v}\} .profile.d/config_vars fi for file in .profile.d/*; do source $file done hash -r关键点如下用户与权限修复slug 是由 slugbuilder 以 UID 1000 的用户编译的而容器内应用用户是slugUID 2000见 Dockerfile。脚本会把所有属主为 1000 的文件改归slug:slug但不动 UID 0root拥有的文件避免破坏系统文件权限。.release 配置变量注入如果 slug 根目录存在.release文件slugbuilder 编译时由 buildpack 的/bin/release脚本生成其中的config_vars会被 Ruby 解析后写入.profile.d/config_vars随后与其他 profile 脚本一起被source从而成为进程的默认环境变量。profile.d 脚本顺序执行所有.profile.d/*脚本按字典序逐个 source这使 buildpack 可以为应用注入 PATH、语言运行时版本等默认环境。hash -r清空 shell 命令哈希表确保新加入 PATH 的二进制如 ruby、rake能被正确找到。start 命令按 Procfile 启动进程Slug Runner 内置一个start子命令用于启动应用 Procfile 中定义的进程类型或 buildpack 提供的默认进程类型$ cat myslug.tgz | docker run -i -a stdin -a stdout -a stderr flynn/slugrunner start webrunner/init中start的解析逻辑是case $1 in start) if [[ -f Procfile ]]; then command$(ruby -e require yaml;puts YAML.load_file(Procfile)[$2]) else command$(ruby -e require yaml;puts (YAML.load_file(.release)[default_process_types] || {})[$2]) fi ;; *) command$ ;; esac若应用根目录存在ProcfileYAML 格式则直接读取其中对应进程类型的命令若没有 Procfile则回退到.release文件中的default_process_types由 buildpack 声明是 Heroku 官方一度非正式弃用、但 Deis 仍兼容的默认进程类型来源其他任何参数则原样作为 shell 命令执行。Deis 的 Builder 在构建完成后也会做同样的判断优先读取应用 Procfile否则从slug.tgz内提取./Procfile或./.release中的进程类型见 builder/rootfs/etc/confd/templates/builder并将结果作为 build 钩子的PROCFILE数据上报给 controller以便调度器按进程类型启动容器。默认的web进程类型会由调度器如 controller/scheduler/fleet.py实际拉起。服务发现通过 sdutil 注册Slug Runner 支持基于go-discover的服务发现实际执行时通过sdutil exec包装用户命令。runner/init中的相关逻辑如下if [[ $SD_NAME $PORT ]]; then if [[ $SD_HOST ]]; then runnersdutil exec -h $SD_HOST -s $SD_NAME:$PORT bash -c unset SD_HOST else runnersdutil exec -s $SD_NAME:$PORT bash -c fi unset SD_NAME elif [[ $SD_ARGS ]]; then runnersdutil $SD_ARGS bash -c unset SD_ARGS else runnerbash -c fi exec $runner $command三种模式的优先级与行为环境变量行为SD_NAMEPORT命令通过sdutil exec -s $SD_NAME:$PORT bash -c ...运行向服务发现注册$SD_NAME:$PORTSD_NAME在执行前被 unset避免递归注册PORT保留因为应用常在不使用服务发现时也读取它上述两者再加SD_HOST追加-h $SD_HOST指定服务发现的后端主机地址随后SD_HOST被 unsetSD_ARGS完全自定义 sdutil 命令行sdutil $SD_ARGS bash -c ...随后SD_ARGS被 unset均未设置退化为普通bash -c不涉及服务发现注意这里最终通过exec替换当前 shell 进程保证应用进程成为容器的 PID 1 进程信号与日志处理语义与直接运行一致。基础镜像环境镜像基于 Heroku 官方Cedar镜像FROM heroku/cedar:14这是 Heroku 经典运行环境内置了 ruby、python、node 等语言运行时与 buildpack 编译出的 slug 天然兼容。Dockerfile 中的其他关键设置创建slug系统用户UID/GID 2000主目录为/appUSER slug使容器内所有进程以非 root 身份运行默认暴露端口ENV PORT 5000EXPOSE 5000应用可通过$PORT环境变量感知监听端口可在运行容器时覆盖WORKDIR /app、ENV HOME /app与runner/init中的export HOME/app保持一致ENV DEIS_RELEASE 1.13.4标记了当前 Deis 版本。在 Deis v1 中的完整调用链把以上内容串起来一次git push deis master触发部署时Slug Runner 的完整生命周期是Builder 的 git receive-pack 钩子builder/rootfs/etc/confd/templates/builder接收到代码后若无 Dockerfile则以deis/slugbuilder运行编译容器把$TMP_DIR:/tmp/app与$CACHE_DIR:/tmp/cache:rw挂载进去slugbuilder 依据 buildpacks 把源码编译成/tmp/slug.tgzBuilder 通过docker cp把它取回应用目录Builder 写入FROM deis/slugrunner的 Dockerfile 并追加ENV GIT_SHA ...docker build时触发 ONBUILD 将slug.tgz注入/app镜像被打上HOST:PORT/app:git-xxxx标签推送到私有 registry见 push-images 模板 中deis/slugrunner:latest的推送逻辑之后调度器fleet在集群节点上用该镜像启动应用容器容器入口/runner/init检测到/app已预置内容直接跳过 stdin/URL 分支source 完 profile.d 后执行start process-type或调度器注入的命令。小结Slug Runner 的职责虽小却是 Deis v1buildpack 式部署模式的最后一环它把 buildpack 生态Procfile、.release、.profile.d、slug 格式与 Docker 运行时无缝衔接并以环境变量方式原生支持服务发现是整个 git push 部署链路从编译到运行的收尾组件。其核心实现集中在 runner/init约 76 行 Bash配合 Dockerfile 阅读即可完整掌握其行为。项目采用 BSD 许可源码目录同时附带 LICENSE 文件可供查阅。赞分享后端云原生【免费下载链接】deisDeis v1, the CoreOS and Docker PaaS: Your PaaS. Your Rules.项目地址https://gitcode.com/gh_mirrors/de/deis点击查看免费下载相关推荐Deis Slug Builder 深度解析用 Docker Buildpacks 将应用源码编译为 Heroku 风格 SlugDeis Slug Builder 深度解析用 Docker Buildpacks 将应用源码编译为 Heroku 风格 Slug 本篇文章以 Deis后端云原生FriendlyId作用域slug在同一模型下创建唯一slug的完整指南FriendlyId作为ActiveRecord的多功能工具提供了强大的slug生成功能其中作用域slug是最实用的高级特性之一。本文将详细介绍如何在同一模后端Draft: slugDraft: slug Components topology ledger ! Lock the SHAPE before depth. One row人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排上一篇Flint 溢出处理机制深度解析200个类目的图表如何依然可读过滤策略与警告系统下一篇xmpp4cj调试技巧:3种调试器报文拦截器,10分钟掌握XMPP通信观测方法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
