Cloud Native 這個詞近年來非常熱門，CNCF 甚至也有針對這個詞給出了一個簡短的定義，然而對於每個使用者來說，要如何實踐這個定義則是百家爭鳴。我認為很認真地去探討到底什麼樣才算 Cloud Native 其實就跟很認真的探討什麼是 DevOps 一樣，就是一個沒有共識，沒有標準答案的問題。
本篇文章從 CNCF 的定義衍伸出 Cloud Native 帶來的優勢，並且針對這個領域介紹了十三種不同面向的科技樹，每個科技樹也都介紹了幾個常見的解決方案。
好處:
1. Speed
作者認為 Cloud Native 的應用程式要具有快速部署與快速開發的特性，擁有這些特性才有辦法更快地去根據市場需求而上線面對。眾多的雲端廠商都提供不同的解決方案讓部署應用程式愈來愈簡單，而 Cloud Native 相關的工具則是大量採用抽象化的方式去描述這類型的應用程式，讓需求可能更簡單與通用的部署到不同環境中。
2. Scalability and Availability
Cloud Native 的應用程式應該要可以無痛擴張來對面不論是面對一百個或是一百萬個客戶。底層所使用的資源應該都要根據當前的需求來動態配置，避免無謂的金錢成本浪費。此外自動化的 Failover 或是不同類型的部署策略(藍綠/金絲雀..等)也都可以整合到 Cloud native 的工具中。
3. Quality
Cloud Native 的應用程式建置時應該要保持不變性，這特性使得應用程式本身能夠提供良好的品質一致性。此外大部分的 Cloud Native 工具都是開放原始碼專案，這意味者使用時比較不會遇到 vendor lock-ins 的問題。
以下是作者列出來認為 Cloud Native 生態系中不可或缺的十三種面向，以及該面向中幾個知名專案。
相關領域
1. Microservices (Node.js/Kotlin,Golang)
2. CI/CD (Gitlab CICD/ Github Actions)
3. Container (Docker/Podmna/LXD)
4. Container Orchestration (Kubernetes/Google Cloud Run)
5. Infrasturcutre as Code (Terraform/Pulumi)
6. Secrets (Vault /Sealed Secrets)
7. Certificates (cert-manager/Google managerd certificates)
8. API Gateway (Ambassador/Kong)
9. Logging (EKF/Loki)
10. Monitoring (Prometheus/Grafana/Datadog)
11. Alerting (Prometheus Alertmanager/Grafana Alerts)
12. Tracing (Jaeger/Zipkin)
13. Service Mesh (Istio/Consul)
https://medium.com/quick-code/how-to-become-cloud-native-and-13-tools-to-get-you-there-861bcebb22bb
cicd好處 在 [心得] CI 的使用注意事項- 看板Soft_Job 的推薦與評價
這篇來聊 CI (Continuous integration) 的導入須知，
什麼是 CI ，中文常見是翻"持續整合"。
(也有人是 CI / CD 持續整合/持續交付 並稱，
我以下都只說 CI，但涵蓋是 CI/CD。)
雖然是一個常見而且通用的概念，
我個人覺得因為名字不太好懂，很多人還是一知半解。
DevOps 很大一部分的工作會跟這題有關，
這個詞的發展就我接觸的順序早 DevOps 不少。
這十年來有些詞彙的發展先後不一，
都是根據當時的市場跟分工需求，定義上有些混亂。
--------
CI 最基本的概念，至少包含，
把一個專案從 source code ，到他真的上服務，
這一段 flow 中間的自動化。
換言之， checkout 自動，build 自動，
local(nightly) release 自動，deploy 自動。
很多人對這題可能認知的只有build專案的服務。
雖然最早 CI 其實是搭配 test ，因為持續發布持續測試，
所以在每個版本可以迅速找到"假設"被破壞的地方回饋。
不過國內撰寫測試風氣不發達，
真的做到測試能涵蓋到確保安全的地方，就我所見不多。
但即使如此，build 仍然是過版失誤中，相當常見的主因，
諸如 build 錯版本，丟錯版本，丟錯地方，下錯環境參數等等。
CI 在 build 自動化的優點在於，
只要設定好一個已經變化不大的 build process 。
剩下的要出錯的機率很低，
因為機器基本上都是 step by step process。
一般來說，做好 CI 有幾個好處：
1. build 版不用倚賴特定工程師的腦內思維，把工程師的中斷減少(不會被叫去過版或buil
2. 設定即文件，而且是活的文件
3. 為測試整合打好基礎
4. 減少測試環境的過版負擔
5. 能夠提供水平角色(pm/qa) 自動存取最新 build 的資料，
包括 web / app / 各類執行檔。
有些專案甚至是每天對外發 nightly version ，
就是個典型 CI 流程的特徵。
----------
目前圈內常見的 CI 手段，
最基本的大概是定期跑排程，一些 batchjob 勉勉強強就算數了。
其他常見工具包括 jenkins (前身為 hudson)，Travis CI ，
travis CI 的優點是跟 github 無縫整合。
可能還有一些其他的，我自己是比較習慣用 jenkins 。
也不是他特別好還是怎樣，從早期就一直用到現在懶得改，
另外是步驟都可以 shell base ，
換言之你能用指令做到的就能用他做，我是用的很習慣。
另外 azure devop 也有提供 pipeline & release，
可以做對應的事情，不過 azure 封裝的比較多，
用起來我自己是覺得跟 jenkins 風格大異其趣。
--------
導入時的第一個問題，build 的環境處理：
當你裝好 jenkins ，他就是個 web server ，
然後你可以使用該台 server 上的環境進行建置。
也可以建多台 slave ，到別台機器上去建置。
(比方說某些有平台相依的，ex. mac vs windows)
建置時有些工具需要分開安裝，
如 build android 需要 android sdk ，
build .net framework 需要 msbuild。
dotnet core 需要 dotnet core runtime 。
除了像 azure pipeline 有提供線上能 build 的機器(要收錢)，
其他大部分都是得自己搞定。
另外要留意一件事情是為了隔離性，
CI 的執行使用者通常不是我們進入操作的高權限帳號，
一開始的各類設定，檔案權限處理，通常會花一點力氣。
---------
第二個常碰到的問題，在於不熟悉指令建置的 input output 。
比方說微軟體系的 msbuild ，多數人可能用過 vs 的發布工具，
但對 msbuild 怎麼用不熟。
其實能用 vs 做到的都能用 msbuild 做到，
但有時需要鑽過茫茫複雜設定海。
另外就是 build 出來的 package 在哪，有時候需要找，
有些專案設定甚至會影響 build 的結果。
要留意跟團隊溝通有變化時要更新對應的 build 設定。
像是 android 有些人會改 gradle 設定檔，加入檔名的變化，
這個設定如果 build 那邊沒考慮到就會事倍功半。
---------
第三個常碰到的問題，在於權限管理的模型設定，
有些地方是採取集中建置的策略，
有些地方是讓工程師各自建置的策略。
其中特別需要的部分，
是把測試環境跟建置環境的權限分開。
另外設定檔的保存，不要讓沒有權限的人，
存取到超過他權限的設定檔也是重要課題之一。
-----------
第四題跟第三題有點重疊，在於各類環境設定的處理。
目前主流有幾派，一個是設定在 os 的環境變數。
(台灣我是非常少看到有專案這樣做)
一個是獨立保管設定檔，
但保管在哪這點目前無標準化，就我看到大家都是各做各的。
如找個 private blob (or s3) 放之類的，
也有人是交給 ansible 之類的發布作業接手。
-----------
常見的問題還包括討厭的跨專案間的相依問題，
比方說某專案需要某建置工具的 A 版本，
另一個專案需要某建置工具的 B 版本。
有時候會需要費心去處理版本的 bin 指定跟環境安裝。
----------
最後因為每次建置，大多數預設的情況，
我們會保留 workspaces 跟 output file 。
所以如果專案 build 出來的東西不幸比較肥，
那可能會常常把伺服器的空間塞爆，
這裡的空間管理就會是問題。
常見做法是直接接到外部的 file service 做保存。
----------
CI 有時候大家會開始設定 trigger ，可能 A 專案建置完之後，要跟著整套建完上測試之類的。
當單一建置時間太常，團隊人又多時，有可能會導致建置服務的塞車。
我們可能也要留意設定上，設定是不是適當的，
舉例，每次都需要 clone 整個專案嗎？
還是只需要取最新版就好。
每次都要重裝相依性套件嗎？(ex. maven , npm , nuget )
能不能 local cache ，或是內部有個 cache service，
有些設定在 build 時，會需要稍微調校來加快效能。
總之，很多人覺得自動化建置，等於再久也沒關係，
實務經驗來說，我覺得還是得追求建置速度，
快速反應，快速前進。
還有一些相對比較不多人關心的問題，
build fail 的處理要怎麼安排，這些就是有空再說了。
我個人會建議，有機會的話，多瞭解一些發布流程如何自動化，
dotnet 工程師看看 msbuild 跟 dotnet(core) .
android 玩一玩 ./gradlew assembleRelease
signapk 怎麼指令化操作
ios 玩一玩 xcode
對自己手邊專案的掌握跟理解都會比較上升。
有時候也可以幫自己省下不少時間，
省下多一點的時間，不管是要混要認真，
還是要在週末上網寫廢文，都會比較有時間。(笑)
-----
Sent from JPTT on my Google Pixel 3 XL.
--
I have a dream, it's silly but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.167.67.203 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1598230146.A.8A1.html
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:28:58
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:19
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:34
是說幾個朋友在FB說, 覺得 CI 跟 build 還是有差,
欸 我覺得原則上同意, 因為 build 只是基礎的一環.
至於有了自動 build 是不是就能達到持續整合的精神,
比方說雖然有 build server 但還是每個月 build 一次.
那樣就不能說有持續整合的精神.
這我同意啦
只是說論述總有遠近, 要講到持續整合這個架構,
能進入的人又少太多了. XDDD
(啊是說你們自己來回啊. = =)
※ 編輯: TonyQ (210.61.209.201 臺灣), 08/24/2020 14:15:18
... <看更多>