最近了解到一个比较新的 Lade 云开发平台，Lade 是专为开发者设计的云端平台，可以帮助开发者在云端部署测试应用，并提供基础的免费应用额度，还有多处数据中心服务器可供选择，还默认直接支持 HTTPS 域名以方便连接访问容器应用。

Lade 开发平台默认支持以下编程语言：

• Go
• Node.js
• PHP
• Python
• Ruby

以及以下这些常用的数据库：

• MariaDB
• Memcached
• MongoDB
• MySQL
• PostgreSQL
• Redis

对于其它编程语言，Lade 还支持以 Dockerfile 形式运行测试应用容器。

首先可以在 Lade 官方网站注册账户，然后需要绑定并验证 GitHub 账号后才能创建部署容器应用。

Lade CLI 部署应用

Lade 网站目前没有提供任何容器应用的部署和管理的功能，容器应用的部署和管理都需要使用 Lade CLI 工具来完成。

这里以 Linux 系统为例进行简单的介绍，按照页面介绍来安装 Lade CLI：

~# curl -L https://github.com/lade-io/lade/releases/latest/download/lade-linux-amd64.tar.gz | tar xz
~# sudo mv lade /usr/local/bin

首先使用 CLI 登录 Lade 账户：

~# lade login
Enter your Lade credentials:
? Username or email: zohead
? Password: 
Logged in as zohead*

输入用户名和密码登录成功之后就可以进行创建部署容器应用了，这次我准备先部署一个 Miniflux 应用来试试效果。

Miniflux 是一个极简的 RSS 阅读器应用，基于 Go 语言开发，使用 Postgres 数据库保存数据，与其它 RSS 阅读器应用相比功能和界面都很简洁，不过关键还支持抓取 RSS 文章全文、全文检索等功能。

Lade 的收费方式可以参考官网 Pricing 页面，并有基础的免费额度，当然免费的额度也是随时有可能取消的：

• 应用：
  • 128 MB 内存；
  • 1 CPU；
• 数据库：
  • 128 MB 内存；
  • 1 GB 存储空间；
• 磁盘：
  • 1 GB 磁盘。

备注：

2025-06-07 开始 Lade 平台正式取消了免费额度，目前最便宜的 128 MB 内存 / 1 CPU 的应用价格为每月 $1.25，大家自行酌情选择合适的容器收费配置计划。

应用容器

我们首先使用 lade apps create 命令创建新的应用容器，按照提示输入应用容器名称，并选择容器配置和区域即可完成创建，这里就选择免费配置计划和日本东京区域：

提示：

• 容器名称非常关键，后面很多命令都需要用到，请谨慎输入；
• 请根据实际应用程序对内存和 CPU 的要求，选择合适的应用配置计划；
• 免费额度随时有可能取消，如果使用免费配置计划，请注意备份应用数据。

~# lade apps create
? App Name: miniflux
? Plan: 128mb
? Region: Tokyo

创建成功之后，可以运行 lade apps list 命令查看容器列表：

~# lade apps list
NAME        PLAN     CREATED           STATUS
miniflux    128mb    43 minutes ago    running

另外使用 lade apps show 命令可以查看具体某个应用容器的详细信息和状态，下方输出数据最后的 Web URL 就是 Lade 云开发平台为容器应用自动分配的 HTTPS 访问域名：

~# lade apps show miniflux
Owner:        XXX@XXX.com
Processes:    web: 0/1
Plan:         128mb
Region:       Tokyo
Status:       running
Web URL:      miniflux-zohead.ladeapp.com

接着我们就需要在容器上部署实际的应用了，对于 Miniflux 可以从 GitHub 检出最新 v2 版本的代码：

~# mkdir miniflux
~# cd miniflux
~/miniflux# git clone --depth 1 https://github.com/miniflux/v2.git

然后使用 lade deploy 命令进行容器应用部署：

~# lade deploy --app miniflux
time="2025-04-24T20:28:59+08:00" level=error msg="Can't add file internal/reader/readability/testdata to tar: archive/tar: unknown file mode ?rw-rw-rw-"
Sending build context to Docker daemon  4.563MB
Step 1/11 : FROM golang:1.23.0
1.23.0: Pulling from library/golang
Successfully built e7ae4ac3677b
Successfully tagged registry.lade.io/zohead/miniflux:build-1njzwaheu4
Pushing miniflux build to registry
Build finished use "lade logs -a miniflux -f" to view app logs

容器应用部署成功之后，我们可以使用 lade ps 命令确认容器内的进程是否运行正常，可以看到 Lade 部署生成的 miniflux.app 应用程序进程正在运行：

~# lade ps -a miniflux
NAME     PLAN     STARTED         COMMAND
web.1    128mb    14 hours ago    miniflux.app

我们还可以使用 lade run 命令实现在应用容器中运行需要的命令，这里就直接运行一个 Bash Shell，运行自定义命令也需要指定一个配置计划，这里还是使用免费配置计划：

~# lade run "bash" -a miniflux -p 128mb

容器内的 Bash Shell 启动成功之后，我们可以查看并确认 Miniflux 应用信息，对于 Miniflux 这种 Go 语言应用，Lade 默认部署生成的应用程序在 /go/bin 目录下：

~$ ls -l /go/bin/miniflux.app
-rwxr-xr-x 1 web web 19411204 Apr 24 12:30 /go/bin/miniflux.app
~$ miniflux.app -i
Version: dev
Commit: HEAD
Build Date: undefined
Go Version: go1.23.0
Compiler: gc
Arch: amd64
OS: linux

另外根据上面部署命令输出中的提示信息，使用 lade logs -a miniflux -f 命令可以跟踪显示容器应用的运行日志，实际上就是显示容器内应用程序的标准输出和错误输出：

~# lade logs -a miniflux -f
web.1 | level=INFO msg="The default value for DATABASE_URL is used"
web.1 | dial tcp [::1]:5432: connect: connection refused

由于还没有为 Miniflux 应用配置数据库，会出现类似上面的报错信息。

数据库扩展

接着我们需要使用 lade addons create 命令为容器应用配置数据库扩展，下面的 lade addons create postgres 命令即为创建 PostgreSQL 数据库，我仍然使用免费配置计划，并选择和应用相同位置的日本东京区域，以加快数据库访问速度：

~# lade addons create postgres
? Addon Name: miniflux-postgres
? Plan: 128mb
? Region: Tokyo
? Version: 17
? Public: No

简单说明一下命令参数：

• Addon Name 为数据库扩展名称，后续扩展管理相关命令也会用到；
• Version 为数据库版本，lade 命令会列出支持的数据库版本；
• Public 表示数据库是否允许外部公共访问，我只需要 PostgreSQL 数据库被 Miniflux 应用访问，并不需要公共访问，这里就选 No 了。

创建成功之后，就可以使用 lade addons show 命令查看数据库扩展的详细信息和状态了：

~# lade addons show miniflux-postgres
Owner:        XXX@XXX.com
Service:      PostgreSQL
Plan:         128mb
Region:       Tokyo
Version:      17
Public:       No
Status:       running
Addon URI:    postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require

最后的 Addon URI 就是最关键的数据库连接地址，我们需要为应用容器配置数据库连接地址，地址中包含数据库服务器地址、用户名、密码、数据库名称等数据。

确认数据库运行正常之后，就可以将 PostgreSQL 数据库扩展附加到 Miniflux 应用容器：

~# lade addons attach miniflux-postgres --app miniflux
? Env Name: POSTGRES_URL

然后使用 lade env list 命令检查应用容器的环境变量：

~# lade env list -a miniflux
DATABASE_URL=postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require
POSTGRES_URL=postgresql://USERNAME:PASSWORD@tyo-sw1.lade.io:30066/XXXX?sslmode=require

可以看到数据库扩展附加之后，会自动为应用容器配置数据库环境变量，包含通用的 DATABASE_URL 和 PostgreSQL 专用的 POSTGRES_URL 环境变量。

Miniflux 应用容器问题

我原以为按照上面的步骤为 Miniflux 应用容器配置好 PostgreSQL 数据库扩展之后，Miniflux 应用就可以正常运行了，而实际上容器仍然有报错：

~# lade logs -a miniflux -f
web.1 | the database schema is not up to date: current=v0 expected=v108

参考 Miniflux 项目 You must run the SQL migrations, the database schema is not up to date: current=v0 expected=v62 Issue 的说明，对于类似 Docker 容器的环境 Miniflux 需要开启 RUN_MIGRATIONS 环境变量。

我们可以使用 lade env set 命令为容器配置或修改环境变量：

~# lade env set RUN_MIGRATIONS=1 -a miniflux

稍等一会容器应用自动重启后，就可以看到 Miniflux 应用已经正常运行了：

~# lade logs -a miniflux -f
web.1 | level=INFO msg="Running database migrations" current_version=0 latest_version=108 driver=postgresql
web.1 | level=INFO msg="Starting HTTP server" listen_address=:3000

现在我们其实就已经可以通过 Lade 云平台为容器应用分配的域名访问 Miniflux Web 管理界面了，当然还是需要用 HTTPS 访问的：

不过由于我们还没有为 Miniflux 配置管理员账户，还不能直接登录。

这个时候就需要借助 lade run 命令在应用容器中运行命令创建管理员账户了，下面输出中的 miniflux.app 程序是在容器内运行的：

~$ miniflux.app -create-admin
Enter Username: admin
Enter Password:
level=INFO msg="Created new admin user" username=admin user_id=1

管理员账户创建成功之后，我们就可以通过容器域名访问 Miniflux Web 管理界面进行 RSS 源的配置和订阅管理了。

当然我们也可以开始就通过指定环境变量让 Miniflux 容器自动创建管理员账户，与上面的 RUN_MIGRATIONS 环境变量配合起来就类似：

~# lade env set RUN_MIGRATIONS=1 CREATE_ADMIN=1 ADMIN_USERNAME=admin ADMIN_PASSWORD=password -a miniflux

这样通过环境变量指定管理员账户名称和密码也很方便。

总结

本文简单介绍了如何使用 Lade 云开发平台的 lade CLI 命令部署配置容器应用，我部署的 Miniflux RSS 阅读器容器应用也运行了一段时间，Lade 云平台还是比较稳定的，只是没有国内的数据中心，访问速度倒是一般。

最后 Lade 云平台的开发者已经确认，目前提供的免费额度仅供开发人员测试使用，免费额度后续随时有可能取消，希望大家不要滥用，如果觉得 Lade 好用也可以考虑付费使用哦，祝大家玩的开心。

前段时间需要验证某客户的 32 位 ARM Linux 程序，由于我们只有现成的 ARM64 设备和系统，而 ARM64 兼容 32 位 armel 和 armhf，因此想到直接在 ARM64（aarch64）Linux 系统中运行 32 位 ARM（armhf）容器来进行测试。

客户程序使用的是 CentOS 7 32 位 ARM 开发环境，这里我使用 LXC 官方镜像来创建一个完整的 CentOS 7 容器系统：

~ # lxc-create -n arm -t download --dir=/var/lib/lxc/arm/rootfs -- --server mirrors.tuna.tsinghua.edu.cn/lxc-images -d centos -r 7 -a armhf

