Soul Of Free Loop » Docker https://zohead.com Uranus Zhou's Blog Sat, 19 Jul 2025 15:42:46 +0000 zh-CN hourly 1 http://wordpress.org/?v=3.8 使用kcptun曲线访问Arukas容器 https://zohead.com/archives/arukas-kcptun/ https://zohead.com/archives/arukas-kcptun/#comments Wed, 06 Mar 2019 17:08:16 +0000 https://zohead.com/?p=1573 新版 Arukas 容器现状

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 容器 Shadowsocks kcptun 速度

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

]]> https://zohead.com/archives/arukas-kcptun/feed/ 0 在Docker容器中使用FUSE文件系统 https://zohead.com/archives/docker-fuse/ https://zohead.com/archives/docker-fuse/#comments Tue, 19 Dec 2017 16:32:18 +0000 https://zohead.com/?p=1518 容器使用 FUSE 的问题

我们一般使用的 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 年能继续玩地开心 ^_^。

]]> https://zohead.com/archives/docker-fuse/feed/ 9 Arukas樱花Docker容器及Endpoint体验 https://zohead.com/archives/arukas-container/ https://zohead.com/archives/arukas-container/#comments Fri, 31 Mar 2017 16:17:46 +0000 https://zohead.com/?p=1408 Arukas 容器介绍

之前我在了解目前主流的容器服务商时除了 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 网络拓扑图

提示

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 服务器容器的配置：

Arukas 容器配置

  • 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 容器启动运行成功之后，你可以在控制面板里查看运行状态：

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 的速度看起来还是比较给力的：

Arukas Shadowsocks 速度

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

Arukas 容器路由追踪

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 月玩的开心。

]]> https://zohead.com/archives/arukas-container/feed/ 9 在Linux容器中使用ZeroTier P2P VPN https://zohead.com/archives/zerotier-container/ https://zohead.com/archives/zerotier-container/#comments Wed, 31 Aug 2016 16:57:17 +0000 https://zohead.com/?p=1266 关于 ZeroTier P2P VPN

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 的更多好玩法，欢迎提出交流哦，祝大家玩的开心～～～。

]]> https://zohead.com/archives/zerotier-container/feed/ 15 IBM Bluemix Docker容器初步体验 https://zohead.com/archives/ibm-bluemix-docker/ https://zohead.com/archives/ibm-bluemix-docker/#comments Thu, 14 Apr 2016 19:20:13 +0000 https://zohead.com/?p=1213 现在国内外流行的云平台越来越多，且不谈像国外的 Amazon ECS、AWS 以及 国内的阿里云、BAE、SAE 这些老牌的云服务，目前提供 Docker 容器服务的平台也多起来，国外有 StackEngine、Tutum、IBM Bluemix 等云平台，国内也有 DaoCloud、时速云、灵雀云之类提供 Docker 容器服务的平台。最近对 Docker 也稍微有了点兴趣，比较之下准备拿 IBM Bluemix 来捣鼓 Docker 容器练练手。

本文不打算对 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 容器内存使用情况

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

注意

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


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

Bluemix 管理区域配额

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

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

]]> https://zohead.com/archives/ibm-bluemix-docker/feed/ 21