分类 观点 下的文章

你问我相信什么样的事情?我们相信云计算是长远的。

去年,作为《穿山甲专访》系列采访之一,我们曾经给大家分享过 UCloud 技术副总裁杨镭先生的访谈。那是我和杨镭先生的第一次见面,虽然采访时间不长,但是他务实严谨的风格,也给我留下了深刻的印象。因此,这次又特意预约了他的时间,专程去上海和他深入地聊了一些过去七年 UCloud 的技术价值观理念,并与这位从一线运维跌打滚爬出身的技术领袖的所思所想产生了深切的共鸣。

作为采访者,我也是一位做了二十多年互联网技术工作的老兵,虽然在私交上我和杨镭并不算熟悉,但是随着在互联网、技术和开源方面话题的展开,我们很快就聊得十分投机。

【图:现场采访图】

第一章 一位技术人员的成长史

话题是先从杨镭先生的技术背景和从业经历展开的。

老王:是否可以请先介绍一下你之前的技术背景和你的从业方面的情况?

杨镭:我结合 UCloud 整个技术发展的情况和我自己的情况跟你讲一下。

我的背景是这样的,我 2006 年加入盛大在线,刚入职时我是从最一线的运维人员开始做的,大概两年多以后逐渐地开始参加一些研发的工作,做一些运维的平台系统开发工作。

我跟老季(UCloud CEO 季昕华)是大概 2008 年认识的,他当时在管盛大在线。盛大在线提供运维平台来支撑各个游戏部门的业务,包括像盛大创新院的服务器,其实背后都是由盛大在线提供运维的。在之后做盛大云时,我们承接了非常多的业务部门的运维工作,而当时我就是在做平台技术方面的工作。

那时包括 OpenStack 才刚刚出现,AWS在国内刚被知晓,而我们那时候自己最早做虚拟化都是通过 VMWare 来做的。我们一直在关注云计算的发展。在 2011 年底,老季出来创业时,问我有没有兴趣出来,我就出来了。

我们当时认为,运维应该走到一线去产生业务价值,而云计算正好是可以让做运维、做技术的人能做产品的一个技术。云计算说白了是把以前运维的东西放在台前了,可以去赚钱了。

?从一封未发出的邮件说起…

杨镭:当时我离开盛大的时候,写了一封邮件,但邮件我没发出去,一直存在我的草稿箱里,现在还在。其实我对盛大也是挺有感情的,整个平台都是我们一手搭建的,做了很多很多的事情,还是很辛苦的。

那封信大概的意思是说,云计算真的能解决很多问题,它能让服务器弹性地、不用关机去升级内存和 CPU……还有很多充满想象力的事情,其实这也是 UCloud 的初衷,是我们出来创业的初心,包括老季在内,其实也是这样的,在那个时候我们每次出问题,他都知道,可能是哪个机房的网线插反了,或者哪个服务器配置不小心没搞对,就像蝴蝶效应一样引发了严重的后果。

那时候出来,我们就是想把云这个事情做好。

践行新技术,到处吃螃蟹

杨镭:因为我不是从研发出身的,当时 UCloud 创业的时候也不容易,我们当时除了三个创始人之外,还有五个研发技术人员。当时所有的运维、开发、底层的一些工作,这些我都参与过。

一开始我是做网络方面的研发,当时懂网络的人比较少,而我是做运维出身的。那时还没有 SDN 的概念,我们开始做云计算的时候,当时主流的虚拟化技术是 Xen,KVM 刚进入视野。我那时候很关心 Linux 内核方面的技术,我认为 KVM 一定是有发展的,所以就建议围绕KVM而不是Xen做底层虚拟化,我们一开始采用的 KVM 就是这样来的,结果在后面就少走了很多的弯路。

我主要的一个工作是虚拟机创建流程,这跟我自己之前的一些运维知识也比较匹配,在这方面我做的很多工作主要是优化。这里面其实有一个云计算产品的精髓,云计算产品如果要做好有两方面:

一方面技术要做好,它的可拓展性、稳定性要好,这是从研发的架构层面来看;另一个方面,你要真正地懂这个产品

比如说云主机,你现在来看很多云计算产品的功能都已经习以为常了,但是 UCloud 一开始做了很多可能现在看起来不同寻常的事情。为什么会做这些事情呢?根本原因在于我们对于运维的理解比较深刻,所以我们敢先做这些功能。比如说当时有一个叫“重装系统”的功能,当时很多云服务商是没有这个功能的——那时候还很早,大约是 2012年的时候——这是我现在回过头来看一开始 UCloud 在那个阶段能冲出来的一个蛮重要的原因。

当时 SDN 也是这样的。在那个时候,很多技术和框架还没有标准的、可以参考的开源实现。比如说做虚拟化,你可以用 KVM 或 Xen 都能做 。因为那个时候我对网络方面一直很感兴趣,我以前主要是做运维,对 IPtables 很熟悉,排查过非常多复杂的现网故障,所以对于IPtables在生产环境中的使用有一定的把握。当时我们就是这样,去 AWS 的 EC2 虚拟机中抓包结合网络上的材料来分析背后的实现方案,然后用最有把握的工具链来实现。我们很快就做了一套自己的 SDN——当时还没有 Open vSwitch,它是 2013 年出来的——而我们当时就很大胆地采用了一个这样的东西。现在你看 UCloud 发布的技术文章、我们把技术实现方式都讲了出去,但是那个时候你只能自己猜和试验。

云计算的问题在于什么呢?它的产品是技术型的,客户用你的产品和服务的时候,你跟客户接触的人员是要懂技术的,尽管我们传统上认为这个事情很多还是商务上、销售上的事情。但是最终你要成就一个优质的客户,因为只有优质的客户,它的业务好,才会更多的买云服务。而优质的客户不光看客户关系的,看的还是你的技术、你的产品和你的人员是不是专业。因为这个原因,所以我后来在整个 UCloud 工作的过程里,不断地在往前走,去做技术支持。那时候我们很重视客户,我去做解决方案架构师,甚至有段时间在事业部参与销售工作,其实是因为被这个问题推着往前走的,包括我现在其实主要的精力也在负责产品以及整体的技术管理这块。

差不多我的技术历程就是这样的,这也是 UCloud 技术这几年发展的一个缩影。

第二章 技术观与价值观

老王:你作为 UCloud 的技术负责人,之前在 TIC 大会上我也听你讲到过 UCloud 的技术价值观的观点,我想了解一下在宏观上、较高层面上你是如何看待云计算技术的发展的,以及这里传达了什么样的价值观?

「能力」——用工程能力解决技术问题

杨镭:接着前面的话题说。尽管在方向上是对的,但是我们还是走了很多小的弯路。我们有一个核心的能力,也是 UCloud 的核心技术能力,就是出现 BUG 或者架构缺陷的时候可以很快地在现网透明地升级解决掉——这实际上是对我们后端的无缝升级能力特别大的挑战。我自己的感受是,一开始讲要这样做时我其实不太相信能做到,但是在第一年,我们就做到了很多这样的事情。

我举个例子,当时我们产品上线以后,做弹性 IP 的实现,一开始很简单,我们搞几台设备,用IPtables实现了弹性IP和内网云主机的映射,放在两台机器上,有故障时候服务自动切换,一切都很美好。但是上线以后就开始发现问题,这两台机器不停地宕机,其实就是出现了 “Kernel Panic”。因为我们一开始只有两台核心网络接入设备,宕机一台就是 50% 的服务不可用,然后客户自然就炸了。但是那时候我们是解决不了这个 “Kernel Panic” 问题的,尽管懂一点内核知识,但是对内核代码层面的问题并不了解,我不知道为什么会发生,虽然我知道肯定是那个方向的问题。

