DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载本指南基于 Atlantis 官方文档的《Requirements》章节系统梳理 Atlantis 对 Git 主机Git Host、Terraform 状态后端、仓库目录结构、Workspaces、.tfvars变量文件以及 Terraform 版本的实际要求。读完本文你将能对照自己的 Git 与 Terraform 环境逐项自检判断 Atlantis 是否可以直接接入并掌握在何种场景下需要额外创建atlantis.yaml配置。总体要求兼容绝大多数 Git 主机与 Terraform 环境Atlantis 被设计为与大多数 Git 托管平台和 Terraform 配置方式兼容。官方文档开篇即给出自检建议Atlantis 可以与大多数 Git 主机和 Terraform 配置协同工作请继续阅读以确认它是否也适用于你的环境。 因此在安装部署之前建议先按本文列出的几个维度逐一核对Git 主机类型、Terraform 状态后端、仓库目录结构、Workspace 使用方式、.tfvars文件位置以及 Terraform 版本策略。Git 主机支持范围Atlantis 官方支持以下 Git 托管平台GitHub支持 public、private 或 enterprise 版本GitLab支持 public、private 或 enterprise 版本Gitea支持 public、private以及兼容的 fork如 ForgejoBitbucket Cloud即 bitbucket.org支持 public 或 privateBitbucket Server即 StashAzure DevOps从源码结构看每个 VCS 都有对应的独立客户端实现目录例如 server/events/vcs/github、server/events/vcs/gitlab、server/events/vcs/bitbucketcloud、server/events/vcs/bitbucketserver、server/events/vcs/gitea 以及 server/events/vcs/azuredevops各个主机通过统一的 server/events/vcs/client.go 接口接入 Atlantis。GitLab 版本要求detailed_merge_status对于 GitLabAtlantis 只支持**仍处于活跃维护期actively maintained**的版本。这里有一个关键的版本分界点GitLab15.6 起引入了detailed_merge_status字段Atlantis 会使用它来做更精确的 mergeable 应用要求mergeable apply requirement 检查。在更早版本的 GitLab上Atlantis 会回退到旧的merge_status字段该字段可能在分支需要 rebase 时仍把 Merge Request 报告为可合并从而造成误判。因此如果你正在使用 GitLab 且依赖apply_requirements: [mergeable]这类防护应尽量将 GitLab 升级到 15.6 及以上版本以获得更准确的合并状态判断。Terraform 状态后端支持一切远端状态唯独不支持 local stateAtlantis 支持除 local state 之外的所有 Terraform 后端类型。不支持 local state 的原因在文档中有明确说明Atlantis 自身没有持久化存储Atlantis不会把新的 statefile 提交回版本控制。这两点决定了它无法承担 local state 的职责。实际部署中应使用远程状态remote state例如 S3、Azure Storage、GCS 或 Terraform Cloud 等。::: tip 提示 如果你正在寻找一个开箱即用的远程状态方案可以试试 Terraform Cloud 提供的免费远程状态存储app.terraform.ioAtlantis 完全支持这种用法。 :::仓库结构支持任意 Terraform 仓库布局Atlantis 对仓库目录结构没有强制要求官方文档指出它支持任意 Terraform 仓库结构。下面逐一展开文档列出的典型布局。单一 Terraform 项目位于仓库根目录最简单的场景整个仓库就是一个 Terraform 项目. ├── main.tf └── ...这种布局下Atlantis 默认就能自动发现并规划plan根目录项目无需任何额外配置。多个项目目录仓库下存在多个相互独立的 Terraform 项目目录. ├── project1 │ ├── main.tf │ └── ... └── project2 ├── main.tf └── ...这种布局也无需配置——Atlantis 会根据 Pull Request 中修改的文件自动判断需要 plan/apply 哪些目录。需要说明的是一旦仓库根目录出现了包含projects配置的atlantis.yamlAtlantis 将不再自动推断项目位置而是完全按照项目配置执行可通过autodiscover.mode: enabled恢复自动发现详见 Repo Level atlantis.yaml Config。模块Modules需要atlantis.yaml才能联动触发当仓库把共享代码抽成模块目录时. ├── project1 │ ├── main.tf │ └── ... └── modules └── module1 ├── main.tf └── ...如果你希望当module1被修改时project1也能被自动规划就必须创建atlantis.yaml文件。这是文档明确指出的要点也是 monorepo 中最常见的配置场景之一。对应的配置方式在 repo-level-atlantis-yaml.md 的 Configuring Planning 一节中有完整示例version: 3 projects: - dir: project1 autoplan: when_modified: [../modules/**/*.tf, *.tf*, .terraform.lock.hcl]这里需要注意几个关键细节when_modified使用 .dockerignore 语法路径相对于项目所在目录因此引用上层modules/需要写../modules/自定义when_modified会整体覆盖默认值。默认的when_modified包含**/*.tf*、**/*.tofu、**/*.tofu.json、**/terragrunt.hcl和**/.terraform.lock.hclwhen_modified同时作用于自动触发和手动执行的 plan即使关闭了 autoplan手动 plan 仍会遵循该匹配规则。Terraform Workspaces通过atlantis.yaml声明 workspace 名称如果你使用 Terraform 0.9.0Atlantis 支持 Workspaces但需要借助atlantis.yaml告诉 Atlantis workspace 的名称。配置方式见 repo-level-atlantis-yaml.md 的 Supporting Terraform Workspaces 一节version: 3 projects: - dir: project1 workspace: staging - dir: project1 workspace: production上述配置下当project1目录的配置发生变更时Atlantis 会同时为staging和production两个 workspace 运行 plan。如果想针对某个 workspace 单独操作可以在 Pull Request 评论中使用带参数的命令atlantis plan -w staging -d project1 atlantis apply -w staging -d project1每个workspace对应一个独立的 Terraform 状态因此文档也强调一个 project 代表一个 Terraform state。默认 workspace 名为default且workspace值不允许包含/、\、..、$、空白字符或控制字符也不能以-或~开头详见 repo-level-atlantis-yaml.md 的 Project 参数表。.tfvars文件两种受支持的方式仓库根目录下散落.tfvars文件的布局是完全受支持的. ├── production.tfvars ├── staging.tfvars └── main.tfAtlantis 支持.tfvars文件的方式有两种分别对应不同的目录约定。方式一env/{workspace}.tfvars自动包含零配置如果仓库采用env/目录约定. ├── main.tf ├── variables.tf └── env/ ├── default.tfvars ├── staging.tfvars └── production.tfvarsAtlantis 会根据当前 workspace自动包含对应的变量文件无需任何额外配置atlantis plan自动包含env/default.tfvarsatlantis plan -w staging自动包含env/staging.tfvarsatlantis plan -w production自动包含env/production.tfvars这一行为在源码中有明确实现在 server/core/runtime/plan_step_runner.go 的buildPlanCmd函数中Atlantis 会检查env/{workspace}.tfvars文件是否存在若存在则向terraform plan追加-var-file参数。源码注释还提到这一特性源自 Atlantis 最早的诞生地 Hootsuite 的仓库实践被保留下来既是致敬也是鼓励这种减少重复的目录组织方式。方式二自定义位置的.tfvars文件需要atlantis.yaml如果.tfvars文件位于其他位置或采用其他结构则需要创建atlantis.yaml通过自定义 workflow 告诉 Atlantis 使用-var-file{YOUR_FILE}。具体示例参见 custom-workflows.md 的 Using .tfvars files 一节。其基本思路是在 workflow 的 plan 步骤中追加extra_args例如version: 3 projects: - dir: . workflows: default: plan: steps: - init - plan: extra_args: [-var-file, production.tfvars]多个仓库Multiple ReposAtlantis 天然支持多个仓库同时接入前提是为每一个仓库都正确配置好指向 Atlantis 的 Webhook。Webhook 配置方法参见 configuring-webhooks.md。Terraform 版本支持Atlantis 支持所有版本的 Terraform包括 0.12并且可以针对不同仓库/项目配置使用不同版本。这一能力通过三层机制实现优先级从高到低为atlantis.yaml中的terraform_version键优先级最高服务端--default-tf-version启动参数Terraform 配置块中的required_version约束详细说明见 terraform-versions.md。方式一服务端默认版本--default-tf-version通过启动参数指定 Atlantis 默认使用的 Terraform 版本atlantis server --default-tf-versionv1.3.7对应的环境变量为ATLANTIS_DEFAULT_TF_VERSION该参数在 server-configuration.md 中有完整说明。方式二atlantis.yaml按项目指定版本如果某个仓库或项目需要使用不同于默认值的 Terraform 版本可在atlantis.yaml中设置terraform_versionversion: 3 projects: - dir: . terraform_version: v1.1.5terraform_version必须是 Semver 兼容的版本号如v0.11.0、0.12.0-beta1Atlantis 会自动下载并使用该版本。官方文档强调atlantis.yaml中指定的terraform_version优先于--default-tf-version参数和 Terraform HCL 中的required_version。方式三Terraform 配置中的required_version约束也可以在.tf文件中通过terraform配置块的required_version指定版本约束。自 Atlantis v0.21.0 起除了精确版本号x.y.z或 x.y.z还支持比较运算符和悲观版本约束pessimistic constraint。文档给出了四类典型写法精确指定 1.2.9terraform { required_version 1.2.9 }1.2 的任意补丁版本1.2.zterraform { required_version ~ 1.2.0 }1 的任意次版本1.y.zterraform { required_version ~ 1.2 }任意不低于 1.2.0 的版本terraform { required_version 1.2.0 }Atlantis 会自动下载满足约束的最新版本。此外还有一点值得注意当项目设置了terraform_distribution时required_version约束会针对该发行版解析——例如 OpenTofu 项目会解析到 OpenTofu 版本而不是 Terraform 版本。关于发行版Distribution的补充如果需要使用 Terraform 之外的发行版如 OpenTofu可在atlantis.yaml中设置terraform_distributionversion: 3 projects: - dir: project1 terraform_distribution: opentofu合法值为terraform和opentofu。服务端也有对应的--default-tf-distribution参数默认terraform。当生效发行版为 OpenTofu 时Atlantis 会额外从.tofu与.tofu.json文件读取required_version且遵循同名文件的优先级规则.tofu覆盖同名.tf.tofu.json覆盖同名.tf.json。模块级自动规划--autoplan-modules目前对.tofu文件的依赖索引仍存在已知限制详见 terraform-versions.md。部署前的自检清单与下一步如果你的环境满足上述全部要求就可以进入安装部署阶段。官方文档给出的下一步是如果 Terraform 配置满足 Atlantis 的要求请继续阅读安装指南并配置 Git 主机访问凭证Git Host Access Credentials。在 access-credentials.md 中你需要为所使用的 Git 主机创建专用账号与访问令牌例如 GitHub 建议创建一个atlantis专用用户或使用 GitHub App令牌需具备repo权限范围及 Commit statuses读写、Contents只读、Pull requests读写等最小权限GitLab 需要api作用域的 Personal Access TokenGitea 需要 issue/repository 的读写与 user 的只读权限Bitbucket Cloud 需要 Pull requests 的读与写Azure DevOps 则要求 Code读写、CodeStatus与 Member Entitlement Management读。完成凭证配置后下一步是创建 Webhook Secret见 webhook-secrets.md。最后建议在接入生产环境前对照以下清单快速自检检查项要求不满足时的处理Git 主机GitHub / GitLab / Gitea / Bitbucket / Azure DevOps 之一暂不支持的主机无法接入GitLab 版本活跃维护版本建议 ≥ 15.6升级 GitLab 以获得detailed_merge_status精确检查状态后端任何远程 backend迁移出 local state可选用 Terraform Cloud 免费远程状态仓库结构任意 Terraform 结构模块联动触发需创建atlantis.yamlWorkspacesTerraform ≥ 0.9.0在atlantis.yaml中声明 workspace 名称.tfvarsenv/{workspace}.tfvars约定或自定义位置自定义位置需用atlantis.yaml配置-var-fileTerraform 版本全部版本按需用terraform_version/--default-tf-version/required_version指定按照上述清单逐项核对即可确认 Atlantis 是否适用于你的 Git 与 Terraform 环境并平稳地完成后续安装与配置。赞分享DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载相关推荐SwinV2 Base Window8 256.ms_in1k多尺度特征提取深入理解分层表示SwinV2 Base Window8 256.ms_in1k多尺度特征提取深入理解分层表示 SwinV2 Base Window8 256.ms_in1k是django-allauth 运行环境与依赖要求Requirements完全指南Python/Django 版本矩阵与第三方库清单django allauth 运行环境与依赖要求Requirements完全指南Python/Django 版本矩阵与第三方库清单 本篇指南以 docs/后端认证鉴权身份认证Coroot 环境要求详解eBPF、内核版本、容器运行时与编排器兼容性Coroot 环境要求详解eBPF、内核版本、容器运行时与编排器兼容性 本篇技术指南完整解读 Coroot 官方安装前置要求对应仓库文档 requireme可观测性指标监控链路追踪APM上一篇智能体训练的革命性突破Agent Lightning语义理解增强实战指南下一篇PDF页面管理的终极解决方案免费开源的PDF Arranger强力工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考