基础设施即代码

许多组织已经开始考虑或已经开始通过基于代码的定义（通常称为基础设施即代码 (IaC)）来部署 IT 基础设施。 执行此作的过程通常包括以下步骤：

1. 选择一种自动化语言，例如 CloudFormation、Terraform、ARM 模板、Bicep 或其他
2. 定义各种基础设施设置，例如虚拟网络配置、虚拟机的规格以及入站负载均衡器或反向代理
3. 从用户启动的手动工具或其他自动化过程运行该环境的“构建”

IaC 部署的结果是一组资源，这些资源可以通过手动成功部署，选择单独的配置和设置，但通过 IaC 可以较强的一致性进行部署、自动重新部署或稍作调整以符合新规范。

ArcGIS 通常与许多 IaC 方法和系统兼容，这些方法和系统通常设计为在特定的云环境或系统中工作，例如 AWS CloudFormation、Azure ARM 模板或 GCP 云部署管理器。 Esri 还为某些提供商构建了工具，特别是 AWS CloudFormation 模板和 Azure ARM 模板，这些工具可用作进一步配置或扩展的基础。

使用 IaC 提供商或工具部署基础设施后，可以手动或自动将 ArcGIS 软件部署到这些系统。 有关详细信息，请参阅自动执行 ArcGIS 软件部署。

某些 IaC 模式专为频繁部署而设计，其中更改会频繁推送到基础设施，或者在代码发生更改时推送。 此模式可能难以与 ArcGIS 系统保持一致，因为 ArcGIS Pro 和 ArcGIS Enterprise 都依赖于相对稳定且一致的网络和基础架构环境。 因此，如果需要 IaC 更改，建议像对企业 IT 系统的任何更改（计划、测试、审查、调整）一样谨慎地进行这些更改，或者将这些系统与其他支持软件部署自动化的 DevOps 样式工具结合使用，以定期重建和部署整个系统。

IaC 和 ArcGIS

将基础设施即代码与 ArcGIS 一起使用的其他建议包括：

• IaC 工具非常适合维护基础设施和基准配置，但不适合维护系统状态。 ArcGIS 系统的“状态”包括用户、项目、内容、服务和数据。 虽然 IaC 可以设置适当的“硬件”和软件安装，但将状态恢复到系统可能既复杂又耗时。
• 使用 IaC 在项目早期（或针对新环境）部署硬件比尝试更新现有环境更直接。 更新可能会调整网络配置、计算机命名、存储或防火墙规则，或者软件所依赖的其他条件，如果软件不知道或未为该更改做好准备，则这些基础设施级别的更改可能会导致不稳定或服务中断。 以此类推，如果正在运行的 ArcGIS 系统是一辆在街上行驶的汽车，您不会期望在中途更换汽车的轮胎，也不会在发动机运转时将汽油换成柴油。
• 其他 IaC 语言或提供程序可能与 ArcGIS 兼容。 通常，在审查潜在的 IaC 方法时，请考虑硬件和基础设施所需的手动配置步骤，尝试按顺序自动执行这些步骤，并在完成后继续进行软件部署和配置。

DevOps、CI/CD 和 ArcGIS

DevOps 术语通常是指代码驱动的部署工作流程，其中提交或发布会自动部署某些内容，替换之前存在的内容。 此领域中使用的其他术语包括_持续集成_（或 CI）和_持续部署_（或 CD），通常组合为 CI/CD。 这些术语来自软件工程领域以及应用程序开发和自定义软件应用程序构建流程，其中持续部署和测试用于支持软件的发布。

ArcGIS 是一种现成的商业软件包，因此它与许多组织现有使用 CI/CD 或 DevOps 进行自定义应用程序开发的做法有些不一致。 部署 ArcGIS 后，将开始在 ArcGIS Enterprise 中创建状态和配置、门户内容、服务、用户内容、配置。 除非恢复备份，否则重新部署 ArcGIS Enterprise 或新的 ArcGIS Online 组织会破坏该现有状态，因此您无法再查看所创建的内容。

要使 DevOps 成功用于 ArcGIS 系统，组织需要：

• 使用固定的内容集或精心管理的内容来维护相当严格的部署，您可以从“空白”系统自动部署这些内容。 例如，可以每晚部署包含一组基于文件的静态数据的单个查看器应用程序，包括自动发布或更新 Web 服务。
• 确定一种可靠的方法来提取状态，例如使用 WebGISDR，重新部署系统组件和基本配置，然后重新部署状态。