我们搞不定怎么办呢?当时老季和我们 COO 经常在外面和客户解释网络故障的原因,例如中午和客户吃饭,边吃边告诉客户我们出了什么问题,会采取什么样的措施确保不再出现。而在后面,我们做了一件什么事儿呢?我们大概花了 2-3 天的时间,我们把两台集中式的服务器变成分布式的了,因为在物理机上崩溃了之后、服务器就挂了嘛,所以我们把这个服务放到虚拟机里去,每一台物理机上我们放两台。这样比如说到时候这里宕机了,这两台就可以及时切换,而且因为是虚拟机,切换速度很快。我们写了一个自动化地拉起所有服务的脚本。两三天就完成了,就把这个问题救活了。如果当时不解决,可能 UCloud 就挂了。

我们靠这个机制顶了大半年,直到我们的内核负责人来了。最后,发现是什么问题呢?确实是流量带宽控制那里有一个隐藏的 BUG,这个 BUG 其实连 CentOS 都没修复——因为我们用的是 CentOS——它没修复,而我们也搞不定。当时去查找 CentOS 的补丁列表,并没发现有这方面的补丁。到最后是怎么发现的呢?是上游后来发一个修复,但是这个修复 CentOS 一直都没放进来。

你看,这本身是一个非常深入的技术问题,但在创业的时候你不一定能解决,而我们通过架构的优化把它解决掉了,这实际上是 UCloud 从成立第一年开始到现在的一个核心能力。我自己经历过这个事情以后,再遇到什么事情都不怕了。

用架构、用工程能力去解决了一个隐藏很深的技术问题,以成本最小的方法解决问题。

杨镭:这是一种变换的能力。这是整个 UCloud 技术文化所贯穿的一点,先提供一个方案把它解决掉,让我们的服务品质不会降低。而要做到这一点,我觉得最难的是你需要对工程这个事情有深刻的理解。大家都会说工程师很重要、工程能力很重要,但是说实话,就像我开始来到 UCloud 的时候,我也会讲我是工程师,我很自信这一点,但是在我第一年遇到并解决了很多问题以后,我发现自己其实还不太懂。比如说,你看现在最近很火一些知识付费类课程,当我走到那个高度后我跟你说这个事情应该这样,应该那样。但如果你是才进入行业两三年的人,你是听不懂的,你并不知道怎么做,只能知道这句话应该是对的。这句话可能确实是对的,但是在日常工作中,你第一时间是反应不过来的,因为你不会深刻理解这句话。

一开始我们的工程能力就是很强的,因为这个基因来自于创始团队是当时最顶尖的工程团队。云计算天生对稳定的要求特别高,这是非常偏工程化,而这个能力对整个行业的影响是很深远的。

「尝试」——当时胆子真的太大了,走得很前面

杨镭:当时我们遇到的挑战很多,我们一开始第一代用 SDN 白盒交换机的,当时没多想就上了,然后我们遇到了非常多的问题,最早还用过 Open Switch。其实 UCloud 前几年在技术上走的比较靠前,因为我们规模较小,决策更快,而且我们的技术团队胆子也很大,因为对技术团队很自信,对自己的工程能力很自信,所以敢尝试新的技术。比如说在网络层,我们有一套是用的 OVS,还有一套是用白盒交换机,而我们在两套之间还做了无缝地升级。我们的胆子大,所以那时候我们玩的都是新的技术。我还记得我在 2013 年出去做过 SDN 相关的演讲,现在看来当时胆子真的太大了,走得很前面。

那时候大家都知道是趋势,但是到底会怎么发展还没有人敢下定论,就像 Service Mesh 一样,现在绝大多数公司在做研究,在做概念验证,而我们已经在产品环境上跑了,我们走在很前面,有点孤独。

从我自己的角度看,我们那时候技术还是走得很快的。我举一个例子,比如现在有的云服务商要在两个地域之间打通,比如说从北京到香港,一般会告诉你要找第三方的网络供应商帮你打通。而 UCloud 是怎么做的呢?我们在底层有物理专线,用户只要在控制台点一下两边就通了。大概在相当早的时候,我们就提供了两个地域连接打通的功能。现在有的云服务商还需要几天才能为客户打通,而我们只要控制台上点一下,计费之后就通了,两个地域间的虚拟机就全部都互通了。

我记得那时候在这个功能的发布前夕,我们为此做了一整个通宵。在早上 7 点钟的时候,公司有人来上班了,我就在群里发了一条消息,说我们这个搞完了,大家都很激动,虽然现在两个地域之间的云计算服务器连起来是很正常的,但是在那个时候是没有人做的,那时候就感觉很有成就感。

其实好几个 UCloud 早期的研发同事,他们都有类似于跟我一样的事情,只是我当时的领域全部在网络上,而他们的领域在其它的方面。

整个云计算这个事情,它的核心其实是一个技术问题,最终想在这个地方走长远,本质上是要比技术能力的,一不小心就会落后。

我再举一个例子,我们在 2014 年下半年的时候招了第一个做 DPDK 研发的人,那时候我们知道 DPDK 技术发展前景还不错,所以我们招了这个岗位;而到了 2018 年的下半年,如果哪家有云产品而没有 DPDK 技术,你的产品是完全不具备商业竞争力的,你会卖得很贵,性能非常差,而友商会卖得很便宜,性能又很好,这个就是技术的红利。DPDK 的红利,但是如果你当时不投入的话,到现在可能会来不及。这是看三年的,所以我们现在在做 Serverless 方面的工作,投入是比较大的,但是如果我们不投入,可能三年以后或者四五年以后就出局了。

杨镭:我们还做了很多很有意思的事情。比如,很多用户买了云计算的虚拟机以后由于密码不严格被黑掉了,然后就变成肉鸡对外发大量数据包。这个事情很多云服务商的处理是很简单粗暴的,就是把你机器关掉,但客户其实是很受伤的。而我们当时不是这样做的。我们看,它不是对外发包吗?我们在宿主机上打开 TCP 来抓包,比如说 10 秒钟的包——因为不能长抓,长抓的量太大了——把它放到数据库里,然后我们去分析这个 TCP 包的特征、出入的比例,如果只是出站没有入站的话,那就肯定是被利用攻击了嘛。后来我们发现,所有被反射攻击利用的特征都是这样的。我们发现如果符合这个特征,就把这个虚拟机的网络给处理掉——我们会把它的网络给漂走,叫做隔离区,并没有把机器关掉,不会影响其他人,但是他的虚拟机自己还是可以登进去的。我们把这叫做最优选择,但是这个技术上很复杂。

实际上这不是纯技术的问题,这是一个理念,你要懂技术,还要懂业务,还要懂数据分析,还要设计一套东西把它串起来。

我们觉得自豪的一点不是说这个技术很厉害,而是我们的友商没人这样去做。我们做了好几件类似的事情,我们最终带动了行业的发展,客户在 UCloud 里体会到好处以后,他跑到别的云服务商说,你看 UCloud 这样做的,别的云服务商没办法,就被我们反逼提供这样的功能。而且这种功能不是说我们为了超越谁,而是我们自己想出来的。我们自己的研发人员自己关起门来说,对这种事情还是挺自豪,某种意义上我觉得这其实是种创新。

「价值观」——我们相信云计算是长远的

老王:你刚才介绍了 UCloud 的情况,作为技术人员我也觉得很有心向往之的感觉。你觉得目前而言,你们这个四五百人的技术团队的优势主要是在工程能力上还是在你们团队上的技术文化上?

杨镭:从我这个角度,首先这是我们的精髓、文化或者说是技术文化。在这个问题上我们是不允许所谓的不纯粹的。所以在管理上,其实我们对刚才说的这几件事情,我们是要求很高的,如果你新来一个人你在文化上不认同,这个可能不适合你。

