使用 Packer 与 Terraform 在 AWS、Azure、GCP 上一键部署 Nomad HashiStack 沙箱集群【免费下载链接】nomadNomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.项目地址: https://gitcode.com/gh_mirrors/no/nomad本文基于 Nomad 仓库 terraform/README.md 的官方指南完整讲解如何借助 Packer 与 Terraform 在 AWS、Azure、GCP 三大云平台上快速搭建一套内置 Nomad、Consul、Vault 与 consul-template 的 HashiStack 沙箱集群。读完本文你将掌握从本地环境准备、Golden Image 构建、多云集群编排到集群验证、Vault 解封与资源清理的完整实战链路并理解这套模板背后的配置与脚本实现原理。项目定位专为探索与学习设计的沙箱环境terraform/目录是 Nomad 官方仓库中面向云环境的基础设施即代码IaC子项目。它使用 Packer 构建统一的基础镜像使用 Terraform 在目标云平台上编排 Nomad Server/Client 节点并在每台机器上同机部署colocatedConsul 与 Vault便于快速体验 Nomad 与整个 HashiCorp 技术栈的原生集成。需要特别强调的是README 明确声明这套环境isnotmeant to be a production ready environment——它的定位是方便探索 Nomad 及其集成的沙箱而不是生产就绪方案。例如 AWS 与 Azure 的部署文档都提示测试环境的安全组放行了 22 端口的所有流量这是刻意为之的开发便利绝不应照搬到生产。环境准备用 Vagrant 搭建本地暂存环境官方推荐的起步方式是克隆仓库后利用仓库自带的 terraform/Vagrantfile 启动一个预装工具的本地暂存虚拟机$ git clone gitgithub.com:hashicorp/nomad.git $ cd nomad/terraform $ vagrant up vagrant ssh查看 terraform/Vagrantfile 源码可以看到这个暂存环境的具体构成基础镜像为ubuntu/bionic64分配 2048MB 内存与 2 核 CPU自动下载并安装 Packer版本 1.8.2与 Terraform版本 1.2.4通过微软官方 apt 源安装 Azure CLI安装 Docker CE 系列组件并把vagrant用户加入docker组通过 synced_folder 将aws/、azure/、shared/、examples/四个目录挂载进虚拟机方便直接在宿主机编辑、在虚拟机内执行构建与部署命令。之所以需要 Packer、Terraform 与 Azure CLI是因为后续三步工作流完全依赖它们Packer 负责构建镜像Terraform 负责编排资源Azure CLI 负责 Azure 侧的认证与信息收集。构建基础镜像Packer 与 setup.sh 的镜像定制三个云平台各有一份packer.jsonAWS、Azure、GCP其核心逻辑高度一致。以 GCP 的 packer.json 为例构建过程分为四步创建/ops目录并放开写权限把 terraform/shared 目录上传到/ops/shared把 terraform/examples 目录上传到/ops/examples执行 terraform/shared/scripts/setup.sh。也就是说三个云平台共享同一份镜像定制逻辑差异只体现在 Packer builder 的云平台适配上如 GCP 的googlecomputebuilder、source_image_family ubuntu-1604-lts、machine_type n1-standard-1。setup.sh镜像内安装了什么terraform/shared/scripts/setup.sh 是镜像定制的主体脚本它完成以下工作安装 HashiCorp 全家桶通过 HashiCorp 官方 apt 源安装固定版本号的产品——Consul1.18.1、Vault1.15.7、Nomad1.7.6、consul-template0.35.0并安装unzip tree redis jq curl tmux openjdk-8-jdk等辅助工具关闭防火墙ufw disable避免沙箱内跨节点通信被干扰安装 Docker配置 Docker 官方 apt 源并安装docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin为 Nomad 的 docker 驱动提供运行时可选 NVIDIA 支持当构建环境设置了INSTALL_NVIDIA_DOCKER变量时额外安装 CUDA 工具包、nvidia-gds 与 nvidia-container-toolkit并配置 Docker 运行时。这一点与仓库 terraform/examples/tensorrt/tensorrt-demo.nomad 这类 GPU 示例任务相呼应——镜像内留出了跑 TensorRT 类负载的通道。镜像内的关键配置模板shared/config/目录存放的 HCL 模板会在开机脚本中被sed填充占位符后复制到各服务配置目录是理解整套集群行为的关键terraform/shared/config/nomad.hclServer 节点配置。data_dir /opt/nomad/data、bind_addr 0.0.0.0server块中bootstrap_expect SERVER_COUNT占位符由脚本替换为实际服务器数量并配置了指向本机 Consul 的consul块127.0.0.1:8500以及默认禁用的vault块address http://active.vault.service.consul:8200预留create_from_role nomad-clusterterraform/shared/config/nomad_client.hclClient 节点配置。开启client并默认放行两个驱动选项driver.raw_exec.enable 1与docker.privileged.enabled true同时启用指向active.vault.service.consul:8200的 Vault 集成terraform/shared/config/consul.hclConsul Server 配置。server true、bootstrap_expect、retry_join占位符按需填充开启ui_config与connect并把 gRPC 端口设为 8502Connect 服务网格所需terraform/shared/config/consul_client.hclConsul Client 配置同样含retry_join占位符用于客户端节点上的本地 Consul agentterraform/shared/config/vault.hclVault 配置使用 Consul 作为存储后端backend consul { path vault/ }监听 8200 端口开发环境关闭 TLStls_disable 1terraform/shared/config/consul-template.hclconsul-template 配置指向 Vault 的active.vault.service.consul:8200并开启 syslog 日志输出。工作流一在 AWS 上部署 Nomad 集群AWS 的完整指南见 terraform/aws/README.md。前置条件与环境变量需要准备AWS 账户、API 访问密钥Access Key、SSH 密钥对。然后导出认证环境变量$ export AWS_ACCESS_KEY_ID[AWS_ACCESS_KEY_ID] $ export AWS_SECRET_ACCESS_KEY[AWS_SECRET_ACCESS_KEY]用 Packer 构建 AMIAWS 的 Terraform 模板默认引用一个公开可用的 AMI你也可以通过修改 terraform/shared/scripts/setup.sh 与 terraform/aws/packer.json 定制自己的镜像$ packer build packer.json编写 terraform.tfvars 并部署切换到环境子目录并更新terraform.tfvars$ cd env/us-eastregion us-east-1 ami ami-09730698a875f6abd instance_type t2.medium key_name KEY_NAME server_count 3 client_count 4其中region、instance_type、server_count、client_count均可按需修改至少需要 1 个 client 和 1 个 server。还可以通过nomad_binary变量在运行时热替换 Nomad 二进制例如指定一个nomad_0.7.0_linux_amd64.zip的下载地址这在升级测试时非常有用region us-east-1 ami ami-09730698a875f6abd instance_type t2.medium key_name KEY_NAME server_count 3 client_count 4 nomad_binary https://releases.hashicorp.com/nomad/0.7.0/nomad_0.7.0_linux_amd64.zip随后执行标准 Terraform 工作流$ terraform init $ terraform get $ terraform plan $ terraform applyAWS 集群的实现细节terraform/aws/modules/hashistack/hashistack.tf 揭示了 AWS 侧编排的核心设计安全组primary安全组放行 22、4646Nomad、8500Consul等端口另有一个server_lb安全组承载负载均衡器流量whitelist_ip变量控制哪些 IP 可以访问Consul 云上自动加入auto-joinretry_join变量默认值为provideraws tag_keyConsulAutoJoin tag_valueauto-joinServer 与 Client 实例都会被贴上ConsulAutoJoinauto-join标签并授予ec2:DescribeInstances、ec2:DescribeTags、autoscaling:DescribeAutoScalingGroups的 IAM 权限见 auto_discover_cluster 策略从而让 Consul 通过标签自动发现彼此这正是 README 中一键部署能自动成环的底层机制负载均衡aws_elb将 Nomad 的 4646 与 Consul 的 8500 端口暴露为 HTTP 负载均衡器用户数据脚本通过user_data模板渲染 server/client 各自的启动脚本把server_count、region、retry_join、nomad_binary注入其中。访问集群用私钥 SSH 到任一 Server 的公有 IP$ ssh -i /path/to/private/key ubuntuPUBLIC_IP⚠️ AWS README 明确指出这套测试环境的安全组放行了对 22 端口的所有流量生产部署绝不应如此配置。工作流二在 Azure 上部署 Nomad 集群Azure 的完整指南见 terraform/azure/README.md流程比 AWS 多出 Azure 特有的服务主体Service Principal配置。安装并登录 Azure CLI可以手动安装 Azure CLI仓库文档给出了 Debian/Ubuntu 的 apt 安装步骤也可以直接用仓库自带的 Vagrantfile 启动暂存环境已预装 Azure CLI。登录$ az login登录输出中的id与tenantId分别对应订阅 ID 与租户 ID需导出为环境变量export ARM_SUBSCRIPTION_IDSUBSCRIPTION_ID export ARM_TENANT_IDTENANT_ID创建应用主体与资源组创建一个 Contributor 角色的应用主体用于 Packer/Terraform 认证$ az ad sp create-for-rbac --roleContributor --scopes/subscriptions/${ARM_SUBSCRIPTION_ID}输出中的appId与password对应export ARM_CLIENT_IDCLIENT_ID export ARM_CLIENT_SECRETCLIENT_SECRET再为 Packer 创建资源组$ az group create --name packer --location East US export AZURE_RESOURCE_GROUPpacker构建镜像并获取 image id$ packer build packer.json $ az image list --query [?tags.ProductHashistack].id查询到的 image id 形如/subscriptions/SUBSCRIPTION_ID/resourceGroups/PACKER/providers/Microsoft.Compute/images/hashistack供 Terraform 使用如需删除镜像可执行az image delete --name hashistack --resource-group packer。为 Consul auto-join 创建 Reader 服务主体Azure 侧 Consul 同样支持云端自动加入但需要额外创建一个Reader角色的服务主体$ az ad sp create-for-rbac --roleReader --scopes/subscriptions/[SUBSCRIPTION_ID]编写 terraform.tfvars 并部署$ cd env/EastUSlocation East US image_id /subscriptions/SUBSCRIPTION_ID/resourceGroups/PACKER/providers/Microsoft.Compute/images/hashistack vm_size Standard_DS1_v2 server_count 1 client_count 4 retry_join providerazure tag_nameConsulAutoJoin tag_valueauto-join subscription_idSUBSCRIPTION_ID tenant_idTENANT_ID client_idCLIENT_ID secret_access_keyCLIENT_SECRET注意这里的retry_join是 Azure 特有的 Consul auto-join 配置串它携带订阅、租户、客户端 ID 与密钥供 Consul 通过 Azure API 依据ConsulAutoJoinauto-join标签发现其他节点。然后同样执行$ terraform init $ terraform get $ terraform plan $ terraform apply访问集群$ ssh -i azure-hashistack.pem ubuntuPUBLIC_IP其中azure-hashistack.pem是部署过程中自动生成的 SSH 私钥。与 AWS 相同该环境同样放行 22 端口所有流量仅适用于测试。工作流三在 GCP 上部署 Nomad 集群GCP 的完整指南见 terraform/gcp/README.md它同时支持在 Cloud Shell 中交互式运行且给出了最完整的端到端流程。安装 HashiCorp 工具与 gcloud在云主机上按文档分别下载安装 Nomad、Consul、Vault、Packer、Terraform 的二进制文档示例版本为 Nomad 0.12.4、Consul 1.8.3、Vault 1.5.3、Packer 1.6.2、Terraform 0.13.1例如curl https://releases.hashicorp.com/nomad/0.12.4/nomad_0.12.4_linux_amd64.zip -o nomad.zip unzip nomad.zip sudo mv nomad /usr/local/bin nomad --version若使用 Cloud Shell 则已自带gcloud可跳过 SDK 安装否则需按官方指引安装并执行gcloud auth login。创建项目、绑定账单并启用 Compute APIexport GOOGLE_PROJECTnomad-gcp-$(cat /dev/random | head -c 5 | xxd -p) gcloud projects create $GOOGLE_PROJECT gcloud config set project $GOOGLE_PROJECT gcloud alpha billing accounts list export GOOGLE_BILLING_ACCOUNTXXXXXXX gcloud alpha billing projects link $GOOGLE_PROJECT --billing-account $GOOGLE_BILLING_ACCOUNT gcloud services enable compute.googleapis.com创建 Terraform 服务账号gcloud iam service-accounts create terraform \ --display-name Terraform Service Account \ --description Service account to use with Terraform gcloud projects add-iam-policy-binding $GOOGLE_PROJECT \ --member serviceAccount:terraform$GOOGLE_PROJECT.iam.gserviceaccount.com \ --role roles/editor gcloud iam service-accounts keys create account.json \ --iam-account terraform$GOOGLE_PROJECT.iam.gserviceaccount.com export GOOGLE_APPLICATION_CREDENTIALS$(realpath account.json)文档特别警告account.json具有该 GCP 项目的高权限访问能力切勿误提交到版本控制系统中生产或团队场景应使用 Vault 之类的密钥管理系统保管凭据。构建 Golden Image 并部署packer build packer.json cd env/us-east terraform init terraform plan -varproject${GOOGLE_PROJECT} -varcredentials${GOOGLE_APPLICATION_CREDENTIALS} terraform apply -auto-approve -varproject${GOOGLE_PROJECT} -varcredentials${GOOGLE_APPLICATION_CREDENTIALS}通过 SSH 隧道访问 Web UIGCP 指南贴心地给出了用gcloud建立 SSH 隧道以访问三个 Web UI 的命令将远端 4646/8200/8500 端口映射到本地gcloud compute ssh hashistack-server-0 --zoneus-east1-c --tunnel-through-iap -- -f -N -L 127.0.0.1:4646:127.0.0.1:4646 gcloud compute ssh hashistack-server-0 --zoneus-east1-c --tunnel-through-iap -- -f -N -L 127.0.0.1:8200:127.0.0.1:8200 gcloud compute ssh hashistack-server-0 --zoneus-east1-c --tunnel-through-iap -- -f -N -L 127.0.0.1:8500:127.0.0.1:8500隧道建立后Nomad、Vault、Consul 的 UI 分别对应本机http://127.0.0.1:4646、http://127.0.0.1:8200、http://127.0.0.1:8500。若之后要使用 Vault CLI可设置export VAULT_ADDRhttp://localhost:8200。集群验证确认 Consul 与 Nomad 正常运转无论选择哪个云平台集群部署完成后都应回到主 README 的Test环节即 terraform/README.md#test运行几个基础状态命令验证服务健康$ consul members $ nomad server members $ nomad node status这三个命令分别回答三个问题Consul 集群的成员拓扑是否完整、Nomad Server 成员之间是否已完成 Raft 组网、Nomad Client 节点是否已被 Server 纳管。对沙箱环境而言若三者输出中的节点数与你配置的server_count、client_count一致即可认为集群部署成功。此外各机器在开机脚本server.sh 与 client.sh中已把CONSUL_HTTP_ADDR、VAULT_ADDR、NOMAD_ADDR写入~/.bashrcSSH 登录后可直接使用对应 CLI。可选步骤初始化并解封 Vault集群中的 Vault 默认处于密封sealed状态。可选的初始化与解封流程如下$ vault operator init -key-shares1 -key-threshold1 $ vault operator unseal $ export VAULT_TOKEN[INITIAL_ROOT_TOKEN]README 特别说明这里用-key-shares1 -key-threshold1只为开发便利——只产生一把解封密钥。生产环境应至少创建 5 份密钥分片key shares并安全分发给独立操作者vault init的默认值正是 5 份分片、阈值 3。如果部署了多台 Server其余节点会成为 standby 节点但仍需逐一解封。可通过 Consul 的 DNS 接口查询主备节点$ dig active.vault.service.consul $ dig active.vault.service.consul SRV $ dig standby.vault.service.consul这套 DNS 查询能生效是因为 server.sh 与 client.sh 都把nameserver 127.0.0.1:8600本机 Consul agent 的 DNS 端口写入了系统解析配置并声明Domains~consul从而让*.service.consul域名的查询全部交给 Consul DNS 解析。这也解释了 Nomad/Vault 配置里为何可以直接使用active.vault.service.consul这样的服务发现地址。清理与销毁GCP 指南在结尾给出了完整的清理流程先用terraform destroy销毁全部基础设施再删除 GCP 项目terraform destroy -force -varproject${GOOGLE_PROJECT} -varcredentials${GOOGLE_APPLICATION_CREDENTIALS} gcloud projects delete $GOOGLE_PROJECTAWS 与 Azure 同理可通过terraform destroy回收所有云资源避免沙箱闲置产生持续费用。从部署走向上手示例作业与下一步镜像在构建时会把 terraform/examples 目录上传到/ops/examples而 server/client 启动脚本server.sh 第 80-83 行、client.sh 第 81-84 行会把它移动到ubuntu用户家目录下并赋予 775 权限。也就是说集群一就绪你就可以直接在每台机器上翻阅这些示例作业如 tensorrt/tensorrt-demo.nomad来快速上手 Nomad 作业编写。至此你已拥有一个可用的 Nomad Consul Vault consul-template 沙箱可以用nomad job run提交示例作业体验 Nomad 的任务编排可以打开 Consul UI 观察服务注册与服务网格可以在 Vault 中创建密钥并借助 Nomad 的 Vault 集成配置见 nomad_client.hcl 的vault块将密钥注入任务还可以用 consul-template 在服务变更时动态渲染配置。整套环境的部署逻辑都可以在 terraform/aws/modules/hashistack/hashistack.tf 与 terraform/shared/scripts 中找到对应实现是学习 HashiCorp 技术栈集成落地方式的绝佳参考。【免费下载链接】nomadNomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.项目地址: https://gitcode.com/gh_mirrors/no/nomad创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考