ss dockerfile 应该使用 exec 命令启动

islishude commented 5 years ago

https://github.com/mritd/dockerfile/blob/ad2bbd4926f234cbd6e7f02b75a0b5d2ede98a63/shadowsocks2/entrypoint.sh#L4-L7

这里应该用 exec 启动，不用的话会衍生出一个新进程，这样信号就不能发送到 ss 服务了。

mritd commented 5 years ago

@islishude

这个问题其实从引入 kcptun 以后就存在了，当容器内存在多个服务时已经违背了容器化理念；一开始这个镜像只有自己在用，后来人用的多了，也没法强制删除 kcptun 服务；

对于进程管理这块，目前通过 5c51231db8321401915cf5fd8377fa01d180c1f3 引入 runit 守护工具解决，对于容器内信号接收，不论是这个镜像还是 java 应用等镜像，事实上我们应当在 dockerd 守护进程中开启 --init 参数以引入 tini 程序来正确处理信号(或者在 run 时手动增加)

在上层 k8s 编排系统中，由于 pod 概念存在，为保证 pod 内容器共享 network namesapce，pause 始终作为 PID 1 进程运行，此时应当保证每个镜像内 entrypoint 由 tini 引导；这个镜像暂时考虑大部份都是单机运行，所以也没去集成 tini

关于容器体积，如果作为一个广泛使用的镜像，在友好使用(体验度)和镜像体积上应当有一个平衡；我个人认为在 200m 内体积大小的镜像都是可以接受的，毕竟一般只会拉取一次而反复使用；只要不强行将 Centos 作为基础镜像来搞一般都可接受；这个镜像实际上从引入 kcptun 以后镜像体积就已经从 "极度精简" 放大到 "一般可用" 的地步，如果真要费力去精简，kcptun、v2ray 都应当在当前 musl c 下动态编译，并且增加 -w -s ldflag，但是感觉这样做的代价和收益是不成正比的

islishude commented 5 years ago

@mritd 我看了你的回复，貌似说的是 shadowsocks，我这里是改动的 shadowsock2，那个 go 实现的。

mritd commented 5 years ago

😌2....我以为没人发现哈哈哈

mritd commented 5 years ago

bash 当时是为了偶尔进去方便，tz 为了调整时区...不过对于这个 ss2 bash 确实是多余的

mritd commented 5 years ago

已经移除了 bash

mritd / dockerfile

ss dockerfile 应该使用 exec 命令启动 #77