---
# System prepended metadata

title: Cloud Foundation Fabric V.S Cloud Foundation Toolkit

---

# Cloud Foundation Fabric V.S Cloud Foundation Toolkit

對於使用 terraform 來建構 GCP 雲端資源，目前兩個常用，且持續維護的 Terraform module repository，分別是：
- **Cloud Foundation Fabric**: 
    以下簡稱 *Fabric*，是 Google 內部維護的 Terraform module
- **Cloud Foundation Toolkit**:
    以下簡稱 *CFT*，為 HashiCorp 和 Google 共同維護的 Terraform module

這兩個功能上有蠻大部分重疊，但又有一些差異化，以下個別簡介，並把我覺得特別不一樣的部分表示出來。

## Cloud Foundation Fabric

cloud-foundation-fabric 官方有建議可以把整個 git repository 當作為一個 unit。鼓勵我們可以**自己 fork 自己修改**，並可**當成自己code base 本地呼叫**

Fabric 提供了一些大項功能分別為
1. Modules
2. Organization blueprint (Fabric FAST) 
3. End-to-end blueprints

### 1. [Modules](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/modules)
這部分提供的功能和我們對 terraform module 的認知是一樣的，為**封裝 low level resources**，讓我們可以重複調用，且不用在意內部 resource 互動細節。

### 2. [Organization blueprint (Fabric FAST)](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/fast)
這功能概念上是大型公司組織開始使用 GCP 時，剛開始要需仔細規劃基礎權限和 infra 劃分，如：
- billing 權限
- network 和 IAM 管理
- 各式環境的對應組織

因為組織管理的複雜性，Fabric FAST 可進一步利用 **yaml 設定管理**。GCP organization 類型設定， Fabric FAST 可以幫忙快速架構這種 Security-first design 雛形。

:::info
Fabric FAST ~= 權限module ＋ 網路module ＋ factroy yaml設定管理複雜人事組織架構
:::


![](https://i.imgur.com/13ivjI6.png)


### 3. [end-to-end blueprints](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/blueprints)
這部分提供的是一個更具體的服務架構，利用特定雲端 resource 滿足特定需求。例如：
- Granular Cloud DNS IAM for Shared VPC
- Wordpress deployment on Cloud Run

等等服務，結合多個 module，形成一個初步解決架構。

:::info
end-to-end blueprints ~= 多個 module 組合 ＋ app
:::

---

## Key Differences
官方有提供一個[文件]((https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/blob/master/FABRIC-AND-CFT.md))講述兩個團隊提供的 terrform module 有什麼差異，但這邊我會依照自己兩邊都使用過的經驗，把一些我覺得重點不同的部分列出來。


### Extensibility
- **Fabric**
因為 Fabric 設計上就是一個 project 內有很多 modules，他也鼓勵使用者可以自己 fork 來訂製修改它的 Terraform module。這方面來說擴展性是 Fabric 比較好。

- **CFT**
如果是比較喜歡直接用別人設計好的 Terraform module，CFT 是比較好的選擇。也因為 CFT 是把每個 module 拆成不同專案，這並不適合一個一個 fork 自訂。


### Release Cadence
- **Fabric**
因為所有 module 統一管理，故版本是統一發布的。

- **CFT**
因為每個 module 都分在不同專案，故每個都會單獨有一版本化，故也是分開發布。

### Examples
- **Fabric**
因為 Fabric 有 blueprints，故範例會比較多元，會用具體解決方案的範例。

- **CFT**
只有單純 module 使用範例。

### Factories
- **Fabric**
Fabric 專門設計的功能，可以通過 YAML 文件設定比較複雜的網路，IAM 設定。

- **CFT**
沒有提供 Factories 功能，變量設定只能依靠 .tfvars



---

# 細部使用心得
有比較細看一下 load-balancer 部分source code。fabric 功能寫的是比較完整的，像是 url-map，fabric 有把 forwarding rule 擴展的很完整 ; 相反 CFT 完全無法設定。

## fabric 執行 terraform init 會比較花時間

因為是直接從 github 上 download fabric，且因為所有 terraform modules 都在 repository 上，故整個包 downloand 下來時間上要花比較多，一般 CFT 的 terraform module 只要幾秒左右就 downloand 好了，以下簡單測了幾次 fabric download：
- 2m 01s
- 1m 10s
- 42s
- 1m 
- 17s
- 31s
- 40s

## fabric db module 
- 沒有 location_preference 的設定

雖然可以啟動 HA ，但是無法自己選擇 parimary zone，只能由 cloud 自己分配 ; secondary zone 是完全無法設定 

- 沒辦法設置 charset 和 collation

cloud 自動分派的 charset 和 collation ，分別是 utf8mb4，utf8mb4_0900_ai_ci ，這部分無法更動。

## fabric vm module
vm module 把 Unmanaged instance group 歸類在一起，但 instance group name 強制和 vm name 一樣。
（把主機台VM，放到一個 instance group 的操作，也可以順便在 vm module 中完成） 

## fabric glb module 
glb module 名稱限制還蠻多的，設定上：
- frontend name
- backend name prefix
- lb external ip name
- health check name 
 
因為都引用同樣變數，所以以上名稱都一樣，無法客製化。

另外 glb 一樣會有蠻多 null 需要寫的，但可以選擇全部不寫，即 options = null
![](https://i.imgur.com/yeF43e2.png)


# Some issues report
- 因為 glb health check 設計有牽涉到 map ，在 terraform 中使用 map，其 key 值不能是動態造出來的，故引用 health check 要用確定好的名字，**不能使用 terraform 造出來的的變動名稱**。

---
# 統計表格

|      | terraform-google-lb-http | cloud-foundation-fabric-net-glb |
| -------- | --------                 | -------- |
| lines    | 322+238+51               | (211+57+253+76+1184)+257+70    |
|