MOPCON 2020 - Moving From Legacy Infrastructure to Kubernetes

從遺留架構動身前往 Kubernetes 的世界
https://mopcon.org/2020/schedule/2020027
本次演講近一年的實戰心得與矽谷 10X 工程師並肩作戰的過程，完整解析將舊架構遷移至 Kubernetes 的過程。

- 遺留程式碼大家很常聽到，那麼什麼是遺留架構呢？
- 遺留架構如何讓我們的生產力低落？
- K8S 如何解決這些痛點？
- 重構架構該考慮些什麼？
- 我們進入 K8S 的世界了，是不是真的這麼好？

如果你對時下最夯的 Kubernetes 有興趣，一定要來聽一下！筆者會以淺顯易懂的方式，開發者的角度，帶你走過 K8S 的技術體系。

Transcript

1. Moving From Legacy Infrastructure to Kubernetes Luka.Huang@mopcon 2020
2. Self Intro • Luka Huang • Senior Backend Developer works for Splashtop
3. Self Intro • Luka Huang • Senior Backend Developer works for Splashtop • Medium - Luka Huang
4. Self Intro • Luka Huang • Senior Backend Developer works for Splashtop • Medium - Luka Huang • A Curator of StarBugs Weekly
5. Self Intro • Luka Huang • Senior Backend Developer works for Splashtop • Medium - Luka Huang • A Curator of StarBugs Weekly • Creator of CodeShiba https://www.facebook.com/CodeShiba
6. Career 1. Web Developer 
 ( Ruby on Rails + Vue.js) 2. Backend Developer 3. Interested in DevOps 
 ( Terraform / Docker / Kubernetes … etc)
7. Involve in Large-scale System 1. It’s exciting 2. Knowledge is important 3. Can earn more money
8. 想要分享的原因
9. 難得的機會 將近 10 年的系統，要遷移至 Kubernetes 需要承載很⼤的流量 對停機時間非常要求 ⾶到矽⾕與架構師、顧問開會，討論、學習如何架構系統 實際參與「開始」到「上線」的完整的過程
10. 延伸 如何將「遺留程式碼」的觀念，⽤在處理「遺留架構」上 ⼗倍⼯程師是怎麼樣的存在︖ 離國際型的⼈才，距離有多遠︖
11. Outline • Why we move to Kubernetes ? • Introduction to Kubernetes & IAC • Move legacy infrastructure to K8s • Legacy infrastructure vs Legacy Code • Talking about 10x Engineer • Conclustion
12. Why we move to Kubernetes ? 為什麼要使⽤ Kubernetes ?
13. 過得好好的，為什什麼要⽤用 K8S ?
14. 契機
15. 啟動歐洲區
16. 如果要擴展歐洲業務， 要建立⼀一個獨立的系統
17. GDPR
18. GDPR
19. 好嚴格阿！
20. ⽤用原來來的架構再搭⼀一套不好嘛？
21. Single system Infrastructure Layer (EC2、VPC、RDS … etc) Application Layer(API, Web, Worker, … etc ) Testing by QA
22. Clone the entire system 2 * Infrastructure Layer (EC2、VPC、RDS … etc) 2 * Application Layer(API, Web, Worker, … etc ) 2 * Testing by QA The new system is 90% the same as original system.
23. 
 in the code and 
 in the infrastructure Don’t Repeat Yourself
24. 插曲，轉折點
25. 顧問降臨臨 直到，從矽⾕的顧問⾶來台北辦公室
26. 介紹了了⼀一下 K8S 技術
27. 了了解 infrastructure
28. 有⽤用 CI 跑測試很棒
29. 兩兩週後，宣布要使⽤用 K8S
31. 眾⼈人：（驚）真的假的？要⽤用 K8S？沒有⼈人會耶
32. 兩兩週後，集結最⾼高戰⼒力力，開始作戰。
33. 我扮演的⾓角⾊色 在遷移至 K8S 這個專案中，主要的後端開發者 負責容器化後端的服務 負責將以前的架構解析，遷移至 K8S 跨團隊協作，與 QA、Auto-testing、DevOps Team 合作 與矽⾕的架構師與顧問合⼒實作後端架構
34. 順利利啟動歐洲區
35. Introduction to Kubernetes & IAC
36. Kubernetes 就是
38. 傳統架構 vs K8S 架構
39. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Traditional Framework
40. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Using Docker without K8S
41. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ K8S
42. 簡單介紹 K8S Kubernetes 重要元件介紹： Node Pod Service Deployment Ingress
43. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Node
44. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Pod
45. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Service & Deployment
46. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Ingress
47. Helm ⽤法有點像是你想要在 ubuntu 系統下安裝 vim 輸入 apt install vim 即可安裝完成 那在 K8S 的世界，你想要安裝⼀個 wordpress 只要輸入 helm install my-wordpress wordpress
 (指令為簡略⽰意版)