还有一方面,我们对整个技术的价值观就像上次我跟你聊的一样,我们会要求很高。我们除了自己不收集,还会帮用户把隐私保护好,告诉用户不要给我们任何的信息,而多数的公司是反过来的。我们大概会在 1 年多后完成大部分云上数据的加密,包括存量的数据。就像我们在去年的 TIC 大会上说的,这里会坚决投入,而且不是一个小的研发投入。因为说白了用户未必自己诉求那么强,很多时候没这个意识。而我们做这个事情因为有很多存量的云主机,几十万台的规模,我们要透明的、不影响性能、安全地放上去,而且密钥还要定期轮换,不能老是一把密钥,但是要轮换的时候又不能影响性能,所以在工程上是有挑战的和有技术深度的。我们做那么多的事情,说白了这就是价值观问题,我们真的对用户的数据安全非常重视。

树立了一个自己的独特价值观,而且为了这个价值观付出了代价、成本。

杨镭:尽管我们现在人不少了,但是我们产品线也很长,我们这点人也是不够的,我们现在做这个事情都在加班做,说白了时间不够,只能花时间解决这种问题。这种事情说白了是在价值观上,你做不做可能没有区别,但是我们认为真正长远地看这个事情是有意义的。眼前不会有太大的得益和收益,但是从长远的趋势看,从我们的信念看,保护隐私、保护数据安全其实是一个所有人都会走向的共同的目标,只是现在还看不到。

所有的这些事情其实都是归纳到一点,你相信什么样的事情?我们相信云计算是长远的。我们跟客户的合作不是做一锤子买卖,我们甚至于对客户都有要求,我们都要做得很优秀,我们要长远看这件事情值不值得做?当然值得做。为什么要看长远?因为我们对自己还是有信心的。其实你的现在是被过去决定的,你现在是为未来做的,所以我们现在在这个层面上想的事情都是三年、五年以后的。现在这些从大势来看,我们做的这些其实都是因为我们前三年做了一些事情,我们坚持了一些事情,因为做了那些事情,我们活了下来了。现在数据隐私这个事情也好,数据安全这个事情也好,或者是很多 Serverless 产品也好,我们相信在那个时代会更重要,所以我们坚持做这个。

第三章 尾声

老王:做这个专访,一方面我们希望看到真正的技术人现在具体做哪些事情。另外一方面我们希望让大家看到有这样的公司在做具体的事情,这些事情会不会对他们产生触动、启发甚至吸引他们去关注或者参与,这是我们希望能进一步做到的东西。

我觉得今天你婉拒了很多采访的邀约而接受我们的专访,我觉得也很荣幸。一方面我们可以持续性地关注你们这边的技术进展,我们把有些可能在你们看来不值得一提,但是在我们看起来可能非常重要或者更有传播和示范意义事件传播给大家。我觉得今天的采访让我确实地了解到了很多我原来没有想到或者没有观察到的地方。

杨镭:我从一个运维人员走到现在,现在做这个事情我才能发现原来是这样的。我觉得我能理解你,因为大家专业不同,我们正好每天在这里做事情,所以就往这个方面想。我希望这篇采访能让大家知道有些事情怎么做更好,只是我们走在了前面一点,我们是这个行业里的人,我们有经验,我们传播出去,这个我很开心,就 OK 了。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二:取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用;穿山甲是珍稀保护动物,宣传公益。

我在 $work 建立了一个基于 Kubernetes 的平台已经快一年了,而且有点像 Kubernetes 的布道者了。真的,我认为这项技术太棒了。然而我并没有对它的运营和维护的困难程度抱过什么幻想。今年早些时候我读了这样的一篇文章,并对其中某些观点深以为然。如果我在一家规模较小的、有 10 到 15 个工程师的公司,假如有人建议管理和维护一批 Kubernetes 集群,那我会感到害怕的,因为它的运维开销太高了!

尽管我现在对 Kubernetes 的一切都很感兴趣,但我仍然对“ 无服务器 Serverless ”计算会消灭运维工程师的说法抱有好奇。这种好奇心主要来源于我希望在未来仍然能有一份有报酬的工作 —— 如果我们前景光明的未来不需要运维工程师,那我得明白到底是怎么回事。我已经在 Lamdba 和Google Cloud Functions 上做了一些实验,结果让我印象十分深刻,但我仍然坚信无服务器解决方案只是解决了一部分问题。

我关注 AWS Fargate 已经有一段时间了,这就是 $work 的开发人员所推崇为“无服务器计算”的东西 —— 主要是因为 Fargate,用它你就可以无需管理底层节点而运行你的 Docker 容器。我想看看它到底意味着什么,所以我开始尝试从头开始在 Fargate 上运行一个应用,看看是否可以成功。这里我对成功的定义是一个与“生产级”应用程序相近的东西,我想应该包含以下内容:

  • 一个在 Fargate 上运行的容器
  • 配置信息以环境变量的形式下推
  • “秘密信息” 不能是明文的
  • 位于负载均衡器之后
  • 有效的 SSL 证书的 TLS 通道

我以“基础设施即代码”的角度来开始整个任务,不遵循默认的 AWS 控制台向导,而是使用 terraform 来定义基础架构。这很可能让整个事情变得复杂,但我想确保任何部署都是可重现的,任何想要遵循此步骤的人都可发现我的结论。

上述所有标准通常都可以通过基于 Kubernetes 的平台使用一些外部的附加组件和插件来实现,所以我确实是以一种比较的心态来处理整个任务的,因为我要将它与我的常用工作流程进行比较。我的主要目标是看看Fargate 有多容易,特别是与 Kubernetes 相比时。结果让我感到非常惊讶。

AWS 是有开销的

我有一个干净的 AWS 账户,并决定从零到部署一个 webapp。与 AWS 中的其它基础设施一样,我必须首先使基本的基础设施正常工作起来,因此我需要先定义一个 VPC。

遵循最佳实践,因此我将这个 VPC 划分为跨可用区(AZ)的子网,一个公共子网和私有子网。这时我想到,只要这种设置基础设施的需求存在,我就能找到一份这种工作。AWS 是免运维的这一概念一直让我感到愤怒。开发者社区中的许多人理所当然地认为在设置和定义一个设计良好的 AWS 账户和基础设施是不需要付出多少工作和努力的。而这种想当然甚至发生在开始谈论多帐户架构之前就有了——现在我仍然使用单一帐户,我已经必须定义好基础设施和传统的网络设备。

这里也值得记住,我已经做了很多次,所以我很清楚该做什么。我可以在我的帐户中使用默认的 VPC 以及预先提供的子网,我觉得很多刚开始的人也可以使用它。这大概花了我半个小时才运行起来,但我不禁想到,即使我想运行 lambda 函数,我仍然需要某种连接和网络。定义 NAT 网关和在 VPC 中路由根本不会让你觉得很“Serverless”,但要往下进行这就是必须要做的。

运行简单的容器

在我启动运行了基本的基础设施之后,现在我想让我的 Docker 容器运行起来。我开始翻阅 Fargate 文档并浏览 入门 文档,这些就马上就展现在了我面前:

等等,只是让我的容器运行就至少要有三个步骤?这完全不像我所想的,不过还是让我们开始吧。

任务定义

