支持HTTP2的cURL——基于Alpine的最小化Docker镜像

wiborgite 2016-09-15

展开全文

cURL（https://curl./）是我喜欢的开源软件之一。虽然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./：

由于HTTP的危急现状，HTTP/2成为了HTTP的代替品。HTTP/2并不是对HTTP协议的完全重写，HTTP方法，状态码，语义都保留了下来，并且应该能够使用和HTTP/1.x（可能有细微调整）一样的API来表示HTTP/2协议。
HTTP/2协议重点关注性能，尤其是端用户的接收延迟、网络和服务器资源的使用。其中一个主要的目标就是从浏览器访问一个Web网站可以只通过一条连接来实现。

简要地说，HTTP2想要解决HTTP/1.1的一些缺点，包括性能问题（https://www./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./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./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./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./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./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 .

一旦构建完镜像，运行镜像就显得非常直接了。让我们来检查看看一切是否按照上描述的那样工作。-s表示启动安静模式，--http2表示使用HTTP2协议，-I能够返回请求头，以此验证我们使用了正确的协议。

$ docker run yourname/curl curl -s --http2 -I https:// 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的依赖的支持。

结论