Aria2c容器化部署(All in One)

之前做的分成三个部分的aria2c容器化部署(参见这里),WEB服务和Aria2c服务两个镜像还好,压缩后大小都不超过100MB。就是WebDAV服务选用了WsgiDAV,该镜像即使是压缩后,也高达390MB——太可怕了。接下来考虑如何最大限度地减小镜像大小

在Alpine发行版中编译Aira2

alpine可以说是Linux发行版中体积最小的,整个大小只有5MB。虽说体积小对于操作系统而言其实也没什么特别的好处,但当讨论到容器的时候,体积小就具有先天优势。不过有意思的是,alpine使用的标准C语言库和其他的发行版用的不一样,是musl-libc,这就造成没办法直接使用release中发布的二进制文件。
没办法,只能手动编译一个。鉴于alpine软件仓库里的aria2版本也很老了,手动编译其实也是很有必要性的。

Alpine dev软件包的小坑

照着Aria2的说明,只安装libxxx-dev这种软件包,当然在编译阶段是没有什么大问题的,必要的头文件都有;如果Aria2编译使用动态链接库,那也没什么大问题,必要的动态库也有。就是当需要编译一个静态链接的Aria2时,就会出现一串 ···ld: cannot find -lsqlite3 ···ld: cannot find -lintl 之类的报错。正常反应就是:欸?我明明装了sqlite-dev包,怎么还会缺sqlite3.a呢?其实,还有个sqlite-static的包。另外alpine上intl.agettext-static包里,而不在libintl——找这个静态库也是花了好大的力气。此外值得一提的是静态链接得到的aria2c,大小有133.8M。

静态链接还是动态链接

正如上面提到的那样,静态链接得到的aria2c还是稍微有一点点大的。动态链接得到的aria2c为108.1MB,减少了25.7MB。如果说一个容器中没有其他的组件,静态链接当然是更好的选择,但如果还有其他组件,动态链接就更好。然而仔细分析一下依赖情况,alpine软件包仓库中的nginx依赖于

  • busybox
  • libcrypto1.1
  • libssl1.1
  • musl
  • pcre
  • zlib

个个都是个头不超过2MB的家伙,因此从理性上,动态链接得到的总镜像大小应该降低得不是很多。然而一通分析猛如虎,实际上镜像大小从430MB降低到了378MB,减少了52MB,降幅12%。所以还是要动态链接。

从WebDAV协议换成S3协议

文件传输主要还是依赖FTP,SSH,HTTP这三类基本协议。一般来说,如果没有什么特别的需求,没人还会去用FTP协议做文件传输,因为FTP作为一个多端口协议,放在容器里就完蛋了。一般会考虑HTTP基础上的WebDAV,三个主要Web服务器都支持WebDAV协议,其中Apache2和IIS都是完整支持的;Nginx部分支持。如果要在容器当中部署WebDAV,那么首选使用Apache2作为Web服务器,也就省却了安装其他WebDAV服务器的必要。相对于之前装一个WsgiDAV还要完整的Python环境,整个镜像的大小可以有十分显著的减小。
那为什么还要执着于Nginx呢?其实只是单纯个人喜好问题,所以就要想办法解决衍生出来的文件传输的问题。总不能指望一个精简版的WebDAV协议能好用吧。

因此在这回的Aria2部署中选用了S3协议,那么实现了S3协议的MinIO就映入眼帘。当然S3协议并不是WebDAV协议的上位替代。另外对于S3协议而言,最大的缺点在于S3不能部署在子目录下,因为URL是需要签名,然后合并进请求头的,但是一般而言的子目录部署都是需要将前缀删除后,再反向代理给S3服务器。当然使用多个域名倒也是能解决这个问题,只不过有的时候内网部署的时候,通常不会去设置域名——一般是直接IP地址访问。
解决方法主要还是直接反代bucket名,然后反代/minio确保minio的Web UI可用。

留下评论