任务定义 Task Definition ”用来定义要运行的实际容器。我在这里遇到的问题是,任务定义这件事非常复杂。这里有很多选项都很简单,比如指定 Docker 镜像和内存限制,但我还必须定义一个网络模型以及我并不熟悉的其它各种选项。真需要这样吗?如果我完全没有 AWS 方面的知识就进入到这个过程里,那么在这个阶段我会感觉非常的不知所措。可以在 AWS 页面上找到这些 参数 的完整列表,这个列表很长。我知道我的容器需要一些环境变量,它需要暴露一个端口。所以我首先在一个神奇的 terraform 模块 的帮助下定义了这一点,这真的让这件事更容易了。如果没有这个模块,我就得手写 JSON 来定义我的容器定义。

首先我定义了一些环境变量:

container_environment_variables = [
    {
      name  = "USER"
      value = "${var.user}"
    },
    {
      name  = "PASSWORD"
      value = "${var.password}"
    }
]

然后我使用上面提及的模块组成了任务定义:

module "container_definition_app" {
  source  = "cloudposse/ecs-container-definition/aws"
  version = "v0.7.0"

  container_name  = "${var.name}"
  container_image = "${var.image}"

  container_cpu                = "${var.ecs_task_cpu}"
  container_memory             = "${var.ecs_task_memory}"
  container_memory_reservation = "${var.container_memory_reservation}"

  port_mappings = [
    {
      containerPort = "${var.app_port}"
      hostPort      = "${var.app_port}"
      protocol      = "tcp"
    },
  ]

  environment = "${local.container_environment_variables}"

}

在这一点上我非常困惑,我需要在这里定义很多配置才能运行,而这时什么都没有开始呢,但这是必要的 —— 运行 Docker 容器肯定需要了解一些容器配置的知识。我 之前写过 关于 Kubernetes 和配置管理的问题的文章,在这里似乎遇到了同样的问题。

接下来,我在上面的模块中定义了任务定义(幸好从我这里抽象出了所需的 JSON —— 如果我不得不手写JSON,我可能已经放弃了)。

当我定义模块参数时,我突然意识到我漏掉了一些东西。我需要一个 IAM 角色!好吧,让我来定义:

