2017年十二月月 发布的文章

TB一周萃选[第3期]

本文是首发于个人微信公众号的文章“TB一周萃选[第3期]”的归档。

img{512x368}

 《岁旦》

   宋伯仁 宋代诗人

  居间无贺客,早起只如常。桃版随人换,梅花隔岁香。
  春风回笑语,云气卜丰穰。柏酒何劳劝,心平寿自长。

本期萃选是2017年的最后一期,也是迎接2018新年“承前启后”的一期。

对于现代中国人来说,公历新年又称为“元旦”。但稍有些历史常识的朋友都会知道:此“元旦”与中国古时的那个“元旦”有所不同。古代中国人把农历大年初一称为元旦,传说古时“元旦”在距今4000多年前“尧舜禹”的时候就已经有了。1911年辛亥革命成功后,当时孙中山领导的国民政府把农历的大年初一称春节,把公历1月1日称元旦,这就是现在元旦的由来。现代中国的元旦,在世界更广的范围内被更多称为“新年”,是全世界人们的一个共同的节日。在这样的一个节日里,人们家庭团聚,亲友重逢,倾诉过往,憧憬新年,祈求平安。

节日,似乎是群居生物的一种典型的行为表现形式,动物有之(可能是以我们无法理解的形式),人类也在进化的几十万年(又或更长的时间)内设定了大大小小的各种节日。这是作为群居动物的人类的一个重要需求,是进化数十万年后依然保留的最古老的基因所表现出的行为倾向。人类通过“节日”来“蓄力”,以迎接新的挑战!不同的是,古代人类挑战的是凶恶的生存环境,现代人类抗争的是现代生活无形的“生活压力”。

不过,人类从来没有屈服于困难!近期火热的电影《芳华》向我们直观生动地阐释了这一点,让我们更加明白生活的真谛,珍惜与家人、爱人、朋友在一起的时光,享受现在的生活,乐观的面对人生。

img{512x368}

一、一周文章精粹

1. Go初学者的类型系统入门

对于Go初学者而言,尤其是对那些从OO语言转到Go的开发者,在他们大脑中根深蒂固的OO type hierachy不见了,这让他们似乎一下子失去了着力点或抓手。原Go core team成员JBD撰文阐述了Go类型系统的特点,诸如:流程优先、嵌入不是继承、多态、没有构造函数、没有范型等。

原文链接:《The Go type system for newcomers》

2. Go反射详解

Go语言提供了反射(reflect)特性,在标准库中很多常见功能都是用反射实现的,比如:encoding/json、fmt包的Println系列等。但日常编程中,直接使用reflect包的场合并不多。reflect为Go程序员提供了一种在运行时 “陷入” 的机制,使得Go程序具备了直接操作runtime中类型元数据的能力以及在运行时凭空“制造”变量的能力,因此reflect操作是比较“危险”的。

Sidhartha Mani的“Go反射详解”分为两个part,part1主要讲解type与kind的区别、基于reflect包的type和value进行Go原生类型变量的构造和值的析出;part2则是针对复合类型,比如数组、map、struct等类型变量的构造和值的析出进行讲解,思路十分清晰。

原文链接:

《Go Reflection: Creating Objects from Types — Part I (Primitive Types)》
《Go Reflection: Creating Objects from Types — Part II (Composite Types)》

3. 现代网络负载均衡和代理指南

lyft的envoy工程师撰文对高可用分布式网络中的负载均衡和反向代理做了详尽的科普性讲解,内容包含:lb与proxy的区别、L4 lb、L7 lb、lb特性分析、lb的拓扑类型、当前L4-lb技术、L7-lb技术现状的情况、全局lb和集中控制平面等。强烈推荐阅读!

原文链接:《Introduction to modern network load balancing and proxying》

img{512x368}

4. Go编译器内幕

这是由国内一位就职于ARM公司的开发者在Go dev group上发的topic,这位开发者将自己学习和整理了Go compiler的原理(主要针对ARM平台)放在了一篇slide中,并在Go core team的反馈下,对他的slide进行了修正和优化。这份资料对于想深入了解Go compiler的朋友可能是大有裨益的。

原文链接:“Golang Compiler Internals for arm64″

5. 年度盘点2017之Service Mesh:群雄逐鹿烽烟起

