最近一两个月我在查看 VPS 运行日志的时候，经常发现 kernel 日志中会有 Out of memory 内存不足报错，而且报错基本都是 php-fpm 引起的：

root@zoserver:~# cat /var/log/kern.log
Dec 15 20:11:43 zoserver kernel: [55751339.090508] Out of memory in UB 1253: OOM killed process 32239 (php-fpm) score 0 vm:56336kB, rss:29832kB, swap:0kB
Dec 15 20:11:56 zoserver kernel: [55751352.643620] Out of memory in UB 1253: OOM killed process 32238 (php-fpm) score 0 vm:55580kB, rss:29444kB, swap:0kB
Dec 15 20:11:57 zoserver kernel: [55751353.609602] Out of memory in UB 1253: OOM killed process 32242 (php-fpm) score 0 vm:56088kB, rss:29800kB, swap:0kB
Dec 15 20:12:23 zoserver kernel: [55751379.072308] Out of memory in UB 1253: OOM killed process 32240 (php-fpm) score 0 vm:55496kB, rss:29520kB, swap:0kB
Dec 15 20:12:45 zoserver kernel: [55751401.084746] Out of memory in UB 1253: OOM killed process 32225 (php-fpm) score 0 vm:55848kB, rss:29564kB, swap:0kB
Dec 15 20:13:22 zoserver kernel: [55751438.326072] Out of memory in UB 1253: OOM killed process 32266 (php-fpm) score 0 vm:56008kB, rss:29880kB, swap:0kB
Dec 15 20:13:36 zoserver kernel: [55751452.087637] Out of memory in UB 1253: OOM killed process 32278 (php-fpm) score 0 vm:55328kB, rss:29356kB, swap:0kB
Dec 15 20:13:37 zoserver kernel: [55751453.035146] Out of memory in UB 1253: OOM killed process 32241 (php-fpm) score 0 vm:55752kB, rss:29784kB, swap:0kB

从日志里可以看到每个 php-fpm 进程的 rss 内存占用都接近 30 MB，我之前就已经将 LNMP 环境里的 php-fpm.conf 配置文件中的 pm.max_children 改为 8，这样如果碰到同时请求数较多的情况，php-fpm 就可能会占用 240 MB 内存。再加上 MySQL、BTSync 等其它程序也要占用内存，我这个在 HighSpeedWeb 上购买的 256 MB 内存的 VPS 应该就撑不住了，出现 Out of memory 错误也就不足为怪了。

为了找到原因，我决定检查一下出现内存不足时候的 nginx 请求日志：

root@zoserver:~# more /home/wwwlogs/zohead.log
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/tcpkill-nfs/ HTTP/1.1" 200
13304 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/newifi-mini-openwrt/ HTTP/1.1" 200
18841 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/linux/ubuntu/ HTTP/1.1" 200
11921 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/phone/ HTTP/1.1" 200
12800 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:43 +0800] "GET /archives/category/technology/ HTTP/1.1" 200
14862 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/category/technology/android/ HTTP/1.1" 200
15127 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/zerotier-container/ HTTP/1.1" 200
16323 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/tag/bash/ HTTP/1.1" 200
11221 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"
-
64.79.85.205 - - [15/Dec/2016:20:11:44 +0800] "GET /archives/tag/ssh/ HTTP/1.1" 200
11266 - "-" "Mozilla/5.0 (compatible; SMTBot/1.0; +http://www.similartech.com/smtbot)"

这就明显是一个不太友善的爬虫干的好事了，由于请求日志太多这里就不列出来了，统计之后可以发现这个 SMTBot 在十几秒钟的时间里请求了几百次，明显超出了 VPS 能处理的范围了。

另外我在检查日志之后还发现经常有各种初步练习用的爬虫也在不断访问 WordPress 博客数据，这种爬虫的特征就是使用各种不同的 User agent：