resource "aws_iam_role" "ecs_task_execution" {
  name = "${var.name}-ecs_task_execution"

  assume_role_policy = <<EOF
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Effect": "Allow"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy_attachment" "ecs_task_execution" {
  count = "${length(var.policies_arn)}"

  role       = "${aws_iam_role.ecs_task_execution.id}"
  policy_arn = "${element(var.policies_arn, count.index)}"
}

这样做是有意义的,我需要在 Kubernetes 中定义一个 RBAC 策略,所以在这里我还未完全错失或获得任何东西。这时我开始觉得从 Kubernetes 的角度来看,这种感觉非常熟悉。

resource "aws_ecs_task_definition" "app" {
  family                   = "${var.name}"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "${var.ecs_task_cpu}"
  memory                   = "${var.ecs_task_memory}"
  execution_role_arn       = "${aws_iam_role.ecs_task_execution.arn}"
  task_role_arn            = "${aws_iam_role.ecs_task_execution.arn}"

  container_definitions    = "${module.container_definition_app.json}"

}

现在,为了运行起来我已经写了很多行代码,我阅读了很多 ECS 文档,我所做的就是定义一个任务定义。我还没有让这个东西运行起来。在这一点上,我真的很困惑这个基于 Kubernetes 的平台到底增值了什么,但我继续前行。

服务

服务,一定程度上是将容器如何暴露给外部,另外是如何定义它拥有的副本数量。我的第一个想法是“啊!这就像一个 Kubernetes 服务!”我开始着手映射端口等。这是我第一次在 terraform 上跑:

resource "aws_ecs_service" "app" {
  name                               = "${var.name}"
  cluster                            = "${module.ecs.this_ecs_cluster_id}"
  task_definition                    = "${data.aws_ecs_task_definition.app.family}:${max(aws_ecs_task_definition.app.revision, data.aws_ecs_task_definition.app.revision)}"
  desired_count                      = "${var.ecs_service_desired_count}"
  launch_type                        = "FARGATE"
  deployment_maximum_percent         = "${var.ecs_service_deployment_maximum_percent}"
  deployment_minimum_healthy_percent = "${var.ecs_service_deployment_minimum_healthy_percent}"

  network_configuration {
    subnets          = ["${values(local.private_subnets)}"]
    security_groups  = ["${module.app.this_security_group_id}"]
  }

}

当我必须定义允许访问所需端口的安全组时,我再次感到沮丧,当我这样做了并将其插入到网络配置中后,我就像被扇了一巴掌。

我还需要定义自己的负载均衡器?

什么?

当然不是吗?

负载均衡器从未远离

老实说,我很满意,我甚至不确定为什么。我已经习惯了 Kubernetes 的服务和 Ingress 对象,我一心认为用 Kubernetes 将我的应用程序放到网上是多么容易。当然,我们在 $work 花了几个月的时间建立一个平台,以便更轻松。我是 external-dnscert-manager 的重度用户,它们可以自动填充 Ingress 对象上的 DNS 条目并自动化 TLS 证书,我非常了解进行这些设置所需的工作,但老实说,我认为在 Fargate 上做这件事会更容易。我认识到 Fargate 并没有声称自己是“如何运行应用程序”这件事的全部和最终目的,它只是抽象出节点管理,但我一直被告知这比 Kubernetes 更加容易。我真的很惊讶。定义负载均衡器(即使你不想使用 Ingress 和 Ingress Controller)也是向 Kubernetes 部署服务的重要组成部分,我不得不在这里再次做同样的事情。这一切都让人觉得如此熟悉。

我现在意识到我需要:

  • 一个负载均衡器
  • 一个 TLS 证书
  • 一个 DNS 名字

所以我着手做了这些。我使用了一些流行的 terraform 模块,并做了这个:

# Define a wildcard cert for my app
module "acm" {
  source  = "terraform-aws-modules/acm/aws"
  version = "v1.1.0"

  create_certificate = true

  domain_name = "${var.route53_zone_name}"
  zone_id     = "${data.aws_route53_zone.this.id}"

  subject_alternative_names = [
    "*.${var.route53_zone_name}",
  ]


  tags = "${local.tags}"

}
# Define my loadbalancer
resource "aws_lb" "main" {
  name            = "${var.name}"
  subnets         = [ "${values(local.public_subnets)}" ]
  security_groups = ["${module.alb_https_sg.this_security_group_id}", "${module.alb_http_sg.this_security_group_id}"]
}

resource "aws_lb_target_group" "main" {
  name        = "${var.name}"
  port        = "${var.app_port}"
  protocol    = "HTTP"
  vpc_id      = "${local.vpc_id}"
  target_type = "ip"
  depends_on  = [ "aws_lb.main" ]
}

# Redirect all traffic from the ALB to the target group
resource "aws_lb_listener" "main" {
  load_balancer_arn = "${aws_lb.main.id}"
  port              = "80"
  protocol          = "HTTP"

  default_action {
    target_group_arn = "${aws_lb_target_group.main.id}"
    type             = "forward"
  }
}

resource "aws_lb_listener" "main-tls" {
  load_balancer_arn = "${aws_lb.main.id}"
  port              = "443"
  protocol          = "HTTPS"
  certificate_arn   = "${module.acm.this_acm_certificate_arn}"

  default_action {
    target_group_arn = "${aws_lb_target_group.main.id}"
    type             = "forward"
  }
}

我必须承认,我在这里搞砸了好几次。我不得不在 AWS 控制台中四处翻弄,以弄清楚我做错了什么。这当然不是一个“轻松”的过程,而且我之前已经做过很多次了。老实说,在这一点上,Kubernetes 看起来对我很有启发性,但我意识到这是因为我对它非常熟悉。幸运的是我能够使用托管的 Kubernetes 平台(预装了 external-dns 和 cert-manager),我真的很想知道我漏掉了 Fargate 什么增值的地方。它真的感觉不那么简单。

经过一番折腾,我现在有一个可以工作的 ECS 服务。包括服务在内的最终定义如下所示:

data "aws_ecs_task_definition" "app" {
  task_definition = "${var.name}"
  depends_on      = ["aws_ecs_task_definition.app"]
}

resource "aws_ecs_service" "app" {
  name                               = "${var.name}"
  cluster                            = "${module.ecs.this_ecs_cluster_id}"
  task_definition                    = "${data.aws_ecs_task_definition.app.family}:${max(aws_ecs_task_definition.app.revision, data.aws_ecs_task_definition.app.revision)}"
  desired_count                      = "${var.ecs_service_desired_count}"
  launch_type                        = "FARGATE"
  deployment_maximum_percent         = "${var.ecs_service_deployment_maximum_percent}"
  deployment_minimum_healthy_percent = "${var.ecs_service_deployment_minimum_healthy_percent}"

  network_configuration {
    subnets          = ["${values(local.private_subnets)}"]
    security_groups  = ["${module.app_sg.this_security_group_id}"]
  }

  load_balancer {
    target_group_arn = "${aws_lb_target_group.main.id}"
    container_name   = "app"
    container_port   = "${var.app_port}"
  }

  depends_on = [
    "aws_lb_listener.main",
  ]

}

我觉得我已经接近完成了,但后来我记起了我只完成了最初的“入门”文档中所需的 3 个步骤中的 2 个,我仍然需要定义 ECS 群集。

集群

感谢 定义模块,定义要所有这些运行的集群实际上非常简单。

module "ecs" {
  source  = "terraform-aws-modules/ecs/aws"
  version = "v1.1.0"

  name = "${var.name}"
}

这里让我感到惊讶的是为什么我必须定义一个集群。作为一个相当熟悉 ECS 的人,你会觉得你需要一个集群,但我试图从一个必须经历这个过程的新人的角度来考虑这一点 —— 对我来说,Fargate 标榜自己“ Serverless”而你仍需要定义集群,这似乎很令人惊讶。当然这是一个小细节,但它确实盘旋在我的脑海里。

告诉我你的 Secret

在这个阶段,我很高兴我成功地运行了一些东西。然而,我的原始的成功标准缺少一些东西。如果我们回到任务定义那里,你会记得我的应用程序有一个存放密码的环境变量:

container_environment_variables = [
    {
      name  = "USER"
      value = "${var.user}"
    },
    {
      name  = "PASSWORD"
      value = "${var.password}"
    }
]

如果我在 AWS 控制台中查看我的任务定义,我的密码就在那里,明晃晃的明文。我希望不要这样,所以我开始尝试将其转化为其他东西,类似于 Kubernetes 的Secrets管理

AWS SSM

Fargate / ECS 执行 secret 管理 secret management 部分的方式是使用 AWS SSM(此服务的全名是 AWS 系统管理器参数存储库 Systems Manager Parameter Store,但我不想使用这个名称,因为坦率地说这个名字太愚蠢了)。

AWS 文档很好的涵盖了这个内容,因此我开始将其转换为 terraform。

指定秘密信息

首先,你必须定义一个参数并为其命名。在 terraform 中,它看起来像这样:

resource "aws_ssm_parameter" "app_password" {
  name  = "${var.app_password_param_name}" # The name of the value in AWS SSM
  type  = "SecureString"
  value = "${var.app_password}" # The actual value of the password, like correct-horse-battery-stable
}

显然,这里的关键部分是 “SecureString” 类型。这会使用默认的 AWS KMS 密钥来加密数据,这对我来说并不是很直观。这比 Kubernetes 的 Secret 管理具有巨大优势,默认情况下,这些 Secret 在 etcd 中是不加密的。

然后我为 ECS 指定了另一个本地值映射,并将其作为 Secret 参数传递:

container_secrets = [
    {
      name      = "PASSWORD"
      valueFrom = "${var.app_password_param_name}"
    },
]

module "container_definition_app" {
  source  = "cloudposse/ecs-container-definition/aws"
  version = "v0.7.0"

  container_name  = "${var.name}"
  container_image = "${var.image}"

  container_cpu                = "${var.ecs_task_cpu}"
  container_memory             = "${var.ecs_task_memory}"
  container_memory_reservation = "${var.container_memory_reservation}"

  port_mappings = [
    {
      containerPort = "${var.app_port}"
      hostPort      = "${var.app_port}"
      protocol      = "tcp"
    },
  ]

  environment = "${local.container_environment_variables}"
  secrets     = "${local.container_secrets}"
出了个问题

此刻,我重新部署了我的任务定义,并且非常困惑。为什么任务没有正确拉起?当新的任务定义(版本 8)可用时,我一直在控制台中看到正在运行的应用程序仍在使用先前的任务定义(版本 7)。解决这件事花费的时间比我预期的要长,但是在控制台的事件屏幕上,我注意到了 IAM 错误。我错过了一个步骤,容器无法从 AWS SSM 中读取 Secret 信息,因为它没有正确的 IAM 权限。这是我第一次真正对整个这件事情感到沮丧。从用户体验的角度来看,这里的反馈非常糟糕。如果我没有发觉的话,我会认为一切都很好,因为仍然有一个任务正在运行,我的应用程序仍然可以通过正确的 URL 访问 —— 只不过是旧的配置而已。

在 Kubernetes 里,我会清楚地看到 pod 定义中的错误。Fargate 可以确保我的应用不会停止,这绝对是太棒了,但作为一名运维,我需要一些关于发生了什么的实际反馈。这真的不够好。我真的希望 Fargate 团队的人能够读到这篇文章,改善这种体验。

就这样了

到这里就结束了,我的应用程序正在运行,也符合我的所有标准。我确实意识到我做了一些改进,其中包括:

  • 定义一个 cloudwatch 日志组,这样我就可以正确地写日志了
  • 添加了一个 route53 托管区域,使整个事情从 DNS 角度更容易自动化
  • 修复并重新调整了 IAM 权限,这里太宽泛了

但老实说,现在我想反思一下这段经历。我写了一个关于我的经历的 推特会话,然后花了其余时间思考我在这里的真实感受。

代价

经过一夜的反思,我意识到无论你是使用 Fargate 还是 Kubernetes,这个过程都大致相同。最让我感到惊讶的是,尽管我经常听说 Fargate “更容易”,但我真的没有看到任何超过 Kubernetes 平台的好处。现在,如果你正在构建 Kubernetes 集群,我绝对可以看到这里的价值 —— 管理节点和控制面板只是不必要的开销,问题是 —— 基于 Kubernetes 的平台的大多数消费者都没有这样做。如果你很幸运能够使用 GKE,你几乎不需要考虑集群的管理,你可以使用单个 gcloud 命令来运行集群。我经常使用 Digital Ocean 的 Kubernetes 托管服务,我可以肯定地说它就像操作 Fargate 集群一样简单,实际上在某种程度上它更容易。

必须定义一些基础设施来运行你的容器就是此时的代价。谷歌本周可能刚刚使用他们的 Google Cloud Run 产品改变了游戏规则,但他们在这一领域的领先优势远远领先于其他所有人。

从这整个经历中,我可以肯定的说:大规模运行容器仍然很难。它需要思考,需要领域知识,需要运维和开发人员之间的协作。它还需要一个基础来构建 —— 任何基于 AWS 的操作都需要事先定义和运行一些基础架构。我对一些公司似乎渴望的 “NoOps” 概念非常感兴趣。我想如果你正在运行一个无状态应用程序,你可以把它全部放在一个 lambda 函数和一个 API 网关中,这可能不错,但我们是否真的适合在任何一种企业环境中这样做?我真的不这么认为。

公平比较

令我印象深刻的另一个现实是,技术 A 和技术 B 之间的比较通常不太公平,我经常在 AWS 上看到这一点。这种实际情况往往与 Jeff Barr 博客文章截然不同。如果你是一家足够小的公司,你可以使用 AWS 控制台在 AWS 中部署你的应用程序并接受所有默认值,这绝对更容易。但是,我不想使用默认值,因为默认值几乎是不适用于生产环境的。一旦你开始剥离掉云服务商服务的层面,你就会开始意识到最终你仍然是在运行软件 —— 它仍然需要设计良好、部署良好、运行良好。我相信 AWS 和 Kubernetes 以及所有其他云服务商的增值服务使得它更容易运行、设计和操作,但它绝对不是免费的。

Kubernetes 的争议

最后就是:如果你将 Kubernetes 纯粹视为一个容器编排工具,你可能会喜欢 Fargate。然而,随着我对 Kubernetes 越来越熟悉,我开始意识到它作为一种技术的重要性 —— 不仅因为它是一个伟大的容器编排工具,而且因为它的设计模式 —— 它是声明性的、API 驱动的平台。 在整个 Fargate 过程期间发生的一个简单的事情是,如果我删除这里某个东西,Fargate 不一定会为我重新创建它。自动缩放很不错,不需要管理服务器和操作系统的补丁及更新也很棒,但我觉得因为无法使用 Kubernetes 自我修复和 API 驱动模型而失去了很多。当然,Kubernetes 有一个学习曲线,但从这里的体验来看,Fargate 也是如此。

总结

尽管我在这个过程中遭遇了困惑,但我确实很喜欢这种体验。我仍然相信 Fargate 是一项出色的技术,AWS 团队对 ECS/Fargate 所做的工作确实非常出色。然而,我的观点是,这绝对不比 Kubernetes “更容易”,只是……难点不同。

在生产环境中运行容器时出现的问题大致相同。如果你从这篇文章中有所收获,它应该是这样的:不管你选择的哪种方式都有运维开销。不要相信你选择一些东西你的世界就变得更轻松。我个人的意见是:如果你有一个运维团队,而你的公司要为多个应用程序团队部署容器 —— 选择一种技术并围绕它构建流程和工具以使其更容易。

人们说的一点肯定没错,用点技巧可以更容易地使用某种技术。在这个阶段,谈到 Fargate,下面的漫画这总结了我的感受:


via: https://leebriggs.co.uk/blog/2019/04/13/the-fargate-illusion.html

作者:Lee Briggs 选题:lujun9972 译者:Bestony 校对:wxy, 临石(阿里云智能技术专家)

本文由 LCTT 原创编译,Linux中国 荣誉推出

在过去十年中,从 Linux 和 MySQL 到 Kubernetes、Spark、Presto 和 MongoDB,开源一直是云的创新支柱。但最近的一些事态发展为开源背后的商业模式带来了阴霾,业界现在必须采取行动,以避免扼杀其最大的创新来源之一。

作为 Apache Hive 项目的共同创始人和前负责人,我知道激励对于开源生态系统的蓬勃发展至关重要。独立开发者需要激励他们为开源项目贡献自己的时间和技能,而那些具有创业思维的人需要激励他们围绕这些项目建立公司以帮助它们蓬勃发展。

公有云可能会破坏这些激励因素,因为它改变了开源的形态。大型云服务商很容易将开源项目拿来,并将其作为托管服务提供个客户。如果它是在没有回馈社区的情况下这样做的,它就是从别人的工作中获得不公平的利润,从而破坏了开源所需要的蓬勃发展的动力。

我们在围绕 AWS 的当前讨论中已经看到了这一点,AWS 被指责 将开源项目作为服务而提供,并对这些开源项目进行品牌重塑,却不总是回馈这些开源社区。这促使包括 ConfluentRedis LabsMongoDB 在内的开源软件供应商使用了新的许可证,以阻止大型商业云服务商将其代码作为托管服务提供。

我不认为这是一种正确的方法。这些新的许可证尚未得到 开源推进组织 Open Source Initiative (OSI)的认可,并且它们有可能会混淆开源软件的使用权。正如 软件自由保护协会 Software Freedom Conservancy 主席 Bradley M. Kuhn 所说,软件自由应该“对所有人来说都是平等的,无论他们是否是商业行为者。”开源之所以蓬勃发展,是因为这个原则一直受到尊重,任何模糊不清的地方都可能会阻止人们加入社区。

我同情那些寻求保护其业务的开源公司。尽管独立开发人员付出了很多的努力,但开源项目需要公司的资源和管理工作才能被视为足够稳定,才足以供企业广泛使用。Linux 在企业领域中起飞,是因为 Red Hat 和 IBM 全力支持它。Kubernetes 的发展是如此的快,也是因为它得到了谷歌的支持。当然也有例外,但如果一个开源项目背后有一家公司,那么这个开源项目更有可能在大型企业中取得成功。

我需要说明一下我的利益相关立场。我的公司提供了一个基于云的数据分析平台,该平台严重依赖 Spark、Presto 和 Hive 等开源组件。与此同时,我们通过两个项目回馈社区,成为优秀的开源公民:Sparklens,一个提高 Spark 应用程序性能的框架;以及 RubiX,一个提升 Presto 和 Spark 性能的缓存框架。

在云中提供开源软件有助于这些项目吸引更多用户和开发人员。但是,如果商业云服务商获利不公平,则会对下一代企业家程序员们构建开源公司和投资者支持他们产生抑制作用。

因此,如果新的许可证不是解决方案,那么什么是呢?

部分要靠大型云服务商的公平竞争。我不认为 AWS 是“邪恶的”,他们的行为是他们认为最符合他们商业利益的行为。但他们需要认识到,从长远来看,破坏开源对他们的伤害会像对其它人的伤害一样。开源倡导者应该继续提高对这个问题的认识,并对云服务商施加公众压力,以便让他们采取负责任的行动。我们已经看到证据表明这种压力可行

我们还需要一个开源的“ 道德规范 code of ethics ”,由社区(贡献者、项目负责人)和开源组织(如 OSI 和 Apache)创建。一个企业的行为即便是 100% 符合开源许可证,但仍然能够以损害社区的方式行事。这个道德规范能够指出一个广泛认可的道德准则,列出了不可接受的做法,这将使公司和个人对他们的行为负责。

最终的推动力来自于竞争。确实,大型云服务商在吸引客户方面具有优势;它们被 CIO 们视为“简单”和“安全”之选。但客户也可以选择最好的软件和支持。如果开源公司能够为他们自己的发布版本提供更好的功能和更好的支持,他们可以说服客户选择他们自己的产品。

我已经概述了社区可以采取的改善这种情况的行动,但我们每个人也都可以以个人身份采取行动。通过让云服务商了解我们的担忧,我们能够对市场产生一定的影响。要求他们通过反馈表和产品论坛向社区提供特定功能,这是让你发出自己的声音的一种方式。这些云服务商的开发人员也在开源论坛中闲逛,并希望成为开源社区的一员;让这些要求引起他们的注意会促使这种改变。

我们所面临的这个挑战并没有简单的解决方案,但我们需要认真对待。开源模式并不脆弱,不会在一夜之间崩坏。但是,如果商业云服务商继续利用开源项目而不给予回馈,那么他们就会削弱帮助开源成功的激励措施。杀死产下金蛋的鸡并不符合他们的利益,这肯定也不符合开发者和客户的利益。


via: https://venturebeat.com/2019/04/14/how-open-source-can-survive-the-cloud/

作者:Ashish Thusoo 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

室内设计应用可以轻松渲染你喜欢的房子,不管是真实的或是想象的。

 title=

我最近接受了一份在弗吉尼亚州的新工作。由于我妻子一直在纽约工作,看着我们在纽约的房子直至出售,我有责任出去为我们和我们的猫找一所新房子。在我们搬进去之前她看不到新房子。

我和一个房地产经纪人签约,并看了几间房子,拍了许多照片,写下了潦草的笔记。晚上,我会将照片上传到 Google Drive 文件夹中,我和我老婆会通过手机同时查看这些照片,同时我还要记住房间是在右边还是左边,是否有风扇等。

由于这是一个相当繁琐且不太准确的展示我的发现的方式,我因此去寻找一个开源解决方案,以更好地展示我们未来的梦想之家将会是什么样的,而不会取决于我的模糊记忆和模糊的照片。

Sweet Home 3D 完全满足了我的要求。Sweet Home 3D 可在 Sourceforge 上获取,并在 GNU 通用公共许可证下发布。它的网站信息非常丰富,我能够立即启动并运行。Sweet Home 3D 由总部位于巴黎的 eTeks 的 Emmanuel Puybaret 开发。

绘制内墙

我将 Sweet Home 3D 下载到我的 MacBook Pro 上,并添加了 PNG 版本的平面楼层图,用作背景底图。

在此处,使用 Rooms 面板跟踪图案并设置“真实房间”尺寸是一件简单的事情。在我绘制房间后,我添加了墙壁,我可以定制颜色、厚度、高度等。

 title=

现在我画完了“内墙”,我从网站下载了各种“家具”,其中包括实际的家具以及门、窗、架子等。每个项目都以 ZIP 文件的形式下载,因此我创建了一个包含所有未压缩文件的文件夹。我可以自定义每件家具和重复的物品比如门,可以方便地复制粘贴到指定的地方。

在我将所有墙壁和门窗都布置完后,我就使用这个应用的 3D 视图浏览房屋。根据照片和记忆,我对所有物体进行了调整,直到接近房屋的样子。我可以花更多时间添加纹理,附属家具和物品,但这已经达到了我需要的程度。

 title=

完成之后,我将该项目导出为 OBJ 文件,它可在各种程序中打开,例如 Blender 和 Mac 上的“预览”中,方便旋转房屋并从各个角度查看。视频功能最有用,我可以创建一个起点,然后在房子中绘制一条路径,并记录“旅程”。我将视频导出为 MOV 文件,并使用 QuickTime 在 Mac 上打开和查看。

我的妻子能够(几乎)能看到所有我看到的,我们甚至可以开始在搬家前布置家具。现在,我所要做的就是把行李装上卡车搬到新家。

Sweet Home 3D 在我的新工作中也是有用的。我正在寻找一种方法来改善学院建筑的地图,并计划在 Inkscape 或 Illustrator 或其他软件中重新绘制它。但是,由于我有平面地图,我可以使用 Sweet Home 3D 创建平面图的 3D 版本并将其上传到我们的网站以便更方便地找到地方。

开源犯罪现场?

一件有趣的事:根据 Sweet Home 3D 的博客,“法国法医办公室(科学警察)最近选择 Sweet Home 3D 作为设计规划表示路线和犯罪现场的工具。这是法国政府建议优先考虑自由开源解决方案的具体应用。“

这是公民和政府如何利用开源解决方案创建个人项目、解决犯罪和建立世界的又一点证据。


via: https://opensource.com/article/19/3/tool-find-home

作者:Jeff Macharyas (Community Moderator) 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

从很久之前开始,火狐浏览器就一直是开源社区的一根顶梁柱。这些年来它几乎是所有 Linux 发行版的默认浏览器,并且曾是阻挡微软彻底争霸浏览器界的最后一块磐石。这款浏览器的起源可以一直回溯到互联网创生的时代。本周(LCTT 译注:此文发布于 2019.3.14)是互联网成立 30 周年的纪念日,趁这个机会回顾一下我们熟悉并爱戴的火狐浏览器实在是再好不过了。

发源

在上世纪 90 年代早期,一个叫 Marc Andreessen 的年轻人正在伊利诺伊大学攻读计算机科学学士学位。在那里,他开始为国家超算应用中心(NCSA)工作。就在这段时间内, 蒂姆·伯纳斯·李 Tim Berners-Lee 爵士发布了今天已经为我们所熟知的 Web 的早期标准。Marc 在那时候了解到了一款叫 ViolaWWW 的化石级浏览器。Marc 和 Eric Bina 看到了这种技术的潜力,他们开发了一个易于安装的基于 Unix 平台的浏览器,并取名 NCSA Mosaic)。第一个 alpha 版本发布于 1993 年 6 月。到 9 月的时候,浏览器已经有 Windows 和 Macintosh 移植版本了。因为比当时其他任何浏览器软件都易于使用,Mosaic 很快变得相当流行。

1994 年,Marc 毕业并移居到加州。一个叫 Jim Clark 的人结识了他,Clark 那时候通过卖电脑软硬件赚了点钱。Clark 也用过 Mosaic 浏览器并且看到了互联网的经济前景。Clark 创立了一家公司并且雇了 Marc 和 Eric 专做互联网软件。公司一开始叫 “Mosaic 通讯”,但是伊利诺伊大学并不喜欢他们用 Mosaic 这个名字。所以公司转而改名为 “ 网景 Netscape 通讯”。

该公司的第一个项目是给任天堂 64 开发在线对战网络,然而不怎么成功。他们第一个以公司名义发布的产品是一款叫做 Mosaic Netscape 0.9 的浏览器,很快这款浏览器被改名叫 Netscape Navigator。在内部,浏览器的开发代号就是 mozilla,意即 “Mosaic 杀手”。一位员工还创作了一幅哥斯拉风格的卡通画。他们当时想在竞争中彻底胜出。

Early Firefox Mascot

早期 Mozilla 在 Netscape 的吉祥物

他们取得了辉煌的胜利。那时,Netscape 最大的优势是他们的浏览器在各种操作系统上体验极为一致。Netscape 将其宣传为给所有人平等的互联网体验。

随着越来越多的人使用 Netscape Navigator,NCSA Mosaic 的市场份额逐步下降。到了 1995 年,Netscape 公开上市了。上市首日,股价从开盘的 $28,直窜到 $78,收盘于 $58。Netscape 那时所向披靡。

但好景不长。在 1994 年的夏天,微软发布了 Internet Explorer 1.0,这款浏览器基于 Spyglass Mosaic,而后者又直接基于 NCSA Mosaic。浏览器战争 就此展开。

在接下来的几年里,Netscape 和微软就浏览器霸主地位展开斗争。他们各自加入了很多新特性以取得优势。不幸的是,IE 有和 Windows 操作系统捆绑的巨大优势。更甚于此,微软也有更多的程序员和资本可以调动。在 1997 年年底,Netscape 公司开始遇到财务问题。

迈向开源

Mozilla Firefox

1998 年 1 月,Netscape 开源了 Netscape Communicator 4.0 软件套装的代码。旨在 “集合互联网成千上万的程序员的才智,把最好的功能加入 Netscape 的软件。这一策略旨在加速开发,并且让 Netscape 在未来能向个人和商业用户免费提供高质量的 Netscape Communicator 版本”。

这个项目由新创立的 Mozilla 机构管理。然而,Netscape Communicator 4.0 的代码由于大小和复杂程度而很难开发。雪上加霜的是,浏览器的一些组件由于第三方的许可证问题而不能被开源。到头来,他们决定用新兴的 Gecko) 渲染引擎重新开发浏览器。