在Kubecon&CloudNativeCon 2017上大放异彩后,Service Mesh在国内已经渐入火热阶段。Service Mesh的著名Advocator:数人云的架构师敖小剑年终前发了此文,对service mesh的发展历史、来龙去脉、各方开源项目和厂商势力分析以及未来发展做了回顾和展望。如果你还不知道什么是service mesh,那借此文赶紧上车吧:)

原文链接:“年度盘点2017之Service Mesh:群雄逐鹿烽烟起”

二、一周资料分享

1. Microservice’ing like a unicorn with kubernetes, envoy, and istio

随着传播渠道多元化和传播速度的加快,新技术“火”的速度也变得以前所未有。以Service Mesh概念为例(参考了 “年度盘点2017之Service Mesh:群雄逐鹿烽烟起”):

  • 2016 年 9 月 29 日在 SF Microservices 上,“Service Mesh”这个词汇第一次在公开场合被使用。这标志着“Service Mesh”这个词,从 Buoyant 公司走向社区。
  • 2017 年 4 月 25 日,William Morgan 发布博文“What’s a service mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。
  • 2017 年 5 月 24 日,Istio 0.1 release 版本发布,Google 和 IBM 高调宣讲,社区反响热烈,很多公司在这时就纷纷站队表示支持 Istio。

istio的正式发布,成为了service mesh的一个重要里程碑事件。谁能否认istio不是另一个Google内部技术的开源版本呢,就好比当年Kubernetes的开源。微服务框架走向统一的service mesh似乎成了大势所趋的趋势。无论国内外,对service mesh的研究、开发和试验,甚至是商用都在如火如荼地进行当中。

Redhat架构师Christian Posta近日在自己的博客上放出一份正在构建中的资料:Microservice’ing like a unicorn with kubernetes, envoy, and istio,对envoy和istio的原理与使用进行案例式的详尽说明,同时配有对应的示例源码。对于希望学习service mesh技术的朋友们,这是一份不可多得的资料。

资料分享链接:Microservice’ing like a unicorn with kubernetes, envoy, and istio

img{512x368}

三、一周工具推荐

1. mdp

今天给大家推荐一个比较有Geek赶脚的present工具:mdp

mdp是一款文稿演示工具,与go present工具有些类似,都是以一种类markdown格式的文档作为输入。不同之处,后者是将演示文稿渲染到浏览器中,而mdp工具则是将文稿渲染到terminal中,效果参见下面图示:

img{512x368}

mdp支持标准markdown语法,同时也支持通过一些扩展语法实现的特定渲染效果。mdp同时支持一些快捷键控制命令,比如:h,j,k,l组合的翻页控制等。在Mac上可使用brew工具来install mdp,在其他平台可以通过下载源码并自行编译的方式安装。

工具链接:mdp

四、一周图书推荐

笔者认为人类正在构建支撑未来20-30年支撑人类社会发展的IT技术“有机生命体”,包括:

  • 能量系统(类比于细胞化学反应,提供计算能量) – IT基础设施(云计算、vm、k8s、container)、Cloud Native技术框架:microservice 、service mesh(服务治理网络) 、serverless等。
  • 神经通道 – 基础高速互联网、移动网络、区块链(信用网络)
  • 大脑 – 人工智能、数据与智能算法
  • 肢体与感知 – 机器人、智能交通工具(比如:无人汽车等)、智能硬件、Iot等。

其中区块链技术作为未来社会信用网络的重要基础,IT技术人员都应该认真学习。本期我就推荐一本有关区块链技术的开源书:yesky的《区块链开发指南》。这是一本关于区块链技术的较为系统的开源书。该书探索了区块链概念的来龙去脉,剥茧抽丝,剖析关键技术原理、典型应用场景、分布式系统核心问题,同时讲解了区块链技术的三大典型应用:比特币、以太坊Hyperledger超级账本以及相关应用的开发入门。

开源书链接:《区块链开发指南》
商业纸板图书链接:《区块链原理、设计与应用》


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

TB一周萃选[第2期]

本文是首发于个人微信公众号的文章TB一周萃选[第2期]的归档。

img{512x368}
封面

“我天性不宜交际。

在多数场合,我不是觉得对方乏味,就是害怕对方觉得我乏味。可是我既不愿忍受对方的乏味,也不愿费劲使自己显得有趣,那都太累了。

我独处时最轻松,因为我不觉得自己乏味,即使乏味,也自己承受,不累及他人,无需感到不安。” ——周国平

本周日晚上就是平安夜了!

