尧图网站建设 
使用 Terraform 在 GCP 上部署 Aptos 验证节点与全节点从零到主网就绪的完整实战指南【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core导读本文以 aptos-core 仓库中 terraform/aptos-node/gcp/README.md 为核心指南完整讲解如何借助 Terraform 在 Google Cloud PlatformGCP上一键创建运行 Aptos 验证节点Validator与全节点Fullnode所需的全部云资源GKE 集群、节点池、VPC/NAT 网络、Cloud DNS 记录并最终通过 Helm Chart 将节点工作负载部署上集群。读完本文你将掌握从 GCP 项目准备、Terraform 状态管理、集群初始化到生成密钥、配置验证者信息、编译 genesis、注入 k8s Secret 并验证节点运行的端到端操作流程同时理解仓库中各 Terraform 文件的底层实现原理具备在生产环境独立运维 Aptos 节点的能力。一、部署架构与 Terraform 模块概览在动手操作之前先理解仓库中 GCP 部署模块的整体构成。模块位于 terraform/aptos-node/gcp与aws/、azure/目录并列共同组成 terraform/aptos-node 的多云部署体系。每个文件承担明确的职责文件职责main.tf声明google与google-betaProvider并批量启用 GCP 项目所需 APIcompute、container、iam、logging、monitoring、secretmanager、spanner、cloudkms 等 10 项服务cluster.tf创建 GKE 集群aptos-workspace与 core / utilities / validators 三个托管节点池network.tf创建 VPC 网络aptos-workspace、Cloud NAT 路由器及静态 IPauth.tf创建 GKE 专用服务账户并授予 logging / monitoring 相关 IAM 角色kubernetes.tf通过 Helm Provider 部署aptos-node与可选monitoringChartdns.tf可选地在一个已存在的 Cloud DNS zone 中创建验证节点与全节点的 A 记录variables.tf全部输入变量及其默认值定义outputs.tf输出 helm release 名称、GKE 集群名称/端点/CA 证书、Workload Identity 配置versions.tf声明 Terraform 与 Provider 版本约束从 versions.tf 可以看到当前仓库要求的版本为 Terraform~ 1.9.1google / google-beta Provider 均为~ 5.0.0同时使用 helm、kubernetes、local、random、time、tls 等 Provider。这比原 README 中建议的 Terraform 1.1.7 更新请以仓库实际约束为准。整个模块的核心部署链路是terraform apply→ 启用 GCP API → 创建 VPC 与 NAT → 创建 GKE 集群与节点池 → 创建ssd存储类基于 GCE PD-SSD→ 用 Helm 渲染 terraform/helm/aptos-node 中的aptos-nodeChart 部署 validator / fullnode / haproxy 工作负载。其中 GKE 集群被配置为私有节点集群enable_private_nodes true、master_ipv4_cidr_block 172.16.0.0/28并启用了 Workload Identityworkload_pool project.svc.id.goog与托管 Prometheus 监控详见 cluster.tf。二、前置条件账号、工具与项目准备本指南假定你已经完成 GCP 账号注册与项目创建若对 GCP 不熟悉可先按 aptos.dev 官方教程完成账号与项目的初始设置。在开始部署前需要安装以下三件工具Terraform基础设施即代码工具用于创建与管理云资源Kubernetes CLIkubectl用于与部署完成后创建的 GKE 集群交互查看 Pod 与服务Google Cloud CLIgcloud / gsutil用于管理 GCP 项目、创建存储桶、获取集群凭据等。其中aptos genesis系列命令来自 aptos-core 仓库自带的 CLI 工具源码位于 crates/aptos用于生成节点密钥、配置验证者信息与编译 genesis后续步骤会逐步用到。三、分步部署从工作区到集群就绪步骤 1创建工作目录与 Terraform 工作区名选择工作区名称例如testnet。注意这个名称定义了 Terraform workspace 名进而决定后续所有云资源的命名前缀如 GKE 集群aptos-testnet、VPCaptos-testnet、Servicetestnet-aptos-node-0-validator-lb。$ export WORKSPACEtestnet $ mkdir -p ~/$WORKSPACE步骤 2创建 Terraform 状态存储桶Terraform 需要将状态文件保存在一个全局唯一的 Google Cloud Storage 桶中远程状态锁可避免多人同时 apply 造成状态冲突。使用gsutil创建$ gsutil mb gs://BUCKET_NAME # 例如 $ gsutil mb gs://project-name-aptos-terraform-devBUCKET_NAME请替换为你实际创建的桶名必须全局唯一后文main.tf中会引用它。步骤 3-4编写main.tf并声明模块参数$ cd ~/$WORKSPACE $ touch main.tf在main.tf中配置 Terraform 后端与aptos-node模块引用示例如下terraform { required_version ~ 1.2.0 backend gcs { bucket BUCKET_NAME # 步骤 2 中创建的桶名 prefix state/aptos-node } } module aptos-node { # 从 aptos-labs/aptos-core 仓库下载 Terraform 模块 source github.com/aptos-labs/aptos-core.git//terraform/aptos-node/gcp?reftestnet region us-central1 # 指定 region zone c # 指定 zone 后缀 project GCP Project Name # 指定你的 GCP 项目名 era 1 # 增大 era 数字可清空链数据重新开始 chain_id 5 image_tag testnet # 指定要使用的 Docker 镜像 tag validator_name Name of Your Validator, no space }关于关键参数的含义region/zoneregion 必填zone 为空时创建区域级regional集群填写后缀如c则创建可用区级zonal集群见 variables.tfera链纪元编号是清空底层存储重新开始一条新链的手段对应 Helm 值chain.erachain_idAptos 链 IDimage_tag验证节点 / 全节点 Docker 镜像的 tag默认值为devnetvalidator_name验证者节点所有者名称不能包含空格。完整的自定义选项见 variables.tf以及 Helm 侧的 terraform/helm/aptos-node/values.yaml。仓库还提供了terraform.tfvars示例文件terraform/aptos-node/gcp/terraform.tfvars展示了 region、zone、validator_name、k8s_api_sources、zone_name 等常用变量如何以变量文件方式注入你可以在实际部署时用它替代main.tf中重复的变量赋值。步骤 5初始化 Terraform在main.tf所在目录执行$ terraform init该命令会下载所有 Terraform 依赖Provider 插件与aptos-node模块到当前工作目录下的.terraform文件夹中。步骤 6创建独立的 Terraform 工作区Terraform workspace 用于隔离不同环境如 dev / testnet / mainnet$ terraform workspace new $WORKSPACE # 列出所有工作区 $ terraform workspace list步骤 7应用配置$ terraform apply此过程可能耗时较长1020 分钟Terraform 会在你的云账号中创建全部资源。从源码看这一步实际会完成启用 10 个 GCP API见 main.tf、创建 VPC 与 Cloud NAT见 network.tf、创建私有 GKE 集群与三个节点池见 cluster.tf、为 GKE 服务账户绑定 logging/metrics 权限见 auth.tf并通过 Helm 部署aptos-nodeChart见 kubernetes.tf。步骤 8检查资源是否就绪apply完成后配置集群访问凭据并检查工作负载# 为 k8s 集群配置访问凭据 $ gcloud container clusters get-credentials aptos-$WORKSPACE --zone region/zone --project project # 查看 Pod应包含 haproxy、validator 和 fullnode其中 validator 与 fullnode 处于 pending后续步骤处理 $ kubectl get pods # 查看 Service应包含 validator-lb 和 fullnode-lb其 external-IP 可用于后续对外连接 $ kubectl get svc注意如果你刚创建 GCP 项目还需要授权集群的服务账户从aptos-globalDocker registry 拉取镜像——在 Artifact Registry 控制台中找到aptos-internal仓库进入Permissions页签点击ADD PRINCIPAL为服务账户授予Artifact Registry Reader角色。步骤 9获取节点对外 IP$ export VALIDATOR_ADDRESS$(kubectl get svc \ ${WORKSPACE}-aptos-node-0-validator-lb \ --output jsonpath{.status.loadBalancer.ingress[0].ip}) $ export FULLNODE_ADDRESS$(kubectl get svc \ ${WORKSPACE}-aptos-node-0-fullnode-lb \ --output jsonpath{.status.loadBalancer.ingress[0].ip})这两个 IP 分别对应验证节点的 6180 端口共识/网络与全节点的 6182 端口全节点对外服务。若配置了 Cloud DNSdns.tf 还会自动为二者创建 A 记录并输出/dns4/域名/tcp/端口格式的 multiaddr 端点validator_endpoint/fullnode_endpoint输出。四、验证者身份初始化密钥、配置与 genesis步骤 10生成密钥对$ aptos genesis generate-keys --output-dir ~/$WORKSPACE该命令会在工作目录生成四个文件public-keys.yaml各公钥汇总private-keys.yaml节点所有者账户、共识、网络的私钥validator-identity.yaml验证节点身份私钥validator-full-node-identity.yaml验证者全节点身份私钥。IMPORTANT请务必备份好这些密钥文件。它们是你确立节点所有权的凭证后续如果符合条件你将凭此信息申领奖励。步骤 11配置验证者信息$ aptos genesis set-validator-configuration \ --local-repository-dir ~/$WORKSPACE \ --username pick a username for your node \ --validator-host $VALIDATOR_ADDRESS:6180 \ --full-node-host $FULLNODE_ADDRESS:6182该命令会在工作目录下创建以你用户名命名的目录例如aptosbot内含两个文件operator.yaml运营商配置与owner.yaml所有者配置。operator.yaml内容形如--- operator_account_address: 2adeace541c3018d1117ae528c95a6cd91d924ab916f6e16d910b0668fe74b34 operator_account_public_key: 0xb612f2727550042e0f8e3c0525f2b64a01e987598bc17c01167ccc94b30e32b4 consensus_public_key: 0x92eed9b185de3745b374200a3bb5e2173573bf8822edcee473a668182a1b1232c692c9a5c008f7425e752bf9aa84e03c consensus_proof_of_possession: 0x810b0d3afb62e9905fcbe215a150d9709bb7c977ceaf05e1ab576c542b087743b35bf655e5db86c5db83ccbacb5926f40bc07e48bd2a00bcedacb43858a7fe3594890abccd03ff1ba340e3fe0e7895a27cdfe8739c16ca75e275af95d026caba validator_network_public_key: 0xe83246a3f3203bb3919621330417243c891e67d8efd3072e237d7d97d4bbe70f validator_host: host: xxx.xxx.xxx.xxx port: 6180 full_node_network_public_key: 0x8f385f894027cfaa95c46d8a3c1b50476114a8bcdb62b2c7c07b391509b45717 full_node_host: host: xxx.xxx.xxx.xxx port: 6182其中consensus_proof_of_possession是共识公钥的所有权证明用于向链上证明你确实持有对应私钥validator_host与full_node_host即步骤 9 中导出的两个负载均衡 IP 及对应端口。步骤 12创建 layout 文件测试模式layout.yaml用于定义验证者集合validatorSet中的节点构成。测试模式下可以创建只包含单个节点的 genesis blob生产模式下该文件由 Aptos Labs 生成无需手动执行。$ vi layout.yaml在其中填写 root key、节点用户名与 chain_id--- root_key: 0x5243ca72b0766d9e9cbf2debf6153443b01a1e0e6d086c7ea206eaf6f8043956 users: - username you created in step 11 chain_id: 5步骤 13下载 AptosFramework Move 字节码测试模式从 aptos-framework 发布版本下载framework.zip并解压得到名为framework的文件夹其中包含格式为.mv的 Move 字节码文件$ unzip framework.zip同样地此步骤仅测试模式需要生产模式由 Aptos Labs 生成。步骤 14编译 genesis blob 与 waypoint测试模式$ aptos genesis generate-genesis --local-repository-dir ~/$WORKSPACE --output-dir ~/$WORKSPACE该命令会在工作目录生成两个文件genesis.blob创世二进制文件包含框架framework、验证者集合validatorSet以及启动链所需的全部信息waypoint.txt创世交易的 waypoint用于验证节点在启动时确认自身所处链位置。步骤 15清点工作目录到这一步你的工作目录应包含以下文件private-keys.yaml所有者账户、共识、网络的私钥validator-identity.yaml设置验证节点身份用的私钥validator-full-node-identity.yaml设置验证者全节点身份用的私钥username.yaml验证节点 / 全节点的节点信息layout.yaml定义 root key、验证者用户与链 ID 的布局文件framework目录包含 AptosFramework 的全部 Move 字节码waypoint.txtgenesis 交易的 waypointgenesis.blob创世二进制包含框架、validatorSet 等信息。五、注入 Secret 并启动节点步骤 16将 genesis 与身份文件作为 Secret 注入集群$ kubectl create secret generic ${WORKSPACE}-aptos-node-genesis-e1 \ --from-filegenesis.blobgenesis.blob \ --from-filewaypoint.txtwaypoint.txt \ --from-filevalidator-identity.yamlvalidator-identity.yaml \ --from-filevalidator-full-node-identity.yamlvalidator-full-node-identity.yaml注意 Secret 名称中的-e1后缀对应era 1如果你修改了 era 数字创建 Secret 时必须同步修改后缀如 era2 则 Secret 名为-e2否则节点找不到对应的 genesis 数据。这正是 values.yaml 中chain.era注释所强调的增大该数字以清空底层存储的运维语义era 既是链数据版本号也是 Secret 命名的一部分。步骤 17确认所有 Pod 运行$ kubectl get pods正常输出形如NAME READY STATUS RESTARTS AGE node1-aptos-node-fullnode-e9-0 1/1 Running 0 4h31m node1-aptos-node-haproxy-7cc4c5f74c-l4l6n 1/1 Running 0 4h40m node1-aptos-node-validator-0 1/1 Running 0 4h30m当三个 Pod 全部处于Running状态时你的 Aptos 节点集群即已完成初始化验证节点与全节点均已接入网络开始同步。六、进阶配置变量与 Helm 值详解6.1 GKE 集群与节点池调优从 cluster.tf 与 variables.tf 可以看到模块内置了较强的默认配置常用可调项包括实例规格core 节点池默认e2-medium承载非关键控制面 Podutilities 节点池默认e2-standard-8承载 haproxyvalidators 节点池默认t2d-standard-60承载验证节点与全节点采用cpu_manager_policy static以启用独占 CPU 管理对应变量core_instance_type、utility_instance_type、validator_instance_type节点池数量与磁盘node_pool_sizes、instance_disk_sizes可覆盖各池节点数与磁盘大小default_disk_size_gb默认 100GB、default_disk_type默认pd-standard自动扩缩容gke_enable_node_autoprovisioning默认开启CPU 上限 500、内存上限 2000gke_autoscaling_profile默认OPTIMIZE_UTILIZATION单池最大节点数gke_autoscaling_max_node_count默认 250集群安全k8s_api_sources控制可访问 Kubernetes API 的 CIDR 白名单默认0.0.0.0/0集群启用了 Workload Identity 与屏蔽虚拟机secure boot、完整性监控taint 与调度validators 节点池默认打上aptos.org/nodepoolvalidators:NO_EXECUTEtaintvalidator_instance_enable_taint默认true并在 Helm values 中通过 nodeSelector 与 tolerations 将 validator / fullnode 调度到该池、将 haproxy 调度到 utilities 池实现控制面与数据面隔离见 kubernetes.tf。6.2 验证节点 / 全节点运行参数Helm Chart terraform/helm/aptos-node/values.yaml 提供了更细粒度的运行参数Terraform 模块通过helm_values、helm_values_file变量将自定义值透传给 Helm见 kubernetes.tf并可覆盖num_validators、num_fullnode_groups、validator_storage_size默认2048Gi存储类为模块创建的ssd等。值得关注的默认项资源预留validator 与 fullnode 的 CPU/内存 requests 与 limits 均为 30 核 / 60GiHAProxy 为 1 核 / 200Mirequests优雅停机terminationGracePeriodSeconds: 60保证共识 / REST 请求在 SIGTERM 后有时间落盘preStopSleepSeconds: 15让 kube-proxy 与 GKE NEG 控制器在 Pod 删除前先摘除端点避免流量在终止瞬间被切断服务暴露validator 与 fullnode 的 HAProxy 均以LoadBalancer类型对外externalTrafficPolicy: LocalREST API 默认开启enableRestApi: truemetrics / admin 端口默认关闭存储分片enable_storage_sharding默认true控制 RocksDB 存储分片开关通过chain.storage.rocksdb_configs.enable_storage_sharding注入 NodeConfig。6.3 可选监控设置enable_monitoring true可额外部署 terraform/helm/monitoring ChartPrometheus 栈并可通过monitoring_helm_values、enable_prometheus_node_exporter、enable_kube_state_metrics进一步控制监控组件见 kubernetes.tf。GKE 集群侧默认已开启托管 Prometheus 与全组件监控采集见 cluster.tf。七、运维要点与常见问题era 与数据重置增大era会清空底层存储、启动一条干净的新链。修改 era 后必须使用匹配的新 Secret 名-eN重新注入 genesis否则工作负载将无法启动。密钥安全private-keys.yaml、validator-identity.yaml等文件是节点所有权与奖励申领的凭证务必离线备份、妥善保管切勿提交到代码仓库。镜像拉取权限新创建的 GCP 项目默认无权访问aptos-global私有镜像仓库需手动为集群服务账户授予Artifact Registry Reader角色否则 Pod 会因 ImagePullBackOff 停滞。测试模式与生产模式差异步骤 1214layout.yaml、framework 字节码、genesis 编译仅适用于测试模式生产网络中这些产物由 Aptos Labs 统一生成与分发。IP 变更与节点身份validator-host/full-node-host在set-validator-configuration时写入若负载均衡 IP 变化需重新生成 operator.yaml 并在链上更新对应配置。多环境隔离利用 Terraform workspace步骤 6可在一套main.tf下隔离 dev / testnet / mainnet 多套环境资源命名会自动带上 workspace 前缀。结语通过 terraform/aptos-node/gcp 模块Aptos 节点运维者可以用一份声明式配置在 GCP 上完成网络 → 集群 → 工作负载 → DNS的全链路自动化部署再配合aptos genesis工具链完成身份初始化与创世数据注入。本文覆盖的 17 个步骤与源码级参数解析既可用于快速搭建测试网络也是理解生产环境部署流程生产模式下 genesis 由 Aptos Labs 提供的坚实基础。后续如需深度定制可继续研读 terraform/aptos-node/gcp/variables.tf 与 terraform/helm/aptos-node/values.yaml 中注释详尽的全部可调参数。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Terraform 在 GCP 上部署 Aptos 验证节点与全节点：从零到主网就绪的完整实战指南
使用 Terraform 在 GCP 上部署 Aptos 验证节点与全节点从零到主网就绪的完整实战指南【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core导读本文以 aptos-core 仓库中 terraform/aptos-node/gcp/README.md 为核心指南完整讲解如何借助 Terraform 在 Google Cloud PlatformGCP上一键创建运行 Aptos 验证节点Validator与全节点Fullnode所需的全部云资源GKE 集群、节点池、VPC/NAT 网络、Cloud DNS 记录并最终通过 Helm Chart 将节点工作负载部署上集群。读完本文你将掌握从 GCP 项目准备、Terraform 状态管理、集群初始化到生成密钥、配置验证者信息、编译 genesis、注入 k8s Secret 并验证节点运行的端到端操作流程同时理解仓库中各 Terraform 文件的底层实现原理具备在生产环境独立运维 Aptos 节点的能力。一、部署架构与 Terraform 模块概览在动手操作之前先理解仓库中 GCP 部署模块的整体构成。模块位于 terraform/aptos-node/gcp与aws/、azure/目录并列共同组成 terraform/aptos-node 的多云部署体系。每个文件承担明确的职责文件职责main.tf声明google与google-betaProvider并批量启用 GCP 项目所需 APIcompute、container、iam、logging、monitoring、secretmanager、spanner、cloudkms 等 10 项服务cluster.tf创建 GKE 集群aptos-workspace与 core / utilities / validators 三个托管节点池network.tf创建 VPC 网络aptos-workspace、Cloud NAT 路由器及静态 IPauth.tf创建 GKE 专用服务账户并授予 logging / monitoring 相关 IAM 角色kubernetes.tf通过 Helm Provider 部署aptos-node与可选monitoringChartdns.tf可选地在一个已存在的 Cloud DNS zone 中创建验证节点与全节点的 A 记录variables.tf全部输入变量及其默认值定义outputs.tf输出 helm release 名称、GKE 集群名称/端点/CA 证书、Workload Identity 配置versions.tf声明 Terraform 与 Provider 版本约束从 versions.tf 可以看到当前仓库要求的版本为 Terraform~ 1.9.1google / google-beta Provider 均为~ 5.0.0同时使用 helm、kubernetes、local、random、time、tls 等 Provider。这比原 README 中建议的 Terraform 1.1.7 更新请以仓库实际约束为准。整个模块的核心部署链路是terraform apply→ 启用 GCP API → 创建 VPC 与 NAT → 创建 GKE 集群与节点池 → 创建ssd存储类基于 GCE PD-SSD→ 用 Helm 渲染 terraform/helm/aptos-node 中的aptos-nodeChart 部署 validator / fullnode / haproxy 工作负载。其中 GKE 集群被配置为私有节点集群enable_private_nodes true、master_ipv4_cidr_block 172.16.0.0/28并启用了 Workload Identityworkload_pool project.svc.id.goog与托管 Prometheus 监控详见 cluster.tf。二、前置条件账号、工具与项目准备本指南假定你已经完成 GCP 账号注册与项目创建若对 GCP 不熟悉可先按 aptos.dev 官方教程完成账号与项目的初始设置。在开始部署前需要安装以下三件工具Terraform基础设施即代码工具用于创建与管理云资源Kubernetes CLIkubectl用于与部署完成后创建的 GKE 集群交互查看 Pod 与服务Google Cloud CLIgcloud / gsutil用于管理 GCP 项目、创建存储桶、获取集群凭据等。其中aptos genesis系列命令来自 aptos-core 仓库自带的 CLI 工具源码位于 crates/aptos用于生成节点密钥、配置验证者信息与编译 genesis后续步骤会逐步用到。三、分步部署从工作区到集群就绪步骤 1创建工作目录与 Terraform 工作区名选择工作区名称例如testnet。注意这个名称定义了 Terraform workspace 名进而决定后续所有云资源的命名前缀如 GKE 集群aptos-testnet、VPCaptos-testnet、Servicetestnet-aptos-node-0-validator-lb。$ export WORKSPACEtestnet $ mkdir -p ~/$WORKSPACE步骤 2创建 Terraform 状态存储桶Terraform 需要将状态文件保存在一个全局唯一的 Google Cloud Storage 桶中远程状态锁可避免多人同时 apply 造成状态冲突。使用gsutil创建$ gsutil mb gs://BUCKET_NAME # 例如 $ gsutil mb gs://project-name-aptos-terraform-devBUCKET_NAME请替换为你实际创建的桶名必须全局唯一后文main.tf中会引用它。步骤 3-4编写main.tf并声明模块参数$ cd ~/$WORKSPACE $ touch main.tf在main.tf中配置 Terraform 后端与aptos-node模块引用示例如下terraform { required_version ~ 1.2.0 backend gcs { bucket BUCKET_NAME # 步骤 2 中创建的桶名 prefix state/aptos-node } } module aptos-node { # 从 aptos-labs/aptos-core 仓库下载 Terraform 模块 source github.com/aptos-labs/aptos-core.git//terraform/aptos-node/gcp?reftestnet region us-central1 # 指定 region zone c # 指定 zone 后缀 project GCP Project Name # 指定你的 GCP 项目名 era 1 # 增大 era 数字可清空链数据重新开始 chain_id 5 image_tag testnet # 指定要使用的 Docker 镜像 tag validator_name Name of Your Validator, no space }关于关键参数的含义region/zoneregion 必填zone 为空时创建区域级regional集群填写后缀如c则创建可用区级zonal集群见 variables.tfera链纪元编号是清空底层存储重新开始一条新链的手段对应 Helm 值chain.erachain_idAptos 链 IDimage_tag验证节点 / 全节点 Docker 镜像的 tag默认值为devnetvalidator_name验证者节点所有者名称不能包含空格。完整的自定义选项见 variables.tf以及 Helm 侧的 terraform/helm/aptos-node/values.yaml。仓库还提供了terraform.tfvars示例文件terraform/aptos-node/gcp/terraform.tfvars展示了 region、zone、validator_name、k8s_api_sources、zone_name 等常用变量如何以变量文件方式注入你可以在实际部署时用它替代main.tf中重复的变量赋值。步骤 5初始化 Terraform在main.tf所在目录执行$ terraform init该命令会下载所有 Terraform 依赖Provider 插件与aptos-node模块到当前工作目录下的.terraform文件夹中。步骤 6创建独立的 Terraform 工作区Terraform workspace 用于隔离不同环境如 dev / testnet / mainnet$ terraform workspace new $WORKSPACE # 列出所有工作区 $ terraform workspace list步骤 7应用配置$ terraform apply此过程可能耗时较长1020 分钟Terraform 会在你的云账号中创建全部资源。从源码看这一步实际会完成启用 10 个 GCP API见 main.tf、创建 VPC 与 Cloud NAT见 network.tf、创建私有 GKE 集群与三个节点池见 cluster.tf、为 GKE 服务账户绑定 logging/metrics 权限见 auth.tf并通过 Helm 部署aptos-nodeChart见 kubernetes.tf。步骤 8检查资源是否就绪apply完成后配置集群访问凭据并检查工作负载# 为 k8s 集群配置访问凭据 $ gcloud container clusters get-credentials aptos-$WORKSPACE --zone region/zone --project project # 查看 Pod应包含 haproxy、validator 和 fullnode其中 validator 与 fullnode 处于 pending后续步骤处理 $ kubectl get pods # 查看 Service应包含 validator-lb 和 fullnode-lb其 external-IP 可用于后续对外连接 $ kubectl get svc注意如果你刚创建 GCP 项目还需要授权集群的服务账户从aptos-globalDocker registry 拉取镜像——在 Artifact Registry 控制台中找到aptos-internal仓库进入Permissions页签点击ADD PRINCIPAL为服务账户授予Artifact Registry Reader角色。步骤 9获取节点对外 IP$ export VALIDATOR_ADDRESS$(kubectl get svc \ ${WORKSPACE}-aptos-node-0-validator-lb \ --output jsonpath{.status.loadBalancer.ingress[0].ip}) $ export FULLNODE_ADDRESS$(kubectl get svc \ ${WORKSPACE}-aptos-node-0-fullnode-lb \ --output jsonpath{.status.loadBalancer.ingress[0].ip})这两个 IP 分别对应验证节点的 6180 端口共识/网络与全节点的 6182 端口全节点对外服务。若配置了 Cloud DNSdns.tf 还会自动为二者创建 A 记录并输出/dns4/域名/tcp/端口格式的 multiaddr 端点validator_endpoint/fullnode_endpoint输出。四、验证者身份初始化密钥、配置与 genesis步骤 10生成密钥对$ aptos genesis generate-keys --output-dir ~/$WORKSPACE该命令会在工作目录生成四个文件public-keys.yaml各公钥汇总private-keys.yaml节点所有者账户、共识、网络的私钥validator-identity.yaml验证节点身份私钥validator-full-node-identity.yaml验证者全节点身份私钥。IMPORTANT请务必备份好这些密钥文件。它们是你确立节点所有权的凭证后续如果符合条件你将凭此信息申领奖励。步骤 11配置验证者信息$ aptos genesis set-validator-configuration \ --local-repository-dir ~/$WORKSPACE \ --username pick a username for your node \ --validator-host $VALIDATOR_ADDRESS:6180 \ --full-node-host $FULLNODE_ADDRESS:6182该命令会在工作目录下创建以你用户名命名的目录例如aptosbot内含两个文件operator.yaml运营商配置与owner.yaml所有者配置。operator.yaml内容形如--- operator_account_address: 2adeace541c3018d1117ae528c95a6cd91d924ab916f6e16d910b0668fe74b34 operator_account_public_key: 0xb612f2727550042e0f8e3c0525f2b64a01e987598bc17c01167ccc94b30e32b4 consensus_public_key: 0x92eed9b185de3745b374200a3bb5e2173573bf8822edcee473a668182a1b1232c692c9a5c008f7425e752bf9aa84e03c consensus_proof_of_possession: 0x810b0d3afb62e9905fcbe215a150d9709bb7c977ceaf05e1ab576c542b087743b35bf655e5db86c5db83ccbacb5926f40bc07e48bd2a00bcedacb43858a7fe3594890abccd03ff1ba340e3fe0e7895a27cdfe8739c16ca75e275af95d026caba validator_network_public_key: 0xe83246a3f3203bb3919621330417243c891e67d8efd3072e237d7d97d4bbe70f validator_host: host: xxx.xxx.xxx.xxx port: 6180 full_node_network_public_key: 0x8f385f894027cfaa95c46d8a3c1b50476114a8bcdb62b2c7c07b391509b45717 full_node_host: host: xxx.xxx.xxx.xxx port: 6182其中consensus_proof_of_possession是共识公钥的所有权证明用于向链上证明你确实持有对应私钥validator_host与full_node_host即步骤 9 中导出的两个负载均衡 IP 及对应端口。步骤 12创建 layout 文件测试模式layout.yaml用于定义验证者集合validatorSet中的节点构成。测试模式下可以创建只包含单个节点的 genesis blob生产模式下该文件由 Aptos Labs 生成无需手动执行。$ vi layout.yaml在其中填写 root key、节点用户名与 chain_id--- root_key: 0x5243ca72b0766d9e9cbf2debf6153443b01a1e0e6d086c7ea206eaf6f8043956 users: - username you created in step 11 chain_id: 5步骤 13下载 AptosFramework Move 字节码测试模式从 aptos-framework 发布版本下载framework.zip并解压得到名为framework的文件夹其中包含格式为.mv的 Move 字节码文件$ unzip framework.zip同样地此步骤仅测试模式需要生产模式由 Aptos Labs 生成。步骤 14编译 genesis blob 与 waypoint测试模式$ aptos genesis generate-genesis --local-repository-dir ~/$WORKSPACE --output-dir ~/$WORKSPACE该命令会在工作目录生成两个文件genesis.blob创世二进制文件包含框架framework、验证者集合validatorSet以及启动链所需的全部信息waypoint.txt创世交易的 waypoint用于验证节点在启动时确认自身所处链位置。步骤 15清点工作目录到这一步你的工作目录应包含以下文件private-keys.yaml所有者账户、共识、网络的私钥validator-identity.yaml设置验证节点身份用的私钥validator-full-node-identity.yaml设置验证者全节点身份用的私钥username.yaml验证节点 / 全节点的节点信息layout.yaml定义 root key、验证者用户与链 ID 的布局文件framework目录包含 AptosFramework 的全部 Move 字节码waypoint.txtgenesis 交易的 waypointgenesis.blob创世二进制包含框架、validatorSet 等信息。五、注入 Secret 并启动节点步骤 16将 genesis 与身份文件作为 Secret 注入集群$ kubectl create secret generic ${WORKSPACE}-aptos-node-genesis-e1 \ --from-filegenesis.blobgenesis.blob \ --from-filewaypoint.txtwaypoint.txt \ --from-filevalidator-identity.yamlvalidator-identity.yaml \ --from-filevalidator-full-node-identity.yamlvalidator-full-node-identity.yaml注意 Secret 名称中的-e1后缀对应era 1如果你修改了 era 数字创建 Secret 时必须同步修改后缀如 era2 则 Secret 名为-e2否则节点找不到对应的 genesis 数据。这正是 values.yaml 中chain.era注释所强调的增大该数字以清空底层存储的运维语义era 既是链数据版本号也是 Secret 命名的一部分。步骤 17确认所有 Pod 运行$ kubectl get pods正常输出形如NAME READY STATUS RESTARTS AGE node1-aptos-node-fullnode-e9-0 1/1 Running 0 4h31m node1-aptos-node-haproxy-7cc4c5f74c-l4l6n 1/1 Running 0 4h40m node1-aptos-node-validator-0 1/1 Running 0 4h30m当三个 Pod 全部处于Running状态时你的 Aptos 节点集群即已完成初始化验证节点与全节点均已接入网络开始同步。六、进阶配置变量与 Helm 值详解6.1 GKE 集群与节点池调优从 cluster.tf 与 variables.tf 可以看到模块内置了较强的默认配置常用可调项包括实例规格core 节点池默认e2-medium承载非关键控制面 Podutilities 节点池默认e2-standard-8承载 haproxyvalidators 节点池默认t2d-standard-60承载验证节点与全节点采用cpu_manager_policy static以启用独占 CPU 管理对应变量core_instance_type、utility_instance_type、validator_instance_type节点池数量与磁盘node_pool_sizes、instance_disk_sizes可覆盖各池节点数与磁盘大小default_disk_size_gb默认 100GB、default_disk_type默认pd-standard自动扩缩容gke_enable_node_autoprovisioning默认开启CPU 上限 500、内存上限 2000gke_autoscaling_profile默认OPTIMIZE_UTILIZATION单池最大节点数gke_autoscaling_max_node_count默认 250集群安全k8s_api_sources控制可访问 Kubernetes API 的 CIDR 白名单默认0.0.0.0/0集群启用了 Workload Identity 与屏蔽虚拟机secure boot、完整性监控taint 与调度validators 节点池默认打上aptos.org/nodepoolvalidators:NO_EXECUTEtaintvalidator_instance_enable_taint默认true并在 Helm values 中通过 nodeSelector 与 tolerations 将 validator / fullnode 调度到该池、将 haproxy 调度到 utilities 池实现控制面与数据面隔离见 kubernetes.tf。6.2 验证节点 / 全节点运行参数Helm Chart terraform/helm/aptos-node/values.yaml 提供了更细粒度的运行参数Terraform 模块通过helm_values、helm_values_file变量将自定义值透传给 Helm见 kubernetes.tf并可覆盖num_validators、num_fullnode_groups、validator_storage_size默认2048Gi存储类为模块创建的ssd等。值得关注的默认项资源预留validator 与 fullnode 的 CPU/内存 requests 与 limits 均为 30 核 / 60GiHAProxy 为 1 核 / 200Mirequests优雅停机terminationGracePeriodSeconds: 60保证共识 / REST 请求在 SIGTERM 后有时间落盘preStopSleepSeconds: 15让 kube-proxy 与 GKE NEG 控制器在 Pod 删除前先摘除端点避免流量在终止瞬间被切断服务暴露validator 与 fullnode 的 HAProxy 均以LoadBalancer类型对外externalTrafficPolicy: LocalREST API 默认开启enableRestApi: truemetrics / admin 端口默认关闭存储分片enable_storage_sharding默认true控制 RocksDB 存储分片开关通过chain.storage.rocksdb_configs.enable_storage_sharding注入 NodeConfig。6.3 可选监控设置enable_monitoring true可额外部署 terraform/helm/monitoring ChartPrometheus 栈并可通过monitoring_helm_values、enable_prometheus_node_exporter、enable_kube_state_metrics进一步控制监控组件见 kubernetes.tf。GKE 集群侧默认已开启托管 Prometheus 与全组件监控采集见 cluster.tf。七、运维要点与常见问题era 与数据重置增大era会清空底层存储、启动一条干净的新链。修改 era 后必须使用匹配的新 Secret 名-eN重新注入 genesis否则工作负载将无法启动。密钥安全private-keys.yaml、validator-identity.yaml等文件是节点所有权与奖励申领的凭证务必离线备份、妥善保管切勿提交到代码仓库。镜像拉取权限新创建的 GCP 项目默认无权访问aptos-global私有镜像仓库需手动为集群服务账户授予Artifact Registry Reader角色否则 Pod 会因 ImagePullBackOff 停滞。测试模式与生产模式差异步骤 1214layout.yaml、framework 字节码、genesis 编译仅适用于测试模式生产网络中这些产物由 Aptos Labs 统一生成与分发。IP 变更与节点身份validator-host/full-node-host在set-validator-configuration时写入若负载均衡 IP 变化需重新生成 operator.yaml 并在链上更新对应配置。多环境隔离利用 Terraform workspace步骤 6可在一套main.tf下隔离 dev / testnet / mainnet 多套环境资源命名会自动带上 workspace 前缀。结语通过 terraform/aptos-node/gcp 模块Aptos 节点运维者可以用一份声明式配置在 GCP 上完成网络 → 集群 → 工作负载 → DNS的全链路自动化部署再配合aptos genesis工具链完成身份初始化与创世数据注入。本文覆盖的 17 个步骤与源码级参数解析既可用于快速搭建测试网络也是理解生产环境部署流程生产模式下 genesis 由 Aptos Labs 提供的坚实基础。后续如需深度定制可继续研读 terraform/aptos-node/gcp/variables.tf 与 terraform/helm/aptos-node/values.yaml 中注释详尽的全部可调参数。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考