# SRE 讀書會 Round2 #3 共筆 CH.2

## 第二章 設置管理

### 使用版本控制

#### 對所有內容進行版本控制

>全部都得簽入
>

>版本控制："刪除"的自由
>

#### 頻繁在主線上簽入程式碼

#### 使用意義明顯的提交注釋

### 相依性管理

#### 外部函式庫管理

#### 元件管理

### 軟體設置管理

#### 設置與靈活性

#### 設置的分類

#### 應用程式的設置管理
1. 獲取設置資訊
2. 為設置建模
3. 系統設置的測試

#### 跨應用程式的設置管理

#### 管理設置資訊的原則

### 環境管理

#### 環境管理工具

#### 管理變更流程

---
## 第一組：
人員：小明、謝鎧陽、義格、Bryan
p31~p39
小明：基本上就是希望能透過 version control 來處理 Config 檔．所有會用在 Production 的東西都該用 Source control
義格：所有配置都要進入 Source control，但是資料結構要怎麼放？要跟程式放在一起還是？
小明：程式碼可能是一個 Folder ，相依的資料庫又放在另外一個 Folder，要去指定程式碼對應的資料庫或 Schema 版本，要定版，控版一定要控好． Roll back 後，任何一個時間點的東西都要是可以動的．
小明：再版控的時候會砍掉不必要的檔案嗎？例如有個 PHP 檔，後來建立了新的Library，那舊的 code 會怎麼樣？
義格：會移除，像 compile 的檔都不會留．
小明：假設有個不要的 main.c，rename 成新的？
義格：會砍掉
鎧陽：compile 後的檔案要留嗎？
小明：可能會放在另外的地方像是 maven

小明：commit 的 log 要怎麼寫？
義格：有用 feature 等，在合併的時候要寫得清楚一點，配合需求工單填在一起．
小明：有時候很簡單，就簡單寫．如果式一個小修改，就會留 tracker 的票號．票號只要寫數字．“因為某個票號所以做哪個修改”
Bryan：如果是開發新功能會怎樣或多久commit 一次
義格：如果是共同開發就會頻繁一點
小明：也會切功能來開發，前後端各一兩個人．

鎧陽：外部函式庫怎麼控制？
義格：用 Jfrog 控制．

----
## 第二組：
人員： 正緯 永富 阿福 john 哲認

控制流程 從流程控制結果 不是直接對結果作監控

版控的成本

需要備份的東西太多

現成服務很多 比之前自己作成本低很多
現階段板控工具很多，所以要做到全面板控已經比過去簡單，有許多的選擇

利用好現成服務的TAG 跟artifacts就能將編譯好的結果做好備份

進入雲端環境其實很多東西都要變成文件才會動

像是K8s 跟 dockerfile 沒有你連做都不能作
針對 infra 或環境，像現在 K8S 你一定也是要先寫 yaml 或 dockerfile 這些也都成為一種可以被板控的內容

程式碼應該都已經有板控，這應該是多數人的習慣與共識，特別是一旦導入 CI 之後，你沒上板控也不行，大家一定要學會板控。

設定檔才是大坑

不是直接儲存「設定檔」，而是板控如何產生「設定檔」的腳本。例如：Ansible playbook

從VM到container之類的改變

設置的變化可以記錄下來

VM 就算用snapshot作紀錄還是看不出來版本之間的差異

container 如果用dockerfile方式就會紀錄

> 直接進去操作 commit還是GG
> vm 用ansible還是有紀錄啦XDD

全部都版控的好處 對錯誤的容忍變高

因為隨時可以再回去

---
## 第三組：
設置管理策略從專案初期 到發布 文件產出 溝通流程 都是一種設置管理 都應該要版空 追蹤
一個完美的策略 應該在整體產品的橫切面上所有的產品設定 環境變數 文件 都應該要進入控制的管理幫中
產出 產品 conponment
ec2 snapshot =>內部有 但是外部環境資訊又沒有辦法做
data是無法坐板空的 無法還原的 因為資料結構會改變