到了 1998 年的 11 月,Netscape 被美国在线(AOL)以价值 42 亿美元的股权收购。

从头来过是一项艰巨的任务。Mozilla Firefox(最初名为 Phoenix)直到 2002 年 6 月才面世,它同样可以运行在多种操作系统上:Linux、Mac OS、Windows 和 Solaris。

1999 年,AOL 宣布他们将停止浏览器开发。随后创建了 Mozilla 基金会,用于管理 Mozilla 的商标和项目相关的融资事宜。最早 Mozilla 基金会从 AOL、IBM、Sun Microsystems 和红帽(Red Hat)收到了总计 200 万美金的捐赠。

到了 2003 年 3 月,因为套件越来越臃肿,Mozilla 宣布 计划把该套件分割成单独的应用。这个单独的浏览器一开始起名 Phoenix。但是由于和 BIOS 制造企业凤凰科技的商标官司,浏览器改名 Firebird(火鸟) —— 结果和火鸟数据库的开发者又起了冲突。浏览器只能再次被重命名,才有了现在家喻户晓的 Firefox(火狐)。

那时,Mozilla 说,”我们在过去一年里学到了很多关于起名的技巧(不是因为我们愿意才学的)。我们现在很小心地研究了名字,确保不会再有什么夭蛾子了。我们已经开始向美国专利商标局注册我们新商标”。

