幹壞事是進步最大的原動力
前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議，所以決定將最後一個 open source 版本的 Terraform 給 fork 出來：「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。
剛剛在 Hacker News 上看到「OpenTF repository is now public (github.com/opentffoundation)」這個，OpenTF 正式開張了。
瞄了一下 issues，初期還有蠻多雜事得處理的，但跨出第一步了，可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...
先前在「HashiCorp 將放棄 Open Source License，改採用 BSL 1.1」這邊提到的，HashiCorp 決定將所有產品線從現有的 open source license 換成非開源的 BSL 1.1 後，OpenTF 先丟出了「呼籲」希望 HashiCorp 可以撤回這個決定：「The OpenTF Manifesto」。
想當然的，HashiCorp 沒有回應，所以 OpenTF 宣佈了要把 Terraform 的最後一個 open source 版本 fork 出來：「OpenTF Announces Fork of Terraform」。
有幾個比較重要的資訊，第一個是申請 Linux Foundation 資格，希望成為 CNCF 的一環：
We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing Foundation.
另外一個是首頁上的 Co-signed 的部分，翻了一下有三家公司 (Spacelift、env0、Scalr) 有提出支援五年五位的 Full time engineer 的經費 (Cover the cost of 5 FTEs for at least 5 years)，另外一家公司 (Sailorcloud) 則是提出支援兩年一位的經費 (Cover the cost of 1 FTE for at least 2 years)。
接下來就是看這些能量到底有多少效果了...
去日本前在 Hacker News 上看到「Squeeze the hell out of the system you have」這篇，用作者的名字翻了一下 LinkedIn，看起來講的是 HashiCorp 的 SRE 事情：「Dan Slimmon」。
看的時候可以注意一下，文章裡面的觀點未必要認同，大多是他自己的看法或是想法，但裡面提到很多發生的事情，可以知道 HashiCorp 內目前搞了什麼東西。
從 LinkedIn 的資料可以看到他從 2019 就加入 HashiCorp 了，所以文章一開頭這邊講的同事應該就是 HashiCorp 的同事：
About a year ago, I raised a red flag with colleagues and managers about Postgres performance.
往下看可以看到他們有遇到 PostgreSQL 的效能問題，然後每次都是以 scale up (加大機器) 的方式解決，考慮到 HashiCorp 的產品線，我會猜應該是 Terraform Cloud 這個產品線遇到的狀況。
然後在後面提到的解法則是提到了 codebase 是 Rails，他們花了三個月的時候不斷的重複 profiling + optimizing，包括 SQL 與 PostgreSQL 的設定：
Two engineers (me and my colleague Ted – but mostly Ted) spent about 3 months working primarily on database performance issues. There was no silver bullet. We used our telemetry to identify heavy queries, dug into the (Rails) codebase to understand where they were coming from, and optimized or eliminated them. We also tuned a lot of Postgres settings.
另外一組人則是弄了 read-only replication server，把 loading 拆出去：
Two more engineers cut a path through the codebase to run certain expensive read-only queries on a replica DB. This effort bore fruit around the same time as (1), when we offloaded our single most frequent query (a SELECT triggered by polling web clients).
這兩個方法大幅降低了資料庫的 peak loading，從 90% 降到 30%：
These two efforts together reduced the maximum weekly CPU usage on the database from 90% to 30%.
可以看到都還沒用到 sharding 的技巧，目前硬體的暴力程度可以撐很久 (而且看起來是在沒有投入太多資源在 DB-related tuning 上面)，快撞到的時候也還可以先用 $$ 換效能，然後投入人力開始 profiling 找問題...
早上發佈的大新聞，HashiCorp 將放棄本來的 Open-source license (MPL-2.0)，改用 BSL 1.1：「HashiCorp adopts Business Source License」，Hacker News 上的討論也可以參考：「HashiCorp Adopts Business Source License (hashicorp.com)」。
看了一下產品線，最成功的應該是 Terraform 這條，其他也有些人會用，但大多都有替代品。
這些軟體可以預期都會有 fork，但後續的開發能量還會有多少就不知道了...
另外前陣子有測過一次 Pulumi，但整體的體驗很差，也許再看看其他的方案？
昨天在「AWS User Group Taiwan Meetup 2022-03 線上 / 下小聚」這邊分享的主題，在講如何在 AWS 上弄出一個高可靠性的 Vault 服務。
投影片在 https://bit.ly/3igUbgh 這邊可以抓到，我另外傳到 Speaker Deck 上面了：(好久沒用這個網站了？)
其實這類架構的設計有點像是 AWS 的 Solution Architect 在做的事情，如果一般的客戶開出類似的需求，應該也是會設計出類似的東西...
另外畢竟是在 AWS 的會議室裡面講，有些東西還是會避免提到，但裡面有很多概念是可以互換的，像是 Microsoft Azure 或是 GCP 上面都有可以抽換的服務，Vault 也都有支援。
以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。
這樣下個禮拜分享會的投影片也要改一改了...
今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。
投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。
這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。
在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。
接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。
接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。
在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。
其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。
概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...
HashiCorp 的東西都還蠻有品質的 (相較於其他的類似方案)，其中有一個觀察到的特性是，如果他門把版本維持在 0.x，代表他們自己對軟體的品質與成熟度都不算滿意。
而 Terraform 算是他們家對於基礎建設資源管理所提出的方案 (尤其是雲端時代的資源)，不過之前最頭痛的，每次升級就會發現有些基本的概念會被改掉，所以不是改改關鍵字就可以解決。
這次 Terraform 推出 1.0 版，代表了他們認為產品有一定的成熟度：「Announcing HashiCorp Terraform 1.0 General Availability」，另外在 GitHub 上面的「Release v1.0.0 · hashicorp/terraform」也可以看到：
Terraform v1.0 is an unusual release in that its primary focus is on stability, and it represents the culmination of several years of work in previous major releases to make sure that the Terraform language and internal architecture will be a suitable foundation for forthcoming additions that will remain backward compatible.
另外也可以從他們對相容性的宣示「Terraform v1.0 Compatibility Promises」看出來他們覺得架構上成熟了：
For all future minor releases with major version 1, we intend to preserve backward compatibility as described in detail in the Terraform v1.0 Compatibility Promises. The later Terraform v1.1.0 will, therefore, be the first minor release with new features that we will implement with consideration of those promises.
總算是開始進入會考慮 backward compatibility 的週期了...
Vault 是 HashiCorp 拿來管理各種敏感資訊的軟體，像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的？)，而是在需要的時候由應用程式呼叫 Vault 取得。
而 Vault 的設計裡面要求應用程式需要「認證」後才能取得，結果這個「認證」又是一組敏感資訊，這就是 Secret Zero 問題，屬於雞蛋問題的一種。
找了一輪發現 HashiCorp 自家的說明解釋的最清楚，不過這篇是放在 blog 上的文章：「Tackling the Vault Secret Zero Problem by AppRole Authentication」。
Vault 在解決 Secret Zero 的方法是使用 AppRole，這邊的認證包括了 role_id 與 secret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。
在 AppRole 這樣的設計下，權限會綁在 role_id 上，而 secret_id 則可以在部屬時動態產生，像是官方提到的 Terraform 與 Chef，或是依照組織裡面使用的管理工具：
這樣就可以透過 role_id 管理權限，但不用在 Git 裡面寫死 Secret Zero 資訊，而且每台機器都有自己的 secret_id 可以提供稽核記錄，把幾個比較明顯的問題解了不少...
HashiCorp 推出了兩個新的產品。
第一個是 Boundary，這個產品看起來還很早期，但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」)：「Announcing HashiCorp Boundary」，這在 Hacker News 上有討論串，而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題：「HashiCorp Boundary (hashicorp.com)」。
這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation，不過傳統的 castle 在小一點的場合也還算夠用...
另外一個是 Waypoint，看起來是個 CI/CD 類的產品：「Announcing HashiCorp Waypoint」，在 Hacker News 上也有討論串，而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西：「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。
我自己看了一下設定的方式以及一些畫面，然後再回頭看 Hacker News 上的討論，以目前得到的資訊來看，這個產品似乎沒有很明顯解決到痛點，也許就是補產品線...