config比例 code config data 的比例
寫一個
develogop出發
或是從production 出發
default 真的有必要一定要設定嘛
installer

default大戰爭
dev:已開發者為出發點
QA: OP兼dev 最常做的事情是build給qa測試
Pro:以業務為出發點 讓業務可以最方便demo給客戶

----
## 第四組：

> ### 使用版本控制
> #### 對所有內容進行版本控制
>全部都得簽入，有辦法做到嗎？

關於簽入的翻譯，原文是 commit，似乎應該要翻譯成提交，簽入的原文應該要是 check in
- docker 之類的就幾乎可以把全部包進去
- 包含 binary ？
- NO
- 1.太大
- 2.可以重新被 rebuild 出來
包含 Certificate 比較機密的部分嗎？
- 需要加密之後就可以，在 CI/CD 階段再解密，有一個代表的帳號會去做這件事
- 解密金鑰的密碼放人腦，CI Server 建好後手動放進去。
- 外部函式庫管理，版控 or not?

>版本控制："刪除"的自由

現階段板控工具很多，所以要做到全面板控已經比過去簡單，有許多的選擇

> git、svn 之外的版控？
- stash、mercurial （付費的）

---

## 第一次小組討論發表

依發表順序紀錄

### 第二組

進入container時代通常都會有相應的設定檔進入版本控制

像是dockerfile k8s 的yaml

比之前方便很多

DNS自己HOST還好
如果用外部服務可能就無法用API去控制
也就沒辦法版控

防火牆的設定管理
因為會改都是十萬火急
不確定哪個版本是可行的
定期備份目前可行的設定檔

提問：大家是不是都盡量做到都有版控

系統備份是不是能回到任意時間點

回答：
盡量紀錄release版本 回復到特定版本號

### 第三組

設置管理回到特定時間點

一切的變化都做管理

版本要下 TAG，Tag 一致即是相同時間點的 產出物、組態、環境⋯⋯

重現環境通常是為了 QA 或 roll back，

資料如何倒回是需要深思的。
>資料表結構或資料

### 第四組

key 私密的東西怎麼處理？
不可能裸奔，
為了 CI / CD 特別準備一組專門用來測試使用的帳號、key，也同樣是有保護過的。
定期更換密碼、key。

> 提問：存加密過的東西 只是密鑰不紀錄？
>

提交 簽入 都是commit

設計文件也要版控
不只系統的
東西

cucumber 用來當作溝通的版控

適度將一些相依物 commit 進去，加快部署的順暢。（但不能過度，會太肥）

> 我會用gitlab 的cache功能紀錄vendor XD

### 第一組

討論設置管理

SQL的結構版控要放到哪

1.跟程式碼放在一起
2.另外用一個大專案，專門放整個產品的資料結構

原始碼跟配置

產生出來的bin不會進版控

commit message
要有需求與 issue，最少也要把 issue 單號寫進去。

> rick 結語
>git message 可以用hook去檢查
>所以一定要符合規範才能commit
>結果有人每次commit都長一樣
>

## 第二段討論

### 第一組

鎧陽：密碼要怎麼管理？
義格：密碼不能跟 code 放在一起
Bryan ： https://aws.amazon.com/kms/ 服務試試看～

鎧陽：環境管理，環境管理工具不曉得大家都用啥
Bryan：Terraform + Docker
義格：怎麼管理密碼
Bryan：用 IAM Role 控制 Terraform 的權限
義格：用 Terraform 管理虛擬機，但感覺不是很友善

小明：關聯到哪些reposotory，需要用另外一個表，來管理．彼此（Service）之間的相依性沒有辦法處理，整個系統的環境總表．
Bryan:code要不要分project(e.g.一個DB, )?

小明：
把環境之間的關聯切開，用 Service 的角度來關聯，而不是 Library 的關聯．
現在有些新專案都是 API 溝通，關聯性本來就比較弱，比較好切．但是 API 有缺點，每個服務都要起一個 service，但是可能有 request、Log 量暴增的問提．

義格：
是不是有些 function 可以做在一起

小明：
看情況，希望服務不要互相影響．