Mozilla Firefox 1.0

Firefox 1.0 : 图片致谢

第一个正式的 Firefox 版本是 0.8,发布于 2004 年 2 月 8 日。紧接着 11 月 9 日他们发布了 1.0 版本。2.0 和 3.0 版本分别在 06 年 10 月 和 08 年 6 月问世。每个大版本更新都带来了很多新的特性和提升。从很多角度上讲,Firefox 都领先 IE 不少,无论是功能还是技术先进性,即便如此 IE 还是有更多用户。

一切都在 Google 发布 Chrome 浏览器的时候改变了。在 Chrome 发布(2008 年 9 月)的前几个月,Firefox 占有 30% 的浏览器份额 而 IE 有超过 60%。而在 StatCounter 的 2019 年 1 月报告里,Firefox 有不到 10% 的份额,而 Chrome 有超过 70%。

趣味知识点

和大家以为的不一样,火狐的 logo 其实没有狐狸。那其实是个 小熊猫 Red Panda 。在中文里,“火狐狸”是小熊猫的另一个名字。

展望未来

如上文所说的一样,Firefox 正在经历很长一段以来的份额低谷。曾经有那么一段时间,有很多浏览器都基于 Firefox 开发,比如早期的 Flock 浏览器)。而现在大多数浏览器都基于谷歌的技术了,比如 Opera 和 Vivaldi。甚至连微软都放弃开发自己的浏览器而转而加入 Chromium 帮派