root@zoserver:~# more /home/wwwlogs/zohead.log
138.197.19.145 - - [17/Dec/2016:08:28:49 +0800] "GET /robots.txt HTTP/1.1" 200
145 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:00 +0800] "GET /wp-login.php HTTP/1.1" 200
2464 - "http://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:01 +0800] "GET /archives/category/technology/network-tech/https-ssl/ HTTP/1.1" 200
8604 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/category/travel/ HTTP/1.1" 502
166 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/tag/video/ HTTP/1.1" 200
11459 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /guestbook/ HTTP/1.1" 200
9962 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14"
-
138.197.19.145 - - [17/Dec/2016:08:29:03 +0800] "GET /archives/tasker-shell/ HTTP/1.1" 200
13094 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/category/technology/ HTTP/1.1" 200
13717 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/537.75.14"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/tag/android/ HTTP/1.1" 200
13879 - "https://zohead.com" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:04 +0800] "GET /archives/category/technology/android/ HTTP/1.1" 200
13842 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36"
-
138.197.19.145 - - [17/Dec/2016:08:29:05 +0800] "GET /archives/author/admin/ HTTP/1.1" 200
13716 - "https://zohead.com" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"

然而这些小爬虫发起请求来也是毫不手软，基本没有在多个请求之间加什么延时的。不过还好看起来爬虫还是读了 robots.txt 文件的，因此可以考虑在 robots.txt 和 nginx 配置里做一些限制。

防治措施

修改 robots.txt

