@brader #29 房间面积小才做一体化定制(用板材)，如果卧室 12 平米以上建议直接买实木家具(尺寸也可以定制)，别用板材，价格贵不了多少，更耐用，更环保。

Portainer ，compose 文件能写在 stack 里

刷墙选涂料，就选立邦或多乐士，二楼潮气大，立邦和多乐士的防霉效果是很好的，别选小众品牌，过 1-2 年墙黑黑的都是霉斑。 (题外话：如果墙面出现黑黑的霉斑，擦了过几星期又出现，最佳解决方式就是用大桶立邦漆刷一遍墙)

如果铺设地暖，地砖比地板好。开地暖，穿袜子不穿鞋踩地砖上暖暖的好舒服，地板传热差些没地砖舒服。 如果不铺设地暖，实木地板是最好的。

别买复合地板，也别买多层实木复合地板，窗边雨水溅入后这 2 种地板泡水几个小时会坏的，纯实木地板泡水几小时擦干净了问题不大。

@connor123 实木地板推荐“圆盘豆” (一种木料)，木制坚硬，色泽不错，绝对是性价比之王。

@sss15 #9 展开讲一下：容器无网卡用 unix socket 通讯

举一个示例： 前置 nginx 接 python flask 的 web(GUNICORN)，nginx 和 flask 都使用容器部署，flask 容器从绑定 tcp:5002 改成无网卡绑定/run/unix-socket/flask/flask.sock 。如果 flask 要访问 mysql 之类的，mysql 开启 unix socket 然后 volume 给 flask 容器即可。

flask 容器的 compose 文件原来配置是：
environment:
- GUNICORN_CMD_ARGS=-w 8 -b 0.0.0.0:5002 -k gevent
改成：
network_mode: none
environment:
- GUNICORN_CMD_ARGS=-w 8 -b unix:/run/unix-socket/flask/flask.sock -k gevent
volumes:
- /run/unix-socket/flask:/run/unix-socket/flask

nginx 容器的 compose 文件加入：
volumes:
- /run/unix-socket/flask:/run/unix-socket/flask

nginx 的网站配置从：
proxy_pass http://flaskcontainer1:5002/;
改成：
proxy_pass http://unix:/run/unix-socket/flask/flask.sock:/;
(语法：nginx 的 url 域名部分替换成 unix:/run/unix-socket/flask/flask.sock)

如果黑客入侵了 flask 容器，感知到的就是一个无网卡的黑洞洞的孤立世界。

@wu67 #6 256MB 内存的小 vps 就能很完美的跑 docker ce 了

很多开源项目或多或少有 bug ，有些常用的开源项目很容易被入侵的。

1. 选 base image 尽量选 debian 别选 alpine 。因为 alpine 基于 busybox 有 nc 、wget 、ping 等黑客入侵时做跳板用工具； debian 基础镜像没有 curl 、wget 、ping 等工具，入侵会困难很多，软件兼容性也好。（这条有点反常识，但是很关键）

2. 如果项目开 tcp 端口支持 unix socket ，可以把项目容器设置成无网卡，通过 volume 将 unix socket 文件夹分享给 nginx 、frp 的前置应用，黑客入侵到项目容器感知到的就是一个黑洞洞的孤立世界。 如果项目不支持 unix socket ，也可以将项目容器配置成无网卡，tcp 端口绑定到容器 127.0.0.1 ，然后使用 socat 转化成 unix socket

如果接入 internet ，当然是用 docker ，安全啊

网上很多入侵案例，用 docker 的只需对容器 down 和 up 一下，如果本机安装就要重装系统工作量超大的。

sdk 层是另外部门的，当然要推回给这个部门。如果感觉自己有能力做 sdk 层，也要等对方扯皮再勉为其难的接下来。

M3 ，8GB 不够用别委屈自己

iphone 手机的国际漫游的开关开了吗

显卡视频解码是用 gpu 的 video decode 单元，这个单元普遍很弱，打不过 cpu 多核解码，intel 、amd 也都一样。

接#57 如果必须在 k8s 上部署数据库，估算一下数据库的大小，然后为容器分配 2 倍以上的内存，例如：估摸着数据库总容量为 6GB ，就为容器分配 12GB 内存。容器刚启动时读盘稍慢些，跑一段时间后数据库都缓存在内存里，就不慢了。

k8s 持久性存储的 io 有瓶颈，绝大多数的 k8s 持久存储都比 sata 还要慢很多，所以数据库不建议部署在 k8s 上。如果是本机 docker 是 OK 的，性能基本接近本机安装，维护也方便。

小心一件事情，如果限制容器的 cpu 、内存资源，容易不稳定出问题。

因为，容器里获取到的 cpu 数量和内存都是主机值，不是容器限制值。

例如：主机 16 核但是 nginx 容器限制 4 核，nginx 会根据 cpu 数量自动设置 workers 进程数量，也就是按 16 核分配了过多的 workers 导致高负载下性能急剧下降。

例如：主机 64GB 内存但是 mysql 容器限制 8GB 内存，mysql 读到的是主机 64GB 内存，然后不断占用内存超 8GB 后被系统杀死，导致 mysql 异常重启。

推荐，不要在 docker 里限制容器 cpu/内存，改成在软件配置里加限制；如果必须在 docker 里限制容器 cpu/内存，则需要调整软件配置以匹配容器限制。

联系 apple support 能改激活起始日期的