这两篇来分享一个实际工作中遇到过的问题,也是在使用terraform部署环境的时候碰到的,terraform虽然是好东西,不过很多时候在一些场景下其实真不一定比手动操作好用,尤其是遇到各种问题的时候,今年之前其实也分享过很多篇terraform相关的文章,有兴趣可以看看
- 使用terraform迁移logic apps
- 解决Terraform StatusCode=429问题
- 使用Terraform来部署performance counter
- 解决Logic Apps terraform部署时大小写问题
这次来讲的主要是在升级azurerm_monitor_diagnostic_setting这个资源的时候遇到的问题,先把代码贴出来
resource "azurerm_monitor_diagnostic_setting" "recovery_vault" {
for_each = local.recovery_services_vault_diagnostics_settings
name = each.value.name
target_resource_id = each.value.target_resource_id
log_analytics_workspace_id = try(each.value.log_analytics_workspace_id, null)
log_analytics_destination_type = try(each.value.log_analytics_destination_type, null)
storage_account_id = try(each.value.storage_account_id, null)
dynamic "log" {
for_each = each.value.logs
content {
category = log.value
enabled = each.value.enabled
#retention policy applies when output type is storage account
retention_policy {
enabled = each.value.retention_policy.enabled
days = each.value.retention_policy.days
}
}
}
dynamic "metric" {
for_each = each.value.metrics
content {
category = metric.value
enabled = each.value.enabled
#retention policy applies when output type is storage account
retention_policy {
enabled = each.value.retention_policy.enabled
days = each.value.retention_policy.days
}
}
}
}
这个资源的作用是部署diagnostic settings,光这么说估计也不太容易理解到底是部署什么,参考下图其实就知道了,部署的实际就是把Azure资源的诊断日志,发送到诸如LA, Eventhub等资源的配置,这属于是个比较场景的需求,上边的代码就是用来做这个的
而这段代码有什么问题呢,主要包括两个方面
1.log这个资源已经deprecated,这个资源对应的其实就是上图里categories里可以选的那些选项,按照官方说法在4.0版本之后就会被remove了,需要用enabled_log替代,这个相对简单
2.第二个就比较复杂了,可以看到retention policy这个资源也在提示已经deprecated,而如果要替代这个资源的话,需要另外部署一个azurerm_storage_management_policy
首先解释下这个retention policy是做什么的,这个主要用在把日志存储在storage account里的场景,你可以通过这个参数指定日志在storage account里存储的时间,比如放30天,之后就删除掉,而这个操作背后用到的其实就是storage account里的生命周期管理,后台会自动帮你创建一条rule出来
这条rule里会指定好之前提到的保存周期,最重要的是还会包含需要删除文件的prefix,下图中的是NSG的flowlog,所以prefix很少,但是像其他服务会有很多种类型的log,这种情况下就需要很多prefix,来确保删除时不要删错文件
以前这都是后台自动执行的,我们只需要配置个参数,指定好保存多少天就行了,但是以后这需要我们自己来管理了,不得不说这是个坏消息。
具体的退役时间线如下:
- 2023 年 3 月 31 日 - 诊断设置存储保留功能将不再可用于为日志数据配置新的保留规则。 这包括使用门户、CLI PowerShell 以及 ARM 和 Bicep 模板。 即使已配置保留设置,也仍然可以在门户中查看和更改它们。
- 2024 年 3 月 31 日 - 无法再使用 API(CLI、Powershell 或模板)或 Azure 门户来配置保留设置,除非将其更改为 0。 仍需遵守现有的保留规则。
- 2025 年 9 月 30 日 - 将在所有环境中禁用诊断设置存储保留功能的所有保留功能。
接下来看下改完之后的代码,log直接替换成enabled_log即可,里边的配置基本也大同小异,区别是多了个category group,不过我这里没用这个,因为牵扯到一些逻辑上的东西。而retention policy上边说过了需要用azurerm_storage_management_policy替代,所以之前的这部分直接删掉就好了
resource "azurerm_monitor_diagnostic_setting" "recovery_vault" {
for_each = local.recovery_services_vault_diagnostics_settings
name = each.value.name
target_resource_id = each.value.target_resource_id
log_analytics_workspace_id = try(each.value.log_analytics_workspace_id, null)
log_analytics_destination_type = try(each.value.log_analytics_destination_type, null)
storage_account_id = try(each.value.storage_account_id, null)
dynamic "enabled_log" {
for_each = each.value.logs
content {
category = enabled_log.value
# category_group = try(enabled_log.value, null)
#retention policy applies when output type is storage account
}
}
dynamic "metric" {
for_each = each.value.metrics
content {
category = metric.value
enabled = each.value.enabled
#retention policy applies when output type is storage account
}
}
}
这部分其实是非常简单的,比较麻烦的是剩下的azurerm_storage_management_policy要部署出来,这部分准备放到另外一篇来说,因为会遇到一些意想不到的坑