使用 Encore Terraform Provider 对接既有基础设施数据源原理、配置与实战【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encoreEncore 是面向智能时代的应用基础设施平台开发者用声明式 SDK 直接在代码中定义数据库、缓存、Pub/Sub 等资源由平台自动在 AWS/GCP 上完成供给与管理。但当你的系统规模庞大、周边已经存在大量由 Terraform、CloudFormation 或云厂商控制台管理的既有设施时就需要把 Encore 供给的资源纳入统一的基础设施管理视图。本文基于 docs/platform/integrations/terraform.md 展开系统讲解 Encore 官方 Terraform Provider 的定位、数据源Data Source工作机制、Provider 配置与鉴权方式并通过真实案例演示如何将 Encore Pub/Sub Topic 与 AWS IoT Core 打通。读完本文你将掌握如何在既有 Terraform 工作流中读取 Encore 管理的云资源标识并安全地把鉴权信息接入 CI/CD 管线。Encore Terraform 数据源的本质只读引用而非资源管理在 Terraform 的词汇表里Resource资源负责创建、修改或销毁基础设施而Data Source数据源只负责读取信息本身不产生任何变更。Encore Terraform Provider 提供的数据源正是后者——它们是对Encore 已经替你供给完成的资源的只读引用read-only references。这一设计决定了它的使用方式你不需要在.tf文件中描述数据库、缓存等资源的完整配置——它们已经由 Encore 依据代码中的声明创建好了数据源的作用是检索云标识cloud identifiers例如数据库实例的 ARN、缓存集群的端点、Pub/Sub Topic 的 SNS ARN 等使用数据源时通常只需要提供资源名name和它所在的环境env两个参数Encore 就会返回该资源在当前环境下的真实标识。这与 Encore 的代码即单一事实来源single source of truth理念完全一致基础设施的生命周期仍由 Encore 的平台模型驱动Terraform 侧只做观察与引用不会出现两套声明互相冲突的局面。从源码与文档结构看Encore 的整个供给流程见 docs/platform/introduction.md以 SDK 声明构建基础设施模型再用该模型驱动云 API 供给资源Terraform 数据源相当于在这个模型之上开了一扇只读窗口。配置 Encore Terraform Provider声明 Provider 并初始化要使用 Encore 数据源第一步是在 Terraform 配置文件中声明 Provider。在terraform块中加入required_providersterraform { required_providers { encore { source registry.terraform.io/encoredev/encore } } }声明完成后在 Terraform 工作目录执行terraform initTerraform 会自动下载 Encore Provider 插件并完成初始化。之后便能正常执行terraform plan/terraform apply等常规操作。鉴权Auth Key 与 ENCORE_AUTH_KEY 环境变量Provider 需要调用 Encore API 才能查询资源信息因此必须配置一个Encore Auth Key完成认证。你可以在 Encore Cloud Dashboard 中生成 auth key路径为Your apps → 选择应用 → App Settings → Auth Keys详见 auth-keys.md。拿到 key 后可以直接写进 Provider 配置块provider encore { env your-env auth_key your-auth-key }但把密钥硬编码进配置文件并不安全。官方文档推荐的方式是设置ENCORE_AUTH_KEY环境变量让 Provider 从环境中读取密钥从而避免密钥入库、进版本控制export ENCORE_AUTH_KEYena_nEQIkfeM43t7oxpleMsIULbhbtLAbYnnLf1DAuth Key 的生成与管理细节结合仓库文档 auth-keys.md 可以补充以下几点关键信息Auth Key 有两种类型Reusable Keys可复用可用于认证多台机器适合长期存在的 CI/CD 环境但正因可复用一旦泄露危害极大官方明确建议存放在 1Password、LastPass 这类密钥保险库中Ephemeral Keys临时被此类 key 认证的机器会在1 小时后自动登出适合短时任务降低泄露窗口同一个 key 可以同时具有可复用和临时两种属性按场景组合即可。Auth Key 的身份语义Auth Key 以生成它的 Encore 应用的身份完成认证。例如开发者 Ada 生成一个 key 并用于配置 CI/CD 管线那么那台机器就是以 Ada 的 Encore 应用身份运行的。生成与吊销Dashboard 的 Auth Keys 页面可以创建与吊销 key出于安全考虑生成后页面不会再次显示完整 key 内容务必在生成时立即复制并存放到密钥保险库吊销 key 会立即阻止所有使用该 key 的机器继续向 Encore Cloud 认证与 key 类型无关。CLI 侧的认证实现佐证CLI 提供了对应的命令行认证方式可在 cli/cmd/encore/auth/auth.go 中看到encore auth login --auth-keyKEY其实现逻辑是loginCmd检测到--auth-key参数时调用DoLoginWithAuthKey()否则回退到设备码Device Auth流程。而DoLoginWithAuthKey()最终调用 cli/internal/platform/login.go 中的ExchangeAuthKey向/login/auth-key端点换取 OAuth 令牌并写入本地凭据配置conf.Write。这印证了 Auth Key 本质上是一种预认证凭据把浏览器交互登录替换为密钥交换特别适合无法交互式登录的 CI/CD 场景。此外cli/cmd/encore/auth/auth.go中还提供了encore auth whoami查看当前登录身份与encore auth logout登出并停止守护进程以清除缓存的凭据等配套命令。使用 Encore Terraform 数据源Provider 配置就绪后就可以在配置文件中引用 Encore 数据源。目前提供的数据源包括encore_database—— 读取 Encore 管理的 SQL 数据库信息encore_cache—— 读取 Encore 管理的缓存实例信息encore_pubsub_topic—— 读取 Encore 管理的 Pub/Sub Topic 信息。每个数据源都有一套自己的属性attributes用于取回该资源在云上的具体标识各数据源的完整属性清单以 Terraform Registry 中发布的最新文档为准。实战案例把 AWS IoT Core 接入 Encore Pub/Sub Topic官方文档给出了一个非常典型的场景Encore 应用内部使用 Pub/Sub 解耦服务而外部设备侧的消息需要经由 AWS IoT Core 流入这些 Topic。此时可以用encore_pubsub_topic数据源拿到 Encore 为 Topic 供给的 AWS 侧标识例如 SNS 主题的 ARN再把它交给 AWS IoT Topic Rule 作为转发目标data encore_pubsub_topic topic { name my-topic env my-env } resource aws_iot_topic_rule rule { name my-rule sql SELECT * FROM my-topic sns { message_format RAW role_arn aws_iam_role.role.arn target_arn data.encore_pubsub_topic.topic.aws_sns.arn } }这段配置的要点在于data.encore_pubsub_topic.topic只做查询按name my-topic、env my-env定位到 Encore 中具体环境的 Topic通过属性.aws_sns.arn拿到该 Topic 在 AWS 上对应的 SNS 主题 ARN这是 Encore 供给资源时创建的底层云资源标识该 ARN 被作为aws_iot_topic_rule的target_arn配合预先创建的 IAM Roleaws_iam_role.role.arn让 IoT 消息能以 RAW 格式投递到 Encore Pub/Sub Topic 中。同理encore_database、encore_cache数据源的输出属性也可以被其他 Terraform 资源、模块或输出变量output引用例如把数据库连接信息暴露给监控系统、备份任务或数据仓库同步作业。为什么 Encore 能与 Terraform 安全共存非全量同步的变更策略使用 Terraform Provider 引用 Encore 资源时一个自然的顾虑是两边会不会互相覆盖改动对此configuration.md 中明确了 Encore Cloud 的变更管理策略正是它与 Terraform、CloudFormation 等 IaC 工具和平共处的基础PATCH 式更新Encore 对云资源只做最小必要修改——采用 compare-and-set 等技巧仅变更需要调整的属性而不是整体重写避免全量同步Avoid full syncs与 Terraform 的整库 refresh 不同Encore 只为完成一次基础设施变更更新必要的资源从而降低意外改动的概率漂移感知Drift-aware每次变更前Encore 会拉取资源的当前属性若检测到漂移例如你在云控制台手动改过某项设置Encore 会更新内部表示以匹配当前状态——除非 Dashboard 中还存在未应用的变更请求。正是这三点保证了你可以在云厂商控制台、Terraform 与 Encore Cloud 之间安全地混用。Encore Cloud 也因此天然适合部分基础设施由外部管理的环境既可以与既有 Kubernetes 集群、已有云资源集成也不会因全量同步而覆盖手工改动。这一点同样体现在 migrate-away.md 的指导中——当团队逐步迁移时可以用 Terraform Provider 去引用那些并非由 Encore 管理的基础设施实现渐进式整合。使用前提与适用边界综合上述文档与仓库内容使用 Encore Terraform Provider 时请注意以下前提面向 Encore Cloud托管平台用户Provider 的数据源读取的是 Encore Cloud 为你供给的资源信息需要有效的 Encore 账号与对应环境的访问权限数据源是只读的它不会、也不能创建或修改 Encore 管理的资源——如果你需要 Terraform 侧的独立资源请直接使用对应云厂商的 Provider鉴权凭据要安全优先使用ENCORE_AUTH_KEY环境变量或密钥管理服务注入避免把 auth key 提交进.tf文件或代码仓库临时任务优先选择 Ephemeral Keys 缩短暴露窗口环境名要对应数据源中的env参数必须与 Encore 中实际的环境名称一致否则查询不到目标资源。小结Encore Terraform Provider 的价值在于把Encore 自动供给的资源与既有 Terraform 基础设施视图无缝衔接通过encore_database、encore_cache、encore_pubsub_topic等只读数据源你可以直接引用 Encore 管理资源的云标识如 SNS ARN将其接入 AWS IoT、监控告警、数据管道等周边系统借助ENCORE_AUTH_KEY环境变量与 Encore CLI 的encore auth login --auth-key能力实现见 cli/cmd/encore/auth/auth.go 与 cli/internal/platform/login.go整个集成过程可以完全自动化地跑在 CI/CD 中。再结合 Encore Cloud 的 PATCH 式更新与漂移感知策略你既享受了代码即基础设施的开发体验又不必牺牲对既有基础设施资产的掌控力。想进一步了解 Encore 供给基础设施的整体模型可继续阅读 docs/platform/infrastructure/infra.md供给与环境的底层机制和 docs/platform/infrastructure/configuration.mdDashboard 中的基础设施配置与进程分配策略。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Encore Terraform Provider 对接既有基础设施：数据源原理、配置与实战
使用 Encore Terraform Provider 对接既有基础设施数据源原理、配置与实战【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encoreEncore 是面向智能时代的应用基础设施平台开发者用声明式 SDK 直接在代码中定义数据库、缓存、Pub/Sub 等资源由平台自动在 AWS/GCP 上完成供给与管理。但当你的系统规模庞大、周边已经存在大量由 Terraform、CloudFormation 或云厂商控制台管理的既有设施时就需要把 Encore 供给的资源纳入统一的基础设施管理视图。本文基于 docs/platform/integrations/terraform.md 展开系统讲解 Encore 官方 Terraform Provider 的定位、数据源Data Source工作机制、Provider 配置与鉴权方式并通过真实案例演示如何将 Encore Pub/Sub Topic 与 AWS IoT Core 打通。读完本文你将掌握如何在既有 Terraform 工作流中读取 Encore 管理的云资源标识并安全地把鉴权信息接入 CI/CD 管线。Encore Terraform 数据源的本质只读引用而非资源管理在 Terraform 的词汇表里Resource资源负责创建、修改或销毁基础设施而Data Source数据源只负责读取信息本身不产生任何变更。Encore Terraform Provider 提供的数据源正是后者——它们是对Encore 已经替你供给完成的资源的只读引用read-only references。这一设计决定了它的使用方式你不需要在.tf文件中描述数据库、缓存等资源的完整配置——它们已经由 Encore 依据代码中的声明创建好了数据源的作用是检索云标识cloud identifiers例如数据库实例的 ARN、缓存集群的端点、Pub/Sub Topic 的 SNS ARN 等使用数据源时通常只需要提供资源名name和它所在的环境env两个参数Encore 就会返回该资源在当前环境下的真实标识。这与 Encore 的代码即单一事实来源single source of truth理念完全一致基础设施的生命周期仍由 Encore 的平台模型驱动Terraform 侧只做观察与引用不会出现两套声明互相冲突的局面。从源码与文档结构看Encore 的整个供给流程见 docs/platform/introduction.md以 SDK 声明构建基础设施模型再用该模型驱动云 API 供给资源Terraform 数据源相当于在这个模型之上开了一扇只读窗口。配置 Encore Terraform Provider声明 Provider 并初始化要使用 Encore 数据源第一步是在 Terraform 配置文件中声明 Provider。在terraform块中加入required_providersterraform { required_providers { encore { source registry.terraform.io/encoredev/encore } } }声明完成后在 Terraform 工作目录执行terraform initTerraform 会自动下载 Encore Provider 插件并完成初始化。之后便能正常执行terraform plan/terraform apply等常规操作。鉴权Auth Key 与 ENCORE_AUTH_KEY 环境变量Provider 需要调用 Encore API 才能查询资源信息因此必须配置一个Encore Auth Key完成认证。你可以在 Encore Cloud Dashboard 中生成 auth key路径为Your apps → 选择应用 → App Settings → Auth Keys详见 auth-keys.md。拿到 key 后可以直接写进 Provider 配置块provider encore { env your-env auth_key your-auth-key }但把密钥硬编码进配置文件并不安全。官方文档推荐的方式是设置ENCORE_AUTH_KEY环境变量让 Provider 从环境中读取密钥从而避免密钥入库、进版本控制export ENCORE_AUTH_KEYena_nEQIkfeM43t7oxpleMsIULbhbtLAbYnnLf1DAuth Key 的生成与管理细节结合仓库文档 auth-keys.md 可以补充以下几点关键信息Auth Key 有两种类型Reusable Keys可复用可用于认证多台机器适合长期存在的 CI/CD 环境但正因可复用一旦泄露危害极大官方明确建议存放在 1Password、LastPass 这类密钥保险库中Ephemeral Keys临时被此类 key 认证的机器会在1 小时后自动登出适合短时任务降低泄露窗口同一个 key 可以同时具有可复用和临时两种属性按场景组合即可。Auth Key 的身份语义Auth Key 以生成它的 Encore 应用的身份完成认证。例如开发者 Ada 生成一个 key 并用于配置 CI/CD 管线那么那台机器就是以 Ada 的 Encore 应用身份运行的。生成与吊销Dashboard 的 Auth Keys 页面可以创建与吊销 key出于安全考虑生成后页面不会再次显示完整 key 内容务必在生成时立即复制并存放到密钥保险库吊销 key 会立即阻止所有使用该 key 的机器继续向 Encore Cloud 认证与 key 类型无关。CLI 侧的认证实现佐证CLI 提供了对应的命令行认证方式可在 cli/cmd/encore/auth/auth.go 中看到encore auth login --auth-keyKEY其实现逻辑是loginCmd检测到--auth-key参数时调用DoLoginWithAuthKey()否则回退到设备码Device Auth流程。而DoLoginWithAuthKey()最终调用 cli/internal/platform/login.go 中的ExchangeAuthKey向/login/auth-key端点换取 OAuth 令牌并写入本地凭据配置conf.Write。这印证了 Auth Key 本质上是一种预认证凭据把浏览器交互登录替换为密钥交换特别适合无法交互式登录的 CI/CD 场景。此外cli/cmd/encore/auth/auth.go中还提供了encore auth whoami查看当前登录身份与encore auth logout登出并停止守护进程以清除缓存的凭据等配套命令。使用 Encore Terraform 数据源Provider 配置就绪后就可以在配置文件中引用 Encore 数据源。目前提供的数据源包括encore_database—— 读取 Encore 管理的 SQL 数据库信息encore_cache—— 读取 Encore 管理的缓存实例信息encore_pubsub_topic—— 读取 Encore 管理的 Pub/Sub Topic 信息。每个数据源都有一套自己的属性attributes用于取回该资源在云上的具体标识各数据源的完整属性清单以 Terraform Registry 中发布的最新文档为准。实战案例把 AWS IoT Core 接入 Encore Pub/Sub Topic官方文档给出了一个非常典型的场景Encore 应用内部使用 Pub/Sub 解耦服务而外部设备侧的消息需要经由 AWS IoT Core 流入这些 Topic。此时可以用encore_pubsub_topic数据源拿到 Encore 为 Topic 供给的 AWS 侧标识例如 SNS 主题的 ARN再把它交给 AWS IoT Topic Rule 作为转发目标data encore_pubsub_topic topic { name my-topic env my-env } resource aws_iot_topic_rule rule { name my-rule sql SELECT * FROM my-topic sns { message_format RAW role_arn aws_iam_role.role.arn target_arn data.encore_pubsub_topic.topic.aws_sns.arn } }这段配置的要点在于data.encore_pubsub_topic.topic只做查询按name my-topic、env my-env定位到 Encore 中具体环境的 Topic通过属性.aws_sns.arn拿到该 Topic 在 AWS 上对应的 SNS 主题 ARN这是 Encore 供给资源时创建的底层云资源标识该 ARN 被作为aws_iot_topic_rule的target_arn配合预先创建的 IAM Roleaws_iam_role.role.arn让 IoT 消息能以 RAW 格式投递到 Encore Pub/Sub Topic 中。同理encore_database、encore_cache数据源的输出属性也可以被其他 Terraform 资源、模块或输出变量output引用例如把数据库连接信息暴露给监控系统、备份任务或数据仓库同步作业。为什么 Encore 能与 Terraform 安全共存非全量同步的变更策略使用 Terraform Provider 引用 Encore 资源时一个自然的顾虑是两边会不会互相覆盖改动对此configuration.md 中明确了 Encore Cloud 的变更管理策略正是它与 Terraform、CloudFormation 等 IaC 工具和平共处的基础PATCH 式更新Encore 对云资源只做最小必要修改——采用 compare-and-set 等技巧仅变更需要调整的属性而不是整体重写避免全量同步Avoid full syncs与 Terraform 的整库 refresh 不同Encore 只为完成一次基础设施变更更新必要的资源从而降低意外改动的概率漂移感知Drift-aware每次变更前Encore 会拉取资源的当前属性若检测到漂移例如你在云控制台手动改过某项设置Encore 会更新内部表示以匹配当前状态——除非 Dashboard 中还存在未应用的变更请求。正是这三点保证了你可以在云厂商控制台、Terraform 与 Encore Cloud 之间安全地混用。Encore Cloud 也因此天然适合部分基础设施由外部管理的环境既可以与既有 Kubernetes 集群、已有云资源集成也不会因全量同步而覆盖手工改动。这一点同样体现在 migrate-away.md 的指导中——当团队逐步迁移时可以用 Terraform Provider 去引用那些并非由 Encore 管理的基础设施实现渐进式整合。使用前提与适用边界综合上述文档与仓库内容使用 Encore Terraform Provider 时请注意以下前提面向 Encore Cloud托管平台用户Provider 的数据源读取的是 Encore Cloud 为你供给的资源信息需要有效的 Encore 账号与对应环境的访问权限数据源是只读的它不会、也不能创建或修改 Encore 管理的资源——如果你需要 Terraform 侧的独立资源请直接使用对应云厂商的 Provider鉴权凭据要安全优先使用ENCORE_AUTH_KEY环境变量或密钥管理服务注入避免把 auth key 提交进.tf文件或代码仓库临时任务优先选择 Ephemeral Keys 缩短暴露窗口环境名要对应数据源中的env参数必须与 Encore 中实际的环境名称一致否则查询不到目标资源。小结Encore Terraform Provider 的价值在于把Encore 自动供给的资源与既有 Terraform 基础设施视图无缝衔接通过encore_database、encore_cache、encore_pubsub_topic等只读数据源你可以直接引用 Encore 管理资源的云标识如 SNS ARN将其接入 AWS IoT、监控告警、数据管道等周边系统借助ENCORE_AUTH_KEY环境变量与 Encore CLI 的encore auth login --auth-key能力实现见 cli/cmd/encore/auth/auth.go 与 cli/internal/platform/login.go整个集成过程可以完全自动化地跑在 CI/CD 中。再结合 Encore Cloud 的 PATCH 式更新与漂移感知策略你既享受了代码即基础设施的开发体验又不必牺牲对既有基础设施资产的掌控力。想进一步了解 Encore 供给基础设施的整体模型可继续阅读 docs/platform/infrastructure/infra.md供给与环境的底层机制和 docs/platform/infrastructure/configuration.mdDashboard 中的基础设施配置与进程分配策略。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考