小明：
管理設置資訊原則，避免過度設計資訊，盡量維持 config 簡單．先想辦法把一些機器做 Grouping，有些人 include A模組，有些 include B 模組．

### 第二組

軟體相依性、相依性管理
> 是否都會在本地建立副本，
1. 把相依的函式庫整個放進git
2. 利用CI/CD過程 把函式庫cache

勿忘npm leftpad事件

相依性與後面提到的 config 的管理有些類似，
你要在哪一個階段管理？是不是要進板控、是不是需要額外管理？

軟體的設置應該要抽出到外部的設定檔

不應相依在CODE裡面 這樣要管理環境的不同也只要看設定檔就好

環境管理

https://www.terraform.io/

>vmware好像也可以
現在 K8S 當道，infra 都轉變成在管理 docker 或 k8s。
現在 container 部署也會有 image 過大的問題，不知道當事人怎麼 build 的，
時間都浪費在傳輸。

所以都玩怎麼讓image變小

設定的加密跟儲存都很麻煩

玩CI/CD 好像沒有辦法不丟上託管的服務

CI / CD 有專用的帳號，不同層面的人有不同權限，高權限者可以讀取任何的私密設定檔，
例如：負責維運者，才有權限可以碰觸。
Red Hat IDM

如果是要保密的資訊
把加密後的東西作版控

像是larvel會有.env.sample

雖然不會存真正的機密資料

但是可以存目前有哪些變數

### 第三組

### 第四組

> 環境管理
- 拉 local 端的 package 來做到版本控制
> configuartion 彈性，兩個極端舉例
- 不用寫 config 做到好
- 用程式語言來彈性設置
> config 弄爛 production 的例子？
- 因 config 設錯，刪錯日期的資料
> 會做 config 的驗證嗎？
- 可以做單純用選的方式，避免未知錯誤
> 什麼情況下會在 build 環境時指定 config?
- 一份 codebase 部屬到不同環境
- ex: build app 時，把 db 的連線資訊放進去

configuration 的保護措施不比程式語言

## 第二次發表

### 第一組

terraform

密碼不要進入版本控制

可以用KMS
>但是你還是進入KMS了
>

紀錄系統相異性總表

用API溝通
>微服務化

> 提問：相異性表的維護
> 回答：拆分
> 47頁說要有所有設定的索引表
> DEBUG要通靈
> 工程師說這在我來之前就有了
>

SRE管這張表 但是可以判斷問題要找誰
> 個人理解XD
>
紀錄服務之間的關聯

可以用文件畫圖嗎（被打

https://www.consul.io/

### 第四組

不指定版號就會抓錯版號
行為就會不一致
需要 local cahce

在建置時導入設置資訊
> 非靜態語言可以在產生artifacts時嵌入？
> 這時代在 docker build 時，也會有人把 config 或 env 塞進去，因此即便不是 build binary 現在也會有類似的狀況。
> 但 docker 本身也是 binary 吧？

組態的保護措施不像 code 一樣容易、良好
有人因為組態出包嗎？
> 因為組態不小心把 prod DB 殺了
>

### 第三組

#### default setting
跟著主要業務環境走

三種可能性
* production
因為DEMO的時候要長得一樣

* QA
Ops 兼 QA，因為要頻繁測試，所以當然 defult 給 QA 環境

* 開發環境
因為預設開發者一拿到，都應該可以在 local build 或 local 將環境運行起來。
用README來指引

我們真的需要 default config 嗎？(wizard ?)
也許要根據需求去調整、修正。

利用流程產生config
ex. wordpress 安裝流程

### 第二組

私密的設定要不要進版控

不進版控 追不到

記過程 不記結果

檢查部屬時設定檔跟預設設定檔會不會差太多
當作門檻

各種相依性

部屬 建置

紀錄建置好以後的結果

可以避免其他問題

建立測試環境來測試設置

測試環境還是要取捨

不可能跟真實環境完全一樣
> 一萬台主機是要怎麼一樣XD

>K8s 可以自己架cluster 自己測？

## rick 結語
還是要取捨