一个 hexo 的最小化服务器端 docker 构建脚本，需要的自取
cnnblike · cnnblike · 2016-12-27 09:05:18 +08:00 · 4461 次点击这是一个创建于 2880 天前的主题，其中的信息可能已经有所发展或是发生改变。
xD 众所周知，大部分 docker 服务提供商诸如 hyper.sh 还有网易蜂巢之类的，都是按容器的大小和数量计费的，因此虽然 docker 官方给的最佳实践是“每个容器只包含一个程序”，但实际上你一个一万年都不会有人访问的博客服务，当然是能省则省，这个脚本就是出于这个目的来设计的——我虽然没有挑战 64mb VPS 那种想法，但是这个脚本构建出来的内存还真的不需要 64mb ，因为不通过 git deployer 提交内容的时候，常态化运行的只有这三个：
-
nginx - 提供静态网页服务
-
ssh - 通过 git 提交时会用到
-
hypervisor - docker 启动时自动启动两个程序，在 ssh 和 nginx 挂掉的时候自动重开，在更新 nginx 设置后提供 hypervisorctl restart nginx 的动作
我在 hyper.sh 上试了一下，这个镜像的内存占用只有 59mb ，如果把 openssh 换成 dropbear ，把 bash 换成其他莫名其妙的 sh ，把 nginx 换成 lighttpd ，内存占用会更少——当然我更加建议你在 hyper.sh 上最少使用 128M 的容器为好， 64M 一个月和 128M 一个月也就差了 0.5 刀，总不至于连这点钱都出不起，哈哈。
地址在这里： https://github.com/cnnblike/hexo-server-all-in-one
构建方法：
把自己的 blog.pub （公钥）放到目录下，然后docker build -t test:v1 .
部署方法自行参照自己的 docker 服务提供商。
如何向这个 docker 灌注内容呢？
你需要两个 repo ，一个 repo 是 content-repo ，一个 repo 是 config-repo 。
content-repo 的信息如下： ssh://root@<your domain="">/var/repo/blog.git ，其中的内容会通过 post-hook 自动复制到 /var/www/html/中，复制后 nginx 会自动重启
config-repo 的信息如下： ssh://root@<your domain="">/var/repo/config.git ，其中的内容会通过 post-hook 自动复制到 /etc/nginx/中，复制后 nginx 会自动重启
事实上，我已经通过自 host 的 gogs 和 jenkins 搭起了一个全自动部署的服务，这样子就可以达到我在 gogs 的网页上修改了后台的 md 文件，会自动推送到 jenkins 服务器进行 hexo g 然后 hexo d 到这个展示的静态 docker 中，感觉还不错，你们有兴趣的话我可以把过程拿出来分享一下
 |
1
leopku 2016-12-27 10:29:39 +08:00
这不完全是虚拟机的思维用 docker 嘛
|
 |
2
GOOD21 2016-12-27 10:35:24 +08:00
"但实际上你一个一万年都不会有人访问的博客服务"...
莫名戳中泪点... |
 |
3
cnnblike OP @leopku
几个点： 0.hypervisor+多进程就是虚拟机了？这里实际上工作的只有 nginx ， git 和 ssh 只在被调用的时候才消耗内存。 1.docker 便宜，而且买到多少内存的 docker 就是多少内存的 docker ，不像 vm ，你买个 OpenVZ 怕超售，买个 128M 的 KVM ， ramnode 那种，一年 15 刀的，价格和 hyper.sh 上一样，但是 128M 的内存，系统内核又吃掉一大半。 2.国内最便宜的可备案服务器是网易蜂巢的 Docker ，网易一个月 30 块， 640M 内存，送 50G 流量，比阿里云便宜得不知道到哪里去了，更不要说阿里云根本都特么不卖 512M 内存的了。 3.相同的功能如果要分成 nginx 和 ssh 分开弄，两个共享一个 docker volume 这么复制来复制去，加起来就是 3 个 docker ，兄弟预算和我不一样。 我在做一个自我挑战，就是一个月花 10 刀，在美国和中国各部署一份服务，保持中美两国的访问速度都在某个范围内。 4. Phusion 对于容器内多任务的看法是这么说的： ``` "But I thought Docker is about running a single process in a container?" Absolutely not true. Docker runs fine with multiple processes in a container. In fact, there is no technical reason why you should limit yourself to one process – it only makes things harder for you and breaks all kinds of essential system functionality, e.g. syslog. We encourage you to use multiple processes. ``` 我觉得你还是看得片面了 |
 |
4
fucker 2016-12-27 10:55:01 +08:00
"但实际上你一个一万年都不会有人访问的博客服务"...
莫名戳中泪点... |
 |
5
bonfy 2016-12-27 10:59:20 +08:00
"但实际上你一个一万年都不会有人访问的博客服务"...
莫名戳中泪点... |
|
6
bonfy 2016-12-27 11:00:05 +08:00
"但实际上你一个一万年都不会有人访问的博客服务"...
莫名戳中泪点..... |
 |
7
shyling 2016-12-27 12:04:45 +08:00
还是喜欢通过 auto build 直接把静态文件写到 image 里，然后 deploy 这个 image ，而不是做个 git repo 。。。
|
 |
8
oott123 2016-12-27 12:19:33 +08:00
同意 #7
完全可以通过自动构建服务，就只需要运行一个 nginx 就好…… 当然了，你都有自动构建服务了，那不如托管到 xx pages 上…… |
|
9
cnnblike OP @shyling
@oott123 现在各家容器托管商的操作流程不大一样，如果统一放到 CI 里面的话，可能到最后 Travis 脚本就变成了纠结这堆托管商的 API 啊之类的事情了。 我个人的想法就是直接把内容部署和容器托管商分开，比方说我可能需要一个德国的 docker ，但是德国当地没有 docker 提供商，只有 VPS 提供商，这样把 docker 部署到 vps 之后，部署用的 git 那一套就是统一的了。 github pages 我也想过，国内的状态还是尴尬。一来是墙，二来是速度，在浙江省境内，网易蜂巢的 ping 不超过 10ms ，完全没法比 另外的考虑就主要是以后还可能要在 image 上跑一些小的实验性的玩具吧， pages 灵活性不大够，加上前几天 github 又对 pages 加各种限制，感觉靠谱度又下降了 |
|
10
leopku 2016-12-27 13:57:17 +08:00
|
|
11
shyling 2016-12-27 14:02:16 +08:00
https://github.com/lingmm/IssueBlog 窝这个就是类似那样的。不过我留的文件稍微多了点
|
Select Language