这也许看起来和 Netscape 当年的辉煌形成鲜明的对比。但让我们不要忘记 Firefox 已经有的许多成就。一群来自世界各地的程序员,就这么开发出了这个星球上第二大份额的浏览器。他们在微软垄断如日中天的时候还占据这 30% 的份额,他们可以再次做到这一点。无论如何,他们都有我们。开源社区坚定地站在他们身后。

抗争垄断是我使用 Firefox 的众多原因之一。随着 Mozilla 在改头换面的 Firefox Quantum 上赢回了一些份额,我相信它将一路向上攀爬。

你还想了解 Linux 和开源历史上的什么其他事件?欢迎在评论区告诉我们。

如果你觉得这篇文章不错,请在社交媒体上分享!比如 Hacker News 或者 Reddit


via: https://itsfoss.com/history-of-firefox

作者:John Paul 选题:lujun9972 译者:Moelf 校对:acyanbird, wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Git 为软件开发所带来的巨大影响是其它工具难以企及的。

在 Linus Torvalds 开发 Git 后的十四年间,它为软件开发所带来的影响是其它工具难以企及的:在 StackOverflow 的 2018 年开发者调查 中,87% 的受访者都表示他们使用 Git 来作为他们项目的版本控制工具。显然,没有其它工具能撼动 Git 版本控制管理工具(SCM)之王的地位。

为了在 4 月 7 日 Git 的十四周年这一天向 Git 表示敬意,我问了一些爱好者他们最喜欢 Git 的哪一点。以下便是他们所告诉我的:

(为了便于理解,部分回答已经进行了小幅修改)

“我无法忍受 Git。无论是难以理解的术语还是它的分布式。使用 Gerrit 这样的插件才能使它像 Subversion 或 Perforce 这样的集中式仓库管理器使用的工具的一半好用。不过既然这次的问题是‘你喜欢 Git 的什么?’,我还是希望回答:Git 使得对复杂的源代码树操作成为可能,并且它的回滚功能使得实现一个要 20 次修改才能更正的问题变得简单起来。”

Sweet Tea Dorminy

“我喜欢 Git 是因为它不会强制我执行特定的工作流程,并且开发团队可以自由地以适合自己的方式来进行团队开发,无论是拉取请求、以电子邮件递送差异文件或是给予所有人推送的权限。”

Andy Price

“我从 2006、2007 年的样子就开始使用 Git 了。我喜欢 Git 是因为,它既适用于那种从未离开过我电脑的小项目,也适用于大型的团队合作的分布式项目。Git 使你可以从(几乎)所有的错误提交中回滚到先前版本,这个功能显著地减轻了我在软件版本管理方面的压力。”

Jonathan S. Katz

“我很欣赏 Git 那种 底层命令和高层命令 的理念。用户可以使用 Git 有效率地分享任何形式的信息,而不需要知道其内部工作原理。而好奇的人可以透过其表层的命令,而发现其为许多代码分享平台提供了支持的可以定位内容的文件系统。”

Matthew Broberg

“我喜欢 Git 是因为浏览、开发、构建、测试和向我的 Git 仓库中提交代码的工作几乎都能用它来完成。它经常会调动起我参与开源项目的积极性。”

Daniel Oh

“Git 是我用过的首个版本控制工具。数年间,它从一个可怕的工具变成了一个友好的工具。我喜欢它使你在修改代码的时候更加自信,因为它能保证你主分支的安全(除非你强制提交了一段考虑不周的代码到主分支)。你可以检出先前的提交来撤销更改,这一点也是很棒的。”

Kedar Vijay Kulkarni

“我之所以喜欢 Git 是因为它淘汰了一些其它的版本控制工具。没人使用 VSS,而 Subversion 可以和 git-svn 一起使用(如果必要),BitKeeper 则和 Monotone 一样只为老一辈所知。当然,我们还有 Mercurial,不过在我几年之前用它来为 Firefox 添加 AArch64 支持时,我觉得它仍是那种还未完善的工具。部分人可能还会提到 Perforce、SourceSafe 或是其它企业级的解决方案,我只想说它们在开源世界里并不流行。”

Marcin Juszkiewicz

“我喜欢内置的 SHA1 化对象模型(commit → tree → blob)的简易性。我也喜欢它的高层命令。同时我也将它作为对 JBoss/Red Hat Fuse 的补丁机制。并且这种机制确实有效。我还喜欢 Git 的 三棵树的故事。”

Grzegorz Grzybek

“我喜欢 自动生成的 Git 说明页(这个页面虽然听起来是有关 Git 的,但是事实上这是一个没有实际意义的页面,不过它总是会给人一种像是真的 Git 页面的感觉…),这使得我对 Git 的敬意油然而生。”

Marko Myllynen

“Git 改变了我作为开发者的生活。它使得 SCM 问题从世界上消失得无影无踪。”

Joel Takvorian

看完这十个爱好者的回答之后,就轮到你了:你最欣赏 Git 的什么?请在评论区分享你的看法!


via: https://opensource.com/article/19/4/what-do-you-love-about-git

作者:Jen Wike Huger 选题:lujun9972 译者:zhs852 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出