圣诞节,是西方最重要的节日之一,也是一个公历纪年的最后一个节日。对于中华大地的人们来说,圣诞节这个洋节日影响力倒不是那么大,不过它却是一个重要的日子,它提醒着大家:这一年要结束了!该总结的总结,该计划的也要开始计划了

img{512x368}

圣诞节是一个美丽的节日。在西方,绿色的挂满彩饰的圣诞树、创意十足的圣诞贺卡、白胡子红袍子的慈祥的圣诞老人、装满礼物的圣诞袜以及美味的圣诞大餐构成了圣诞节永恒不变的节日主题。不过中国人的过法与西方完全不同,尤其是年轻人。他们喜欢成双成对地在商业街以休闲购物的方式过圣诞节,这不仅是商业元素的引导,可能也是荷尔蒙的需要。对于渐渐步入中年的我而言,家庭的分量更重。守在孩子和老婆身边,更能带来心灵上的温暖。

img{512x368}

一、一周文章精粹

1、七牛CEO许式伟:”我与Go语言的这十年”

许式伟是大中华地区Go首席布道者(至少,我还不知道谁使用Go和大力推广Go早过许总^_^),并且身体力行、率先垂范地在自己的项目中、在自己的公司产品全面使用Go技术栈。在这篇文章中,许总回顾了Go语言10年来的成长以及他个人使用和推广Go语言的历程。许总对Go有着深刻的理解和洞察力,在这篇文章的结尾处许总再次给出了自己对Go语言未来十年的预测,这里笔者表示不能同意再多了^0^。这里将一段文字摘录如下:

下一个十年会怎样?我知道有一些人很期望 Go 语言特性的迭代。但是如果你抱有这种想法可能会失望,因为下一个十年 Go 不会发生太大的变化。对远期需求变化的预测和把控能力,是 Go 的最大魅力之一。这一点上能够和 Go 相比的是 C 语言(C 语言不同版本的规范差异极少),但因为 Go 要解决的问题更多,做到这一点实际上也更难。下一个十年 Go 仍然会继续深耕服务端开发的生态,同时积极探索其他潜在的应用市场。

原文链接:“我与Go语言的这十年”

img{512x368}
图:Go语言的十年

2、追求极简:Docker镜像构建演化史

这是笔者在CSDN《程序员杂志》2017.12上投稿的一篇文章。这两年容器技术飞速发展,除了Docker之外,又有Rktkata container等容器引擎或runtime的出现。但Docker依然是容器领域使用最为广泛的主流技术。对于已经接纳和使用Docker技术在日常开发工作中的开发者而言,构建Docker镜像已经是家常便饭。但如何更高效地构建以及构建出Size更小的镜像却是很多Docker技术初学者心中常见的疑问,甚至是一些老手都未曾细致考量过的问题。这篇文章将从一个Docker用户角度来阐述Docker镜像构建的演化史,希望能起到一定的解惑作用。

原文链接:“Docker镜像构建演化史”

img{512x368}

3、Service Mesh时代的选边与站队

2017年KubeCon&CloudNativeCon Austin大会上,作为代表下一代微服务解决方案设计理念的Service Mesh成为“热词”而被众人追捧。国内的ServiceMesh也是刚刚起步,方兴未艾。这篇“Service Mesh时代的选边与站队 ”就是发表在国内ServiceMesh社区上的一篇文章。文章脉络大致如下:

  • Service Mesh的地位与生态格局
  • 大公司间关于Service Mesh的布局与斗争策略
  • istio尚未发布1.0时,最早提出Service Mesh概念的小公司buoyant的努力喘息
  • Service Mesh的2018

原文链接:“Service Mesh 时代的选边与站队”

img{512x368}

img{512x368}

4、全文检索数据库Bleve简介

去年年末在做一个全文检索查询功能时曾用过陈辉的wukong引擎,不过wukong引擎由于作者的日理万机,无闲打理,已经不再维护。而在Go语言实现的全文检索工具领域,国外社区更流行的是Bleve。这篇文章介绍了作者所在公司为何用bleve替换solr,并对bleve中概念、使用方法进行了介绍,算是Bleve的入门文章。不过对于中文分词和全文检索的支持好坏,还需验证。

原文链接:“Go实现的全文检索数据库Bleve简介”

5、十年专业写博经验谈