48. Terraform https://geekflare.com/terraform-for-beginners/
49. Moving from legacy infrastructure
 to Kubernetes
50. but how?
51. 第⼀一個難題
52. 如何了了解⽬目前的系統？
53. Part 1 - 從 Application Level 了了解
54. Application level Application level - 應⽤程式層 API Server Web Server Worker Other Service
55. 伺服器上藏著許多⼤大密寶
56. 幾種⼤大密寶 init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ? system.d - 伺服器上藏了多少服務型⼤密寶 (shell script) ? monit.d - 伺服器上藏了多少監控型⼤密寶 (shell script) ?
57. init.d init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ? 服務啟動腳本通通放置於 /etc/init.d/ 底下 init 是開機後核⼼主動呼叫 根據使⽤者⾃訂的執⾏等級 (runlevel) 來喚醒不同的服務
58. system.d 伺服器上藏了多少服務型⼤密寶 (shell script) ? 系統初始化需要做的事情非常多 每⼀步驟被 system.d 抽象成⼀個單元 service - 代表⼀個後台 process，例如： mysqld, httpd, … etc IUUQGFMJYMJODPNMJOVYJOJU&#$&$&"%#&"#&#%&##$&##"&&MJOVY&%&"#&$JOJU&###&##&'#$$&"$"$&"&TZTUFNE
59. system.d https://linuxhint.com/list_service_systemd/
60. monit.d 可以⾃動修復已經停⽌的程序 不需要⼈⼯⼲預 所以這些需要 monit 的 process，是重要的
61. Nginx / Apache Config init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ? system.d - 伺服器上藏了多少服務型⼤密寶 (shell script) ? monit.d - 伺服器上藏了多少監控型⼤密寶 (shell script) ? Nginx / Apache 的 config 做了哪些設定︖
62. Nginx Config IUUQTTUBDLPWFSGMPXDPNRVFTUJPOTIPXEPJNBLFNZMBSBWFMBQQXPSLPOBOHJOYTFSWFS
63. 發現了了⼤大密寶之後
64. 還是要出來來⾯面對
65. 把這些搬到 K8S 上⾯面
66. 好東⻄西，不搬嘛？
67. 搬！哪次不搬？
68. 所以要怎麼搬呢？
69. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint
70. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶 => K8S 讓 pod 中的 process 變得單純
71. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶 => docker / entrypoint monit.d - 監控型⼤密寶 => 運⽤ K8S 對 pod 的監控機制
72. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶 => docker / entrypoint monit.d - 監控型⼤密寶 => 運⽤ K8S 對 pod 的監控機制 Nginx / Apache 的 config => ingress 的設定
73. Part 2 - 從 Deployment 了了解
74. 如何更更新 code ，達到持續部屬(CD)的⽬目標
75. 以前的⽅方法是把 code 拉到伺服器上⾯面
76. 傳統的⽅方法是把 code 拉到伺服器上⾯面， 再去重啟
77. 可能透過⼀一些⼯工具去協助你，但原理理⼤大概 就是這樣。
78. 進入 kubernetes 的世界之後
79. 使⽤用 Docker 是比較有效益的作法
80. Docker 跟 Ansible 相比 Docker 不太會跟環境相依，Ansible 會
81. 同樣的腳本，有時候 Ansible 會莫名其妙的失敗， 可能是作業系統不同或是某種套件版本不⼀一導致
82. 現代化，使⽤用 docker + kubernetes 的機制 進⾏行行部屬
83. kubernetes 有很完整的機制達到更更新 pod 的 版本，卻不會讓使⽤用者感到存在停機時間
84. K8S - pod 的⽣生命週期 readiness probe - 確保 pod 就緒才把流量導進來 liveness probe - 確保 pod 還是在正常⼯作，否則 kubernetes 會終⽌這個 pod 並重啟。
85. Part 3 - Infrastructure layer
86. IAC - Infrastructure as Code Terraform - 把所有的基礎設施寫成程式碼，例如：EC2、S3、 VPC ... etc，使⽤ Terraform 來撰寫。 Docker - 把安裝在機器中的東西也寫成程式碼，例如：⽤ apt install nginx 之類的套件，可以⽤ Ansible / Docker 來寫。 Kubernetes - 能夠將所有機器變成⼀個⼤平台。透過修改 K8S 的設定檔即可完成所需架構。
87. 如果可以把 infrastruce 寫成 code，其 實就可以⽤用程式碼的概念念來來套⽤用
88. 實現 IAC 的步驟 實現 IAC 的第⼀步 - ⽤ Docker 建⽴ test image 實現 IAC 的第⼆步 - ⽤ Ansible 寫出 Staging 伺服器配置 實現 IAC 的第三步 - 設計新的架構來對應舊架構 實現 IAC 的最終⽬標 - 所有的改動，都使⽤ Terrafrom + Helm
89. 進入到今天的重點
90. Legacy infrastructure vs Legacy Code
91. Legacy Code 怎麼樣的程式碼是 Legacy Code ?
92. Legacy Code 1. 別⼈寫的
93. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的
94. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的 3. 沒有測試覆蓋
95. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的 3. 沒有測試覆蓋 4. 測試無法表達意圖
96. Keywords 1. Legacy Code 2. Unit Test 3. Refactor 4. TDD (Test Driven Development)
97. 如果⾃自⼰己讀不懂的話
98. 可以找他
100. 91 敏捷開發之路路 1. Legacy Code 2. Unit Test 3. Refactor 4. TDD (Test Driven Development)
101. Legacy Infrastructure 怎麼樣的架構是遺留架構︖
102. Legacy Infrastructure 1. 別⼈架設的伺服器
103. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的
104. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的 3. 沒有測試覆蓋
105. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的 3. 沒有測試覆蓋 4. 測試無法表達意圖
106. Can we write down tests on infrastructure?
107. Yes, we can.
108. Testing on Infrastructure 1. End-to-End testing
109. Testing on Infrastructure 1. End-to-End testing 2. Nightly build
110. Testing on Infrastructure 1. End-to-End testing 2. Nightly build 3. Load Testing
111. Testing on Infrastructure 1. End-to-End testing => 功能正確 2. Nightly build => 修改後的架構可以提供正常服務 3. Load Testing => 修改後的架構可以承載⼤流量 4. 這些都整合在 CI / CD 裡⾯
112. Refactor 程式碼的 Refactor
113. Refactor 的⽤用意 • 降低未來修改的成本 • 降低未來理解程式碼的成本
114. Refactor Infrastructure 架構⾯的 Refactor
115. Refactor Infrastructure • 架構也是⼀樣的道理 • 降低未來修改的成本 • 降低未來理解程式碼的成本
116. Refactor Infrastructure • 相同的事情，有沒有更簡單，更容易懂的作法︖例如： • 公司內網才能使⽤管理員後台 • 資料庫只能被 Application Server 存取 • S3 只能由被 Application Server 存取
117. Refactor Infrastructure • 我們可以藉由不斷的重構，讓 IAC 的 Code 變得越來 越直覺。 • 以後需要變動架構的時候，才不會覺得很痛苦，不知 道怎麼改起
118. 10x Engineer
119. ⼗倍⼯程師是否真的存在︖
120. 有⼈說，我以前不相信⼗倍⼯程師的 存在，直到我遇到了 1/10 ⼯程師
121. 真的有⼗倍⼯程師存在嘛︖
122. 是的，真的有⼗倍⼯程師的存在
123. ⼗倍⼯程師是怎麼樣的⼈︖
124. ⼗十倍⼯工程師 技術又深又廣，每⼀個點的技術都比你強 Web Infrastructure Endpoint K8S
125. ⼗十倍⼯工程師 強⼤的跨⽂化溝通能⼒與跨團隊溝通能⼒ Backend DevOps Ops QA Auto Testing
126. ⼗十倍⼯工程師 語⾔能⼒ 英⽂ (native) ⽇⽂ 中⽂ (最近學的)
127. ⼗十倍⼯工程師 能夠說服公司採⽤⽅案 有很強的技術不是⼀切 技術強，也要想辦法轉換成價值，讓公司買單 並且真的做出來，產⽣效益
128. ⼗十倍⼯工程師 ⾜夠⼤的市場 市場規模，決定你的想像⼒ 技術強，思維也要跟上，才能解決更⼤市場的問題 如何讓⾃⼰可以接觸這樣的市場就是⼀個重要的課題
129. ⼗十倍⼯工程師 ⼤家多多嘗試進軍世界舞台，可以看到不⼀樣的世界
130. Conclusion 了解 K8S、Helm、Terraform … 等等技術名詞的意義。 了解傳統作法與新的 Terraform + K8S 技術體系的差異 了解頗析⼀個舊架構，遷移至 K8S 為中⼼的雲原⽣架構的過程。 了解如何重構舊架構 聽到了⼀個⼗倍⼯程師的故事
131. Thanks for listening