使用 Azure Export for Terraform 工具将现有的 Azure 资源导出

2 年 ago
清, 宇
2 minutes

最近我对Azure逐渐熟悉起来了。现在我渴望引入IaC来管理资源。
然而，我相信在已经存在的项目中后期引入IaC是有可能的，而我正处于这种情况下。
因此，我会尝试将Azure资源导出到Terraform中以进行管理。

基础架构即代码 (Infrastructure as Code) 和 Terraform。

IaC 是什么意思？

在现代开发环境中，已经有人可能正在实践将基础设施视为代码的思维方式。
过去，通过版本控制系统管理软件的状态是常见的做法。但随着公有云的兴起等因素，我们需要像管理软件一样管理基础设施，并从中获得好处。
这种思维方式和实践就是IaC，并得到了工具集（如Terraform）的支持。

例如，微软公司对此进行了如下解释。

基础设施即代码（IaC）是一种主要的DevOps实践，涉及基础设施（网络、计算服务、数据库、存储、连接拓扑等）的管理，并以描述性模型的形式呈现。通过使用IaC，团队能够更快速且可靠地进行开发和发布变更。

— Azure / 云计算部署框架 / 就绪 / 作为代码的基础设施.

实现 IaC 的工具们

在谈到IaC时，根据其策略和领域等因素，有很多不同的角度可以考虑。在这里我们先讨论IaC的实现方法，然后列举具体的工具。

将以下内容用中文进行同意表达：

两个基础架构即代码。

在IaC中，可以说有两种主要的实现方法。一种是命令式IaC，即通过脚本进行自动化，这种方法早已被广泛采用。另一种是声明式IaC，在最近变得越来越流行。

    命令型IaC

需要用像Bash或PowerShell这样的语言编写脚本，明确指定要执行以达到所需结果的命令。如果使用命令式部署，可以根据需要管理依赖关系的顺序、错误控制和资源更新。

    宣言型IaC

需要描述一个指定环境外观的定义。这个定义不是关于实现目标结果的方法，而是关于指定目标结果的方法。工具通过检查当前状态并比较目标状态来确定差异，并应用这些差异来实现结果的方法。

— Azure / 云计算引入框架 / 准备就绪 / 基于代码的基础设施 > 工具

具體的工具 de

在这里我们会介绍一些具体的工具，并进行简单的比较。

ツール概要IaCタイプいいところもう少しなところARM(Azure Resource Manager) テンプレートインフラストラクチャが記述されているJSONファイル宣言型Azure Native であり、ARM への変換等は必要ない可読性や保守性が低い
Azure 専用BicepAzure リソースをデプロイするドメイン固有言語 (DSL) です。Bicep ファイルでは、デプロイするインフラストラクチャとそのプロパティを宣言します。宣言型ARM テンプレートに比べて遥かに可読性が高く、記述しやすいBicep(DSL) の学習コストがかかる
Azure 専用Terraformクラウド インフラストラクチャのプロビジョニングおよび管理を行うためのオープン ソースの IaC (コードとしてのインフラストラクチャ) ツールです宣言型ARM テンプレートに比べて遥かに可読性が高く、記述しやすい
マルチクラウド・オンプレミス対応Hashicorp Configuration Language(HCL) の学習コストがかかるAnsibleRedHatが開発・提供するオープンソースの構成管理ツール命令型命令型ではあるが専用の言語を学習する必要はなく参入障壁が少ないYAML の学習コストがかかる
命令型なので取り回しに注意が必要なケースがある

为什么选择 Terraform？

我个人认为Terraform在以下几个方面很棒。

    • マルチクラウド対応なので、学習コストの効率がよい

Terraform で書ければとりあえず Azure/AWS/GCP などを統一的に扱える
AWS CDK や Bicep ではそれぞれ対応するクラウドが異なるため、クラウドプラットフォームが変わるごとに学習コストがかかる

Ansible は命令型なので扱いにくい面がある

既存の YAML ファイルからあるリソースを削除したい場合、削除することを明示的に書かないと削除されない
Terraform のコードからリソースを削除したら、それを適用するときに当該リソースは削除される

クラウドベンダーから独立している

特定のベンダー傘下にある企業のプロダクトだった場合、対応内容に優劣がついたり、他のベンダーを排斥するような活動を展開する可能性がある

Azure 导出 Terraform

在开始使用Azure和Terraform之前，我研究了如何将其应用于现有资源环境。微软针对这种用例发布了名为”Learn/Azure/开发者/Terraform/Azure Export for Terraform 概述”的文档，我将在阅读该文档并进行实践的过程中逐步进行。

阅读文件并准备所需材料

安装

我希望安装在运行于WSL2的Ubuntu 22.04上。

前提条件 tí

    • Terraform は local backend を使用するものとします。

 

    • terraform コマンドはインストール済みとします。

 

    • 筆者の環境では次のように構成しました。

 

    • tfenv –version

 

    • tfenv 3.0.0

 

    • terraform –version

 

    • Terraform v1.5.3

 

    • on linux_amd64

 

    + provider registry.terraform.io/hashicorp/azurerm v3.65.0

安裝

根据GitHub页面上的说明进行安装并执行。

# run as root
curl -sSL https://packages.microsoft.com/keys/microsoft.asc > /etc/apt/trusted.gpg.d/microsoft.asc
ver=22.04
apt-add-repository https://packages.microsoft.com/ubuntu/${ver}/prod
apt-get install aztfexport
# run as user
aztfexport --version
# aztfexport version v0.13.1(c690456)
# disable telemetry
aztfexport config set telemetry_enabled false

顺利安装完成，并且这次也将遥测发送功能禁用了。

运用方式

这次我们尝试将仅包含LogAnalytics工作区和存储帐户的资源组进行导出。

出口

aztfexport resource-group rg-my-sample-group
terraform init --upgrade
terraform plan
=== < 中略 > ===
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no
changes are needed.

如果输出显示“不需要变更”，则可以判断导出正常。

如果需要释放资源的话

如果导出成功，您可以按照通常的 Terraform 使用方法进行销毁。
如果要销毁整个导出的资源组，请使用以下命令。
※如果需要预先验证，请执行 terraform plan -destroy -out terraform.destroy.tfstate 等操作。

terraform destroy

关于限制事项

关于Azure Export for Terraform的已知限制事项，请参考Learn / Azure / 开发者 / Terraform / Azure Export for Terraform的工作机制>限制事项中的描述。

这一次我们没有遇到。

AzureRM中的特定属性是只读的，并且不包含由Azure Export for Terraform生成的代码。

在这种情况下，似乎也有这样的情况发生。我们可以在进行terraform plan并进行审查时进行检测，并在代码中添加属性定义作为应对措施。如果遇到这种情况，我想尝试一下这种方法。

总结。

我想尝试使用IaC，但是在将其引入到现有资源组中的难度很高！但是，看来这种常见需求确实有解决方案。
虽然不完美，但我想使用Azure Export for Terraform迈出第一步。
此外，据我所知，还定义了Azure DevOps提供程序，所以应该也可以管理Azure Pipelines等等。
这些管理方式可能因项目等情况而异，但如果有机会的话，我想试一试。

bannerAds