Andrew Chen是硅谷的一位企业家,创业顾问,“Growth Hacker is the new VP of Marketing”一文作者,目前就职于uber。他还是一位拥有10年写博经验的博主。在“十年专业写博经验谈”一文中,他总结了10年来写博的经验教训,并逐条给出详细的亲历讲解。

原文链接:“10 years of professional blogging – what I’ve learned”

6、Go数据科学Data Sheet

Go语言在数据科学领域算得上是一个年轻,但却极具潜力的选手。近一年来,Go语言在大数据领域已经有了gonumgorgonia等用于数值计算和数据分析的library。gorgonia项目的作者Chewxy这篇”Data Science In Go: A Cheat Sheet”就是使用gonum和gorgonia进行数据科学计算和统计计算的速查手册。

原文链接:“Data Science In Go: A Cheat Sheet”

img{512x368}

二、一周资料分享

Go正式发布8年后,市面上关于Go语言入门的书籍和课程资料已经出现很多了,无论免费的还是收费。和其他语言的技术资料一样,很多资料质量良莠不齐。hackr.io针对Go语言的教程发起了社区投票,在这里我们可以看到社区对这些资料的质量甄别,同时这也是一份很好的Go书籍资料集合。这个投票是open的,你也可以提交list上尚没有的gobook,并根据你的阅读体验贡献你的vote。

原文地址:“Best Community up-voted Go programming resources”

三、一周工具推荐

1、135editor

之前将blog内容同步到微信公众号的时候,多为简单的复制粘贴,导致很多朋友抱怨公众号文章格式太粗糙,尤其是贴代码部分。自从有了做“TB一周萃选”这个weekly issue后,我就在市面上搜寻好用的微信公号文章编辑器。之前用的是微信编辑器(www.wxbj.cn),简洁易用。但不知何故,该站点现在似乎变成了“易企秀”。于是我将编辑器换成了135editor,这个似乎更加强大,就是左栏下方的广告推广多了一些。

135editor还支持在绑定公众号后的素材库同步,省了一步copy的动作。

四、一周书籍推荐

1、Kubernetes Handbook

Kubernetes赢得了与mesos、docker swarm的关于容器管理和服务编排引擎的“战争”,成为这个领域当之无愧的领头羊。越来越多的公司开始试用Kubernetes,这里推荐一个有关于Kubernetes的开源书《Kubernetes Handbook》,是由talkingdata的jimmy song编写整理的。该书的最大特点就是全面,从K8s的基本概念、运维手段到k8s的领域应用,并且有详细的实践操作讲解。

书籍链接:《Kubernetes Handbook》


我的联系方式:

微博:http://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

追求极简:Docker镜像构建演化史

本文首发于CSDN《程序员》杂志2017.12期,这里是原文地址

本文为《程序员》杂志授权转载,谢绝其他转载。全文如下:

自从2013年dotCloud公司(现已改名为Docker Inc)发布Docker容器技术以来,到目前为止已经有四年多的时间了。这期间Docker技术飞速发展,并催生出一个生机勃勃的、以轻量级容器技术为基础的庞大的容器平台生态圈。作为Docker三大核心技术之一的镜像技术在Docker的快速发展之路上可谓功不可没:镜像让容器真正插上了翅膀,实现了容器自身的重用和标准化传播,使得开发、交付、运维流水线上的各个角色真正围绕同一交付物,“test what you write, ship what you test”成为现实。

对于已经接纳和使用Docker技术在日常开发工作中的开发者而言,构建Docker镜像已经是家常便饭。但如何更高效地构建以及构建出Size更小的镜像却是很多Docker技术初学者心中常见的疑问,甚至是一些老手都未曾细致考量过的问题。本文将从一个Docker用户角度来阐述Docker镜像构建的演化史,希望能起到一定的解惑作用。

一、镜像:继承中的创新

谈镜像构建之前,我们先来简要说下镜像

Docker技术本质上并不是新技术,而是将已有技术进行了更好地整合和包装。内核容器技术以一种完整形态最早出现在Sun公司Solaris操作系统上,Solaris是当时最先进的服务器操作系统。2005年Sun发布了Solaris Container技术,从此开启了内核容器之门。

