關於 版本控制git ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://faun.pub/the-best-infrastructure-as-code-tools-for-2021-b37c323e89f0

這篇文章是一個 IaC (Infrastructure as Code) 的推廣文，文章分成幾個部分，從 IaC 的基本概念與應用談起，接者分析了幾個常見的 IaC 工具，最後探討了實際的使用案例

文章偏長，對於 IaC 概念很熟悉的讀者應該可以很快速地看完，以下針對部分進行一些摘要

The need for Infrastructure as Code
作者先描述過去幫機房部署新伺服器時的各種流程，機器少量時能夠透過人力慢慢處理，但是這類型的操作繁瑣，重複且惱人
為了讓這些流程處理得更佳順遂與一致，會有各式各樣的 scripts 等相關工具被開發出來，而這些流程慢慢的會往自動化的方式去發展。
IaC 文化的興起會使得有愈來愈多獲得共識的工具被開發出來，這使得 IaC 的使用門檻會有機會降低，愈來愈多的使用者能夠更簡易的透過 IaC 的方式來管理與維護自身的架構

Benefits and reasons to implement IaC
IaC 帶來的好處是非常顯著的，譬如
1. 將 Config 檔案當作整個環境的 sing source of truth
2. 每次的部署都是基於上述的 Config 來部署，能夠確保每次部署都獲得一樣的結果，避免人為的反覆長期操作帶來的錯誤
3. 透過程式化的方式去建置環境能夠更快速的去應變各種環境需求，對於 testing, developing, production 等各種變化都可以透過 config 的差異來快速搭建
4. Config 也可以透過 Git 的方式去管理來獲得更好的可稽核性與管理性。

Principles and best practices of Infrastructure as code
作者這邊列出了幾個實作上的推薦方式
1. 透過版本控制的方式來管理 IaC 的設定檔案，能夠讓維運人員使用開發者常見的開發合作流程來管理 IaC
2. 將 IaC 的工具整合到 pipeline 的 CI/CD 流程，讓 CI 流程去檢查 IaC 的設定是否符合預期以及 CD 流程來幫忙自動部署修改架構

Infrastructure as code tools
這個區塊作者列出了幾個常見的工具，包含 Terraform, CloudFormation, Puppet, Pulumi 等，接者又透過一張大表格來比較 Terraform/Pulumi/CloudFormation 三者的差異
Pulumi 這工具這一兩年開始聲勢比較多，跟 Terraform 一個最大的差異我想就是撰寫的方式，可以透過 Js, Go, Python...等程式語言來描述架構而並非使用 Terraform 自定義的 DSL 來管理。

最後面作者也列舉了六七個適合 IaC 的使用場景，有興趣的歡迎閱讀全文

C/C++ Linux 專案，網路 Socket 程式設計，建立 TCP/IP 通訊協定堆疊，使用 C 語言實現 L2 和 L3

從這 14.5 小時的課程，你會學到

1 從頭開始自己實現 TCP / IP 通訊協定堆疊的第2/3層

2 編寫自定義 CLI 命令以配置網路拓撲

3 從頭開始建構網路拓撲

4 實施路由和交換演算法 – 實用方法

5 計時器、GLthreads、程式庫整合、Makefile、專案模組化技術

6 使用版本控制系統 git 從頭開始管理和開發大型原始碼

7 這是理論最少的 100％ 編碼課程

8 在網路領域的所有其他面試中，都將要求你解釋基本的路由概念，所以請不要錯過本課程！

https://softnshare.com/tcpipstack/

ref: https://itnext.io/helm-3-secrets-management-4f23041f05c3

Secret Management 的議題一直以來都是 CI/CD 流程中不可忽似的一部分，本篇文章作者不同於以往採用常見的解決方案(Hashicorp Vault, Helm Secret, SealedSecret)，反而是使用 Helm 內建的 AES 加解密功能來實作 Heml Chart 資料的加解密需求。

作者認為一個良好的機密管理解決方案需要能夠為其團隊提供三個基本需求
1) 所有的機密資訊都要能夠存放到版本控制系統中(Git...etc)
2) 所有被上傳到 Chartmuseum 的 Helm Chart Package 都不能有任何 k8s secret 物件，要放的只能有加密後結果。反之使用者要使用時也必須要有能力去解密
3) 單一工具管理，以作者來說會希望能夠都使用 Helm 這個工具來處理，愈少的工具意味者依賴性愈少，同時在維護與管理上要花的心力也更少。

作者首先列舉了兩個現存的專案，分別是 Helm Secrets 以及 Hashicorp Vault 並且針對這兩者進行了簡單的介紹，並且舉出為什麼這兩個專案並不適合作者團隊的需求與使用情境。

作者最後開始認真研究 Helm 本身有什麼內建的加解密功能可以使用，最後發現 encryptAES 以及 descryptAWS 這兩個內建函式可以使用，譬如

value: encryptAES "secretkey" {{ .Values.valueToEncrypt }}
value: {{ .Values.valueToDecrypt }} | decryptAES "secretkey"

有了基本的概念與用法後，作者透過 shell script 實作一層 wrapper 來簡化整個處理流程。
最後將這些資訊也導入到 CI/CD 流程中來幫忙進行解密的相關動作，讓 CD 可以順利的將目標 Secret 給送到 Kubernetes 中。

個人心得: 採用加解密的系統個人還是喜歡採用 SealedSecret 的設計理念，將解密的時間點延後到 Kubernetes 內而並非 CI/CD 系統上，主要是 CI/CD 的 pipeline 要是沒有仔細設計其實很多人會不小心把過程命令給輸出的，這樣的話加解密的過程，使用的 Key 等都有可能會洩漏出去。