本文讲的是支持HTTP2的cURL——基于Alpine的最小化Docker镜像【编者的话】本文详细地描述了如何构建一个支持HTTP2的cURL镜像，并且尽可能地降低镜像的体积。
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.github.io/
：
由于HTTP的危急现状，HTTP/2成为了HTTP的代替品。HTTP/2并不是对HTTP协议的完全重写，HTTP方法，状态码，语义都保留了下来，并且应该能够使用和HTTP/1.x（可能有细微调整）一样的API来表示HTTP/2协议。
HTTP/2协议重点关注性能，尤其是端用户的接收延迟、网络和服务器资源的使用。其中一个主要的目标就是从浏览器访问一个Web网站可以只通过一条连接来实现。
简要地说，HTTP2想要解决HTTP/1.1的一些缺点，包括
性能问题
。通过对前面链接中的样本用例进行测试，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包的
请输入链接描述
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 curldeps
enter 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工具。
原文链接：cURL with HTTP2 Support - A Minimal Alpine-based Docker Image（翻译：杨润青）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译者介绍
杨润青，90后博士僧，研究方向是网络和信息安全。
原文发布时间为：2016-08-26
本文作者：2016-08-26
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：支持HTTP2的cURL——基于Alpine的最小化Docker镜像