2008年,以Google公司开发人员为主导实现的Linux Container(即LXC)功能在被merge到Linux内核中。LXC是一种内核级虚拟化技术,主要基于NamespacesCgroups技术,实现共享一个操作系统内核前提下的进程资源隔离,为进程提供独立的虚拟执行环境,这样的一个虚拟的执行环境就是一个容器。本质上说,LXC容器与现在的Docker所提供容器是一样的。Docker也是基于Namespaces和Cgroups技术之上实现的,Docker的创新之处在于其基于Union File System技术定义了一套容器打包规范,真正将容器中的应用及其运行的所有依赖都封装到一种特定格式的文件中去,而这种文件就被称为镜像(即image),原理见下图(引自Docker官网):

img{512x368}
图1:Docker镜像原理

镜像是容器的“序列化”标准,这一创新为容器的存储、重用和传输奠定了基础。并且“坐上了巨轮”的容器镜像可以传播到世界每一个角落,这无疑助力了容器技术的飞速发展。

Solaris Container、LXC等早期内核容器技术不同,Docker为开发者提供了开发者体验良好的工具集,这其中就包括了用于镜像构建的Dockerfile以及一种用于编写Dockerfile领域特定语言。采用Dockerfile方式构建成为镜像构建的标准方法,其可重复、可自动化、可维护以及分层精确控制等特点是采用传统采用docker commit命令提交的镜像所不能比拟的。

二、“镜像是个筐”:初学者的认知

“镜像是个筐,什么都往里面装” – 这句俏皮话可能是大部分Docker初学者对镜像最初认知的真实写照。这里我们用一个例子来生动地展示一下。我们将httpserver.go这个源文件编译为httpd程序并通过镜像发布,考虑到被编译的源码并非本文重点,这里使用了一个极简的demo代码:

//httpserver.go

package main

import (
        "fmt"
        "net/http"
)

func main() {
        fmt.Println("http daemon start")
        fmt.Println("  -> listen on port:8080")
        http.ListenAndServe(":8080", nil)
}

接下来,我们来编写一个用于构建目标image的Dockerfile:

From ubuntu:14.04