首先把原来不太重视的 robots.txt 文件完善一下，增加了一些限制，大概如下：

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /*?replytocom=*
Crawl-delay: 30
Sitemap: https://zohead.com/sitemap.xml

禁止所有爬虫访问一些 WordPress 内部目录，增加了 Crawl-delay 参数，并设置为 30 秒，防止产生过多的请求。

修改 nginx 配置

由于并不是所有爬虫都会读取并遵守 robots 协议，特别是 Google 和百度这样的搜索巨头也明确表态不支持上面增加的 Crawl-delay 参数，为此还是需要修改 nginx 配置直接限制并发连接数：

root@zoserver:~# more /usr/local/nginx/conf/nginx.conf
http {
	limit_req_zone $anti_spider zone=anti_spider:60m rate=200r/m;
}

server {
	limit_req zone=anti_spider burst=5 nodelay;
	set $anti_spider $http_user_agent;
}

上面只是简单节选列出了 nginx 服务器配置的修改，使用 limit_req_zone 限制每分钟 200 个请求，最大并发为 5。

经过上面两步修改之后，VPS 日志里的内存不足错误看起来是减少了，但是好景不长，直到过几天我再去检查内核日志和 nginx 请求日志时发现来了一个臭名昭著的家伙，其频繁的请求仍然导致 VPS 出现 Out of memory 问题：

root@zoserver:~# more /home/wwwlogs/zohead.log
42.236.99.242 - - [09/Jan/2017:05:41:44 +0800] "GET /archives/tag/keepassdroid/?wpmp_switcher=mobile HTTP/1.1" 503
608 - "https://m.zohead.com/archives/tag/keepassdroid/?wpmp_switcher=mobile" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.178 - - [09/Jan/2017:05:41:44 +0800] "GET /archives/easymoney-to-feidee/?lang=en&replytocom=641replytocom=641replytocom=641replytocom=640replytocom=641replytocom=641replytocom=640replytocom=640&wpmp_switcher=desktop HTTP/1.1" 503
608 - "https://zohead.com/archives/easymoney-to-feidee/?lang=en&replytocom=641replytocom=641replytocom=641replytocom=640replytocom=641replytocom=641replytocom=640replytocom=640&wpmp_switcher=desktop" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.230 - - [09/Jan/2017:05:41:45 +0800] "GET / HTTP/1.1" 301
178 - "http://www.zohead.com/" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.194 - - [09/Jan/2017:05:41:47 +0800] "GET /archives/qiniu-https-tamper/?lang=en&replytocom=2190 HTTP/1.1" 200
12300 - "https://zohead.com/archives/qiniu-https-tamper/?lang=en&replytocom=2190" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.206 - - [09/Jan/2017:05:41:48 +0800] "GET /archives/category/technology/linux/page/3/?wpmp_switcher=true HTTP/1.1" 503  
608 - "https://m.zohead.com/archives/category/technology/linux/page/3/?wpmp_switcher=true" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
180.153.236.19 - - [09/Jan/2017:05:41:48 +0800] "GET /archives/category/technology/cplusplus/ HTTP/1.1" 503
608 - "https://m.zohead.com/archives/category/technology/cplusplus/" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
42.236.99.154 - - [09/Jan/2017:05:41:48 +0800] "GET /comments/feed/?lang=en HTTP/1.1" 503
608 - "http://zohead.com/comments/feed/?lang=en" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"
-
180.153.236.165 - - [09/Jan/2017:05:41:49 +0800] "GET /archives/tag/start-stop-daemon/?lang=en&wpmp_switcher=mobile HTTP/1.1" 200
8502 - "http://zohead.com/archives/tag/start-stop-daemon/?lang=en&wpmp_switcher=mobile" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0); 360Spider"

上面只是同一时段博客访问日志的很小一部分，360 搜索的 360Spider 爬虫在不断访问博客，而且看起来 360 服务器集群机器也是相当多，360 蜘蛛的 IP 地址列表可以在其官网查看：

https://www.so.com/help/spider_ip.html

经过分析日志我发现最要命的是 360 爬虫根本就没有读取 robots.txt 文件，这样根本谈不上让 Crawl-delay 之类的参数发挥作用。

迁移服务器

经过我差不多一个月的观察，现在 VPS 遇到的内存不足问题基本都是由 360 爬虫引起的，另外偶尔也有一些小爬虫不按规矩狂发请求。只是考虑到现在这个 256 MB 内存的 VPS 始终不是长久之计，因此还是想把博客迁移到其它服务器上。

首先看了看 HighSpeedWeb 现有的套餐，512 MB 内存以上的 OpenVZ 或 KVM 套餐现在价格也都不太便宜。一番参考之后我准备先将博客迁移到 IBM Bluemix 容器平台顶着，因为看起来 Bluemix 容器系统里能使用的突发内存量还是比较多的，而且毕竟目前 Bluemix 平台在我这几个月的使用感受来看除了计费不太清晰之外其它方面还算比较稳定的。

现在博客域名的 A 记录已经修改，你现在看到的页面就是运行在 Bluemix 容器上的了。另外最近碰到好几次 HTTP 的博客网站老是被运营商插入广告代码，于是我也直接禁用了 HTTP 支持，现在必须以 HTTPS 方式访问本博客了。这么一来只是略微可惜了原来 HighSpeedWeb 相当稳定的服务器了：

root@zoserver:~# uptime
 21:29:27 up 325 days,  6:16,  1 user,  load average: 0.00, 0.00, 0.00

HighSpeedWeb VPS 服务器已经稳定运行了将近一年时间了，基本上自从上次续费时不小心重启了一下服务器之后 DNSPod 的监控就没有再报过警了。因此这段时间如果 Bluemix 容器万一出什么幺蛾子还能尽快切换回 HighSpeedWeb，最后还是希望现在的 Bluemix 容器能尽量稳定运行了，祝大家元宵节玩的开心。

最近在 IBM Bluemix 管理控制台中查看容器状态时发现一直会报 策略违例 问题，进入容器详细信息界面，可以看到漏洞顾问程序扫描到的容器系统中存在的违例情况，主要是系统中某些软件包版本比较老，Bluemix 建议进行安全更新升级：

由于我的 Bluemix 容器使用的是 Ubuntu 14.04 系统，起初想着直接运行 apt-get 命令将系统中的软件包都进行升级应该就差不多可以搞定了：

root@instance-007a20ff:~# apt-get update
root@instance-007a20ff:~# apt-get upgrade

但是在升级 udev 软件包的时候发现能正确下载软件包但升级失败，提示 /etc/modprobe.d 内核模块配置目录无法正常写入：

root@instance-007a20ff:~# apt-get install udev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  udev
1 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
28 not fully installed or removed.
Need to get 735 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main udev amd64 204-5ubuntu20.19 [735 kB]
Fetched 735 kB in 1s (437 kB/s)
(Reading database ... 30255 files and directories currently installed.)
Preparing to unpack .../udev_204-5ubuntu20.19_amd64.deb ...
Adding 'diversion of /bin/udevadm to /bin/udevadm.upgrade by fake-udev'
Unpacking udev (204-5ubuntu20.19) over (204-5ubuntu20.15) ...
dpkg: error processing archive /var/cache/apt/archives/udev_204-5ubuntu20.19_amd64.deb (--unpack):
 unable to create `/etc/modprobe.d/fbdev-blacklist.conf.dpkg-new' (while processing `./etc/modprobe.d/fbdev-blacklist.conf'): Permission denied
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Removing 'diversion of /bin/udevadm to /bin/udevadm.upgrade by fake-udev'
Processing triggers for ureadahead (0.100.0-16) ...
Errors were encountered while processing:
 /var/cache/apt/archives/udev_204-5ubuntu20.19_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

我如果跳过升级 udev 包，又会由于 cpio 等软件包依赖新版本的 udev 包导致其它的软件包也无法正常升级，因此最好能解决 udev 包的升级问题。

接着我测试在报错的 /etc/modprobe.d 目录中创建文件或者拷贝文件，发现始终都是报 Permission denied 错误。看起来很有可能是由于 Bluemix 容器的限制导致无法在该目录中进行写操作。要解决 udev 包升级的问题看来需要重新打包 udev 进行安装。

重新打包 udev

首先使用 apt-get 命令下载最新版本的 udev 安装包：

root@instance-007a20ff:~# apt-get download udev
Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main udev amd64 204-5ubuntu20.19 [735 kB]
Fetched 735 kB in 0s (905 kB/s)

创建用于解压缩及重新构建 deb 包的目录：

root@instance-007a20ff:~# mkdir extract extract/DEBIAN build

开始解压缩 deb 安装包中的文件以及专用的 control 文件：

root@instance-007a20ff:~# dpkg -X udev_204-5ubuntu20.19_amd64.deb extract/
root@instance-007a20ff:~# dpkg -e udev_204-5ubuntu20.19_amd64.deb extract/DEBIAN/

接着就可以删除不需要的 fbdev-blacklist.conf 文件了，需要注意的是 control 目录中也需要移除对应项：

root@instance-007a20ff:~# rm -f extract/etc/modprobe.d/fbdev-blacklist.conf
root@instance-007a20ff:~# sed -i '/fbdev-blacklist.conf/d' extract/DEBIAN/conffiles

最后就可以打包新的 deb 安装文件了：

root@instance-007a20ff:~# dpkg-deb -b extract build
dpkg-deb: warning: 'extract/DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: warning: ignoring 1 warning about the control file(s)

dpkg-deb: building package `udev' in `build/udev_204-5ubuntu20.19_amd64.deb'.

升级 udev 相关软件包

到这一步就可以直接用 dpkg 命令安装我们重新打包的 udev 安装文件了：

root@instance-007a20ff:~# dpkg -i build/udev_204-5ubuntu20.19_amd64.deb
(Reading database ... 30255 files and directories currently installed.)
Preparing to unpack .../udev_204-5ubuntu20.19_amd64.deb ...
Adding 'diversion of /bin/udevadm to /bin/udevadm.upgrade by fake-udev'
Unpacking udev (204-5ubuntu20.19) over (204-5ubuntu20.15) ...
dpkg: dependency problems prevent configuration of udev:
 udev depends on libdbus-1-3 (>= 1.0.2); however:
  Package libdbus-1-3:amd64 is not configured yet.
 udev depends on libudev1 (= 204-5ubuntu20.19); however:
  Package libudev1:amd64 is not configured yet.

dpkg: error processing package udev (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Errors were encountered while processing:
 udev

这里的报错信息可以先不用管，后面我们再运行 apt-get upgrade 命令升级完其它的软件包就没有问题了。此时用 dpkg 命令就可以检查新的 udev 包状态：

root@instance-007a20ff:~# dpkg -l udev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture     Description
+++-======================-================-================-=================================================
ii  udev                   204-5ubuntu20.19 amd64            /dev/ and hotplug management daemon

将 Bluemix 报告的有安全风险的软件包都进行升级，等到 Bluemix 重新进行漏洞扫描之后，再访问管理控制台就可以看到 Ubuntu 容器系统已经不会报策略违例了。

本文不打算对 Docker 容器技术本身对什么介绍了，选择 IBM Bluemix 开发平台的主要原因是：

• 同时支持运行时（基于 Cloud Foundry）、容器和虚拟机（基于 openstack）；
• 服务器在国外，绑定域名不需要备案，这个优势我也挺无奈；
• 免费账户提供两个公网 IP、每个月有 365 GB-小时的运行内存额度（相当于一个 512MB 内存的容器运行一个月），能基本满足需求；
• 容器可以开启多个自己指定的 TCP 端口；
• IBM 出的货应该还比较稳定。

有关 IBM Bluemix 的详情请参考官网：

http://www.ibm.com/cloud-computing/bluemix/cn-zh/

注册账户什么的这里就不说了，Bluemix 的免费账户有 30 天的试用期，30 天之后添加有效的信用卡就可以继续使用免费额度内的运行时和容器。

Bluemix 提供了 Cloud Foundry 命令行界面 (cf) 来修改应用程序、服务实例和服务绑定，Cloud Foundry CLI 也可以安装 IBM Containers 插件以实现命令行方式管理 Docker 容器。考虑为了熟悉 Docker 命令行的目的，而且 Bluemix 容器中有一些高级功能使用 IBM Containers 插件（cf ic）可以很方便的完成，本文就主要介绍以 IBM Containers 插件（cf ic） CLI 命令的方式管理你的 Bluemix 容器。

IBM Containers 插件 (cf ic) 的官方文档请参考这里：

https://console.ng.bluemix.net/docs/containers/container_cli_cfic.html

安装 cf ic 插件

cf ic 插件的具体安装步骤可以参考 IBM 官方文档，这里我做个简单的说明。

IBM Containers 插件 (cf ic) 需要依赖 Docker 1.6 以上版本，而 Docker 官方推荐在 Linux 3.8 以上版本的 64 位系统中运行，我使用的 Chromebook 刚好能满足要求，在 Crouton 的 Ubuntu 14.04 环境中安装 Docker 非常简单：

(trusty)zzm@localhost:~$ sudo apt-get install docker.io

接着需要从 https://github.com/cloudfoundry/cli/releases 下载安装 Cloud Foundry 命令行界面 (cf)。

按照 IBM 官方文档介绍的使用 cf 命令安装容器插件时遇到报错：

(trusty)zzm@localhost:~$ cf install-plugin https://static-ice.ng.bluemix.net/ibm-containers-linux_x64

**Attention: Plugins are binaries written by potentially untrusted authors. Install and use plugins at your own risk.**

Do you want to install the plugin https://static-ice.ng.bluemix.net/ibm-containers-linux_x64? (y or n)> y

Attempting to download binary file from internet address...
10138400 bytes downloaded...
Installing plugin /tmp/ibm-containers-linux_x64...
FAILED
exit status 2

插件已经下载成功，但运行时直接报错，没办法我使用上面的地址手工下载 ibm-containers-linux_x64 之后运行，看具体是什么导致的运行出错：

(trusty)zzm@localhost:~$ ./ibm-containers-linux_x64
panic: Asset i18n/resources/zh_Hans.all.json not found

goroutine 1 [running]:
github.com/ibm-containers/i18n.initWithLocale(0x8899d0, 0x7, 0x8899d0)
        /home/jenkins/workspace/Containers-CCSCLI/containers-dcscli/plugins/src/github.com/ibm-containers/i18n/i18n.go:61 +0x72
github.com/ibm-containers/i18n.Init(0x7fa7674a3558, 0xc20802eaf0, 0x7fa7674a3658, 0xac8a10, 0xe)
        /home/jenkins/workspace/Containers-CCSCLI/containers-dcscli/plugins/src/github.com/ibm-containers/i18n/i18n.go:55 +0x124
github.com/ibm-containers/i18n.init()
        /home/jenkins/workspace/Containers-CCSCLI/containers-dcscli/plugins/src/github.com/ibm-containers/i18n/i18n.go:41 +0x199
main.init()
        /home/jenkins/workspace/Containers-CCSCLI/containers-dcscli/plugins/src/github.com/ibm-containers/wrapper_docker.go:55 +0x78

goroutine 6 [runnable]:
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:19
created by os/signal.init·1
        /usr/local/go/src/os/signal/signal_unix.go:27 +0x35

看起来是加载中文语言信息（我的 Ubuntu 默认语言就是中文）时出错然后直接退出了，试试直接把语言设为英文运行看看：

LANG=en_US.UTF-8 cf install-plugin https://static-ice.ng.bluemix.net/ibm-containers-linux_x64
......
(trusty)zzm@localhost:~$ cf plugins
Listing Installed Plugins...
OK

Plugin Name      Version   Command Name   Command Help   
IBM-Containers   0.8.826   ic             IBM Containers plug-in

这下果然就没有报错了，cf ic 插件安装成功，使用 cf plugins 命令可以列出所有安装的 Cloud Foundry 插件。

初步使用 cf ic 插件

首先使用 cf login 命令登录到区域服务器，目前 Bluemix 有美国南部、悉尼、英国这 3 个区域，这里我使用美国南部(其它区域更换 login 后面的地址即可)，输入邮箱和密码登录之后就可以看到区域信息:

(trusty)zzm@localhost:~$ cf login -a https://api.ng.bluemix.net
API endpoint: https://api.ng.bluemix.net

Email> xxx@gmail.com
Password> 
Authenticating...
OK

Targeted org xxx@gmail.com
Targeted space zohead

API endpoint:   https://api.ng.bluemix.net (API version: 2.40.0)
User:           xxx@gmail.com
Org:            xxx@gmail.com
Space:          zohead

然后需要初始化 CLI：

(trusty)zzm@localhost:~$ cf ic init

初始化完成之后可以运行 cf ic info 获取容器云服务的状态：

(trusty)zzm@localhost:~/bluemix$ cf ic info
Date/Time                : 2016-03-18 03:02:01.808641119 +0800 CST
Debug Mode               : false
Host/URL                 : https://containers-api.ng.bluemix.net
Registry Host            : registry.ng.bluemix.net
Bluemix API Host/URL     : https://api.ng.bluemix.net
Bluemix Org              : xxx@gmail.com(xxx-xxx-xxx-xxx-xxx)
Bluemix Space            : zohead(xxx-xxx-xxx-xxx-xxx)
CLI Version              : 0.8.826
API Version              : 3.0 2028 2016-03-16T19:34:24
Namespace                : zohead
Environment Name         : prod-dal09-vizio3
Containers Limit         : Unlimited
Containers Usage         : 0
Containers Running       : 0
CPU Limit (cores)        : Unlimited
CPU Usage (cores)        : 0
Memory Limit (MB)        : 2048
Memory Usage (MB)        : 0
Floating IPs Limit       : 2
Floating IPs Allocated   : 0
Public IPs Bound         : 0

可以看到试用账户的内存使用限制是 2GB，可以使用两个 IP 地址。

使用 cf ic 构建 Docker 容器

一般情况下你都可以使用 Bluemix 官方提供的 Docker 镜像进行快速构建，由于通常的 Docker 镜像只是为了运行特定的程序或服务设计的会有不少限制，无法满足我要调试运行多个程序的需求，而且为了后续 SSH 登录之类的考虑，我准备使用 Baseimage-docker 这个比较特殊的 Docker 镜像来构建容器。

首先在当前目录下生成 Dockerfile 文件：

(trusty)zzm@localhost:~/bluemix$ cat > Dockerfile 
# Use phusion/baseimage as base image.
# See https://github.com/phusion/baseimage-docker/blob/master/Changelog.md for a list of version numbers.
FROM phusion/baseimage:0.9.18

EXPOSE 22 80 443 9080 9443

# Use baseimage-docker's init system.
CMD ["/sbin/my_init"]

# ...put your own build instructions here...

# Clean up APT when done.
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Dockerfile 文件简单说明如下：

• FROM 后面的 phusion/baseimage:0.9.18 表示 Docker 镜像的地址和版本，具体使用哪个版本请参考上面注释里的 Changelog.md 文档；
• EXPOSE 表示此 Docker 容器要导出哪些 TCP 端口以使外部能访问到容器。

提示

IBM Bluemix 目前对容器导出的端口有严格的限制，只有常用端口才能导出，官方论坛里列出的可用端口为：
22,80,443,9080,9443

不属于上面列出的其它端口就算通过 Dockerfile 导出也无法访问。

同时需要注意的是使用 Dockerfile 构建容器完成之后就不能再修改导出的端口了，想再换别的端口只能删除旧容器重新构建，因此开始的端口选择需要谨慎。

总之我的 Dockerfile 文件将可用的 5 个端口都导出了，下面使用 cf ic build 命令构建容器：

(trusty)zzm@localhost:~/bluemix$ cf ic build -t zohead-server:v1 .

上面的 zohead-server 为新的容器名字，最后的 . 参数表示 Dockerfile 文件所在的目录（. 即当前目录）。

容器构建完成之后如果没有什么问题就可以用 cf ic run 命令启动新容器了：

cf ic run --name=zohead-server -m 512 -p 22 -p 80 -p 443 -p 9080 -p 9443 registry.ng.bluemix.net/`cf ic namespace get`/zohead-server:v1

cf ic run 命令的 --name 参数指定容器名字；-m 参数则是为新容器分配的内存大小，为了不超过免费额度我分配了 512MB；-p 参数指定公开用于 TCP 流量的端口,可以指定多个，这里我指定的 5 个端口和 Dockerfile 文件中的一致。

启动容器成功之后等待一段时间就可以使用 cf ic ip list 命令查看 IBM Bluemix 为你的容器分配的公网 IP 地址，公网 IP 地址分配成功之后才可以直接访问容器中的服务：

(trusty)zzm@localhost:~/bluemix$ cf ic ip list
Number of allocated public IP addresses: 1

Listing the IP addresses in this space...
IP Address       Container ID   
134.168.27.107   xxx-xxx-xxx-xxx-xxx

上面列出的 IP Address 就是为容器分配的公网 IP 地址，由于我使用的是美国南部区域，分配的公网 IP 地址 ping 值不是特别理想。

访问 Docker 容器

即使容器没有分配正确的公网 IP 地址，我们也可以使用 cf ic exec 命令直接访问容器执行命令：

(trusty)zzm@localhost:~/bluemix$ cf ic exec zohead-server echo "Hello Bluemix"
Hello Bluemix

当然也可以使用 cf ic exec 命令直接开启一个连接到容器的 Bash Shell 终端：

(trusty)zzm@localhost:~/bluemix$ cf ic exec -t -i zohead-server bash -l

有了公网 IP 地址之后，你就可以参考 Baseimage-docker开启 SSH 的说明启用 SSH 证书登录了，这里也比较简单我就不做介绍了。

Bluemix Docker 容器能够 SSH 登录之后就比较方便了，Baseimage-docker 镜像里自带了 Python 3 支持，我们可以直接使用 Python 3 运行一个最简单的 Web 服务器验证导出的 TCP 端口能否正常访问：

root@instance-001afe36:/home/wwwroot# python3 -m http.server 80

由于 Bluemix 容器用的是 IBM Containers，我们可以用 capsh 命令看看 Bluemix 是否和其它 Docker 容器服务一样存在权限限制：

root@instance-001afe36:~# capsh --print
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)

看起来限制和常见的 Docker 平台也差不多，没有一些特别的系统管理权限，例如我想测试的基于 tun 驱动的开源 VPN 服务也无法使用了。

监控 Bluemix 容器运行状态

一番使用下来你会发现参考 Bluemix 官方的文档就可以基本只用 cf ic 命令实现完成创建、构建、运行和管理 Bluemix 容器这一整套操作了。如果你要监控容器的历史运行状态或者要查看账单之类的那可能还是需要访问 Bluemix Web 控制台的，这个是我的 Docker 容器运行时的内存使用情况：

基本的功能在 Bluemix Web 控制台里也是可以完成的，如果使用中遇到问题可以在 Web 控制台里创建技术支持工单（只是 IBM 的技术支持响应速度似乎很慢的）。

注意

我在试用 Bluemix 容器的时候发现有一个不太容易被注意到的坑就是容器里使用 free 或者 top 等命令看到的内存非常大（远远超过我分配的 512MB，似乎显示的是实际服务器的总体内存，而且容器里的程序也能分配超过 512MB 的内存，因此容器里实际运行的程序内存占用需要注意不要超过限额。

你也可以在 Web 控制台中点击账户图标，然后进入「管理组织」设置，这里可以修改当前区域的运行时和容器使用配额：

经过十几天对 IBM Bluemix Docker 容器的试用来看，虽然 IBM 的服务器不在国内，但 Bluemix 容器还算是比较稳定的，对于一般的开发者来说调试运行一些服务程序也是比较方便的。

一般用户使用这种容器服务最多的用途像跑博客之类的 Web 服务是没什么问题的，不过国内似乎不少人只是用 Bluemix 容器跑 Shadowsocks 代理了（真的算是国内用户的刚性需求了么 -_-#），对此我只能说 IBM Bluemix 目前还是比较良心的，大家且用且珍惜请不要滥用呢，最后祝玩的开心 ～～～。