更改 state 有其风险,State manipulation 有赚有赔(?),更改前应详阅官方文件说明书
课程内容与代码会放在 Github 上: https://github.com/chechiachang/terraform-30-days
赛後文章会整理放到个人的部落格上 http://chechia.net/
本篇讲解进阶的 terraform state 操作,请复习基本State 操作与基本 Backend 的相关概念
一般来说,我们可以完全仰赖 provider 自动管理 state,不需要手动干涉 state 内容。此时 state 的 workflow 很单纯:针对每个 root module
前面 18 天的课程,我们都是依照上面的流程,让 terraform 自动管理 state
更改 state 有其风险,State manipulation 有赚有赔(?),更改前应详阅官方文件说明书
Terraform 官方文件对於 state manipulation 的描述 标记 important note
Important: Modifying state data outside a normal plan or apply can cause Terraform to lose track of managed resources, which might waste money, annoy your colleagues, or even compromise the security of your operations. Make sure to keep backups of your state data when modifying state out-of-band.
重要!在正常 plan / apply 以外的流程更改 state,可能造成 terraform 无法追踪远端 resource
在进到更改 state 之前,要来细看 terraform 是如何 address state
以 azure/foundation/compute_network
为例说明。首先回忆一下 .tf 内容
modules/compute_network
https://github.com/Azure/terraform-azurerm-network
的 remote module由於我们已经 apply 过,这边使用 state list 列出现有的 state
cd azure/foundation/compute_network
terragrunt state list
module.network.data.azurerm_resource_group.network
module.network.azurerm_subnet.subnet[0]
module.network.azurerm_subnet.subnet[1]
module.network.azurerm_subnet.subnet[2]
module.network.azurerm_virtual_network.vnet
我们这个 root module (azure/foundation/compute_network
) 产生五个 resource
module.network.azurerm_subnet.subnet(s)
module.network.azurerm_virtual_network.vnet
module / resource 的命名也很直观
module.<module-name>.azurerm_virtual_network.<resouce-name>
上面把 state manipulation 说得这麽可怕,那 terraform 都自动把 state 维护好,我们有什麽动机需要手动来更改 state?
实务上比较常见到的例子
rename resource / module 应该是常见的需求,特别是针对开发中的 module,会希望让 resource 的名称更直观
从 resource addressing
如果我们把 module.network.azurerm_virtual_network.vnet
的 azurerm_virtual_network.vnet
rename 成为 azurerm_virtual_network.main
module.network.azurerm_virtual_network.vnet
不见了module.network.azurerm_virtual_network.main
module.network.azurerm_virtual_network.vnet
module.network.azurerm_virtual_network.main
应该要产生- module.network.azurerm_virtual_network.vnet {
}
+ module.network.azurerm_virtual_network.main {
}
1 to create, 1 to delete
这也是 terraform,应该说是 RESTful API 常见的问题
在这种情形下,如果我们希望的是 rename,便可以更改 state
module.network.azurerm_virtual_network.vnet
-> module.network.azurerm_virtual_network.main
module.network.azurerm_virtual_network.main
,state 中也有 module.network.azurerm_virtual_network.main
,两个是对在一起的state mv 方法很多种,例如:
State manipulation 有其风险有赚有赔(?)工程师应详阅官方文件公开说明书。
今天我们遇上上面描述的情形,被迫要手动调整 state,然而 state 更改方式许多种,使用 editor 直接 edit 大概是最容易出错的一种
当使用 local state 进行变更时(ex. apply),本地会有一个版本的 terraform.tfstate.backup 档案,是 terraform 使用 local state 的时候,一个贴心的小功能。如果
如果 terraform.tfstate 跟 terraform.tfstate.backup 都改坏了,那复原的步骤就会变得非常麻烦,而且一个不小心就会弄坏远端的 resource。这在 prod 发生的话不是开玩笑的
附带一提,这时就体现出 state versioning 的优势,如果使用的 backend 有支援 state versioning,远端的 backend 上会保留非常多以前 apply 的 state,万一真的不幸搞坏最近几个版本,还是可以 checkout 更早版本的 state,协助回朔
然而,版本离越远,回朔的过程越痛苦。这是一个惹恼同事的好方法 ;)
烂方法没试过不知道他有多烂
_poc
内使用 local backend 的范例
<<: Day 06 Heroku、Heroku CLI、Git push建置
>>: [Day 3]从零开始学习 JS 的连续-30 Days---字串
大家好,我是羊小咩 这章来谈谈混合加密系统(hybrid cryptosystem) 现今大多传送...
建立资料 写资料前要先有栏位,找到前面指令建立的 create_todos_table migrat...
我们因为只有一个工程师,做 App 的话跨平台开发是很自然的选项。 在2018年开发时,当初只有 R...
今天学习如何在网页上显示清单列表,我们需要用到ul li与ol li 首先是ul li,在body里...
延续昨天,今天来完成一个导览列吧!! 首先先在components创一个navbar.vue 像昨天...