RUN apt-get update \
      && apt-get install -y software-properties-common \
      && add-apt-repository ppa:gophers/archive \
      && apt-get update \
      && apt-get install -y golang-1.9-go \
                            git \
      && rm -rf /var/lib/apt/lists/*

ENV GOPATH /root/go
ENV GOROOT /usr/lib/go-1.9
ENV PATH="/usr/lib/go-1.9/bin:${PATH}"

COPY ./httpserver.go /root/httpserver.go
RUN go build -o /root/httpd /root/httpserver.go \
      && chmod +x /root/httpd

WORKDIR /root
ENTRYPOINT ["/root/httpd"]

构建这个Image:

# docker build -t repodemo/httpd:latest .
//...构建输出这里省略...

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
repodemo/httpd                   latest              183dbef8eba6        2 minutes ago       550MB
ubuntu                           14.04               dea1945146b9        2 months ago        188MB

整个镜像的构建过程因环境而定。如果您的网络速度一般,这个构建过程可能会花费你10多分钟甚至更多。最终如我们所愿,基于repodemo/httpd:latest这个镜像的容器可以正常运行:

# docker run repodemo/httpd
http daemon start
  -> listen on port:8080

一个Dockerfile最终生产出一个镜像。Dockerfile由若干Command组成,每个Command执行结果都会单独形成一个layer。我们来探索一下构建出来的镜像:

# docker history 183dbef8eba6
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
183dbef8eba6        21 minutes ago      /bin/sh -c #(nop)  ENTRYPOINT ["/root/httpd"]   0B
27aa721c6f6b        21 minutes ago      /bin/sh -c #(nop) WORKDIR /root                 0B
a9d968c704f7        21 minutes ago      /bin/sh -c go build -o /root/httpd /root/h...   6.14MB
... ...
aef7700a9036        30 minutes ago      /bin/sh -c apt-get update       && apt-get...   356MB
.... ...
<missing>           2 months ago        /bin/sh -c #(nop) ADD file:8f997234193c2f5...   188MB

我们去除掉那些Size为0或很小的layer,我们看到三个size占比较大的layer,见下图:

img{512x368}
图2:Docker镜像分层探索

虽然Docker引擎利用r缓存机制可以让同主机下非首次的镜像构建执行得很快,但是在Docker技术热情催化下的这种构建思路让docker镜像在存储和传输方面的优势荡然无存,要知道一个ubuntu-server 16.04的虚拟机ISO文件的大小也就不过600多MB而已。

三、”理性的回归”:builder模式的崛起

Docker使用者在新技术接触初期的热情“冷却”之后迎来了“理性的回归”。根据上面分层镜像的图示,我们发现最终镜像中包含构建环境是多余的,我们只需要在最终镜像中包含足够支撑httpd运行的运行环境即可,而base image自身就可以满足。于是我们应该去除不必要的中间层:

img{512x368}
图3:去除不必要的分层

现在问题来了!如果不在同一镜像中完成应用构建,那么在哪里、由谁来构建应用呢?至少有两种方法:

  1. 在本地构建并COPY到镜像中;
  2. 借助构建者镜像(builder image)构建。

不过方法1本地构建有很多局限性,比如:本地环境无法复用、无法很好融入持续集成/持续交付流水线等。借助builder image进行构建已经成为Docker社区的一个最佳实践,Docker官方为此也推出了各种主流编程语言的官方base image,比如:gojava、node、python以及ruby等。借助builder image进行镜像构建的流程原理如下图:

img{512x368}
图4:借助builder image进行镜像构建的流程图

通过原理图,我们可以看到整个目标镜像的构建被分为了两个阶段:

  1. 第一阶段:构建负责编译源码的构建者镜像;
  2. 第二阶段:将第一阶段的输出作为输入,构建出最终的目标镜像。

我们选择golang:1.9.2作为builder base image,构建者镜像的Dockerfile.build如下:

// Dockerfile.build

FROM golang:1.9.2

WORKDIR /go/src
COPY ./httpserver.go .

RUN go build -o httpd ./httpserver.go

执行构建:

# docker build -t repodemo/httpd-builder:latest -f Dockerfile.build .

构建好的应用程序httpd放在了镜像repodemo/httpd-builder中的/go/src目录下,我们需要一些“胶水”命令来连接两个构建阶段,这些命令将httpd从构建者镜像中取出并作为下一阶段构建的输入:

# docker create --name extract-httpserver repodemo/httpd-builder
# docker cp extract-httpserver:/go/src/httpd ./httpd
# docker rm -f extract-httpserver
# docker rmi repodemo/httpd-builder

通过上面的命令,我们将编译好的httpd程序拷贝到了本地。下面是目标镜像的Dockerfile:

//Dockerfile.target
From ubuntu:14.04

COPY ./httpd /root/httpd
RUN chmod +x /root/httpd

WORKDIR /root
ENTRYPOINT ["/root/httpd"]

接下来我们来构建目标镜像:

# docker build -t repodemo/httpd:latest -f Dockerfile.target .

我们来看看这个镜像的“体格”:

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
repodemo/httpd                   latest              e3d009d6e919        12 seconds ago      200MB

200MB!目标镜像的Size降为原来的 1/2 还多。

四、“像赛车那样减去所有不必要的东西”:追求最小镜像

前面我们构建出的镜像的Size已经缩小到200MB,但这还不够。200MB的“体格”在我们的网络环境下缓存和传输仍然很难令人满意。我们要为镜像进一步减重,减到尽可能的小,就像赛车那样,为了能减轻重量将所有不必要的东西都拆除掉:我们仅保留能支撑我们的应用运行的必要库、命令,其余的一律不纳入目标镜像。当然不仅仅是Size上的原因,小镜像还有额外的好处,比如:内存占用小,启动速度快,更加高效;不会因其他不必要的工具、库的漏洞而被攻击,减少了“攻击面”,更加安全。

img{512x368}
图5:目标镜像还能更小些吗?

一般应用开发者不会从scratch镜像从头构建自己的base image以及目标镜像的,开发者会挑选适合的base image。一些“蝇量级”甚至是“草量级”的官方base image的出现为这种情况提供了条件。

img{512x368}
图6:一些base image的Size比较(来自imagelayers.io截图)

从图中看,我们有两个选择:busyboxalpine

单从image的size上来说,busybox更小。不过busybox默认的libc实现是uClibc,而我们通常运行环境使用的libc实现都是glibc,因此我们要么选择静态编译程序,要么使用busybox:glibc镜像作为base image。

而 alpine image 是另外一种蝇量级 base image,它使用了比 glibc 更小更安全的 musl libc 库。 不过和 busybox image 相比,alpine image 体积还是略大。除了因为 musl比uClibc 大一些之外,alpine还在镜像中添加了自己的包管理系统apk,开发者可以使用apk在基于alpine的镜像中添 加需要的包或工具。因此,对于普通开发者而言,alpine image显然是更佳的选择。不过alpine使用的libc实现为musl,与基于glibc上编译出来的应用程序不兼容。如果直接将前面构建出的httpd应用塞入alpine,在容器启动时会遇到下面错误,因为加载器找不到glibc这个动态共享库文件:

standard_init_linux.go:185: exec user process caused "no such file or directory"

对于Go应用来说,我们可以采用静态编译的程序,但一旦采用静态编译,也就意味着我们将失去一些libc提供的原生能力,比如:在linux上,你无法使用系统提供的DNS解析能力,只能使用Go自实现的DNS解析器。

我们还可以采用基于alpine的builder image,golang base image就提供了alpine 版本。 我们就用这种方式构建出一个基于alpine base image的极小目标镜像。

img{512x368}
图7:借助 alpine builder image 进行镜像构建的流程图

我们新建两个用于 alpine 版本目标镜像构建的 Dockerfile:Dockerfile.build.alpine 和Dockerfile.target.alpine:

//Dockerfile.build.alpine
FROM golang:alpine

WORKDIR /go/src
COPY ./httpserver.go .

RUN go build -o httpd ./httpserver.go

// Dockerfile.target.alpine
From alpine

COPY ./httpd /root/httpd
RUN chmod +x /root/httpd

WORKDIR /root
ENTRYPOINT ["/root/httpd"]

构建builder镜像:

#  docker build -t repodemo/httpd-alpine-builder:latest -f Dockerfile.build.alpine .

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED              SIZE
repodemo/httpd-alpine-builder    latest              d5b5f8813d77        About a minute ago   275MB

执行“胶水”命令:

# docker create --name extract-httpserver repodemo/httpd-alpine-builder
# docker cp extract-httpserver:/go/src/httpd ./httpd
# docker rm -f extract-httpserver
# docker rmi repodemo/httpd-alpine-builder

构建目标镜像:

# docker build -t repodemo/httpd-alpine -f Dockerfile.target.alpine .

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
repodemo/httpd-alpine            latest              895de7f785dd        13 seconds ago      16.2MB

16.2MB!目标镜像的Size降为不到原来的十分之一。我们得到了预期的结果。

五、“要有光,于是便有了光”:对多阶段构建的支持

至此,虽然我们实现了目标Image的最小化,但是整个构建过程却是十分繁琐,我们需要准备两个Dockerfile、需要准备“胶水”命令、需要清理中间产物等。作为Docker用户,我们希望用一个Dockerfile就能解决所有问题,于是就有了Docker引擎对多阶段构建(multi-stage build)的支持。注意:这个特性非常新,只有Docker 17.05.0-ce及以后的版本才能支持。

现在我们就按照“多阶段构建”的语法将上面的Dockerfile.build.alpine和Dockerfile.target.alpine合并到一个Dockerfile中:

//Dockerfile

FROM golang:alpine as builder

WORKDIR /go/src
COPY httpserver.go .

RUN go build -o httpd ./httpserver.go

From alpine:latest

WORKDIR /root/
COPY --from=builder /go/src/httpd .
RUN chmod +x /root/httpd

ENTRYPOINT ["/root/httpd"]

Dockerfile的语法还是很简明和易理解的。即使是你第一次看到这个语法也能大致猜出六成含义。与之前Dockefile最大的不同在于在支持多阶段构建的Dockerfile中我们可以写多个“From baseimage”的语句了,每个From语句开启一个构建阶段,并且可以通过“as”语法为此阶段构建命名(比如这里的builder)。我们还可以通过COPY命令在两个阶段构建产物之间传递数据,比如这里传递的httpd应用,这个工作之前我们是使用“胶水”代码完成的。

构建目标镜像:

# docker build -t repodemo/httpd-multi-stage .

# docker images
REPOSITORY                       TAG                 IMAGE ID            CREATED             SIZE
repodemo/httpd-multi-stage       latest              35e494aa5c6f        2 minutes ago       16.2MB

我们看到通过多阶段构建特性构建的Docker Image与我们之前通过builder模式构建的镜像在效果上是等价的。

六、来到现实

沿着时间的轨迹,Docker 镜像构建走到了今天。追求又快又小的镜像已成为了 Docker 社区 的共识。社区在自创 builder 镜像构建的最佳实践后终于迎来了多阶段构建这柄利器,从此构建 出极简的镜像将不再困难。


微博:@tonybai_cn
微信公众号:iamtonybai
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多