cURL(https://curl.haxx.se/)是我喜欢的开源软件之一。虽然cURL的强大常常被认为是理所当然的,但我真心地认为它值得感谢和尊重。如果我们的工具箱失去了curl
,那些需要和网络重度交互的人(我们大多数人都是这样的)将会陷入到困境中。curl
速度快、体积小,并且和大多数好工具一样,简洁干净,尽量不影响用户,只做它们需要做的事情。
如果有人想使用curl
中的一种功能(比如UNIX套接字支持),而恰恰系统提供的包的配置不支持这种功能,或者包版本太老而不包含这种功能,由于curl
享有“数据传输的瑞士军刀”的美誉,可以想象这种情况是有可能发生的。因此你会发现,你想要编译一个包含你所需要的功能的curl
。编译自己的软件是令人害怕的,尤其是当你不擅长解决这类问题时,让我们先暂时抛开这个事实,自定义你所使用的软件将会是一次难以置信的、解放自身的体验。
如果需要,你可以编译自己的软件,并且不受限于其它人交给你的软件包,明确这一点将会给你带来自信。突然间,你脑中可能会充斥着兴奋的快感——你能够按照你喜欢的方式安装和配置任何软件,并不需要接受其它人配置中的限制。人类常常喜欢给一样东西加上自己的标记,这就是使用开源软件的令人上瘾的原因之一。
由于Docker文件系统的分离特性,它成为了完成这类事情最佳的选择。你并不需要担心安装依赖库或者运行一个糟糕的make install
类似的命令,会将你的本地文件系统弄乱。它能够让你在真实的环境中进行操作,并且允许你犯错。这对于学习知识是一个极佳的工具,因为将事情完全弄糟是学习的必经之路,并且在容器中将事情弄糟,你能够轻易地将这些容器丢弃,这种方式比弄糟自己的本地系统要安全多了。除此之外,如果你将这些步骤以脚本的形式写入到Dockerfile
中,那么在后续重新构建时,构建步骤将保持一致。尽管Dockerfile
不能100%保证构建的结果,但这总比README
中的随意描述好多了。
接下来让我们一起构建一个Dockerfile
来创建一个支持HTTP2的、体积最小的、基于Alpine Linux的镜像。重点将会放在减小镜像体积和能够100%自定义curl
上。
方法步骤
我们将会:
讨论为什么我们要关注HTTP2?
简要地看一遍Dockerfile
,让你对构建过程有初步了解。
讨论为什么将Alpine作为基础镜像?
详细解释Dockerfile
,一步一步地理解它。
构建并且运行镜像。
为什么选择HTTP2?
引用自 https://http2.github.io/:
由于HTTP的危急现状,HTTP/2成为了HTTP的代替品。HTTP/2并不是对HTTP协议的完全重写,HTTP方法,状态码,语义都保留了下来,并且应该能够使用和HTTP/1.x(可能有细微调整)一样的API来表示HTTP/2协议。
HTTP/2协议重点关注性能,尤其是端用户的接收延迟、网络和服务器资源的使用。其中一个主要的目标就是从浏览器访问一个Web网站可以只通过一条连接来实现。
简要地说,HTTP2想要解决HTTP/1.1的一些缺点,包括性能问题(https://www.cloudflare.com/http2/)。通过对前面链接中的样本用例进行测试,CloudFlare声明HTTP/2对我的电脑会有4~8倍的速度提升。能够提升网页4~8倍的速度?是的,你没有听错。
Dockerfile
这就是支持HTTP2的curl的Dockerfile
:
FROM alpine:edge # For nghttp2-dev, we need this respository. RUN echo https://dl-cdn.alpinelinux.org/alpine/edge/testing >>/etc/apk/repositories ENV CURL_VERSION 7.50.1 RUN apk add --update --no-cache openssl openssl-dev nghttp2-dev ca-certificates RUN apk add --update --no-cache --virtual curldeps g++ make perl && \ wget https://curl.haxx.se/download/curl-$CURL_VERSION.tar.bz2 && \ tar xjvf curl-$CURL_VERSION.tar.bz2 && \ rm curl-$CURL_VERSION.tar.bz2 && \ cd curl-$CURL_VERSION && \ ./configure \ --with-nghttp2=/usr \ --prefix=/usr \ --with-ssl \ --enable-ipv6 \ --enable-unix-sockets \ --without-libidn \ --disable-static \ --disable-ldap \ --with-pic && \ make && \ make install && \ cd / && \ rm -r curl-$CURL_VERSION && \ rm -r /var/cache/apk && \ rm -r /usr/share/man && \ apk del curldeps CMD ["curl"]
以上的构建过程大概做了以下事情:
我们安装了一些包,里面包含了我们所需要的、支持SSL(HTTPS)和HTTP2的库。
我们安装了一些编译cURL所必需的库。
我们下载和解压了cURLDE 源代码(在写作时的最新稳定版)。
我们配置,编译,然后安装了curl
。
我们清理了那些构建需要的、但是不想保留在最终镜像中的依赖。
我们将默认的CMD
设置为curl
。
为什么选择Alpine?
Alpine Linux是体积最小的Linux发行版,它重点关注于安全和速度。使用apk
能够很快地安装软件包,默认情况下,镜像只包含了完成基础UNIX任务所需要的东西 ,因此相对于其它Docker基础镜像,体积会更小。
对比常用的、没有压缩过的基础镜像(在写作时使用的是:latest标签):
Alpine
- 4.8MB
Ubuntu
- 124.8 MB
Debian
- 125.1MB
Centos
- 196MB
想象一下,在网络上一次又一次地下载拉取这些镜像
你是否正在考虑这能否对硬盘和带宽产生同样25倍价值的提升?在某些情况下,是相等的,但是Alpine每天都在不断地改进和提高,并且提供了很多杀手锏级别的特性,比如说通过文件名来查找(例子:需要定位哪一个apk
包包含了二进制文件mke2fs
,完全没有问题。)。在使用其它工具时,我必须花费大量的时间来学习它们奇怪的使用方式,对此我感到十分愤怒,不同于这些工具,我对使用Alpine十分高兴,并且它不断地给我惊喜。尤其是在使用一些小工具类型的容器时,比如说curl
,镜像体积的缩小对我来说非常棒。
详细的构建步骤
让我们更深入地了解Dockerfile。
FROM alpine:edge # For nghttp2-dev, we need this respository. RUN echo https://dl-cdn.alpinelinux.org/alpine/edge/testing >>/etc/apk/repositories
在Alpine的edge分支中,nghttp2
包(支持cURL中的HTTP2所必需的包)只有在testing仓库有效,因此这几行命令确保了当我们执行apk install
时nghttp2
包能够被正确安装。阅读“如何让cURL支持HTTP2”的文档就会发现, nghttp2
库是必需的(由于HTTP2所带来的复杂性),并且在Alpine的归档中闲逛时,发现了edge分支中nghttp2
只在testing仓库有效。
ENV CURL_VERSION 7.50.1
当cURL发布了新版本,我们想要更新镜像,我们仅仅需要修改这个文件的一处位置——环境变量,7.50.1
表示在写作时cURL最新的稳定版。
RUN apk add --update --no-cache openssl openssl-dev nghttp2-dev ca-certificates
这些是我们想要最终保留在镜像的依赖,默认证书和库是为了让curl
支持SSL(HTTPS连接)。注意—no-cache
,这个确保了apk
不会使用多余的硬盘空间来缓存包位置查找的结果,最终就会节省镜像的空间。
下一条RUN命令只会产生一个文件层(因此我们可以安装一些依赖,使用它们,然后清除它们,不将它们保留在最终镜像中)。这条命令内容比较多,让我们一步一步来看它们到底做了什么操作。
RUN apk add --update --no-cache --virtual curldeps g++ make perl && \
以上全都是成功编译和安装curl
所需要的工具。--virtual
是一个非常有用的apk特性——虚拟包。你可以给予包的集合一个标签,然后通过使用一条命令 apk del virtual-pkg-name
来将它们全部清除。
wget https://curl.haxx.se/download/curl-$CURL_VERSION.tar.bz2 && \ tar xjvf curl-$CURL_VERSION.tar.bz2 && \ rm curl-$CURL_VERSION.tar.bz2 && \ cd curl-$CURL_VERSION && \
获得cURL的源码压缩包,解压它,删除压缩包(我们在解压后就不需要它了),然后使用cd
命令进入到源文件目录。
./configure \ --with-nghttp2=/usr \ --prefix=/usr \ --with-ssl \ --enable-ipv6 \ --enable-unix-sockets \ --without-libidn \ --disable-static \ --disable-ldap \ --with-pic && \ make && \ make install && \
在熟悉的./configure;make;make install
命令的基础上加上了一些cURL特有的偏好设置。--with-nghttp2=/usr
就是用来配置HTTP2支持的,由于我们将nghttp2-dev
安装在Aline的/usr/lib
目录下,在构建cURL的时候,程序会自动在/usr
下的lib目录寻找一个包配置文件。因此,你可能在其他的例子中看到参数设置为/usr/local
或者其它目录。
大多数的其它参数(除了—with-ssl
)都是都拷贝自上游对curl包的请输入链接描述(http://git.alpinelinux.org/cgit/aports/tree/main/curl/APKBUILD)APKBUILD文件。由于Alpine的包维护者比较可靠,因此我决定复用这些已经存在的配置。如果我对这么做感到太鲁莽,那么我将会深入进去,然后从底层的角度来决定哪些我需要,哪些不需要,但是我还是希望它们包含UNIX套接字和IPV6的支持,因此我保留了这些已存在的配置。
cd / && \ rm -r curl-$CURL_VERSION && \ rm -r /var/cache/apk && \ rm -r /usr/share/man && \ apk del curldeps
以上全都是清除工作。
保留构建目录(也就是二进制文件被安装的地方),去除源代码目录,运行apk del curldepsenter code here
命令来清除我们之前创建的虚拟包,接下来再去除/var/cache/apk
(这是包缓存,老实说,我也不清楚为什么使用了—no-cache
选项,缓存依旧存在)和/usr/share/man
目录(帮助手册,在man命令没有被安装的情况下,这是无用的)。其中一些清除操作,尤其是缓存和帮助页面的清除,某种程度上可以说是对缩小镜像体积的一种怪癖,毕竟它们实际上不会超过1MB。这些都是我通过运行du | sort -n
后,认为在最终镜像中可能不必要的内容,我只能说,我狂热地追求尽可能地缩小镜像体积。
由于以上的这些操作都属于同一个RUN命令,因此这最终会产生一个相对小的镜像层,尽管在命令最开始的时候,我们为了构建最终的产品,安装了将近212MB的依赖。如果这些操作分布在不同的层,清除操作实际上不会真正地在最终镜像上删除这些文件,相反,只是将这些文件隐藏了起来。
最后一条:
CMD ["curl"]
docker run image
命令将会默认调用curl
命令。当然这也能够替换为ENTRYPOINT
,但是我并不介意CMD
能够简单地通过docker run
被重新赋值。
构建并且运行镜像
首先是构建,将Dockerfile
丢进一个空目录下,然后在这个目录下运行:
$ docker build -t yourname/curl .
一旦构建完镜像,运行镜像就显得非常直接了。让我们来检查看看一切是否按照nghttp2.org上描述的那样工作。-s
表示启动安静模式,--http2
表示使用HTTP2协议,-I
能够返回请求头,以此验证我们使用了正确的协议。
$ docker run yourname/curl curl -s --http2 -I https://nghttp2.org HTTP/2 200 date: Sat, 06 Aug 2016 21:47:31 GMT content-type: text/html last-modified: Thu, 21 Jul 2016 14:06:56 GMT etag: "5790d700-19e1" accept-ranges: bytes content-length: 6625 x-backend-header-rtt: 0.00166 strict-transport-security: max-age=31536000 server: nghttpx nghttp2/1.14.0-DEV via: 2 nghttpx x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block x-content-type-options: nosniff
很好,一切正常工作。并且最终的镜像体积保持在16MB左右。这对于私人订制的curl构建来说是不错的,毕竟编译curl需要上百MB的依赖的支持。
结论
Alpine Linux非常棒。
从零构建你自己的工具是难以想象的,但确实令人兴奋。
Docker非常适合于从源代码构建工具。
你能够拥有支持HTTP2的cURL工具。
本文为翻译文章,点击阅读原文链接可查看原文。