尧图网站建设 
Chainlink Local CRE 环境运维指南从env start到本地节点与能力构建【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文是 Chainlink 仓库中 Local CREChainlink Runtime Environment本地开发环境操作文档的完整技术指南核心对应文档位于 docs/local-cre/environment/index.mdCLI 实现位于 core/scripts/cre/environment。文章围绕环境生命周期、env start全量参数、本地源码构建节点与能力、镜像与 ECR 管理、Chip Ingress 栈与可观测性、状态持久化及故障排查展开读完即可独立完成一套本地 CRE 环境的启动、调试、重置与问题定位。CLI 入口与两种调用方式Local CRE 的 CLI 源码位于仓库的 core/scripts/cre/environment 目录入口为 main.go环境相关子命令在 environment/environment.go 中通过EnvironmentCmd注册。默认的调用方式是直接在源码目录下用go run执行cd core/scripts/cre/environment go run . command [subcommand]例如启动环境即go run . env start部署工作流即go run . workflow deploy。如果需要重复使用也可以安装为可执行二进制make install该命令会在 GNUmakefile 的驱动下产出local_cre二进制除常规命令外还包含交互式 shelllocal_cre sh适合在交互式终端中连续执行多条环境操作。env命令组在源码中注册了多个子命令组start、stop、status、workflow、chip-ingress-stack、swap、state、billing等见 environment.go其中env status可查看环境、Chip Ingress 栈、Billing、可观测性四类服务的运行状态。环境生命周期start / stop / restart / state purge启动环境go run . env start [--auto-setup]--auto-setup-a会在启动前先自动执行env setup来准备前置依赖。启动流程在源码中的实际执行顺序为先读取并校验配置CTF_CONFIGS指向的拓扑 TOML随后依次执行 Docker 检查、镜像预检、环境启动、状态持久化写入 repo 内状态文件等步骤详见 environment.go。停止环境go run . env stop go run . env stop --all普通stop仅移除环境容器并清理本地 CRE 状态文件--all-a会额外停止 Chip Ingress 栈、Billing 服务与可观测性栈并删除全部环境状态与缓存文件源码见 environment.go。值得注意的是stop之后若发现仍有附加服务在运行CLI 会打印对应服务的单独停止命令提示例如go run . env chip-ingress-stack stop、go run . env billing stop、go run . obs down。重启环境go run . env restart go run . env restart --with-chip-ingress-stackrestart是start的别名源码中Aliases: []string{restart}因此start的全部参数在restart下同样可用。清空环境状态go run . env state purge当已保存的状态或缓存的环境产物如~/.local/share/beholder、~/.local/share/observability、~/.local/share/chip_ingress_set、~/.local/share/ctf等缓存目录看起来不一致时使用purge一键清除env state list可先查看当前存在的状态文件与缓存目录源码见 environment.go。env start核心参数详解原文档列出的env start参数在源码中均有对应 Flag 定义见 environment.go下表补充了默认值与短标志参数短标志默认值说明--auto-setup-afalse启动前先运行env setup准备前置镜像与工具--wait-on-error-timeout-w15s启动失败时清理容器前等待的时长如10s、1m、1h--cleanup-on-error-lfalse启动失败时是否移除 Docker 容器并保存容器日志--extra-allowed-gateway-ports-e[]允许 Gateway Connector 出站连接的额外端口如8080,8081--with-example-xfalse启动后部署并验证一个示例工作流--example-workflow-timeout-u5m等待示例工作流成功的超时时间--with-chip-ingress-stack—false部署 Chip Ingress 栈Chip Ingress Red Panda--with-beholder-bfalse已废弃别名等价于--with-chip-ingress-stack--with-dashboards-dfalse部署可观测性栈并配置 Grafana 仪表盘--with-observability—false启动 OTel/Grafana 可观测性栈--with-billing—false部署 Billing Platform Service--setup-config-sconfigs/setup.tomlsetup 命令使用的 TOML 配置路径--grpc-port-g见chip-ingress.toml默认值Chip Ingress 的 gRPC 端口--local-node—false从本地工作树构建节点镜像并用于全部节点--local-capabilities—无从本地源码构建指定能力插件逗号分隔或all--capabilities-path—见下文本地 capabilities 仓库路径--local-build-platform—linux/host arch本地构建的目标平台如linux/arm64--local-node-image—cre-node:local本地构建节点镜像的 tag其中-p/--with-plugins-docker-image已彻底废弃源码在检测到该 Flag 时会直接报错并提示改为在拓扑 TOML 的[nodesets.nodesets.node_specs.node.image]字段中配置镜像见 environment.go。--extra-allowed-gateway-ports的底层实现会将这些端口与配置中 fake 服务的端口合并构造 Gateway Connector 的出站白名单WhitelistConfig默认放行0.0.0.0/0CIDR见 environment.go。从本地源码构建节点与能力默认情况下节点镜像来自拓扑的docker_ctx构建在 Docker 内构建能力插件则使用固定的上游版本。当你正在开发节点或某个能力时下面这些 Flag 会改为从本地工作树构建——包括本地replace指令例如本地chainlink-common这是 Docker 内构建无法感知的。相关实现集中在 environment/localbuild.go。--local-node本地交叉编译 Chainlink 节点在宿主机上交叉编译当前 checkout 的 Chainlink 节点烘焙进一个极简镜像基于ubuntu:24.04仅包含 ca-certificates、curl、libstdc6 与 chainlink 二进制并让拓扑中每一个节点都使用该镜像覆盖拓扑的docker_ctx/image。镜像 Dockerfile 由代码动态生成见 localbuild.go。源码中的一个重要联动逻辑如果只设置了--local-node而没有--local-capabilities由于本地极简镜像本身不携带任何能力插件代码会自动把能力构建范围默认为all保证 DON 拥有可用的插件见 localbuild.go。--local-capabilities names|all本地构建能力插件从本地源码构建指定 CRE 能力并通过capabilities/capabilities_container_dir注入到每个节点中覆盖节点镜像里内置的版本未列出的能力继续使用镜像版本。支持all或逗号分隔列表go run . env start --local-capabilities cron,consensus,evm,http-action,http-trigger源码中knownCapabilities表见 localbuild.go定义了可本地构建的能力及对应模块目录与输出二进制名能力名模块目录相对 capabilities 仓库额外构建参数croncron-tags timetzdataconsensusconsensus—http-actionhttp_action—http-triggerhttp_trigger—evmchain_capabilities/evm—名称同时接受中划线-与下划线_两种写法resolveCapabilities会统一规范化能力以CGO_ENABLED0交叉编译构建产物按capability_defaults.toml中的binary_name命名并在容器创建时复制到/usr/local/bin见 localbuild.go 与localBuildContainerCapDir常量。相关路径与环境变量--capabilities-path dir本地 capabilities 仓库位置默认取$CRE_CAPABILITIES_PATH否则为~/go/src/github.com/smartcontractkit/capabilities。--local-build-platform os/arch本地构建目标平台默认linux/host arch即 Docker Desktop 在 arm64 上跑 arm64 容器、amd64 上跑 amd64。--local-node-image tag本地构建节点镜像的 tag默认cre-node:local。一次性前置条件这些 Flag 不会自动执行C 交叉编译器当宿主机 OS/arch 与目标不一致时需要为节点的 CGO 构建准备交叉编译器可用CRE_LOCAL_CC/CRE_LOCAL_CXX/CRE_LOCAL_LIBDIR覆盖默认的 zig 包装器路径默认基于$CLCROSS即~/clcross在 Linux 宿主机构建linux/同架构时无需交叉编译器。托管镜像需先执行go run . env setup准备好 Job Distributor 等托管镜像。示例# 节点 全部能力均来自本地源码带可观测性 go run . env start --with-observability --local-node --local-capabilities all # 使用完整的固定版本节点镜像仅用本地构建覆盖 cron evm go run . env start --local-capabilities cron,evm环境初始化与镜像管理镜像来源的两条路径默认情况下 Local CRE 从本地分支构建 Chainlink 镜像。要改用预构建镜像只需在每个节点定义的拓扑 TOML 中设置image并省略docker_ctx与docker_file字段。默认拓扑示例见 configs/workflow-gateway-capabilities-don.toml其中节点通过docker_ctx ../../../..docker_file core/chainlink.Dockerfile指向仓库根目录的 core/chainlink.Dockerfile把这两项换成image chainlink-tmp:latest文件中的注释行即可切换为预构建镜像。env setup与托管镜像env setup用于确保所需托管镜像存在包括Job DistributorChip RouterChip IngressChip Config其行为由 configs/setup.toml 驱动每个组件都定义了build_config从源码构建与pull_config从 ECR 拉取两条路径。例如 Job Distributor 的构建配置指向job-distributor仓库v0.28.0分支的e2e/Dockerfile.e2e拉取配置使用模板{{.MAIN_ECR}}/job-distributor:0.28.0Chip Router 使用{{.SDLC_ECR}}/local-cre-chip-router:v1.0.1。镜像缺失时env setup会交互式询问 Pullp需要 AWS SSO还是 Buildb见 setup.go。setup命令还提供若干实用参数见 setup.gogo run . env setup --config configs/setup.toml --no-prompt # 非交互接受默认值 go run . env setup --purge # 清除已有镜像并重新拉取/构建 go run . env setup --build # 本地构建而非从 ECR 拉取Apple Silicon 上很有用 go run . env setup --with-billing # 一并准备 Billing 服务setup还会检查 DockermacOS 上会校验虚拟化框架、默认 socket、CPU ≥ 4 核、内存 ≥ 10 GB 等配置、AWS CLI、GitHub CLI最低版本由min_gh_cli_version指定默认v2.50.0、Bun 等前置工具并克隆 chainlink-observability 仓库到~/.local/share/observability源码见 setup.go。ECR 注册表配置从 ECR 拉取托管镜像时需要同时配置两个注册表环境变量MAIN_AWS_ECR核心托管 CRE 镜像SDLC_AWS_ECRChip Router 镜像Chip Router 镜像解析顺序启动时 Chip Router 镜像的解析顺序为CTF_CHIP_ROUTER_IMAGE若已设置当前拓扑 TOML 中的chip_router.image若解析出的 router 镜像本地缺失启动流程会走与 Chip Ingress 栈镜像相同的 build-or-pull 回退路径相关实现见 environment.go 的ensureChipRouterImageExists。Chip Ingress 栈与可观测性如何选择需要ChIP ingress 栈 Red Panda时使用--with-chip-ingress-stack--with-beholder为废弃别名需要Grafana 可观测性栈时使用--with-observability或--with-dashboards。相关重要参数--grpc-portChip Ingress 的 gRPC 端口--with-dashboards在可观测性之上额外配置仪表盘。启用后CLI 会等待 Grafana 在http://localhost:3000可用源码中最多轮询 30 秒见 environment.go随后调用观测仓库中的deploy-cre-local.sh脚本部署仪表盘。Chip Router 拓扑与端口Chip Router 是50051端口的 ingress owner节点将工作流遥测发送给 routerrouter 再扇出fan out给下游订阅者。当前本地端口分配端口用途50050Chip Router 管理 API50051Chip Router ingress gRPC50052chip-config50053真实 ChIP / Chip Ingress 栈 gRPC在测试场景中sink-backed 场景会向 Chip Router 注册一个测试 sinkstack-backed 场景则向 Chip Router 注册真实的 ChIP ingress源码见 chip_ingress_stack.go通过chiprouter.RegisterSubscriber完成注册。在不改动已提交 TOML 的前提下覆盖 router 镜像export CTF_CHIP_ROUTER_IMAGEchip-router:commit-sha该环境变量的优先级高于拓扑中的chip_router.image源码见 environment.go。状态存储与复用Local CRE 会把环境状态持久化到repo 内的状态文件envconfig.MustLocalCREStateFileAbsPath后续系统测试会复用这份状态——这正是 smoke-test 辅助函数能够检测到已存在环境、从而避免重复创建的原因。启动成功的配置含合约地址也会在结束时再次写入状态文件供测试读取见 environment.go。如需完全重置环境先执行go run . env state purge再重新运行env setup与env start。调试、遥测与追踪日常调试的主要手段仍然是检查核心节点日志与容器状态重建或热替换swap能力插件追踪工作流活动时启用可观测性与 Chip Ingress 栈。能力热替换相关命令与工作流专项命令见 Workflow Operations 与 Advanced Topics。Local CRE 栈支持的能力OTel 可观测性Chip Router 扇出 Chip Ingress 栈集成DX 追踪启动/设置结果会通过 tracking 组件上报源码见 environment.go。若需要完整的追踪栈用于调试或演示请在启动时启用可观测性并按 Advanced Topics 中的环境专属追踪配置进行设置。可观测性栈的 OTel 覆盖配置可参考 observability-overrides/otel.yaml。故障排查该领域最常见的失败场景Chainlink 节点迁移失败Docker 镜像未找到Docker 无法下载所需公共镜像gh缺失或未认证当启动出现问题时按顺序处理重新运行go run . env setup确认镜像访问与认证检查MAIN_AWS_ECR/SDLC_AWS_ECR是否设置、AWS SSO 会话是否有效、GitHub CLI 是否已gh auth login并执行gh auth setup-git若保存的状态已过期执行go run . env state purge若需要更多信号使用可观测性或 Chip Ingress 栈重启--with-observability/--with-chip-ingress-stack。源码对启动失败还有两道保护--cleanup-on-error会在失败时先保存容器日志到./logs再移除容器启动 panic 时同样会触发恢复处理器并尝试清理避免残留带ctf标签的容器与卷见 environment.go。另外启动前 CLI 会设置TESTCONTAINERS_RYUK_DISABLEDtrue防止 Ryuk 在命令结束后销毁容器。针对拓扑专属问题请继续阅读 Topologies and Capabilities完整的快速上手流程前置条件、env setup、首次启动与首个工作流部署见 Getting Started。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Chainlink Local CRE 环境运维指南：从 `env start` 到本地节点与能力构建
Chainlink Local CRE 环境运维指南从env start到本地节点与能力构建【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文是 Chainlink 仓库中 Local CREChainlink Runtime Environment本地开发环境操作文档的完整技术指南核心对应文档位于 docs/local-cre/environment/index.mdCLI 实现位于 core/scripts/cre/environment。文章围绕环境生命周期、env start全量参数、本地源码构建节点与能力、镜像与 ECR 管理、Chip Ingress 栈与可观测性、状态持久化及故障排查展开读完即可独立完成一套本地 CRE 环境的启动、调试、重置与问题定位。CLI 入口与两种调用方式Local CRE 的 CLI 源码位于仓库的 core/scripts/cre/environment 目录入口为 main.go环境相关子命令在 environment/environment.go 中通过EnvironmentCmd注册。默认的调用方式是直接在源码目录下用go run执行cd core/scripts/cre/environment go run . command [subcommand]例如启动环境即go run . env start部署工作流即go run . workflow deploy。如果需要重复使用也可以安装为可执行二进制make install该命令会在 GNUmakefile 的驱动下产出local_cre二进制除常规命令外还包含交互式 shelllocal_cre sh适合在交互式终端中连续执行多条环境操作。env命令组在源码中注册了多个子命令组start、stop、status、workflow、chip-ingress-stack、swap、state、billing等见 environment.go其中env status可查看环境、Chip Ingress 栈、Billing、可观测性四类服务的运行状态。环境生命周期start / stop / restart / state purge启动环境go run . env start [--auto-setup]--auto-setup-a会在启动前先自动执行env setup来准备前置依赖。启动流程在源码中的实际执行顺序为先读取并校验配置CTF_CONFIGS指向的拓扑 TOML随后依次执行 Docker 检查、镜像预检、环境启动、状态持久化写入 repo 内状态文件等步骤详见 environment.go。停止环境go run . env stop go run . env stop --all普通stop仅移除环境容器并清理本地 CRE 状态文件--all-a会额外停止 Chip Ingress 栈、Billing 服务与可观测性栈并删除全部环境状态与缓存文件源码见 environment.go。值得注意的是stop之后若发现仍有附加服务在运行CLI 会打印对应服务的单独停止命令提示例如go run . env chip-ingress-stack stop、go run . env billing stop、go run . obs down。重启环境go run . env restart go run . env restart --with-chip-ingress-stackrestart是start的别名源码中Aliases: []string{restart}因此start的全部参数在restart下同样可用。清空环境状态go run . env state purge当已保存的状态或缓存的环境产物如~/.local/share/beholder、~/.local/share/observability、~/.local/share/chip_ingress_set、~/.local/share/ctf等缓存目录看起来不一致时使用purge一键清除env state list可先查看当前存在的状态文件与缓存目录源码见 environment.go。env start核心参数详解原文档列出的env start参数在源码中均有对应 Flag 定义见 environment.go下表补充了默认值与短标志参数短标志默认值说明--auto-setup-afalse启动前先运行env setup准备前置镜像与工具--wait-on-error-timeout-w15s启动失败时清理容器前等待的时长如10s、1m、1h--cleanup-on-error-lfalse启动失败时是否移除 Docker 容器并保存容器日志--extra-allowed-gateway-ports-e[]允许 Gateway Connector 出站连接的额外端口如8080,8081--with-example-xfalse启动后部署并验证一个示例工作流--example-workflow-timeout-u5m等待示例工作流成功的超时时间--with-chip-ingress-stack—false部署 Chip Ingress 栈Chip Ingress Red Panda--with-beholder-bfalse已废弃别名等价于--with-chip-ingress-stack--with-dashboards-dfalse部署可观测性栈并配置 Grafana 仪表盘--with-observability—false启动 OTel/Grafana 可观测性栈--with-billing—false部署 Billing Platform Service--setup-config-sconfigs/setup.tomlsetup 命令使用的 TOML 配置路径--grpc-port-g见chip-ingress.toml默认值Chip Ingress 的 gRPC 端口--local-node—false从本地工作树构建节点镜像并用于全部节点--local-capabilities—无从本地源码构建指定能力插件逗号分隔或all--capabilities-path—见下文本地 capabilities 仓库路径--local-build-platform—linux/host arch本地构建的目标平台如linux/arm64--local-node-image—cre-node:local本地构建节点镜像的 tag其中-p/--with-plugins-docker-image已彻底废弃源码在检测到该 Flag 时会直接报错并提示改为在拓扑 TOML 的[nodesets.nodesets.node_specs.node.image]字段中配置镜像见 environment.go。--extra-allowed-gateway-ports的底层实现会将这些端口与配置中 fake 服务的端口合并构造 Gateway Connector 的出站白名单WhitelistConfig默认放行0.0.0.0/0CIDR见 environment.go。从本地源码构建节点与能力默认情况下节点镜像来自拓扑的docker_ctx构建在 Docker 内构建能力插件则使用固定的上游版本。当你正在开发节点或某个能力时下面这些 Flag 会改为从本地工作树构建——包括本地replace指令例如本地chainlink-common这是 Docker 内构建无法感知的。相关实现集中在 environment/localbuild.go。--local-node本地交叉编译 Chainlink 节点在宿主机上交叉编译当前 checkout 的 Chainlink 节点烘焙进一个极简镜像基于ubuntu:24.04仅包含 ca-certificates、curl、libstdc6 与 chainlink 二进制并让拓扑中每一个节点都使用该镜像覆盖拓扑的docker_ctx/image。镜像 Dockerfile 由代码动态生成见 localbuild.go。源码中的一个重要联动逻辑如果只设置了--local-node而没有--local-capabilities由于本地极简镜像本身不携带任何能力插件代码会自动把能力构建范围默认为all保证 DON 拥有可用的插件见 localbuild.go。--local-capabilities names|all本地构建能力插件从本地源码构建指定 CRE 能力并通过capabilities/capabilities_container_dir注入到每个节点中覆盖节点镜像里内置的版本未列出的能力继续使用镜像版本。支持all或逗号分隔列表go run . env start --local-capabilities cron,consensus,evm,http-action,http-trigger源码中knownCapabilities表见 localbuild.go定义了可本地构建的能力及对应模块目录与输出二进制名能力名模块目录相对 capabilities 仓库额外构建参数croncron-tags timetzdataconsensusconsensus—http-actionhttp_action—http-triggerhttp_trigger—evmchain_capabilities/evm—名称同时接受中划线-与下划线_两种写法resolveCapabilities会统一规范化能力以CGO_ENABLED0交叉编译构建产物按capability_defaults.toml中的binary_name命名并在容器创建时复制到/usr/local/bin见 localbuild.go 与localBuildContainerCapDir常量。相关路径与环境变量--capabilities-path dir本地 capabilities 仓库位置默认取$CRE_CAPABILITIES_PATH否则为~/go/src/github.com/smartcontractkit/capabilities。--local-build-platform os/arch本地构建目标平台默认linux/host arch即 Docker Desktop 在 arm64 上跑 arm64 容器、amd64 上跑 amd64。--local-node-image tag本地构建节点镜像的 tag默认cre-node:local。一次性前置条件这些 Flag 不会自动执行C 交叉编译器当宿主机 OS/arch 与目标不一致时需要为节点的 CGO 构建准备交叉编译器可用CRE_LOCAL_CC/CRE_LOCAL_CXX/CRE_LOCAL_LIBDIR覆盖默认的 zig 包装器路径默认基于$CLCROSS即~/clcross在 Linux 宿主机构建linux/同架构时无需交叉编译器。托管镜像需先执行go run . env setup准备好 Job Distributor 等托管镜像。示例# 节点 全部能力均来自本地源码带可观测性 go run . env start --with-observability --local-node --local-capabilities all # 使用完整的固定版本节点镜像仅用本地构建覆盖 cron evm go run . env start --local-capabilities cron,evm环境初始化与镜像管理镜像来源的两条路径默认情况下 Local CRE 从本地分支构建 Chainlink 镜像。要改用预构建镜像只需在每个节点定义的拓扑 TOML 中设置image并省略docker_ctx与docker_file字段。默认拓扑示例见 configs/workflow-gateway-capabilities-don.toml其中节点通过docker_ctx ../../../..docker_file core/chainlink.Dockerfile指向仓库根目录的 core/chainlink.Dockerfile把这两项换成image chainlink-tmp:latest文件中的注释行即可切换为预构建镜像。env setup与托管镜像env setup用于确保所需托管镜像存在包括Job DistributorChip RouterChip IngressChip Config其行为由 configs/setup.toml 驱动每个组件都定义了build_config从源码构建与pull_config从 ECR 拉取两条路径。例如 Job Distributor 的构建配置指向job-distributor仓库v0.28.0分支的e2e/Dockerfile.e2e拉取配置使用模板{{.MAIN_ECR}}/job-distributor:0.28.0Chip Router 使用{{.SDLC_ECR}}/local-cre-chip-router:v1.0.1。镜像缺失时env setup会交互式询问 Pullp需要 AWS SSO还是 Buildb见 setup.go。setup命令还提供若干实用参数见 setup.gogo run . env setup --config configs/setup.toml --no-prompt # 非交互接受默认值 go run . env setup --purge # 清除已有镜像并重新拉取/构建 go run . env setup --build # 本地构建而非从 ECR 拉取Apple Silicon 上很有用 go run . env setup --with-billing # 一并准备 Billing 服务setup还会检查 DockermacOS 上会校验虚拟化框架、默认 socket、CPU ≥ 4 核、内存 ≥ 10 GB 等配置、AWS CLI、GitHub CLI最低版本由min_gh_cli_version指定默认v2.50.0、Bun 等前置工具并克隆 chainlink-observability 仓库到~/.local/share/observability源码见 setup.go。ECR 注册表配置从 ECR 拉取托管镜像时需要同时配置两个注册表环境变量MAIN_AWS_ECR核心托管 CRE 镜像SDLC_AWS_ECRChip Router 镜像Chip Router 镜像解析顺序启动时 Chip Router 镜像的解析顺序为CTF_CHIP_ROUTER_IMAGE若已设置当前拓扑 TOML 中的chip_router.image若解析出的 router 镜像本地缺失启动流程会走与 Chip Ingress 栈镜像相同的 build-or-pull 回退路径相关实现见 environment.go 的ensureChipRouterImageExists。Chip Ingress 栈与可观测性如何选择需要ChIP ingress 栈 Red Panda时使用--with-chip-ingress-stack--with-beholder为废弃别名需要Grafana 可观测性栈时使用--with-observability或--with-dashboards。相关重要参数--grpc-portChip Ingress 的 gRPC 端口--with-dashboards在可观测性之上额外配置仪表盘。启用后CLI 会等待 Grafana 在http://localhost:3000可用源码中最多轮询 30 秒见 environment.go随后调用观测仓库中的deploy-cre-local.sh脚本部署仪表盘。Chip Router 拓扑与端口Chip Router 是50051端口的 ingress owner节点将工作流遥测发送给 routerrouter 再扇出fan out给下游订阅者。当前本地端口分配端口用途50050Chip Router 管理 API50051Chip Router ingress gRPC50052chip-config50053真实 ChIP / Chip Ingress 栈 gRPC在测试场景中sink-backed 场景会向 Chip Router 注册一个测试 sinkstack-backed 场景则向 Chip Router 注册真实的 ChIP ingress源码见 chip_ingress_stack.go通过chiprouter.RegisterSubscriber完成注册。在不改动已提交 TOML 的前提下覆盖 router 镜像export CTF_CHIP_ROUTER_IMAGEchip-router:commit-sha该环境变量的优先级高于拓扑中的chip_router.image源码见 environment.go。状态存储与复用Local CRE 会把环境状态持久化到repo 内的状态文件envconfig.MustLocalCREStateFileAbsPath后续系统测试会复用这份状态——这正是 smoke-test 辅助函数能够检测到已存在环境、从而避免重复创建的原因。启动成功的配置含合约地址也会在结束时再次写入状态文件供测试读取见 environment.go。如需完全重置环境先执行go run . env state purge再重新运行env setup与env start。调试、遥测与追踪日常调试的主要手段仍然是检查核心节点日志与容器状态重建或热替换swap能力插件追踪工作流活动时启用可观测性与 Chip Ingress 栈。能力热替换相关命令与工作流专项命令见 Workflow Operations 与 Advanced Topics。Local CRE 栈支持的能力OTel 可观测性Chip Router 扇出 Chip Ingress 栈集成DX 追踪启动/设置结果会通过 tracking 组件上报源码见 environment.go。若需要完整的追踪栈用于调试或演示请在启动时启用可观测性并按 Advanced Topics 中的环境专属追踪配置进行设置。可观测性栈的 OTel 覆盖配置可参考 observability-overrides/otel.yaml。故障排查该领域最常见的失败场景Chainlink 节点迁移失败Docker 镜像未找到Docker 无法下载所需公共镜像gh缺失或未认证当启动出现问题时按顺序处理重新运行go run . env setup确认镜像访问与认证检查MAIN_AWS_ECR/SDLC_AWS_ECR是否设置、AWS SSO 会话是否有效、GitHub CLI 是否已gh auth login并执行gh auth setup-git若保存的状态已过期执行go run . env state purge若需要更多信号使用可观测性或 Chip Ingress 栈重启--with-observability/--with-chip-ingress-stack。源码对启动失败还有两道保护--cleanup-on-error会在失败时先保存容器日志到./logs再移除容器启动 panic 时同样会触发恢复处理器并尝试清理避免残留带ctf标签的容器与卷见 environment.go。另外启动前 CLI 会设置TESTCONTAINERS_RYUK_DISABLEDtrue防止 Ryuk 在命令结束后销毁容器。针对拓扑专属问题请继续阅读 Topologies and Capabilities完整的快速上手流程前置条件、env setup、首次启动与首个工作流部署见 Getting Started。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考