為什麼這篇gcp k8s教學鄉民發文收入到精華區：因為在gcp k8s教學這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者qrtt1 (有些事，有時候。。。)看板Soft_Job標題Re: [請益] 教學10000p ...
原標題：
[請益] 教學10000p heroku aws GCP deploy
覺得原標太爛不利 search 或助憶，先改成
[心得] docker container 資料的生命週期
※ 引述《MOONY135 (談無慾)》之銘言：
: 我有一個服務是後台 需要用到mysql
: 已經把後台跟mysql都包成docker了
: 但我想不透是
: 要把mysql用docker打開(然後後台docker去連)
: 還是要用aws gcp heroku提供的db
: 懸賞10000p有沒有人可以提供教學的
主要的盲點在於，你太在意 "docker"
而不是思考一個 container 與其相關資源的生命週期。
所謂 container 並不是一個具體的東西，它其實是商業包裝出來的詞
如同 docker 代言著將 container 打包成 image 這樣便利的工具一般。
CONTAINERS ARE NOT A REAL THING!!!
https://twitter.com/thejsj/status/840295431779172352
不管採用的隔離手段是什麼，最終它就是一個 process。
問題會變成，
當我這個 mysql server process 消失後，會發生什麼事？
情境一：在自己的 linux 上用 docker 啟動它
啟動指令如下：
docker -d -p 3306:3306 --name db my-mysql-server
預期的結果，由於沒有別掛載 volume，
此 container 的 filesystem 隨著 container 同生共死
當 container (process pid 0) 被停止時，filesystem 也會被回收
在它啟動後，到它結束前新加入的資料都會被清除。
你下一次，再執行它將是全新的開始。
情境二：在自己的 linux 上用 docker 啟動它
啟動指令如下：
docker -d -p 3306:3306 -v /opt/db_data:/var/lib/mysql \
--name db my-mysql-server
跟前例相似，但多掛了 volume，對 container 來說，
filesystem 也是跟著它同生共死，但是在路徑 /var/lib/mysql
上的資料，在 container 結束後的事情，不關他的事，
它只是剛好與 host 有個對應，資料會被存在 host 的 /opt/db_data
下回，再重新啟動時，恰巧 /var/lib/mysql 內有資料，
可以回應其它 client 端先前保存的記錄。
情境一、二是你能完全掌握 host 時的情況，沒有哪種比較適當，
是要看你想要有哪種效果，不過一般來說想要寫入效能好一點，
都會想要加個 -v 來使用 host 上的 filesystem。
情境三：別人替你啟動 container
一些 cloud provider 都有提供 managed container
所謂 managed 就是別人替你管的，你得在他的規則下做事
並且不要試著搞些奇葩的設計，這樣生活才不會覺得痛苦
以為全世界都與你為敵。
情況粗分為 2 類：
* 3a: 能掛載 volume
* 3b: 不能掛載 volume
3a) 假設，供應商提供掛載 volume 的功能，那他是怎麼提供你的？
1. 讓你使用 host filesystem
2. 讓你使用外部儲存空間，例如 nfs, s3 之類的東西模擬
這聽起來就是很麻煩的東西，因為一個 volume 要被 mapping 進 container
內要考慮的東西實在太多了，
一是這東西能不能同時被掛載，而是同時寫入時會不會發生災難。
還有，當你同一個 image 要 scale out 時要怎麼處理？
替每個 container 生它們專屬的 volume，還是共用 volume (如果有支援的話)
因為上述諸多的麻煩，加上 docker 對於 volume 的用心並不多，
它在後來的幾年才增強了 volume 的設計。
基於歷史的因素 (這功能本來就很弱)
以及 container 最好是 stateless 的良好設計
(container 表示，不要讓我處理 state，請丟到別的地方)
managed container 應該都不太會有支援你使用 volume 的情況
換句話說，情況回到了情境一的形勢 (也就變成了 3b)
docker -d -p 3306:3306 --name db my-mysql-server
你可以啟動 mysql server，但它因故重啟後，就像中了人生重來槍一樣
一切都回到了最初的樣子
附帶一提，由於沒有用過 heroku，快速查了一下。
https://devcenter.heroku.com/articles/container-registry-and-runtime
VOLUME -
Volume mounting is not supported.
The filesystem of the dyno is ephemeral.
====================================================================
BUT 雖然 docker 或其它的 container engine (?)
對 volume 的功能並不太用心，在 Kubernetes 下就認真地做這塊的東西了
====================================================================
最後，結論上是如果你的資料需要長期保存的，
就該使用供應商的資料存儲服務。
這裡的長期並不是一個具體的時間長短，而是它得是個超越
container (那個 process) 生命週期的存在。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.236.126 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1580046672.A.BAC.html
推 TuCH: 學了一課 01/26 23:01
推 x246libra: 給推 原來雲端不一定支援 掛載 volume 以為都可以掛載 01/26 23:28
推 ab830921: 推學觀念 01/27 01:48
推 onegoman: 推。 01/27 07:44
→ MOONY135: 感謝說明 稅後6000p 01/27 08:03
推 vi000246: 推 01/27 09:51
推 ice831107: 推。 01/27 11:09
噓 pig2014: 請避免使用晶晶體，docker請用碼頭工人 01/27 15:18
豬貳零壹肆，我是覺得該用則用，硬翻成中文反而看不懂。※ 編輯: qrtt1 (36.231.138.200 臺灣), 01/27/2020 16:38:39
※ 編輯: qrtt1 (36.231.138.200 臺灣), 01/28/2020 10:50:01
推 BignoZe: 推推 01/28 12:56
推 hiefal: 這篇講得很好，推個 01/28 15:02
推 SimoHsieh: 推！ 01/28 15:19
推 tyoukensen: 看不懂，還是推一下。 01/28 16:52
→ easterday: 想要順便問一個問題:像下面這種docker指令 01/28 21:20
→ easterday: docker run -d -p 8888:8888 -p 8889:8889 bbsdocker/i 01/28 21:21
→ easterday: 有限制一定要甚麼作業系統嗎?(ex Linux or FreeBSD) 01/28 21:22
→ easterday: 那我用各種不同的linux dist會有很小的差別還是很大呢? 01/28 21:23
→ smartb: 回樓上, 能裝 docker engine 的話不管linux bsd 甚至 win 01/28 22:41
→ smartb: 10 pro 都可以跑 01/28 22:41
→ smartb: 執行結果應該都要一致 01/28 22:41
除了結果要一樣之外，有著不同的考量。
在早期對於 image 該用什麼有很多的試驗，
有人甚至想把 linux 弄好後，再弄 ssh 與 desktop，
簡直把它當 VM 在用了。 (好孩子不要學)
實戰了幾年後，普遍認同的是基於安全的考量
image 最好知道來源，並且不需要的東西就不要裝，以減少攻擊面積。
例如，沒有裝 ssh 相關的東西，那 openssl 有洞就不用理它了是不是 :)
基於上面的理由與 12 factor 概念被接受，
multi-stage 的支援是一種重要的宣示
https://docs.docker.com/develop/develop-images/multistage-build/
編譯時，用包含有 package manager 與 dev library 版的 image
完工的打包選用最小的 image，極端的狀態連 shell 都沒有。
像很常用的
https://github.com/alpinelinux/docker-alpine
與這幾年剛開始用的
https://github.com/GoogleContainerTools/distroless
12 fators 補充影片
https://www.youtube.com/watch?v=jufe_sHejXc
推 lasekoutkast: 推 01/29 15:39
推 kinggogo: 觀念很正確，針對db類型的服務，在架構上需要建置完整的 01/29 16:50
→ kinggogo: 保存機制 01/29 16:50
做好 backup and recovery plan 不再擔心刪庫到跑路。通例一點來想，該怎麼收納 "state"，
如果期望這些 container 都是 "stateless" 時，
當它們消失或暫時停用之時，我們資料該存在哪兒？
不外乎就是外部的 db service、object storage 或 block device。
(其實還有模擬的 filesystem，像 nfs 或 smb/cifs)
※ 編輯: qrtt1 (36.231.138.200 臺灣), 01/29/2020 17:44:34
推 uopsdod: 講的真清楚 01/30 01:05
推 zased: 之前用container化的gitlab，docker重啓後git資料全沒... 01/30 02:34
推 Arctica: 推@@ 對Container的觀念又更清楚了一點點 01/30 11:56
推 zhuzii: 推觀念++ 01/31 18:59
推 Jeniberg: 推 02/01 22:08
推 domototice: 推 謝謝大大的分享~! 02/12 05:00
推 domototice: 可以請教問題嗎?qrtt1大大，用docker能有容錯以及備份 02/12 05:15
→ domototice: 或者是能一直開著 讓Client端使用者端一直存取嗎? 02/12 05:16
→ domototice: 會有隨時當機的風險嗎? 比如 流量太大機器過熱之類的? 02/12 05:17
→ domototice: 感謝大大，求解答，不好意思....! 02/12 05:17
→ qrtt1: 單純的 docker 沒有 HA 機制，所以大家才會尋求 02/17 13:35
→ qrtt1: container orchestration 的機制，如 swarm 或 k8s 02/17 13:35
→ qrtt1: 常見的問題是被 oom killer 殺了或遇到其它 cgroup 限制 02/17 13:36
https://docs.docker.com/ee/ucp/admin/configure/join-nodes/
看起來在企業版有支援 HA，但目前的潮流是上 kubernetes。
docker 未來還會不會是主流並不明朗，因為去年它把公司賣給別人先拿錢出場了。
docker 說倒底是商業策略很成功的包裝，也改變了開發與部署的生態。
把原先不平易近人的相關技術整合在一起，
現在的主要概念轉換到 container 這中性的詞上了。
反正不管 docker 還會活多久，我們都有 container 相關技術能用。
目前只能定期盯一下 k8s 支援的前 3 名 container runtime 唄
https://kubernetes.io/docs/setup/production-environment/container-runtimes/
(去年 rkt 被拿掉了，就不用再追它囉)
※ 編輯: qrtt1 (36.231.131.153 臺灣), 02/17/2020 13:45:08