32 位 ARM 容器可以正常启动，但使用 yum 安装任何软件包会报错：

bash-4.2# yum install openssh-server
Loaded plugins: fastestmirror
Determining fastest mirrors


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: base/7/armv8l

yum 修改

上面 yum 命令的报错提示找不到 repo 为 base/7/armv8l 的地址，我们可以在容器中使用 uname 命令确认当前的系统架构为 armv8l（ARM64 内核运行 32 位 ARM 程序）：

bash-4.2# uname -m
armv8l

而在主机端则可以看到真正的系统架构为 aarch64：

~ # uname -m
aarch64

正是由于 yum 不能正确识别 armv8l这个特殊的系统架构，导致命令执行失败。

我们可以修改 /usr/lib/python2.7/site-packages/rpmUtils/arch.py 文件，使 yum 可以正确处理 armv8l 架构，以下为 patch 修改内容：

diff -rNp a/arch.py b/arch.py
*** a/arch.py   Thu Oct 29 23:46:21 2020
--- b/arch.py   Thu Oct 29 23:48:55 2020
*************** arches = {
*** 73,78 ****
--- 73,79 ----
      "armv5tel": "noarch",
  
      #arm hardware floating point
+     "armv8l": "armv7hl",
      "armv7hnl": "armv7hl",
      "armv7hl": "noarch",
  
*************** def getBaseArch(myarch=None):
*** 442,447 ****
--- 443,450 ----
          return "ppc"
      elif myarch.startswith("arm64"):
          return "arm64"
+     elif myarch == "armv8l":
+         return "armhfp"
      elif myarch.startswith("armv7h"):
          return "armhfp"
      elif myarch.startswith("arm"):

此时再运行 yum 就可以正确找到软件包了：

bash-4.2# yum install openssh-server
Loaded plugins: fastestmirror
Determining fastest mirrors
 * base: mirrors.bfsu.edu.cn
 * extras: mirrors.bfsu.edu.cn
 * updates: mirrors.bfsu.edu.cn
base                                                                                                                                                                                              | 3.6 kB  00:00:00
extras                                                                                                                                                                                            | 2.9 kB  00:00:00
updates                                                                                                                                                                                           | 2.9 kB  00:00:00
(1/4): base/7/armhfp/group_gz                                                                                                                                                                     | 153 kB  00:00:00
(2/4): extras/7/armhfp/primary_db                                                                                                                                                                 | 170 kB  00:00:00
(3/4): updates/7/armhfp/primary_db                                                                                                                                                                | 562 kB  00:00:00
(4/4): base/7/armhfp/primary_db                                                                                                                                                                   | 4.1 MB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package openssh-server.armv7hl 0:7.4p1-21.el7 will be installed
--> Processing Dependency: libwrap.so.0 for package: openssh-server-7.4p1-21.el7.armv7hl
--> Running transaction check
---> Package tcp_wrappers-libs.armv7hl 0:7.6-77.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================================================================================================
 Package                                                    Arch                                             Version                                                 Repository                                     Size
=========================================================================================================================================================================================================================
Installing:
 openssh-server                                             armv7hl                                          7.4p1-21.el7                                            base                                          446 k
Installing for dependencies:
 tcp_wrappers-libs                                          armv7hl                                          7.6-77.el7                                              base                                           64 k

Transaction Summary
=========================================================================================================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 510 k
Installed size: 1.0 M
Is this ok [y/d/N]: y
Downloading packages:
(1/2): tcp_wrappers-libs-7.6-77.el7.armv7hl.rpm                                                                                                                                                   |  64 kB  00:00:00
(2/2): openssh-server-7.4p1-21.el7.armv7hl.rpm                                                                                                                                                    | 446 kB  00:00:00
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                                                    1.7 MB/s | 510 kB  00:00:00
Running transaction check
Running transaction test


Transaction check error:
  package tcp_wrappers-libs-7.6-77.el7.armv7hl is intended for a different architecture
  package openssh-server-7.4p1-21.el7.armv7hl is intended for a different architecture

不过这次轮到 rpm 报错了，提示 RPM 包的架构不相符。

rpm 修改

我们先试着手工安装 yum 下载下来但安装失败的 RPM 包，可以看到还是相同的报错：

bash-4.2# rpm -ivh /var/cache/yum/armhfp/7/base/packages/tcp_wrappers-libs-7.6-77.el7.armv7hl.rpm
Preparing...                          ################################# [100%]
        package tcp_wrappers-libs-7.6-77.el7.armv7hl is intended for a different architecture

这也是由于 rpm 命令不能正确处理 armv8l 架构，其实对于这种 RPM 包的架构不相符的情况，我们可以为 rpm 命令增加 --ignorearch 参数强制安装：

bash-4.2# rpm -ivh --ignorearch /var/cache/yum/armhfp/7/base/packages/tcp_wrappers-libs-7.6-77.el7.armv7hl.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:tcp_wrappers-libs-7.6-77.el7     ################################# [100%]

当然我们的最终目的是要让 yum 能够自动安装软件包，因此还需要让 rpm 命令也能正确识别 armv8l 架构。

为此我们需要修改 /usr/lib/rpm/rpmrc 文件，将 armv8l 视为 armv7hnl：

diff -rNp a/rpmrc b/rpmrc 
*** a/rpmrc     Fri Oct 30 00:15:17 2020
--- b/rpmrc     Fri Oct 30 00:16:32 2020
*************** arch_compat: armv5tel: armv4tl
*** 398,403 ****
--- 398,404 ----
  arch_compat: armv4tl: armv4l
  arch_compat: armv4l: armv3l
  arch_compat: armv3l: noarch
+ arch_compat: armv8l: armv7hnl
  arch_compat: armv7hnl: armv7hl
  arch_compat: armv7hl: noarch

此时我们再使用 yum 命令就可以正确下载和安装软件包了：

bash-4.2# yum install openssh-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.bfsu.edu.cn
 * extras: mirrors.bfsu.edu.cn
 * updates: mirrors.bfsu.edu.cn
Resolving Dependencies
--> Running transaction check
---> Package openssh-server.armv7hl 0:7.4p1-21.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================================================================================================
 Package                                                  Arch                                              Version                                                 Repository                                      Size
=========================================================================================================================================================================================================================
Installing:
 openssh-server                                           armv7hl                                           7.4p1-21.el7                                            base                                           446 k

Transaction Summary
=========================================================================================================================================================================================================================
Install  1 Package

Total size: 446 k
Installed size: 921 k
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
  Installing : openssh-server-7.4p1-21.el7.armv7hl                                                                                                                                                                   1/1
  Verifying  : openssh-server-7.4p1-21.el7.armv7hl                                                                                                                                                                   1/1

Installed:
  openssh-server.armv7hl 0:7.4p1-21.el7

Complete!

后续安装其它软件包也都没有问题了，例如安装基础开发包：

bash-4.2# yum -y install gcc make openssl-devel glibc-static openssl-static

2017 年我写了两篇介绍日本 Arukas 樱花容器服务的文章，那个时候主要用来跑 Shadowsocks 梯子服务。后来不知道是否因为国内用户蜂拥而至，Arukas 容器基本所有的 IP 地址都被封了，接着 Arukas 也停止提供服务，直到去年才恢复。最近住处的移动宽带不知何故连接一直使用的美国 VPS 速度很慢，因此我想着可以试试新版本 Arukas 容器的效果。

恢复后的新版 Arukas 服务直接把原来的账户都给删除了，用户都需要重新注册，实际使用还必须绑定有效的信用卡，容器配置可以参考其官网（需要爬墙）：

https://arukas.io/en/#pricing

每个账户可以最多创建一个免费容器，免费容器配置如下：

• 每个月 730 小时运行时间；
• 0.1 vCPU；
• 128 MB 内存；
• 100 GB 流量；
• 仍然不支持外部存储；
• 支持绑定域名（针对 Endpoint）；
• 仍然只支持 Docker Hub 库，而且只支持修改 CMD 启动命令。

可以看到新版 Arukas 免费容器的配置是有点捉襟见肘，还好我也只是拿来访问 Google 服务之类的，对流量需求不大，如果你经常要看 YouTube 视频之类的，那就不用考虑 Arukas 容器咯。

按照原来写的 Arukas容器使用ge.tt替代Endpoint域名 文章重新部署 Shadowsocks 容器，我发现还算欣慰的是 Arukas 提供的 Endpoint 域名还没有被封锁，容器内 Web 服务器提供的内容可以通过 Endpoint 域名访问。

如果你只需要跑一个简单的静态网站，对资源和流量要求也不高的话，那 Arukas 容器也是挺不错的，毕竟还支持绑定自定义的域名。不过 Arukas 的 Endpoint 域名转发服务仍然只支持 HTTPS 访问，而且 Endpoint 地址应该只对容器开放的第一个内部端口有效，只支持 HTTP 协议，不支持 TCP 或者 UDP。如果用 Arukas 容器来跑动态网站，那有可能效果不太理想。

不出意料的是我准备搭梯子的时候，发现墙对 Arukas 封锁的比较彻底，测试了多个 IP 地址都无法正常连接，为此考虑修改原来的容器试试通过 kcptun 进行转发访问。

Shadowsocks 容器修改

我原来制作的 Arukas 专用 Shadowsocks 容器是基于 Baseimage-docker 镜像修改的，增加 kcptun 支持也很简单。访问 kcptun 的官方 GitHub release 页面：

https://github.com/xtaci/kcptun/releases

下载 Linux amd64 版本的 kcptun 程序，我们也只需要将服务端程序加到原来的 Shadowsocks 容器镜像中，并简单修改下 /etc/my_init.d/01_start_ss_ssh.sh 启动脚本（支持 kcptun 的修改已高亮显示）：

#!/bin/bash

# Enable SSH
rm -f /etc/service/sshd/down
/etc/my_init.d/00_regen_ssh_host_keys.sh
touch /etc/service/sshd/down

# Setup SSH key
if [ "x$SSH_AUTHORIZED_KEYS" = "x" ]; then
	/usr/sbin/enable_insecure_key
else
	mkdir ~/.ssh
	echo "$SSH_AUTHORIZED_KEYS" | sed 's/\\n/\n/g' > ~/.ssh/authorized_keys
	chmod 400 ~/.ssh/authorized_keys
fi

# Start web server
env | grep -E '^MARATHON_HOST=|MARATHON_PORT_' > /home/wwwroot/default/marathon.conf
if [ "x$MARATHON_HOST" != "x" ]; then
	getent hosts $MARATHON_HOST | awk '{print "MARATHON_HOST_IP="$1; exit;}' >> /home/wwwroot/default/marathon.conf
fi

start-stop-daemon -S -b -n tmp-httpd -d /home/wwwroot/default -x /usr/bin/python3 -- -m http.server 80

# Start ShadowSocks
env | grep '^SHADOWSOCKS_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	SS_NAME="${T_NAME:17}"
	echo "${!T_NAME}" > /etc/shadowsocks-libev/${SS_NAME}.json
	start-stop-daemon -n ss-$SS_NAME -x /usr/bin/ss-server -b -S -- -c /etc/shadowsocks-libev/${SS_NAME}.json -u --fast-open
done

# Start kcptun
env | grep '^KCPTUN_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	KCP_NAME="${T_NAME:12}"
	echo "${!T_NAME}" > /etc/kcptun/${KCP_NAME}.json
	start-stop-daemon -n kcp-$KCP_NAME -x /usr/bin/kcptun_server -b -S -- -c /etc/kcptun/${KCP_NAME}.json
done

if [ "x$GETT_TOKEN" != "x" ]; then
	if [ "x$HOME" = "x" ]; then
		export HOME="/root"
	fi
	echo -n "$GETT_TOKEN" > ~/.gett-token
	if [ "x$GETT_SHARE_NAME" != "x" ]; then
		python3 /usr/local/gett/uploader.py -l http://ge.tt/$GETT_SHARE_NAME | awk '{if (substr($5,1,13)=="http://ge.tt/") {print $5;}}' | xargs python3 /usr/local/gett/uploader.py --delete
		python3 /usr/local/gett/uploader.py -s http://ge.tt/$GETT_SHARE_NAME /home/wwwroot/default/marathon.conf
	fi
fi

exec /usr/sbin/sshd -D -e -u 0

新版支持 kcptun 访问 Shadowsocks 的 Arukas 专用容器安装包下载地址，仍然支持 SSH 登录以及通过 Endpoint 地址或者 ge.tt 分享获取容器当前地址和端口：

https://zohead.com/downloads/arukas-baseimage-xenial-ss.tar.gz

原有的 CMD 启动命令以及以 SHADOWSOCKS_CFGS_ 开头的 Shadowsocks 配置变量和 SSH_AUTHORIZED_KEYS SSH 证书变量配置都没有变化。

此次增加了以 KCPTUN_CFGS_ 开头的 kcptun 配置变量，当然别忘了容器端口配置中也得指定一个新的 UDP 端口给 kcptun 服务使用。

例如我现有的 Shadowsocks 服务配置变量：

SHADOWSOCKS_CFGS_xxx={ "server":"0.0.0.0", "server_port":17374, "local_port":1080, "password":"arukas-ss-svr", "timeout":30, "method":"aes-256-cfb" }

现在需要在 Arukas 容器中运行 kcptun 服务器进行 UDP 转发，可以添加一个 kcptun 配置变量（仍然是 JSON 格式，需要写成一行）：

KCPTUN_CFGS_xxx = { "listen": ":29900", "target": "127.0.0.1:17374", "key": "arukas-kcp-svr", "crypt": "xor", "mode": "fast2", "mtu": 1350, "sndwnd": 128, "rcvwnd": 128, "datashard": 0, "parityshard": 0, "dscp": 46, "nocomp": true, "acknodelay": false, "nodelay": 0, "interval": 40, "resend": 2, "nc": 1, "sockbuf": 4194304, "keepalive": 10, "log": "/var/log/kcptun.log" }

这里我指定 kcptun 服务器绑定默认的 29900 UDP 端口（Arukas 容器端口配置中即需要开放 29900 UDP 端口），转发地址即指向本地的 Shadowsocks 服务器端口。

提示

上面贴出来的我使用的 kcptun 配置并不是最佳配置，只是由于我的 OpenWRT 路由器运算能力比较孱弱，避免出现路由器上的 kcptun 客户端导致 CPU 占用过高的问题。

kcptun 的配置稍微有点复杂，需要根据用户实际网络环境修改，这里我就不详细介绍了，请参考 GitHub 项目主页的说明。

Android kcptun 测试

我们可以首先用 Android 手机测试通过 kcptun 连接 Arukas 容器的 Shadowsocks 服务，在手机上安装 Shadowsocks App 和专用的 kcptun 插件。

安装完成之后 Shadowsocks 配置文件中就可以选择 kcptun 插件，需要注意你如果使用的是像我的 Nubia Z17 这种魔改版手机，可能需要在 手机管家 之类的系统设置中开启 kcptun 的自启动权限，防止出现 Shadowsocks App 无法启动 kcptun 的问题。

Shadowsocks App 连接的服务器地址也需要更换为 Arukas 容器实际地址和 kcptun 服务的外部访问端口，kcptun 插件的配置则保持与服务端一致即可，我的配置如下：

dscp=46;nocomp;mtu=1350;datashard=0;parityshard=0;mode=fast2;key=arukas-kcp-svr;crypt=xor

Android kcptun 插件的配置使用 key=value 的格式，中间以分号隔开，如果只有 key 没有 value 则表示启用该参数（true），具体配置参数可以点击 kcptun 插件的 ? 按钮查看详细说明。

OpenWRT 自动更新配置脚本

使用 kcptun 之后，OpenWRT 路由器上的 Shadowsocks 配置也不太一样了，例如我的 /etc/shadowsocks-arukas.json 配置文件就可以保持不变了（固定连接本地 kcptun 地址和端口）：

{
	"server" : "127.0.0.1",
	"server_port" : "17374",
	"password": "arukas-ss-svr",
	"local_port": "1080",
	"timeout" : "30",
	"method": "aes-256-cfb"
}

相应的增加 kcptun 客户端的配置文件 /etc/kcptun-arukas.json，key 密码与容器中 kcptun 服务器密码一致，remoteaddr 就是容器 kcptun 服务 UDP 监听的外部访问地址和端口：

{
"localaddr": ":17374",
"remoteaddr": "",
"key": "arukas-kcp-svr",
"crypt": "xor",
"mode": "fast2",
"mtu": 1350,
"sndwnd": 128,
"rcvwnd": 128,
"datashard": 0,
"parityshard": 0,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 40,
"resend": 2,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

为了支持 kcptun，我也稍微改了下 OpenWRT 路由器的 arukas-ss.sh 自动更新配置脚本，为了使用方便我把 kcptun 客户端的启动和停止操作也放到 /etc/init.d/shadowsocks 服务脚本中了，其它路由器请自行修改此脚本：

#!/bin/sh
ARUKAS_ENDPOINT=""
GETT_SHRNAME=""
RESTART_SHADOWSOCKS="no"

[ $# -ge 2 ] || exit 1

[ -f /tmp/.marathon.conf ] && mv /tmp/.marathon.conf /tmp/.marathon.conf.bak

IND=0
while [ $IND -lt 5 ]; do
	let IND++
	[ -f /tmp/.marathon.conf ] && rm -f /tmp/.marathon.conf
	if [ "x$GETT_SHRNAME" != "x" ]; then
		T_FILEID=`curl -s -k -f http://api.ge.tt/1/shares/$GETT_SHRNAME | sed -e 's/^.*"fileid"[^:]*:[^"]*"//' -e 's/".*$//'`
		if [ "x$T_FILEID" != "x" ]; then
			curl -s -k -f -o /tmp/.marathon.conf -L -e "http://ge.tt/$GETT_SHRNAME" "http://api.ge.tt/1/files/$GETT_SHRNAME/$T_FILEID/blob?download"
			[ $? -eq 0 ] && break
		fi
	fi
	curl -s -k -f -o /tmp/.marathon.conf https://$ARUKAS_ENDPOINT.arukascloud.io/marathon.conf
	[ $? -eq 0 ] && break
	sleep 1
done

[ -s /tmp/.marathon.conf ] || exit 1
echo "Fetch server config after $IND tries."

if [ -f /tmp/.marathon.conf.bak ]; then
	cmp -s /tmp/.marathon.conf /tmp/.marathon.conf.bak
	if [ $? -eq 0 ]; then
		rm -f /tmp/.marathon.conf
		exit 0
	fi
fi

. /tmp/.marathon.conf 2>/dev/null
if [ "x$MARATHON_HOST" = "x" ]; then
	rm -f /tmp/.marathon.conf
	exit 1
fi

if [ "x$MARATHON_HOST_IP" != "x" ]; then
	MARATHON_HOST="$MARATHON_HOST_IP"
fi

while [ $# -gt 2 ]; do
	CMD="echo \${MARATHON_PORT_$2}"
	TMP_PORT=`eval $CMD`

	if [ -f $1 -a "x$TMP_PORT" != "x" ]; then
		if [ "x$3" = "xshadowsocks" ]; then
			sed -i -e 's/"server"[^:]*:[^,]*,/"server" : "'$MARATHON_HOST'",/' -e 's/"server_port"[^:]*:[^,]*,/"server_port" : "'$TMP_PORT'",/' $1
			grep -q '^CONFIG.*='$1 /etc/init.d/shadowsocks
			[ $? -eq 0 ] && RESTART_SHADOWSOCKS="yes"
		elif [ "x$3" = "xkcptun" ]; then
			sed -i 's/"remoteaddr"[^:]*:[^,]*,/"remoteaddr" : "'$MARATHON_HOST':'$TMP_PORT'",/' $1
			grep -q '^KCPTUN_CONFIG.*='$1 /etc/init.d/shadowsocks
			[ $? -eq 0 ] && RESTART_SHADOWSOCKS="yes"
		fi
	fi
	shift
	shift
	shift
done

if [ "x$RESTART_SHADOWSOCKS" = "xyes" ]; then
	/etc/init.d/shadowsocks restart
fi

使用之前请修改脚本最上面的 ARUKAS_ENDPOINT 和 GETT_SHRNAME 变量，分别为 Arukas 容器的 Endpoint 名（Arukas Endpoint 地址可访问的情况下建议优先使用）和 ge.tt 分享名。

为了区分 Shadowsocks 和 kcptun 配置文件，我对脚本调用方式也做了修改，增加了指定配置类型的参数（shadowsocks 或 kcptun），例如我的 crontab 配置：

30 * * * * /etc/arukas-ss.sh /etc/kcptun-arukas.json 29900 kcptun

这样路由器就可以自动更新 kcptun 客户端配置文件中的 remoteaddr 项了。

我的渣渣移动宽带环境下电脑通过路由器 kcptun 爬墙看 YouTube 视频效果如下：

受限于路由器硬件的性能，Arukas 网络的 kcptun 速度并没有完全发挥出来，不过还是比原先的美国 VPS 要好多了，最后祝大家在开会的特殊阶段也能把梯子搭的开心。

我们一般使用的 Docker 容器都是非特权容器，也就是说容器内的 root 用户并不拥有真正的 root 权限，这就导致很多属于系统管理员的操作都被禁用了。

最近有个在 IBM Bluemix 容器内部挂载 FUSE 文件系统的需求，例如我使用 davfs2 挂载 WebDAV 服务器不出意外地会报错：

root@instance-007a20ff:~# mount.davfs https://dav.jianguoyun.com/dav/ /mnt/
Please enter the username to authenticate with server
https://dav.jianguoyun.com/dav/ or hit enter for none.
  Username: xxx@xx.com
Please enter the password to authenticate user fcoe@qq.com with server
https://dav.jianguoyun.com/dav/ or hit enter for none.
  Password: 
mount.davfs: can't open fuse device
mount.davfs: trying coda kernel file system
mount.davfs: no free coda device to mount

mount.davfs 命令报错表示无法打开 fuse 设备，而 fuse 设备实际上是存在的（说明 fuse 模块也已经加载了）：

root@instance-007a20ff:~# cat /sys/devices/virtual/misc/fuse/dev
10:229

从容器内部可以查看到 cgroup 实际允许访问的设备，并没有包含 fuse 设备：

root@instance-007a20ff:~# cat /sys/fs/cgroup/devices/devices.list
c 1:5 rwm
c 1:3 rwm
c 1:9 rwm
c 1:8 rwm
c 5:0 rwm
c 5:1 rwm
c *:* m
b *:* m
c 1:7 rwm
c 136:* rwm
c 5:2 rwm
c 10:200 rwm

手工允许 fuse 设备自然也是不可行的：

root@instance-007a20ff:~# echo "c 10:229 rwm" > /sys/fs/cgroup/devices/devices.allow
-bash: /sys/fs/cgroup/devices/devices.allow: Permission denied

另外由于 Bluemix 提供的是非特权容器，即使允许访问 /dev/fuse 设备也会因为没有 mount 权限而挂载失败。

UML 系统修改

虽然 Docker 容器内部不能直接挂载使用 FUSE 文件系统，但我想到如果用 User-mode Linux（以下简称 UML） 来实现在应用层再运行一个 Linux kernel，就可以在 UML guest 系统中挂载 FUSE 文件系统了，而且 UML 系统中也可以通过 hostfs 直接访问容器本身的文件系统。

有关 UML 的介绍和编译使用可以参考我之前写的 小内存OpenVZ VPS使用UML开启BBR 文章。

首先我们需要修改 UML kernel 配置：

• 增加对 FUSE 的支持，这个是必须的了，否则无法在 UML guest 系统中使用 FUSE 文件系统；
• 增加了对 xfs、btrfs、ext4、squashfs、iso9660 等常见文件系统的支持（方便在 UML 系统中挂载各种文件系统镜像）；
• 另外为了支持将 UML guest 的文件系统导出，启用了 sunrpc 和 NFS 服务器支持；
• UML 网络配置中增加了对 Slirp 和 VDE 网卡的支持。

UML kernel 目前支持常见的几种网络模式：

• TUN/TAP
  最简单和常用的模式，不过 host kernel 需要支持 tun 或者 tap 设备，这个在 Docker 容器中一般都不可用的；
• SLIP
  SLIP 串行线路 IP 支持，现在一般很少用到了，同样 host kernel 需要支持 slip 设备；
• Slirp
  通过用户层的 slirp 程序实现 SLIP 连接，好处是不依赖任何内核层的设备，而且 slirp 可以支持非 root 用户使用，不过 Slirp 只支持模拟 IP 协议的数据包，详细可以参考 Slirp 开源项目的官方网站。
• VDE
  VDE（Virtual Distributed Ethernet）可以在不同的计算机间实现软件定义的以太网络，同样支持在用户层以非 root 用户身份来运行，目前 Linux 上的 QEMU 和 KVM 虚拟机都支持 VDE 虚拟网络。

鉴于我们需要在 Docker 容器中运行 UML 系统，目前只能使用 Slirp 和 VDE 模式的网卡，另外单独的 slirp 程序使用起来相对 VDE 也更简单（支持 VDE 的 UML kernel 可以直接调用 slirp 程序，不像 VDE 还需要预先使用 vde_switch 等命令配置软件交换机），因此这里的 UML 系统就使用 Slirp 网卡了。

当然原来基于 busybox 的 UML 系统用户层也做了些修改：

• 增加 libfuse 支持挂载 FUSE 文件系统；
• 增加 rpcbind、nfs-common、nfs-kernel-server 等软件包，支持在 UML 系统中运行 NFS 服务器，导出 UML guest 的文件系统；
• 增加 dropbear，支持 SSH 和 SFTP 服务器和客户端了；
• 增加 httpfs2 FUSE 文件系统支持，来自 GitHub 上的 httpfs2-enhanced 项目，方便挂载访问 HTTP 和 HTTPS 远程文件；
• 增加 archivemount FUSE 文件系统支持，方便直接挂载 zip、rar、tar.gz 等各种格式的压缩包以支持直接访问压缩包中的文件；
• 增加 CurlFtpFs FUSE 文件系统支持，支持挂载 FTP 远程文件；
• 增加 davfs2 FUSE 文件系统支持，支持挂载远程 WebDAV 目录；
• 增加 sshfs FUSE 文件系统支持，支持通过 SFTP 方式挂载远程主机目录。

提示

• httpfs2-enhanced 最好使用支持 SSL 和多线程的版本，可以加快响应速度并能挂载 HTTPS 的远程文件；
• 我在测试中发现 httpfs2-enhanced 工具在国内的网络环境下挂载某些 HTTP 远程文件存在一些问题，因此做了简单的修改，并 fork 到我自己的 GitHub 仓库里了。有需要的朋友可以参考我修改过的 httpfs2-enhanced，检出其中的 http-fix 分支即可，我也已经针对原项目提交了 Pull request。

为了方便使用，我给原来的 uml-linux.sh 执行脚本增加了新的 uml.conf 配置文件：

UML_ID="umlvm"
UML_MEM="64M"

UML_NETMODE="slirp"
#HOST_ADDR="192.168.0.3"
#UML_ADDR="192.168.0.4"
#UML_DNS=""

TAP_DEV="tap0"
ROUTER_DEV="eth0"
VDE_SWITCH=""

REV_TCP_PORTS=""
REV_UDP_PORTS=""
#FWD_TCP_PORTS="111 892 2049 32803 662"
#FWD_UDP_PORTS="111 892 2049 947 32769 662 660"

简单说明如下：

• UML_MEM 指定为 UML 系统分配多少内存，默认 64 MB；
• UML_NETMODE 比较重要，指定 UML 系统的网卡模式，目前支持 tuntap、slirp、vde 这三个选项；
• 如果是 tuntap 网卡模式，TAP_DEV 指定 host 主机上的 TUN 网卡设备名称，可以使用 HOST_ADDR 配置 host 主机 TUN 网卡的 IP 地址，UML_ADDR 配置 UML guest 主机的 IP 地址（最好和 HOST_ADDR 在同一网段），如果需要端口转发，那么还需要修改 ROUTER_DEV 指定 host 主机用于转发的物理网卡设备名称；
• 如果是 slirp 网卡模式，那么会直接使用 Slirp 默认固定的专用地址：10.0.2.2 为 host 主机地址，10.0.2.15 为 UML guest 主机的 IP 地址，并自动将 UML guest 系统内的 DNS 服务器地址设置为 10.0.2.3 通过 host 主机进行域名解析；
• 如果是 vde 网卡模式，那么必须修改 VDE_SWITCH 指定 VDE 软件交换机的路径，VDE 软件交换机需要通过 vde_switch 等命令预先配置，详细使用说明可以参考 Virtualsquare VDE Wiki 页面；
• FWD_TCP_PORTS 和 FWD_UDP_PORTS 指定进行转发的 TCP 和 UDP 端口列表（多个转发端口以空格隔开），转发端口支持 10080-80 这种形式（表示将 host 主机的 10080 端口转到 UML guest 的 80 端口），上面 uml.conf 中的注释列出来的是 UML 系统中对外的 NFS 服务器所需要的端口（根据实际情况也可以只允许 111、892、2049 这几个端口）。

为了能够根据 uml.conf 文件配置 Slirp 的端口转发功能，我还为 slirp 程序增加了一个 slirp.sh wrapper 脚本：

#!/bin/sh
DIR="$( cd "$( dirname "$0" )" && pwd )"

[ -f $DIR/uml.conf ] && . $DIR/uml.conf

CMD=`which slirp-fullbolt 2>/dev/null || which slirp`

for i in $FWD_TCP_PORTS; do
	if [ "x$i" = "x*" ]; then
		continue
	fi
	CMD="$CMD \"redir ${i%-*} ${i##*-}\""
done
for i in $FWD_UDP_PORTS; do
	if [ "x$i" = "x*" ]; then
		continue
	fi
	CMD="$CMD \"redir udp ${i%-*} ${i##*-}\""
done

eval "exec $CMD"

由于 UML kernel 调用 slirp 程序时不支持附加参数，这里才通过 slirp.sh 脚本来实现，功能也非常简单，通过 slirp 程序的 redir 选项配置端口转发。

提示

为了让 UML guest 系统的 Slirp 网络真正达到接近 host 主机的网络性能，host 主机上编译 slirp 程序时必须打开 FULL_BOLT 开关，并为 slirp 源代码打上 real full bolt 的 patch，否则 UML guest 系统内通过 Slirp 访问外网的速度会很慢。

值得庆幸的是 Debian、Ubuntu 系统自带的 slirp 软件包一般都打上了这个 patch，而且提供了 slirp-fullbolt 和 slirp 这两个程序分别对应 FULL_BOLT 开启和关闭的 Slirp，我的 slirp.sh 脚本也对此做了判断，优先使用速度更快的 slirp-fullbolt 程序。

至于新的启动 UML 系统的脚本 uml-linux.sh 稍微有点长，这里就不贴出来了，和原来相比的改动就是增加对 Slirp 和 VDE 网络的支持。

另外新的 uml-linux.sh 脚本改为默认前台方式启动 UML 系统；如果需要以后台方式启动 UML 系统，则可以用 uml-linux.sh -D 的方式来运行。

使用 UML 挂载 FUSE 文件系统

修改之后支持 FUSE 和 NFS 服务器的 UML 系统可以从这里下载（百度网盘备用）：

https://zohead.com/downloads/uml-fuse-nfsd-x64.tar.xz
https://pan.baidu.com/s/1bp6l7B5

解压缩下载下来的 uml-fuse-nfsd-x64.tar.xz 文件，运行其中的 uml-linux 脚本就可以启动 UML 系统了，此 UML 系统的 root 用户默认密码为 uml。

下面我以挂载 HTTP 远程 iso 文件中的安装包为例，介绍如何在 UML 系统中使用 FUSE。

首先使用 httpfs2 挂载阿里云上的 CentOS 6.9 iso 文件（这里为 httpfs2 指定 -c /dev/null 参数是为了去掉 httpfs2 的网络访问输出日志），挂载成功之后可以查看挂载点中的文件：

~ # httpfs2 -c /dev/null http://mirrors.aliyun.com/centos/6/isos/x86_64/CentOS-6.9-x86_64-minimal.iso /tmp
file name:      CentOS-6.9-x86_64-minimal.iso
host name:      mirrors.aliyun.com
port number:    80
protocol:       http
request path:   /centos/6/isos/x86_64/CentOS-6.9-x86_64-minimal.iso
auth data:      (null)
httpfs2: main: connecting to mirrors.aliyun.com port 80.
No SSL session data.
httpfs2: main: closing socket.
httpfs2: main: connecting to mirrors.aliyun.com port 80.
httpfs2: main: keeping socket open.
file size:      427819008
httpfs2: main: closing socket.
~ # ls -l /tmp
total 0
-r--r--r--    1 root     root     427819008 Mar 29  2017 CentOS-6.9-x86_64-minimal.iso

我们可以发现 httpfs2 的挂载点中实际上就只有一个远程文件名，我们可以直接挂载这个 iso 文件：

~ # mount -t iso9660 -o ro,loop /tmp/CentOS-6.9-x86_64-minimal.iso /media
~ # ls /media
CentOS_BuildTag                GPL                            RPM-GPG-KEY-CentOS-6           RPM-GPG-KEY-CentOS-Testing-6   isolinux
EFI                            Packages                       RPM-GPG-KEY-CentOS-Debug-6     TRANS.TBL                      repodata
EULA                           RELEASE-NOTES-en-US.html       RPM-GPG-KEY-CentOS-Security-6  images

到这里就可以直接查看远程 iso 文件中的软件包了，你可以很方便地将远程 iso 中的软件包拷贝到 host 主机的文件系统中。

如果你想直接拷贝软件包中的特定文件，也可以通过 archivemount 来实现哦：

~ # archivemount /media/Packages/sed-4.2.1-10.el6.x86_64.rpm /mnt
fuse: missing mountpoint parameter
~ # ls /mnt
bin  usr

这样直接复制软件包中的文件就实在太方便了（请忽略 archivemount 时的 fuse 警告，实际不影响使用）。

当然如果你想挂载 FTP 远程文件就可以通过 curlftpfs 命令来实现，也可以使用 mount.davfs 命令挂载 WebDAV 服务器上的文件（例如直接访问坚果云中的文件）。

导出 UML FUSE 文件系统

有些情况下我们需要将 UML 系统中的 FUSE 挂载点导出给 host 主机或者网络中的其它主机使用，这时可以通过 hostfs、SFTP、NFS 等方式实现，分别简单说明一下。

hostfs 导出 FUSE

这是最简单的方式，由于 UML 直接使用 hostfs 访问 host 主机的文件系统，因此 UML 系统内可以直接将 FUSE 中的文件拷贝到 hostfs 文件系统，只是这种方式 host 主机并不能直接访问 UML guest 主机的 FUSE 文件系统。

SFTP 导出 FUSE

这种方式也很简单，由于 UML 系统启动时自动运行了 dropbear 服务，我们可以先修改 uml.conf 配置文件设置 SSH 端口转发，将 host 主机的 2222 端口通过 Slirp 转发到 UML guest 系统内的 22 端口（如果 host 主机本身并没有运行 SSH 服务器，那甚至可以配置为 FWD_TCP_PORTS="22" 直接转发 22 端口）：

FWD_TCP_PORTS="2222-22"

此时 host 主机就可以使用 scp 命令直接从 UML 的 FUSE 文件系统中拷贝文件了：

root@instance-007a20ff:~# scp -P 2222 root@192.168.1.52:/mnt/bin/sed /home

注意

上面命令中的 192.168.1.52 应根据实际情况替换为 host 主机上实际访问网络的网卡 IP 地址，不能使用 localhost 或者 127.0.0.1，因为 slirp 默认会自动选择访问网络的网卡，并不会进行本地转发。

NFS 导出 FUSE

首先需要修改 uml.conf 配置文件中的 FWD_TCP_PORTS 和 FWD_UDP_PORTS 值，将默认的 NFS 服务需要的 TCP 和 UDP 端口注释去掉，表示将这些端口转发到 UML 系统内。

提示

如果你需要在 host 主机上直接 NFS 挂载 UML 系统里的 FUSE 文件系统，由于 sunrpc 的 111 端口无法修改而且需要转发到 UML 系统内，这种情况下 host 主机的 portmap 或者 rpcbind 服务需要保持关闭状态，防止 111 端口被占用。

使用 uml-linux.sh 脚本启动 UML 系统，启动完成之后通过集成的 FUSE 相关工具挂载需要访问的 FUSE 文件系统。

假设需要导出 UML 系统中的 /mnt FUSE 文件系统，UML 中默认的 NFS 导出目录配置文件 /etc/exports 如下：

/mnt 0.0.0.0/0.0.0.0(async,insecure,no_subtree_check,rw,no_root_squash,fsid=0)

上面的配置文件表示将 /mnt 目录通过 NFS 导出，默认允许所有主机访问，你可以根据需要修改导出目录路径和允许访问的主机地址。

接着在 UML 系统中通过集成的服务脚本启动 rpcbind 和 nfs 服务：

~ # /etc/init.d/rpcbind start
Starting up rpcbind...
~ # /etc/init.d/nfs start
Starting nfs service:
fs.nfs.nlm_tcpport = 32803
fs.nfs.nlm_udpport = 32769
Exporting directories for NFS...
Starting NFS daemon: 
rpc.nfsd: address family inet6 not supported by protocol TCP
NFSD: the nfsdcld client tracking upcall will be removed in 3.10. Please transition to using nfsdcltrack.
NFSD: starting 90-second grace period (net 000000006035a880)
Starting NFS mountd:

如果一切正常的话，此时就可以在外部通过 NFS 挂载 UML 系统导出的 FUSE 文件系统进行访问了：

root@instance-007a20ff:~# mount -t nfs -o nolock,proto=tcp,mountproto=tcp 192.168.1.52:/mnt /media

提示

nolock 参数是为了防止如果挂载的主机上没有运行 portmap 或者 rpcbind 服务导致挂载失败的问题（如果直接在 host 主机上挂载，host 的对应服务需要关闭）；
proto=tcp 和 mountproto=tcp 参数指定 NFS 数据和挂载请求都使用 TCP 协议，防止使用的随机 UDP 端口无法被 slirp 转发的问题。

这里需要说明的是如果直接在 Docker 容器（UML 的 host 主机）上挂载 NFS，虽然绝大多数 Docker 容器平台都默认支持 NFS 文件系统，但在非特权容器内部由于没有权限 mount 还是会失败的。

总结

本文介绍的在容器中使用 UML 挂载 FUSE 文件系统并通过 NFS 导出 UML 文件系统的方法是一个比较小众的需求，不过也算达到我的目的了。

对于非特权 Docker 容器来说，虽然还不能直接挂载 UML guest 的文件系统，但初步看起来还是可以通过 LKL（Linux Kernel Library）在应用层访问 UML 网络并实现 NFS 挂载的，只是 LKL 库的 NFS 挂载目录并不能直接给 Docker 容器中的普通应用程序使用。

最后祝大家在即将到来的 2018 年能继续玩地开心 ^_^。

前面写了一篇介绍日本 Arukas 樱花容器及使用其 Endpoint 域名的文章，目前我在 Arukas 上面跑了一个 Shadowsocks 容器用于路由器自动爬墙。不过还是发现如果 Arukas 容器的开放端口里开启了 UDP 端口（给 OpenWRT 路由器上的 ss-tunnel 用于转发解析被封锁的域名），这种情况下 Arukas 的 Endpoint 地址就基本没办法正常访问了。文章中我写的 OpenWRT 下自动获取 Arukas 容器 Shadowsocks 配置的脚本也经常出错，用起来还是不太方便。

刚好之前为了给其他人分享文件，我还写了一篇介绍 ge.tt 文件分享 API 的文章，就想到既然 Endpoint 地址访问容易出错，那可以在 Arukas Shadowsocks 容器里使用 ge.tt 的 Python CLI 将容器的当前地址和外部端口配置文件上传到指定的 ge.tt 分享地址，这样 OpenWRT 系统里也能很方便地通过分享地址更新配置文件了。

Arukas 容器修改

这里的 Arukas 容器系统我使用的还是最新 baseimage 系统，增加了 shadowsocks-libev 服务器程序，并将 gett-cli 工具集成到 baseimage 系统，然后将 /etc/my_init.d/01_start_ss_ssh.sh 启动脚本修改为：

#!/bin/bash

# Enable SSH
rm -f /etc/service/sshd/down
/etc/my_init.d/00_regen_ssh_host_keys.sh
touch /etc/service/sshd/down

# Setup SSH key
if [ "x$SSH_AUTHORIZED_KEYS" = "x" ]; then
	/usr/sbin/enable_insecure_key
else
	mkdir ~/.ssh
	echo "$SSH_AUTHORIZED_KEYS" | sed 's/\\n/\n/g' > ~/.ssh/authorized_keys
	chmod 400 ~/.ssh/authorized_keys
fi

# Start web server
env | grep -E '^MARATHON_HOST=|MARATHON_PORT_' > /home/wwwroot/default/marathon.conf
if [ "x$MARATHON_HOST" != "x" ]; then
	getent hosts $MARATHON_HOST | awk '{print "MARATHON_HOST_IP="$1; exit;}' >> /home/wwwroot/default/marathon.conf
fi

start-stop-daemon -S -b -n tmp-httpd -d /home/wwwroot/default -x /usr/bin/python3 -- -m http.server 80

# Start ShadowSocks
env | grep '^SHADOWSOCKS_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	SS_NAME="${T_NAME:17}"
	echo "${!T_NAME}" > /etc/shadowsocks-libev/${SS_NAME}.json
	start-stop-daemon -n ss-$SS_NAME -x /usr/bin/ss-server -b -S -- -c /etc/shadowsocks-libev/${SS_NAME}.json -u --fast-open
done

if [ "x$GETT_TOKEN" != "x" ]; then
	if [ "x$HOME" = "x" ]; then
		export HOME="/root"
	fi
	echo -n "$GETT_TOKEN" > ~/.gett-token
	if [ "x$GETT_SHARE_NAME" != "x" ]; then
		python3 /usr/local/gett/uploader.py -l http://ge.tt/$GETT_SHARE_NAME | awk '{if (substr($5,1,13)=="http://ge.tt/") {print $5;}}' | xargs python3 /usr/local/gett/uploader.py --delete
		python3 /usr/local/gett/uploader.py -s http://ge.tt/$GETT_SHARE_NAME /home/wwwroot/default/marathon.conf
	fi
fi

exec /usr/sbin/sshd -D -e -u 0

这里增加了两个 ge.tt 文件分享服务相关的环境变量，通过 Docker 容器的 ENV 环境变量指定：

• GETT_TOKEN
  在某台设备上使用 gett-cli 工具登录成功之后就能看到 ~/.gett-token 文件中的 Refresh Token 内容；
• GETT_SHARE_NAME
  预先创建好固定的 ge.tt 分享名（例如：8D95lij2），可以在 ge.tt 网页中上传文件创建，也可以用 gett-cli 工具创建。

如果容器的 ENV 列表里有这两个环境变量，启动脚本会自动将 Arukas 容器的当前地址和外部端口配置文件 marathon.conf 上传到指定的 ge.tt 分享地址。

使用 Shadowsocks 容器

容器的 CMD 指令值以及其它 SSH 公钥和 Shadowsocks 服务器 JSON 配置文件环境变量与 Arukas 容器文章中介绍的相同，可以根据需要自行配置。

我修改后的 Arukas 上支持 ge.tt 并适用于 baseimage 系统的 Shadowsocks 服务器安装包可以从这里下载：

https://zohead.com/downloads/arukas-baseimage-xenial-ss.tar.gz

另外我还制作了一个 ShadowsocksR 服务器安装包，有需要的朋友可以下载测试看看，由于 baseimage 系统已经自带了 Python 3 环境，因此 ShadowsocksR 服务器安装包体积也要小一些：

https://zohead.com/downloads/arukas-baseimage-xenial-ssr.tar.gz

对于容器 ENV 列表中以 SHADOWSOCKS_CFGS_ 开头的变量，启动脚本会自动在 /etc/shadowsocks-libev 目录（对于 ShadowsocksR 是 /etc/shadowsocks 目录）下生成 Shadowsocks 或 ShadowsocksR 服务器配置文件，配置文件内容就是该 JSON 格式变量的值。

例如我的 Arukas 容器配置中的 ShadowsocksR 环境变量：

SHADOWSOCKS_CFGS_xxx = { "server":"0.0.0.0", "server_port":8113, "local_port":1080, "password":"ssr-pass", "timeout":30, "method":"aes-128-ctr", "protocol" : "auth_aes128_md5", "obfs" : "http_simple" }

当然对于 ShadowsocksR 容器也需要相应地将 CMD 启动指令改为：

/sbin/my_init -- sh -c 'curl -o /arukas-baseimage-xenial-ssr.tar.gz https://zohead.com/downloads/arukas-baseimage-xenial-ssr.tar.gz && tar -C / -xzf /arukas-baseimage-xenial-ssr.tar.gz && /etc/my_init.d/01_start_ss_ssh.sh'

OpenWRT 自动更新配置脚本

为了能支持从 ge.tt 分享地址下载更新 Shadowsocks 配置，我对 OpenWRT 路由器上的 arukas-ss.sh 脚本也做了修改：

#!/bin/sh
ARUKAS_ENDPOINT=""
GETT_SHRNAME=""

[ $# -ge 2 ] || exit 1

[ -f /tmp/.marathon.conf ] && mv /tmp/.marathon.conf /tmp/.marathon.conf.bak

IND=0
while [ $IND -lt 5 ]; do
	let IND++
	[ -f /tmp/.marathon.conf ] && rm -f /tmp/.marathon.conf
	if [ "x$GETT_SHRNAME" != "x" ]; then
		T_FILEID=`curl -s -k -f http://api.ge.tt/1/shares/$GETT_SHRNAME | sed -e 's/^.*"fileid"[^:]*:[^"]*"//' -e 's/".*$//'`
		if [ "x$T_FILEID" != "x" ]; then
			curl -s -k -f -o /tmp/.marathon.conf -L -e "http://ge.tt/$GETT_SHRNAME" "http://api.ge.tt/1/files/$GETT_SHRNAME/$T_FILEID/blob?download"
			[ $? -eq 0 ] && break
		fi
	fi
	curl -s -k -f -o /tmp/.marathon.conf https://$ARUKAS_ENDPOINT.arukascloud.io/marathon.conf
	[ $? -eq 0 ] && break
	sleep 1
done

[ -s /tmp/.marathon.conf ] || exit 1
echo "Fetch server config after $IND tries."

if [ -f /tmp/.marathon.conf.bak ]; then
	cmp -s /tmp/.marathon.conf /tmp/.marathon.conf.bak
	if [ $? -eq 0 ]; then
		rm -f /tmp/.marathon.conf
		exit 0
	fi
fi

. /tmp/.marathon.conf 2>/dev/null
if [ "x$MARATHON_HOST" = "x" ]; then
	rm -f /tmp/.marathon.conf
	exit 1
fi

while [ $# -gt 1 ]; do
	CMD="echo \${MARATHON_PORT_$2}"
	SS_PORT=`eval $CMD`

	if [ -f $1 -a "x$SS_PORT" != "x" ]; then
		if [ "x$MARATHON_HOST_IP" != "x" ]; then
			MARATHON_HOST="$MARATHON_HOST_IP"
		fi
		sed -i -e 's/"server"[^:]*:[^,]*,/"server" : "'$MARATHON_HOST'",/' -e 's/"server_port"[^:]*:[^,]*,/"server_port" : "'$SS_PORT'",/' $1
	fi
	shift
	shift
done

if [ "x$RESTART_SHADOWSOCKS" != "xno" ]; then
	/etc/init.d/shadowsocks restart
fi

使用之前请先根据需要修改脚本最上面的 ARUKAS_ENDPOINT 和 GETT_SHRNAME 变量（一般指定其中一个即可），分别为 Arukas 容器的 Endpoint 名和 ge.tt 分享名，脚本会分别尝试通过 ge.tt 分享地址和 Arukas Endpoint 地址下载容器的 marathon.conf 配置文件。

为了使用简单性考虑，修改后的 arukas-ss.sh 脚本是直接通过 /etc/init.d/shadowsocks 服务脚本重启 OpenWRT 上的 Shadowsocks 客户端程序。该脚本的使用方法也请参考我之前写的介绍 Arukas 容器及 Endpoint 的文章。

最后祝大家心中无墙，玩的开心 ^_^。

之前我在了解目前主流的容器服务商时除了 IBM Bluemix 还知道了日本 Arukas 容器，不过一直都没有测试的机会，最近 Arukas 难得给我发了注册通过的邮件，最新的政策显示免费测试期会延长到 2017 年 6 月 30 日（未来收费策略待定）。

下面的基本操作都在 Arukas 控制面板：

https://app.arukas.io/

Arukas 容器限制

Arukas 容器还处于免费测试阶段，有一些限制需要先说明：

• 不支持特权容器，无法使用 TUN/TAP 设备（目前的容器服务商基本都不支持）；
• 没有固定公网 IP 地址，容器可能每隔几天甚至几个小时就会重启；
• 配置的容器内部端口会被映射到随机的外部端口；
• 自定义 Endpoint 域名只能以 HTTPS 方式访问，对应的容器内部端口只支持 HTTP 协议（下面会详细介绍）；
• 不支持使用自定义的 Dockerfile 文件构建容器，只能使用 Docker hub 上的镜像；
• 暂时不支持外部存储，因此容器里无法保存任何数据，每次重启容器数据会全部丢失；
• 创建容器时只能配置 Dockerfile 中的 ENV（环境变量）和 CMD（启动执行命令）指令，不支持 RUN 及 ENTRYPOINT 等其它指令。

关于 Endpoint

通过参考 Arukas 日文版帮助文档，我们可以得知虽然 Arukas 容器没有固定的公网 IP 地址，容器开放的内部端口每次启动也都被映射到随机的外部端口，但容器的 Endpoint 地址是始终固定不变的，类似于这样：

https://xxx.arukascloud.io/

经过测试我发现容器的 Endpoint 地址必须以 HTTPS 方式访问（HTTP 访问会直接返回 Connection refused），Endpoint 地址只对容器开放的第一个内部端口有效，而且该内部端口只支持 HTTP 协议，不支持 TCP 或者 UDP。

用户访问 Endpoint 子域名地址时并不是直接访问容器的当前公网地址，而是访问 Arukas 提供的 HAProxy 负载均衡服务器，HAProxy 负责转发并均衡容器下多个实例的 HTTP 请求，其网络拓扑图大概如下所示：

提示

Arukas 官网上对 Endpoint 的说明遗漏了比较重要的一点：如果容器配置里开启了多个对外开放的内部端口，那么 Endpoint 请求转发只会在所有这些端口的服务都已经运行的情况下才有效。

这样 Arukas 就能够在有限的服务器（内部端口映射到随机外部端口）和公网 IP 地址（固定 Endpoint 地址）情况下提供尽量多的容器访问支持。

构建容器

从上面的介绍来看虽然 Arukas 容器有很多体验不太好的限制，但其所在的樱花机房线路还是相当有吸引力的，立马准备建立容器看看运行效果。

为了测试 Arukas 容器的运行效果，我没有使用一些做好的通用 SSH 系统（例如：centos-ssh）或者 Shadowsocks 系统镜像，本文还是用的之前捣鼓过的 baseimage-docker Docker 镜像。

baseimage-docker 的问题

baseimage-docker 镜像虽然用起来很方便，支持轻量级的 runit 服务管理方案，但该镜像默认并没有开启 SSH 登录，如果需要开启 SSH 服务器或者执行自定义命令都需要修改 Dockerfile 文件中的 RUN 指令，具体可以参考该项目 GitHub 主页。

然而 Arukas 容器并不支持使用 RUN 命令配置执行自定义命令，也不能保存任何数据，因此 SSH 登录和执行自定义命令的问题需要通过其它方法解决。

幸好 baseimage-docker 还支持通过 CMD 指令开启运行 one-shot command 单次命令支持，对应的 CMD 指令类似这样：

/sbin/my_init -- COMMAND ARGUMENTS ...

容器系统的运行流程就相当于：

• 运行所有启动脚本，例如 /etc/my_init.d/* 及 /etc/rc.local；
• 启动所有 runit 服务；
• 运行 my_init 参数中指定的自定义命令；
• 自定义命令退出之后即停止所有 runit 服务。

因此我们可以在单次命令参数上做文章，实现开启 SSH 服务器、安装需要的软件并启动附加的服务。

容器基本配置

下面是我在 Arukas 控制面板建立的一个 Shadowsocks 服务器容器的配置：

• Image 我使用的是最新的 baseimage-docker 镜像：phusion/baseimage:0.9.19；
• Instances 一般就用默认的一个实例；
• Memory 可以根据需要选择 256 MB 或者 512 MB；
• Endpoint 指定 Endpoint 子域名地址；
• Port 设置里可以将容器中最多 20 个 TCP 或者 UDP 端口对外开放，我填了 80、22 外加一个 Shadowsocks 服务器端口，需要注意的就是上面的固定 Endpoint 地址只支持第一个端口；
• ENV 环境变量根据需要设置，我在这里指定了 SSH key 和 Shadowsocks 服务器配置；

• CMD 设置比较关键，我建立的 Shadowsocks 测试容器是这样的：

  /sbin/my_init -- sh -c 'curl -o /arukas-baseimage-xenial-ss.tar.gz https://zohead.com/downloads/arukas-baseimage-xenial-ss.tar.gz && tar -C / -xzf /arukas-baseimage-xenial-ss.tar.gz && /etc/my_init.d/01_start_ss_ssh.sh'
  

我制作了一个适用于最新 baseimage 系统的 Shadowsocks 服务器安装包：

https://zohead.com/downloads/arukas-baseimage-xenial-ss.tar.gz

容器系统启动时会自动将安装包下载到根目录下解压缩，然后执行其中的 /etc/my_init.d/01_start_ss_ssh.sh 启动脚本：

#!/bin/bash

# Enable SSH
rm -f /etc/service/sshd/down
/etc/my_init.d/00_regen_ssh_host_keys.sh
touch /etc/service/sshd/down

# Setup SSH key
if [ "x$SSH_AUTHORIZED_KEYS" = "x" ]; then
	/usr/sbin/enable_insecure_key
else
	mkdir ~/.ssh
	echo "$SSH_AUTHORIZED_KEYS" | sed 's/\\n/\n/g' > ~/.ssh/authorized_keys
	chmod 400 ~/.ssh/authorized_keys
fi

# Start web server
env | grep -E '^MARATHON_HOST=|MARATHON_PORT_' > /home/wwwroot/default/marathon.conf
if [ "x$MARATHON_HOST" != "x" ]; then
	getent hosts $MARATHON_HOST | awk '{print "MARATHON_HOST_IP="$1; exit;}' >> /home/wwwroot/default/marathon.conf
fi

start-stop-daemon -S -b -n tmp-httpd -d /home/wwwroot/default -x /usr/bin/python3 -- -m http.server 80

# Start ShadowSocks
env | grep '^SHADOWSOCKS_CFGS_' | awk -F '=' '{print $1;}' | while read T_NAME; do
	SS_NAME="${T_NAME:17}"
	echo "${!T_NAME}" > /etc/shadowsocks-libev/${SS_NAME}.json
	start-stop-daemon -n ss-$SS_NAME -x /usr/bin/ss-server -b -S -- -c /etc/shadowsocks-libev/${SS_NAME}.json -u --fast-open
done

exec /usr/sbin/sshd -D -e -u 0

该启动脚本的执行流程如下：

• 首先启用 SSH 服务器，并产生 SSH host key；
• 如果容器配置的 ENV 环境变量里存在 SSH_AUTHORIZED_KEYS 变量，那么就使用这个变量的内容作为 SSH 公钥（容器配置截图里我就使用此方法指定自定义公钥），如果不存在则使用 baseimage 提供的默认公钥；
• 接着获取 Arukas 容器的当前临时域名、公网 IP 地址以及每个内部端口映射等内容输出到 /home/wwwroot/default Web 服务器目录下的 marathon.conf 文件；
• 在默认的 80 端口启动 Web 服务器以支持 Endpoint 地址访问；

• 遍历容器配置的所有 ENV 环境变量，如果存在以 SHADOWSOCKS_CFGS_ 开头的变量，就在 /etc/shadowsocks-libev 目录下生成 Shadowsocks 服务器配置文件，配置文件内容就是该变量的值。

  例如我使用的一个 Shadowsocks 配置变量（将 Shadowsocks 服务器的 JSON 配置写成一行）：

  SHADOWSOCKS_CFGS_xxx={ "server":"0.0.0.0", "server_port":17374, "local_port":1080, "password":"arukas-ss-svr", "timeout":30, "method":"aes-256-cfb" }
  

  这样就会自动产生 /etc/shadowsocks-libev/xxx.json 配置文件；

• 依次启动 ENV 环境变量里指定的所有 Shadowsocks 服务器（可以指定多个以 SHADOWSOCKS_CFGS_ 开头的变量）；
• 最后以前台方式启动 SSH 服务器，这样就能实现 SSH 远程登录，而且 baseimage 容器也不会退出。

容器运行状态

Arukas 容器启动运行成功之后，你可以在控制面板里查看运行状态：

这里可以看到容器的 Endpoint 地址、用于直接访问容器的临时域名和映射的外部端口等信息。

容器启动之后会将当前的临时域名、内部端口映射等信息输出到系统环境变量中，这样上面的 /etc/my_init.d/01_start_ss_ssh.sh 启动脚本才能直接获取到这些信息，有兴趣的朋友可以在容器中确认：

root@02a78258745b:~# env | grep -E '^MARATHON|MESOS'
MESOS_TASK_ID=db89b5a5-7df0-49f0-b5d4-47d6406abbd8.6cccf318-080c-11e7-aca2-0242a39fa0e7
MARATHON_PORT0=31198
MARATHON_PORT1=31689
MARATHON_PORT=31198
MARATHON_APP_RESOURCE_DISK=0.0
MARATHON_APP_RESOURCE_MEM=32.0
MARATHON_APP_LABEL_HAPROXY_0_VHOST=gloomy-golick-3736.arukascloud.io
MARATHON_APP_RESOURCE_GPUS=0
MESOS_CONTAINER_NAME=mesos-eb1747b8-0843-4061-bc0e-9cd1b5347ee2-S9.d07c30b6-51b1-44ca-a453-d4302ec08d2e
MARATHON_APP_LABEL_HAPROXY_GROUP=external
MARATHON_HOST=seaof-153-125-239-206.jp-tokyo-27.arukascloud.io
MARATHON_APP_LABELS=HAPROXY_GROUP HAPROXY_0_VHOST
MARATHON_APP_ID=/db89b5a5-7df0-49f0-b5d4-47d6406abbd8
MARATHON_APP_DOCKER_IMAGE=phusion/baseimage:0.9.19
MARATHON_APP_VERSION=2017-03-13T16:45:10.089Z
MARATHON_PORTS=31198,31689
MARATHON_APP_RESOURCE_CPUS=0.01
MARATHON_PORT_80=31198
MARATHON_PORT_22=31689
MESOS_SANDBOX=/mnt/mesos/sandbox

我们可以看看 Arukas 容器的服务器信息，其使用的是 CoreOS 系统（内核版本为 4.9.9）：

root@837bc28c1c36:~# uname -a
Linux 837bc28c1c36 4.9.9-coreos-r1 #1 SMP Tue Mar 28 22:27:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

内存是所有容器一起共享的（如果容器使用的内存超过配置中的限制太多会被重启）：

root@837bc28c1c36:~# free -m
              total        used        free      shared  buff/cache   available
Mem:          24115        4300        1520         715       18295       17563
Swap:          4095          24        4071

CPU 配置还算给力，使用的是 8 个 Xeon E5-2650：

root@837bc28c1c36:~# grep -E '^processor|physical id|model name' /proc/cpuinfo
processor	: 0
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 0
processor	: 1
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 1
processor	: 2
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 2
processor	: 3
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 3
processor	: 4
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 4
processor	: 5
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 5
processor	: 6
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 6
processor	: 7
model name	: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
physical id	: 7

只是容器内核对文件系统的支持比较坑爹：

root@837bc28c1c36:~# cat /proc/filesystems
nodev	sysfs
nodev	rootfs
nodev	tmpfs
nodev	bdev
nodev	proc
nodev	cpuset
nodev	cgroup
nodev	cgroup2
nodev	devtmpfs
nodev	debugfs
nodev	tracefs
nodev	securityfs
nodev	sockfs
nodev	bpf
nodev	pipefs
nodev	ramfs
nodev	hugetlbfs
nodev	devpts
nodev	pstore
nodev	mqueue
nodev	selinuxfs
nodev	autofs
	squashfs
	iso9660
	ext3
	ext2
	ext4
nodev	overlay

不支持 NFS 挂载远程目录，也不支持 FUSE 用户层文件系统来实现挂载 Amazon S3 存储之类的，这对于目前还不支持外部存储的 Arukas 容器来说实在不算友好。

使用 Shadowsocks 容器

Shadowsocks 效果

客户端使用上面指定的 Shadowsocks 服务器配置就可以爬墙上网了，当然使用前需要将 Shadowsocks 服务器地址更换为 Arukas 容器的临时域名，并将服务器端口改为当前映射出来的外部端口（不能直接使用内部端口）。

这个是我在宿舍江苏移动宽带网络下观看 Youtube 1080p 视频的效果，8 Mbps 的速度看起来还是比较给力的：

换到南京电信网络进行路由追踪，可以看到 ping 值还不到 50 ms：

OpenWRT 自动更新 Shadowsocks 配置

由于 Arukas 容器的外网地址和端口在每次启动时都不是固定的，容器重启后 Shadowsocks 客户端都需要获取当前临时域名和外部端口，这样用起来还是不太方便。特别对于我这种需要 OpenWRT 路由器直接翻墙的用户来说，每次修改 OpenWRT 设置就太麻烦了。

好消息就是 Arukas 容器的 Endpoint 地址还是固定的，我写的启动脚本也自动将容器当前的临时域名、公网 IP 地址、所有外部端口都输出到文件了，可以直接通过 Endpoint 地址访问。

因此我又专门写了一个适用于 OpenWRT 系统的更新 Arukas 容器配置的脚本：arukas-ss.sh，可添加到路由器的 Shadowsocks 服务脚本中，也可以设置成定时任务：

#!/bin/sh
[ $# -ge 2 ] || exit 1

[ -f /tmp/.marathon.conf ] && mv /tmp/.marathon.conf /tmp/.marathon.conf.bak

IND=0
while [ $IND -lt 20 ]; do
	let IND++
	[ -f /tmp/.marathon.conf ] && rm -f /tmp/.marathon.conf
	curl -s -k -f -o /tmp/.marathon.conf https://zohead-server.arukascloud.io/marathon.conf
	[ $? -eq 0 ] && break
	sleep 1
done

[ -s /tmp/.marathon.conf ] || exit 1
echo "Fetch server config after $IND tries."

if [ -f /tmp/.marathon.conf.bak ]; then
	cmp -s /tmp/.marathon.conf /tmp/.marathon.conf.bak
	if [ $? -eq 0 ]; then
		rm -f /tmp/.marathon.conf
		exit 0
	fi
fi

. /tmp/.marathon.conf 2>/dev/null
if [ "x$MARATHON_HOST" = "x" ]; then
	rm -f /tmp/.marathon.conf
	exit 1
fi

while [ $# -gt 1 ]; do
	CMD="echo \${MARATHON_PORT_$2}"
	SS_PORT=`eval $CMD`

	if [ -f $1 -a "x$SS_PORT" != "x" ]; then
		if [ "x$MARATHON_HOST_IP" != "x" ]; then
			MARATHON_HOST="$MARATHON_HOST_IP"
		fi
		sed -i -e 's/"server"[^:]*:[^,]*,/"server" : "'$MARATHON_HOST'",/' -e 's/"server_port"[^:]*:[^,]*,/"server_port" : "'$SS_PORT'",/' $1
		SS_PID=`pgrep -f "ss-redir -c $1"`
		if [ $? -eq 0 ]; then
			kill $SS_PID >/dev/null 2>&1
			kill -9 $SS_PID >/dev/null 2>&1
			start-stop-daemon -x /usr/bin/ss-redir -b -S -- -c $1 -b 0.0.0.0
		fi
	fi
	shift
	shift
done

arukas-ss.sh 脚本的使用方法为：

arukas-ss.sh shadowsocks-1.json 17374 shadowsocks-2.json 2233 ... ...

第一个参数为 Shadowsocks 客户端 JSON 配置文件的完整路径，第二个参数为该文件对应的 Arukas Shadowsocks 服务器配置的内部监听端口号，arukas-ss.sh 脚本支持多个本地 Shadowsocks 配置文件和服务器内部监听端口号，依次类推即可。

使用前需要替换 arukas-ss.sh 脚本中的 Endpoint 地址，考虑到 Arukas 容器目前的 Endpoint 访问还不太稳定的情况，脚本里也加了多次访问尝试，我的 Endpoint 地址是这样：

https://zohead-server.arukascloud.io/marathon.conf

另外可以修改 OpenWRT 的定时任务配置实现自动更新，例如在 /etc/crontabs/root 文件中增加一行：

30 * * * * /etc/arukas-ss.sh /etc/shadowsocks.json 17374

这就表示在每个小时的第 30 分钟执行 arukas-ss.sh 脚本更新 Arukas Shadowsocks 配置，一般这样就能对付 Arukas 容器每隔几个小时自动重启的问题了。

后记

经过我这段时间的试用，Arukas 容器做为爬墙服务器还是比较顺畅的，如果想捣鼓一个简单的 API 服务器也还凑合，不过由于 Arukas 目前还不支持外部存储，想拿来跑个博客程序之类的就要涉及到如何保存和恢复网站数据的问题了。

当然容器只能用 Endpoint 地址访问也是一个大问题，经过测试我也发现如果容器内开放的内部端口稍微一多（可能超过 3 个）时，Arukas 的 HAProxy 转发服务就不太稳定了，经常出现 502 或者 503 错误。如果容器内开放了 UDP 端口，Endpoint 地址甚至可能会处于一直都不能访问的状况。

如果 Arukas 容器在内测期间能解决这些问题，后续正式使用价格也不算离谱的话，感觉应该还是有些竞争力的，最后祝大家 4 月玩的开心。

最近一两个月我在查看 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 容器系统已经不会报策略违例了。

P2P VPN 和我们平常使用的 PPTP、OpenVPN 等 VPN 的不同之处在于其只负责将两个或多个主机通过点对点的方式进行连接，不需要中心服务器支持，多个主机之间通过 STUN 打洞或者 TURN 中继等方式进行连接，比较适合不同网络间的多个主机进行直接连接，不像 PPTP 这种在国内用的最多的就是拿来爬墙的。

目前使用的比较多的包括 n2n、tinc 和本文要介绍的 ZeroTier 等几种免费开源的 P2P VPN 软件。

n2n 由于已经没人继续开发支持了所以不予考虑，我在对比了 tinc 和 ZeroTier 之后发现 ZeroTier 虽然看起来性能比 tinc 略差一点，但其客户端配置步骤非常简单，不需要像 tinc 那样要在多个主机分别手工生成配置文件，而且 ZeroTier 自己也自带了几个不同国家区域的中继服务器方便普通用户使用，另外一点就是本文要介绍的 ZeroTier 支持在 Linux 容器中使用，因此平时我主要使用 ZeroTier，tinc 用作辅助。

ZeroTier 的虚拟网络可以包含多个处于相同或不同物理网络里的主机，每个虚拟网络都有一个唯一的网络 ID，多个运行 ZeroTier 服务的主机加入同一个 ZeroTier 网络 ID 就可以构成一个虚拟网络。虚拟网络都是由 ZeroTier Controller 控制器来管理的，默认可以使用 ZeroTier 提供的控制器来管理，用户也可以自行搭建控制器来实现完全自己管理 ZeroTier 网络。

另外 ZeroTier 有一个特殊的 8056c2e21c000001 网络 ID 表示全球公共 ZeroTier 网络，如果只是想测试连接网络的话也可以加入这个公共网络；但实际使用中为了安全性考虑建议最好在 ZeroTier 网站上注册一个账户并新建你自己的 P2P VPN 网络用于管理。

有关 ZeroTier P2P VPN 的详细介绍可以参考其官网：

https://www.zerotier.com/

容器中使用 ZeroTier 的问题

简单了解 ZeroTier P2P VPN 主机端的工作机制之后我就发现一个问题，其依赖的 TUN/TAP 驱动（n2n 和 tinc VPN 也同样依赖）在很多 Linux 容器系统中是无法使用的。

我使用的 OpenVZ VPS 容器还好还可以在控制面板里开启 TUN/TAP 支持，而对于现在非常流行的 Docker 容器（例如之前我用到的 IBM Bluemix 容器）就比较麻烦了，Docker 容器在运行时必须包含 SYS_NET_ADMIN 特权才能正常执行 TUN/TAP 虚拟网卡设备的创建操作（Docker 容器中同样也不能使用 OpenVPN、OpenConnect 等依赖 TUN/TAP 驱动的程序），但目前的容器服务厂商基本上不会以特权方式运行容器。

ZeroTier 为此提出的解决方案就是 Network Containers 模式，通过实现一个轻量级的应用层 TCP/IP API 来 hook 现有应用程序的 Socket API，这样可以使现有的程序也能使用 ZeroTier 技术连接其它主机。

最近 ZeroTier 已经将 Network Containers 模式更名为 ZeroTier SDK 并使用了单独的版本库，开发者也可以选择将 ZeroTier SDK 直接编译进自己的应用程序以方便直接使用。有关容器模式的详细介绍可以参考官方介绍文章：ZeroTier Network Containers。

关于 Codeanywhere 容器

这里我使用 Codeanywhere 虚拟机来测试 ZeroTier Network Containers，Codeanywhere 作为一个云端 IDE 平台还是比较好用的，其提供的免费版本的容器支持：

• 2GB 磁盘空间；
• 256MB RAM (+ 512 MB 交换空间)；
• sudo 支持；
• 支持 SSH 登录（免费版本的容器每次启动时 SSH 端口不固定）；
• 支持访问所有 HTTP 和 Websocket 端口（默认 1024 - 9999）。

问题是 Codeanywhere 免费版本的虚拟机不支持固定 IP 地址，也不支持域名绑定或者固定子域名，每次虚拟机启动之后分配到的都是一个超长的子域名，例如你看到的子域名可能就是下面的形式：

preview.7reszf59tfv18aor9x7odheaio340a4ih8tcn8fvndzvkj4i.box.codeanywhere.com

这样实际开发测试起来还是有点不太方便。

当然 Codeanywhere 也是不提供 TUN/TAP 支持的，这样如果 ZeroTier 的容器模式可以在 Codeanywhere 虚拟机内正常使用，我就可以直接在自己的电脑上直接使用虚拟的 P2P VPN 节点 IP 地址来访问 Codeanywhere 虚拟机了，可以省掉那一长串恶心的子域名了。

使用 ZeroTier Network Containers

编译安装 ZeroTier Network Containers

首先创建一个新的 Codeanywhere 虚拟机，建议使用 C/C++ Development Stack 类型方便后续编译安装 ZeroTier 程序，另外操作系统最好选择 Centos 6.5 64 位，如果使用 Ubuntu 系统可能存在连接不上 P2P VPN 网络的问题。

在 Codeanywhere 虚拟机中使用 git 命令检出 ZeroTier 官方版本库，检出之后运行 make netcon 命令就可以编译出 ZeroTier Network Containers 模式需要的文件了：

[cabox@box-codeanywhere ZeroTierOne]$ ls                                           
AUTHORS.md   examples                 netcon        ui
LICENSE.txt  ext                      node          version.h
Makefile     include                  objects.mk    windows
README.md    java                     one.cpp       world
artwork      libzerotierintercept.so  osdep         zerotier-cli
attic        make-freebsd.mk          selftest.cpp  zerotier-idtool
cluster-geo  make-linux.mk            service       zerotier-netcon-service
controller   make-mac.mk              tcp-proxy

其中最重要的就是 zerotier-netcon-service 服务和 libzerotierintercept.so 以及 netcon 目录中的 liblwip.so 应用层 Socket API 库文件了，接着可以先将 ZeroTier Network Container 模式程序和有关库文件安装到 /var/lib/zerotier-one 目录中：

[cabox@box-codeanywhere ZeroTierOne]$ mkdir -m /var/lib/zerotier-one
[cabox@box-codeanywhere ZeroTierOne]$ cp -ra zerotier-* /var/lib/zerotier-one
[cabox@box-codeanywhere ZeroTierOne]$ cp libzerotierintercept.so netcon/liblwip.so /var/lib/zerotier-one

将容器主机加入 ZeroTier 虚拟网络

下面就可以在 Codeanywhere 虚拟机中进行测试了，首先启动 Network Container 模式下的 ZeroTier 主服务程序：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-netcon-service -d

服务启动成功之后稍等片刻，运行 zerotier-cli 命令加入现有的 ZeroTier 虚拟网络，下面命令行中的 565799d8f61077e9 就是我在 ZeroTier 网站上新创建的虚拟网络 ID：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-cli join 565799d8f61077e9

提示

如果你加入的是 8056c2e21c000001 这个全球公共 ZeroTier 虚拟网络那就可以省掉下面这一段落的配置步骤了。

join 操作完成之后需要在 ZeroTier 网站后台虚拟网络管理界面中先允许新的主机加入此网络，接着可以为此主机配置虚拟网络上的 IP 地址、子网掩码之类的，具体配置操作步骤还算比较简单基本都可以在 ZeroTier Central 网站后台中完成。

配置完成之后就可以在容器中继续运行 zerotier-cli 命令查询该主机上 ZeroTier 虚拟网络状态：

[cabox@box-codeanywhere workspace]$ /var/lib/zerotier-one/zerotier-cli listnetworks
200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks 565799d8f61077e9 zohead-network fa:d9:cf:a8:b2:40 OK PRIVATE /var/lib/zerotier-one/nc_565799d8f61077e9 10.10.8.4/24

可以看到该容器中已经正确连接到我建立的私有 ZeroTier 虚拟网络了，而且分配到了一个 10.10.8.4 的 IP 地址，子网掩码为 255.255.255.0（对应 24）。

通过虚拟网络访问容器主机

此时需要特别注意的是容器中运行的程序还不能直接使用 ZeroTier 虚拟网络与其它主机进行连接，必须通过预加载 Network Container 库文件的方式运行程序才可以在容器系统中正确访问 ZeroTier 虚拟网络，这里我们以 SSH 服务器为例，首先可以新运行一个 sshd 服务程序：

[cabox@box-codeanywhere workspace]$ sudo ZT_NC_NETWORK=/var/lib/zerotier-one/nc_565799d8f61077e9 LD_PRELOAD=/var/lib/zerotier-one/libzerotierintercept.so /usr/sbin/sshd -p 27001

这样可以新运行一个 sshd 服务程序，并绑定新的端口（例如上面例子中的 27001 端口）防止和系统默认的 22 端口冲突，ZT_NC_NETWORK 变量指定需要使用的 ZeroTier 虚拟网络路径（默认为：/var/lib/zerotier-one/nc_网络ID），LD_PRELOAD 是必须指定的，否则新运行的 sshd 程序将无法访问 ZeroTier 虚拟网络。

新的 sshd 服务启动成功之后，我们就可以在测试的 Windows、Linux 等主机上运行 ZeroTier 客户端，加入同样的虚拟网络并配置虚拟网络 IP 地址（例如我的 Windows 机器 ZeroTier 网络 IP 地址是 10.10.8.3）及子网掩码。

最后我们可以在 Windows 主机上 ping 测试 Codeanywhere 容器的虚拟网络 IP 地址了，如果通讯正常的话就可以通过 ssh 客户端工具直接连接登录 Codeanywhere 容器系统了，这样就顺利绕过了 Codeanywhere 的随机子域名限制。

后记

如果需要在 Codeanywhere 容器系统启动时自动连接 ZeroTier 虚拟网络并开启独立的 sshd 服务程序，那可以将类似下面的两句命令加到 /etc/rc.local 文件末尾：

/var/lib/zerotier-one/zerotier-netcon-service -d
echo "ZT_NC_NETWORK=/var/lib/zerotier-one/nc_565799d8f61077e9 LD_PRELOAD=/var/lib/zerotier-one/libzerotierintercept.so /usr/sbin/sshd -p 27001" | at now + 2 minutes

第二句命令表示在 ZeroTier Network Container 服务程序启动两分钟之后再启动单独的 sshd 服务程序，以使 ZeroTier 服务程序在等待的时间内能正确连接虚拟网络。

本文主要介绍 ZeroTier 程序里不太常见的 Network Container 容器模式，这对于越来越多的 Docker 容器系统而言能绕过 TUN/TAP 限制还是有点用处的，如果读者发现了有关 ZeroTier P2P VPN 的更多好玩法，欢迎提出交流哦，祝大家玩的开心～～～。

本文不打算对 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 目前还是比较良心的，大家且用且珍惜请不要滥用呢，最后祝玩的开心 ～～～。