作者qrtt1 (有些事，有时候。。。)
看板Soft_Job
标题Re: [请益] 教学10000p heroku aws GCP deploy
时间Sun Jan 26 21:51:08 2020
原标题：
[请益] 教学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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1580046672.A.BAC.html
1F：推 TuCH: 学了一课 01/26 23:01
2F：推 x246libra: 给推 原来云端不一定支援 挂载 volume 以为都可以挂载 01/26 23:28
3F：推 ab830921: 推学观念 01/27 01:48
4F：推 onegoman: 推。 01/27 07:44
5F：→ MOONY135: 感谢说明 税後6000p 01/27 08:03
6F：推 vi000246: 推 01/27 09:51
7F：推 ice831107: 推。 01/27 11:09
8F：嘘 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
9F：推 BignoZe: 推推 01/28 12:56
10F：推 hiefal: 这篇讲得很好，推个 01/28 15:02
11F：推 SimoHsieh: 推！ 01/28 15:19
12F：推 tyoukensen: 看不懂，还是推一下。 01/28 16:52
13F：→ easterday: 想要顺便问一个问题:像下面这种docker指令 01/28 21:20
14F：→ easterday: docker run -d -p 8888:8888 -p 8889:8889 bbsdocker/i 01/28 21:21
15F：→ easterday: 有限制一定要甚麽作业系统吗?(ex Linux or FreeBSD) 01/28 21:22
16F：→ easterday: 那我用各种不同的linux dist会有很小的差别还是很大呢? 01/28 21:23
17F：→ smartb: 回楼上, 能装 docker engine 的话不管linux bsd 甚至 win 01/28 22:41
18F：→ smartb: 10 pro 都可以跑 01/28 22:41
19F：→ 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
20F：推 lasekoutkast: 推 01/29 15:39
21F：推 kinggogo: 观念很正确，针对db类型的服务，在架构上需要建置完整的 01/29 16:50
22F：→ 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
23F：推 uopsdod: 讲的真清楚 01/30 01:05
24F：推 zased: 之前用container化的gitlab，docker重啓後git资料全没... 01/30 02:34
25F：推 Arctica: 推@@ 对Container的观念又更清楚了一点点 01/30 11:56
26F：推 zhuzii: 推观念++ 01/31 18:59
27F：推 Jeniberg: 推 02/01 22:08
28F：推 domototice: 推 谢谢大大的分享~! 02/12 05:00
29F：推 domototice: 可以请教问题吗?qrtt1大大，用docker能有容错以及备份 02/12 05:15
30F：→ domototice: 或者是能一直开着 让Client端使用者端一直存取吗? 02/12 05:16
31F：→ domototice: 会有随时当机的风险吗? 比如 流量太大机器过热之类的? 02/12 05:17
32F：→ domototice: 感谢大大，求解答，不好意思....! 02/12 05:17
33F：→ qrtt1: 单纯的 docker 没有 HA 机制，所以大家才会寻求 02/17 13:35
34F：→ qrtt1: container orchestration 的机制，如 swarm 或 k8s 02/17 13:35
35F：→ 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