码农的硅谷生活：健康但无聊

优胜美地国家公园是码农们郊游的好去处之一。
　　常规意义上的硅谷包括了从旧金山南下到圣何塞，这 100 多公里的狭长地带。硅谷的北面是旧金山湾，南面则是蜿蜒的山脉。 这个狭长地带包括了 San Mateo、Menlo Park、Palo Alto、Mountain View、Sunnyvale、Cuputino、Santa Clara、San Jose。旧金山和这些小城市几乎聚集了所有的科技公司，也吸引了硅谷所有的中国程序员和工程师们。

　　他们每天的活动就是公司与家，奔波在硅谷的几条主要交通干道 101、280、237 和 880 上。虽然并不需要早晚打卡上班，但每天早班上下班高峰期的时候，101 和 237 这样主要干道的拥堵程度丝毫不亚于北京的四环路。最为拥堵的上班高峰路段莫过于 101 高速通往谷歌总部的出口，而在下班的时刻，从 Mountain View 到圣何塞机场原本 20 分钟的路程甚至会赌上一个多小时。中国码农把这样的上下班戏称为 “Fight 101”。

　　与国内大城市生活相比，生活在硅谷无疑有着诸多吸引力。虽然硅谷 PM 2.5 指数常年在 20-40 之间徘徊，属于美国空气质量相对较差的地区，但与近年来北京、上海等国内大城市的雾霾天相比，这里几乎每天都是阳光灿烂和蓝天白云。生活在日晒强烈的硅谷，墨镜是必不可少的装备。每年的 4 月到 10 月，硅谷几乎很少下雨，远处的山坡几乎是枯黄一片，只有到了冬天的雨季才会绿草油油，呈现出 Windows XP 经典桌面的景象。

　　华人聚集的加州湾区，和纽约与洛杉矶一道是美国中餐馆最为密集的地区之一。围绕着中国超市开设的诸多中餐馆，也是中国程序员们的主要活动场所。每当夕阳西下时分，成家的程序员们会赶回家中，而单身的码农们则会约在中餐馆相聚。每新开一家中餐馆，几乎都会在中国码农的生活圈内传来。因为晚上的硅谷，除了 Palo Alto 的斯坦福大学附近，几乎没有什么休闲娱乐，除了看电影似乎就只能健身房锻炼了。

　　在忙碌了一周之后，中国码农们通常会在周末选择相约郊游。开车或往北开到葡萄酒产地 Napa，或往南行驶至海景小镇 Carmel，或往东奔至优胜美地国家公园，或往西到 1 号公路眺望太平洋。走进大自然，爬爬山看看海聊聊天成为主要的休闲方式。他们通常会自嘲 “国外生活是好山好水好无聊，国内则是又脏又乱又逍遥”。

成家立业的烦恼：结婚和买房

　　要在硅谷成家立业，中国程序员们也要面对这里的烦恼。硅谷的生活水平也是美国最高的地区之一，尤其是住房成本。如今在硅谷，一套一室一厅的较新公寓月租金已经在 2000 美元-2500 美元，而房价则在 40-50 万美元不等。拥有诸多科技公司的 Palo Alto 和 Mountain View 也成为了湾区房价最高的城市。这里的独栋房屋售价基本都在 200 万美元以上。

　　但相对于北京和上海，在硅谷买房虽然价格也高，但也并非遥不可及的梦想。买不起独栋房屋，也可以住公寓；买不起南湾房子，也可以选择半小时车程外的东湾地区。一套公寓或者一栋房子，对硅谷的程序员来说，也只是几年的收入。程序员在硅谷大科技公司的起步年薪约在 8 万左右。工作两三年后，包括奖金与分红的年薪通常会达到 20 万美元左右。

　　不过硅谷最神奇之处就是这里的造富神话。如果眼光好水平高，加入前景看好的创业公司，遇到公司被收购或者上市，或许就成为了百万富翁。硅谷的买房梦想就可以瞬间实现。Facebook 和 Twitter 的上市，也给里面的诸多中国员工带来了丰厚的股权财富。2009 年之前加入 Twitter 的员工，所持的股份如今都价值百万美元。

　　相对于买房，找对象的问题则令中国程序员们更加头疼。因为在硅谷，大部分的中国男人都会找中国女孩结婚。在科技精英汇聚的硅谷，男女中国工程师比例严重失调，呈现出一派 “狼多肉少” 的局面。更加烦恼的是，很多中国程序员的生活圈子较小，接触的异性同胞数量也不多。在这样的情况下，两颗红豆这样的相亲网站，非诚勿扰这样的活动在硅谷受到中国单身码农的广泛欢迎。

逃不掉的调侃话题：印度三哥

微软印度裔新任 CEO 萨提亚·纳德拉 (Satya Nadella)。 。 　　在此之后，中国工程师与程序员在硅谷似乎出现了一个力量断层。虽然每年都有中国人源源不断涌入硅谷，但却再也没有中国人在硅谷重要科技公司担任高层职位。大量的中国科技精英在科技巨头公司似乎遇到了一个无形的天花板，始终卡在中层到高层的晋升道路上。

　　虽然印度人和中国人有很多相似之处，但印度人更喜欢聚居。在 Sunnyvale、Cupertino 等印度人聚集的地区，走进小区就可以闻到一股标志性的咖喱味。虽然印度裔占硅谷总人口的比例只有 6%，但却有 15% 的硅谷科技公司是印度人创办。而被中国人戏称为 “三哥” 的印度软件工程师也成为中国科技精英绕不过去的话题。

　　在硅谷，中国和印度是科技公司最主要的外籍员工来源地。在中国人的晋升之路遇到天花板的时候，印度人却似乎在硅谷发展的顺风顺水。伯克利大学 2012 年的调查显示，三分之一的硅谷科技公司都有一位印度裔高管和技术主管。安卓与 Chrome 联合主管桑达·皮猜 (Sundar Pichai) 是目前谷歌最有实权的高管，谷歌的发布会最常听到的就是印度特色的英语发音。即便不在硅谷的微软也选择了萨提亚·纳德拉 (Satya Nadella) 作为新任 CEO。

　　对于强势崛起的印度同事们，硅谷的中国程序员们更多是抱着一种复杂的态度。当中国人聚会的时候，他们也会开始吐槽印度工程师的各种不良职场行为。“爱向上头抢功，在办公室拉帮结派，压制中国员工”，这些是典型的印度三哥特征。

　　谈到中国与印度程序员的差别时，一位在硅谷呆了十多年的中国程序员直接地说，印度人拉帮结派是出名的了，往好了说这是团结；他们习惯于拱出一个人担任主管，然后会罩着团队里的所有印度人，还会招募大量的印度同胞，阻碍中国人的发展；而中国人或许习惯各自为战，缺乏印度人那样的集团作战。

　　对于这种说法，印度程序员则另有话说。曾经效力谷歌的印度裔软件程序员马尼什阿罗拉 (Maneesh Arora) 对新浪科技表示，越来越多的印度裔员工在硅谷科技公司担任要职，这或许是因为印度人更善于交际，也更有语言优势。英特尔的印度裔公关妮莎·迪奥 (Nisha Deo) 则认为，在英特尔内部关系中，印度裔员工和中国裔员工没有什么不同。

码农中的精英前辈：李彦宏等

1999 年，李彦宏在妻子的鼓励下，告别了硅谷搜索公司 InfoSeek 的工程师职位，回国创建了百度公司。

　　就时间而言，硅谷出现大量中国计算机精英的身影是从上世纪九十年代开始。在此之前，硅谷的科技公司几乎见不到多少中国人的身影；但随着中国大陆的逐渐开放，越来越多的精英学子来到美国求学。学成之后的他们，并没有回到国内，而因为各种原因选择来到硅谷，在英特尔、思科等老牌科技公司开始了自己的职业生涯。

　　在这一批中国计算机精英中，涌现出了诸多在硅谷留下烙印的杰出人才。在上世纪九十年代中后期，他们有的硅谷创业，成就了中国人在硅谷的一段传奇；有的回国创业，成为了中国互联网行业的领军人物；有的继续奋斗，成为了科技巨头中的顶级华人高管。不管选择哪条道路，这批如今 45 岁以上的中国程序员，都是中国互联网及科技史上最传奇的一代人。

　　在那一代的硅谷华人创业者中，邓峰、谢青等人无疑是最为成功的。邓峰和谢青等人创办的网络安全公司 NetScreen，在 2001 年美国科技低潮期成功上市，又在 2004 年作价 40 亿美元被网络设备巨头 Juniper 收购。这个金额目前仍然是硅谷华人创业公司的一个纪录。在被 Juniper 收购之后，拿到巨额资金的邓峰开始了投资人生涯，创办了北极光风投。北极光的投资项目包括红孩子、展讯科技、百合网、珠海炬力等公司。而谢青则早早另起炉灶，创办了自己的网络安全设备公司飞塔 (Fortinet)，并在 2009 年成功上市。目前飞塔的市值接近 40 亿美元。

　　选择回国创业的人则奠定了中国互联网行业的基石。李彦宏无疑是其中最为成功的硅谷回国创业者。1999 年，李彦宏在妻子的鼓励下，告别了硅谷搜索公司 InfoSeek 的工程师职位，回国创建了百度公司。如今的百度是中国最大的互联网搜索公司，市值高达 540 亿美元，李彦宏也一度成为了中国首富。

　　而选择在科技巨头公司工作的那一代中国科技精英，他们当中的最杰出代表莫过于微软全球执行副总裁陆奇。先后效力于 IBM、雅虎和微软的陆奇也是美国科技巨头公司中职位最高的中国大陆人。同样曾在科技巨头公司中担任要职的还有如今新浪联席总裁许良杰，他曾是 eBay 和思科的首位华人全球副总裁，被美国前副总统戈尔誉为 “硅谷华人的骄傲”

编译完了。利用其它方式传

经验这个东西就说起来话长了。如果你有具体问题，把问题写明白，log、转图都弄上来，我们倒是可以一起看看怎么解决。。

可惜在上海。。。。。

@PUMA 可以看看这个职位

估计卓越系的某些行为和游戏开发团队不匹配

在畅游， 配置管理就属于卓越运作体系。

搜狐畅游的总裁和 CEO 干上了。。。。这公司乱的

畅游 CEO 王滔先生发文 “畅游为什么必须变革”

今日（5 月 20 日）畅游 CEO 王滔先生在畅游内部论坛中发表名为《致全体畅游人的一封信》一文。文章中解释了畅游变革的原因及必要性。王滔先生在信中强调：“（畅游）会坚定不移地推动卓越运作体系，全面审视传统的管理方式，创新出新时代的卓越运作理念。” 并建议员工 “无论遇到什么问题，都问自己一句话——如果爱会怎么做？”

业界普遍将此信视为王滔对搜狐畅游总裁陈德文先生发布的《我的战斗宣言》一文的回应。陈德文先生于 5 月 16 日下午在畅游内部论坛发布《我的战斗宣言》一文，文中提及对 “非业务人员插手业务运作” 情况的不满，同时表达了自己 “继续战斗” 的决心（此前有传言称陈德文先生可能离开畅游）。“战斗宣言” 一文发布后，在内部论坛及游戏行业中引起较大反响。畅游的 “卓越运作” 体系对游戏立项、研发及推广所造成的影响也遭到部分畅游在职员工及从业者的质疑。

王滔先生信件全文如下：

亲爱的每一位畅游人:

八年前，畅游是一家新生的小公司，十来个人的小团队。到今天，畅游已经成长为国内排名第三、世界排名第十九的大型企业，成为年营收超过 40 亿、员工数超过 6000 人的行业典范。这一切的取得，靠的是所有畅游人的众志成城、无私奉献！

如今，整个互联网的大环境大家都很清楚，畅游人埋头做游戏，辛辛苦苦累积出来的优势，很快就会被那些手握平台资源的公司消耗殆尽。如果畅游还是延续原来的发展战略，只依靠游戏，在竞争激烈的互联网江湖中，畅游将很快失去生命力，即使未来几年内公司游戏业务再翻一番，也不足以支撑畅游的长治久安，因为当我们在急行军的时候，别的公司正乘着飞机前进。正因如此，公司提出未来 5 年的战略是：游戏赚钱养平台，平台占渠道推游戏。由此我们进入移动互联领域和拓展海外业务，相应的逐步的结构性人员调整完全是基于业务策略并支持业务发展的。这一战略也已经跟大家进行过多轮沟通，希望大家都能理解公司做出此战略性调整的初衷和必要性。

近年来公司游戏业务持续增长，以此为契机，畅游人也迈出了开拓海外市场的步伐。目前我们的应用商店项目等产品在海外每日有上千万的活跃用户，每月资源分发量超过 12 亿，各项数据在海外遥遥领先于同类产品，已覆盖二百余个国家和地区。包括国内市场的 17173 媒体、视频、浏览器等各平台及应用，月度活跃用户数目已达到 2.39 亿，同比增长 182%。事实证明，畅游的平台化策略收效巨大，公司也将坚定不移地继续执行这一策略，开发平台，抢占渠道，为畅游的可持续发展赢得先机。

目前公司正面临重新创业的挑战和机遇，为了支持畅游事业的长远发展，夯实管理体系，完善流程建设与发展业务是同等重要的事情，也是公司管理层的共识，我们会坚定不移地推动卓越运作体系，全面审视传统的管理方式，创新出新时代的卓越运作理念。完善的流程、高效的组织架构是支持畅游未来战略的组织保证，也是企业从优秀走向卓越的必然。做出变革的决定并不容易，我们都明白，在变革的过程中总会遇到种种困难、挫折、反复，出现一些问题也是在所难免的，没有一家卓越企业的成长是一帆风顺的，而所有的挑战和问题，都是我们审视自我、迎难而上的契机。

在此我们也呼吁各位畅游人，以开放、包容的心态，做到爱守心，正视困难、拥抱变革，做好直面挑战并战胜它的准备。无论遇到什么问题，都问自己一句话——“如果爱会怎么做？”

公司也会加强沟通与引导，创造各种条件促进正能量的释放。公司尊重每一位畅游人的想法，在变革时期，很多事情打破我们旧有的习惯，大家持有不同意见在所难免，对于每一位勇于表达自己意见的畅游人，公司都心存感激，这也是畅游一直倡导的安全透明的企业文化，与公司强调的 “活出幸福、无恐惧的畅游” 一脉相承。

……

最后，再次感谢每一位畅游人对畅游做出的贡献，变革的历程中，你我继续风雨同舟，心心连结，一路前行，直至抵达光明的彼岸！

触乐网将持续关注事态发展。

与林仕鼎聊云计算：技术将重构整个社会

林仕鼎，现任百度大数据首席架构师，负责公司数据相关工作，并统一指导基础架构部、系统部以及运维部的技术和战略方向，同时对影响公司未来战略的关键技术进行前瞻研究和探索。

他于 2007 年 10 月加入百度，任网页搜索部高级研究员、主任架构师，主持开发了百度新一代网页存储与处理平台——百灵，带领百度搜索引擎实现了网页与索引的跨量级增长。2010 年 6 月，制定了百度统一基础架构发展的长期技术规划，推动相关团队的整合并创立基础架构部，担任主任架构师。2011 年 9 月，任百度云首席架构师，负责百度云的技术产品研发、对外合作与生态系统建设等工作。

林仕鼎 2002 年在北京航空航天大学计算机系获得硕士学位。此后在微软亚洲研究院系统研究组工作，主要研究大规模分布式系统和高性能系统架构。

“一个全新时代的大幕才刚刚拉开，云、移动、大数据这些技术蓬勃发展，新的商业模式也初现曙光。当我们把所有用户的行为和需求汇集到一块去的时候，整个社会都将被技术的发展所重构。”

与林仕鼎聊过好几次天，每次都收获很多。在我所接触过的技术人员之中，他可能是最具思想家气质的一个，常有天马行空的灵思妙想。而另一方面，他又是目前业界为数不多的还在写代码、坚持在一线的高级技术管理者，深知且在主导技术实践和基础架构的演变。有了这种贯通天地的独特优势，他对云计算趋势的看法，当然应该洗耳恭听。

云中缺失的关键一环

这次我找林仕鼎聊天之前， 已经同国内许多公共云计算平台企业的负责人有过交流，总体感觉是云计算在中国的发展实际上并没有那么乐观，媒体和业界表面上反映出来的那种很热、高歌猛进 的势头，其实是不符合实际的。国外 Amazon AWS 为代表的 IaaS 模式，Google GAE 为代表的 PaaS 模式，还有 Salesforce 为代表的 SaaS，在国内对应的实践都不是那么顺利。（参见本刊 2013 年 4 月期《中国云计算大势图》一文。）

我问林仕鼎：你对此怎么看？

林仕鼎的判断是，技术只有当真正能够去改变人的生活时才会更有意思，IaaS、 PaaS、SaaS 这些形态都只是一些垂直而非普遍意义上的服务。它们其实只是将技术经过合适的包装，以平台形式发布而已。以前软件是没有运营的，发布出去之后就基本跟你没关系了。现在在平台后面可以运营，就可以做很多事情，可以持续地优化，可以统一地协调资源。这种 as a Service 的形式，可以称之为云化。但当前的云化是面向应用而非最终用户的，中间还有一环缺失。

分析起来，如图 1 所示，云里实际上存在四种 OS（操作系统）。

[attach] 2350[/attach]

图 1 云 OS

第一个是数据中心里面每一台机器上运行的 OS，现在主要是 Linux。从宏观上看，它其实相当于以前的 BIOS。

第二个，如果把整个数据中心看作一台机器的话，其中很多的大规模软件架构本身就是一层 OS，它并不是去处理用户的任务，更多是处理其他 Service 所产生的任务，更多跑的并不是 App，而是一个个 Task。

第三个 OS 是用户终端上的，比如 Android 和 iOS，可以看成是 Driver。

但要将二和三联系起来，之间还需要第四个 OS，这个 OS 是面向用户的中枢系统。就像原来桌面电脑上的 OS 对用户来说是一个总管家，不仅要管各种硬件设备资 源，比如 CPU、硬盘、内存等，也要负责人机交互，要管输入输出，用户只需要与之交互。现在这个 OS 是缺失的，它需要能够支持新型的基于云的 App，与现 在手机上装的本机 App 不同。本机 App 基本不维护状态，没法迁移，没法适配不同的终端。而新型 App 能够在多个终端（本质上是多个屏幕）之间无缝地切 换，状态都在云里。App 退出时只是在某一个屏幕上关闭，所有的状态都还在后面运行，随时可以在另一个屏幕显示出来。

现在，这个最重要的处于中心的 OS（林仕鼎说他本来是称之为云 OS 的，只是阿里居然将这个名字用在手机操作系统上……），现在却是缺失的。林仕鼎的看法是，这一点没有想清楚，云计算不容易做好。

另外，他还批评国内在技术上缺乏深入的思考和实践，更多的是现成开源技术的应用，一开始可能做得比较快，慢慢就会觉得问题没有看清楚，发现不知道自己处在什 么样的位置，也不知道后续发展方向是什么。以 EC2 弹性计算为例，国内很多人想得太简单了，以为拿一个 Xen 或 KVM 搭一搭就能出来。可是真正一做就会发 现，这是个泥潭，远比他们想象的复杂，时间长，投入大，收益却比想象的要小，很可能难以为继。

云本质上是在重构互联网

在林仕鼎看来，现在的互联网有很多问题：计算资源分散，每个人自己要在机器上装程序、选择服务、升级；每个用户的数据也是分散的；互联网的网页提供的更多是数据本身，一些功能很难提供，必须依靠移动 App；而 App 这些功能之间也没有可交互性，互相不可操作。

所以，互联网需要重构。如果能将以前互联网的网页数据和用户的个人数据都变成接口，将各种服务也变成接口，由统一的平台在用户终端这边通过智能助手的方式自由组合起来，就能实现完全的个性化。

真正的云平台实际上是一个人人共享的统一操作系统，它与开放平台是不同的。开放平台其实是应用通过 API 进行连接，还是一个个应用。

而云平台的关键词则是托管和聚合，是机器与人的有机组合，所有数据、服务、用户的 ID、业务系统本身都聚合在一个平台上，形成一个大规模、合作创新的平台。 由于有了全局的数据，大数据算法可以发挥作用，这个平台在工程师和用户以及大数据的推动下不断进化，最终会变成一个超大的、囊括性的统一智能系统。这本质 上就是对互联网的一次重构。这个云平台很像《黑客帝国》中 Matrix 的雏形。

我注意到，林仕鼎所说的智能助手，其实与 Apple Siri 在概念上是很像的。早在 Siri 还是独立公司的时候，知名的技术博客 Robert Scoble 就注意到，一旦人与系统也就是林仕鼎说的云平台之间的交互，转变为通过小秘书式的智能助手直接调用 API 来获取和处理信息的话，网页其实就失 去了存在的必要。这对于互联网现有的商业模式的改变可想而知。

现在大部分网站（尤其是中文）的大部分页面其实都不是独有的、原始的数据，很 多内容是重复的，只是换了一种组织和展示形式，就可以通过广告或者电子商务来赚钱。当未来用户都通过助手直接调那些原始数据之后，这种商业模式将面临消 失。新模式将鼓励原创性、独特性数据和产品的创造和产生，产品越独特，越有个性，就越有可能生存。

对此林仕鼎看得更透：广告作为平台只是市场费用的一部分，而如果你能够转向直接为用户提供产品和服务的话，那空间就增大为整个 GDP。

是的，云不仅将重构互联网本身，也将重构互联网的商业模式。

技术发展将重构整个社会

根据上面的推理，未来不仅广告会消失，绝大多数的销售渠道也会消失，因为它们存在的前提都是信息不对称。这本身就将对实体经济产生巨大冲击。

林仕鼎进一步指出，技术对实体经济的影响还体现在生产上。如果能完全知道需求，生产商就可以按需去做后面的资源配置，开发新产品，还能确定生产量。

这与我之前分析大数据时提到过的计划经济可能卷土重来是完全一致的。出乎我意料的是，林仕鼎已经与经济学家许小年讨论过这一话题，许小年认同未来需求分析能够计划的观点，但需求怎么满足仍然是完全市场化的。

3D 打印与这一大趋势是完全相符的。林仕鼎将其与计算机中的 API 相提并论，代表的都是标准化带来的威力。标准化开始往往会造成浪费，因为有很大额外的工作， 技术要求也带来较高的成本，但一旦规模上去之后就完全不同。有了标准化，各种不同需求不需要专门做一份，而是用标准模块组合加工。标准化又能够带来规模 化，从而形成正向循环。

而技术更深刻的影响还体现在，当需求已知之后，可以反过来重构原来的架构和设计，毕竟现实生活中，太多的事情是缺乏 科学论证、数据支持而靠拍脑袋决定的。比如智能汽车，如果有了足够的交通数据，那就可以重新做道路规划，交通的组织方式也可以据此改变。大规模数据计算也 是一样，知道了用户的需求，就可以反过来推动整个软硬件设计的变化。

林仕鼎认为下一步基础设施的硬件架构会变得更加简单。现在这么一大堆乱七八糟的东西是无序发展起来的，缺乏规划。硬件本身应该变得足够傻，但有可编程的接口，能够规模足够大、成本足够少、能耗足够低。然后上面做一个软件系统 平台，把这些资源都管理起来，去运行各种各样的服务。这也就是所谓的软件定义数据中心。

互联网变为云平台，生成的是一个超大规模系统。林仕鼎说，这才是完整的生命，人的作用要么是为它提供工具，要么是提供数据。而人与机器合一组成的这个生命体，实际上是把最终的结果跟你去产生这个结果的原因连接在一起了，它将会快速进化，最终重构整个社会。

这是一次波澜壮阔的技术革命，旧有的模式、框架和秩序都将被颠覆，身处其中，每个人的生活方式也都将改变。有意思的是，这场革命起源于数据中心，影响却更为深远——对于技术从业者的我们来说，这是无尚的荣耀和骄傲。

管理层不懂很正常啊。管理层经常把一句放到嘴边就是：“我都懂，还要你来干什么”

不懂可以，但是至少可以正面支持一下。

用一台 windows 装 jenkins slave + cygwin，然后在 cygwin 里编译。 或者 用一台 Linux 上装 jenkins slave，在 Linux 上直接编译

没有管理层的支持，SCM 的工作难做的很。

这篇文章要仔细阅读，体会

[i=s] 本帖最后由 laofo 于 2014-5-13 18:54 编辑

Delivering eBay’s CI Solution with Apache Mesos – Part II by THE EBAY PAAS TEAM on 05/12/2014 in CLOUD,DATA INFRASTRUCTURE AND SERVICES,SOFTWARE ENGINEERING

In part I of this post we laid out in detail how to run a large Jenkins CI farm in Mesos. In this post we explore running the builds inside Docker containers and more:

Overview

Jenkins follows the master-slave model and is capable of launching tasks as remote Java processes on Mesos slave machines. Mesos is a cluster manager that provides efficient resource isolation and sharing across distributed applications or frameworks. We can leverage the capabilities of Jenkins and Mesos to run a Jenkins slave process within a Docker container using Mesos as the resource manager.

Why use Docker containers?

This page gives a good picture of what Docker is all about.

At eBay Inc., we have several different build clusters. They are primarily partitioned due to a number of factors: requirements to run different OS flavors (mostly RHEL and Ubuntu), software version conflicts, associated application dependencies, and special hardware. When using Mesos, we try to operate on a single cluster with heteregeneous workloads instead of having specialized clusters. Docker provides a good solution to isolate the different dependencies inside the container irrespective of the host setup where the Mesos slave is running, thereby helping us operate on a single cluster. Special hardware requirements can always be handled though slave attributes that the Jenkins plugin already supports. Overall, then, this setup scheme helps maintain consistent host images in the cluster, avoids having to introduce a wide combination of different flavors of Mesos slave hosts running, yet handles all the varied build dependencies within a container.

Now why support Docker-in-Docker setup?

When we started experimenting with running the builds in Docker containers, some of our teammates were working on enabling Docker images for applications. They posed the question, How do we support Docker build and push/pull operations within the Docker container used for the build? Valid point! So, we will explore two ways of handling this challenge. Many thanks to Jérôme Petazzoni from the Docker team for his guidance.

Environment setup

A Vagrant development VM setup demonstrates CI using Docker containers. This VM can be used for testing other frameworks like Chronos and Aurora; however, we will focus on the CI use of it with Marathon. The screenshots shown below have been taken from the Vagrant development environment setup, which runs a cluster of three Mesos masters, three Mesos slave instances, and one Marathon instance. (Marathon is a Mesos framework for long-running services. It provides a REST API for starting, stopping, and scaling services.)

[code] 192.168.56.101 mesos1 marathon1 192.168.56.102 mesos2 192.168.56.103 mesos3[/code]

Running Jenkins slaves inside Mesos Docker containers requires the following ecosystem:

Jenkins master server with the Mesos scheduler plugin installed (used for building Docker containers via CI jobs). Apache Mesos master server with at least one slave server . Mesos Docker Executor installed on all Mesos slave servers. Mesos slaves delegate execution of tasks within Docker containers to the Docker executor. (Note that integration with Docker changes with the Mesos 0.19 release, as explained in the miscellaneous section at the end of this post.) Docker installed on all slave servers (to automate the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere). Docker build container image in the Docker registry. Marathon framework.

1. Creating the Jenkins master instance

We needed to first launch a standalone Jenkins master instance in Mesos via the Marathon framework. We placed Jenkins plugins in the plugins directory, and included a default config.xml file with pre-configured settings. Jenkins was then launched by executing the jenkins.war file. Here is the directory structure that we used for launching the Jenkins master:

. ├── README.md ├── config.xml ├── hudson.model.UpdateCenter.xml ├── jenkins.war ├── jobs ├── nodeMonitors.xml ├── plugins │ ├── mesos.hpi │ └── saferestart.jpi └── userContent └── readme.txt 3 directories, 8 files

1. Launching the Jenkins master instance

Marathon launched the Jenkins master instance using the following command, also shown in the Marathon UI screenshots below. We zipped our Jenkins files and downloaded them for the job by using the URIs field in the UI; however, for demonstration purposes, below we show using a Git repository to achieve the same goal.

[code] git clone https://github.com/ahunnargikar/jenkins-standalone && cd jenkins-standalone; export JENKINS_HOME=$(pwd); java -jar jenkins.war --webroot=war --httpPort=$PORT0 --ajp13Port=-1 --httpListenAddress=0.0.0.0 --ajp13ListenAddress=127.0.0.1 --preferredClassLoader=java.net.URLClassLoader --logfile=../jenkins.log [/code]

[attach] 2329[/attach] [attach] 2330[/attach] [attach] 2331[/attach] [attach] 2332[/attach] [attach] 2333[/attach]

1. Launching Jenkins slaves using the Mesos Docker executor [attach] 2334[/attach] Here’s a sample supervisord startup configuration for a Docker image capable of executing Jenkins slave jobs: [code] [supervisord] nodaemon=true

[program:java-jenkins-slave] command=/bin/bash -c "eval $JENKINS_COMMAND" [/code]

As you can see, Jenkins passed its slave launch command as an environment variable to the Docker container. The container then initialized the Jenkins slave process, which fulfilled the basic requirement for kicking off the Jenkins slave job.

This configuration was sufficient to launch regular builds within the Docker container of choice. Now let’s walk through the two options that we explored to run Docker operations for a CI build inside a Docker container. Strategy #1 required use of supervisord to control the Docker daemon process. For the default case (regular non-Docker builds) and strategy #2, supervisord was not required; one could simply pass the command directly to the Docker container.

3.1 Strategy #1 – Using an individual Docker-in-Docker (dind) setup on each Mesos slave

This strategy, inspired by this blog, involved a dedicated Docker daemon inside the Docker container. The advantage of this approach was that we didn’t have a single Docker daemon handling a large number of container builds. On the flip side, each container was now absorbing the I/O overhead of downloading and duplicating all the AUFS file system layers.

[attach] 2335[/attach]

The Docker-in-Docker container had to be launched in privileged mode (by including the “-privileged” option in the Mesos Docker executor code); otherwise, nested Docker containers wouldn’t work. Using this strategy, we ended up having two Docker executors: one for launching Docker containers in non-privileged mode (/var/lib/mesos/executors/docker) and the other for launching Docker-in-Docker containers in privileged mode (/var/lib/mesos/executors/docker2). The supervisord process manager configuration was updated to run the Docker daemon process in addition to the Jenkins slave job process. [code] [program:docker] command=/usr/local/bin/wrapdocker [/code] The following Docker-in-Docker image has been provided for demonstration purposes for testing out the multi-Docker setup:

[code] hashish/jenkins-dind[/code] In real life, the actual build container image would capture the build dependencies and base image flavor, in addition to the contents of the above dind image. The actual command that the Docker executor ran looked similar to this one: [code] docker run -cidfile /tmp/docker_cid.6c6bba3db72b7483 -c 51 -m 302365697638 -e JENKINS_COMMAND=wget -O slave.jar http://192.168.56.101:9000/jnlpJars/slave.jar && java -DHUDSON_HOME=jenkins -server -Xmx256m -Xms16m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true -jar slave.jar -jnlpUrl http://192.168.56.101:9000/computer/mesos-jenkins-beb3a8ae-3de7-4117-8c4e-efe50b37fbb4/slave-agent.jnlp hashish/jenkins-dind 3.2 Strategy #2 – Using a shared Docker Setup on each Mesos slave [/code] All of the Jenkins slaves running on a Mesos slave host could simply use a single Docker daemon for running their Docker containers, which was the default standard setup. This approach eliminated redundant network and disk I/O involved with downloading the AUFS file system layers. For example, all Java application projects could now reuse the same AUFS file system layers that contained the JDK, Tomcat, and other static Linux package dependencies. We lost isolation as far as the Docker daemon was concerned, but we gained a massive reduction in I/O and were able to leverage caching of build layers. This was the optimal strategy for our use case. [attach] 2336[/attach]

The Docker container mounted the host’s /var/run/docker.sock file descriptor as a shared volume so that its native Docker binary, located at /usr/local/bin/docker, could now communicate with the host server’s Docker daemon. So all Docker commands were now directly being executed by the host server’s Docker daemon. This eliminated the need for running individual Docker daemon processes on the Docker containers that were running on a Mesos slave server.

The following Docker image has been provided for demonstration purposes for a shared Docker setup. The actual build Docker container image of choice essentially just needed to execute the Docker binary via its CLI. We could even have mounted the Docker binary from the host server itself to the same end.

[code] hashish/jenkins-dind-single[/code] The actual command that the Docker executor ran looked similar to this: [code] docker run -cidfile /tmp/docker_cid.6c6bba3db72b7483 -v /var/run/docker.sock:/var/run/docker.sock -c 51 -m 302365697638 -e JENKINS_COMMAND=wget -O slave.jar http://192.168.56.101:9000/jnlpJars/slave.jar && java -DHUDSON_HOME=jenkins -server -Xmx256m -Xms16m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true -jar slave.jar -jnlpUrl http://192.168.56.101:9000/computer/mesos-jenkins-beb3a8ae-3de7-4117-8c4e-efe50b37fbb4/slave-agent.jnlp hashish/jenkins-dind-single[/code]

1. Specifying the cloud configuration for the Jenkins master

We then needed to configure the Jenkins master so that it would connect to the Mesos master server and start receiving resource offers, after which it could begin launching tasks on Mesos. The following screenshots illustrate how we configured the Jenkins master via its web administration UI.

[attach] 2337[/attach] [attach] 2338[/attach] [attach] 2339[/attach] [attach] 2340[/attach] [attach] 2341[/attach]

Note: The Docker-specific configuration options above are not available in the stable release of the Mesos plugin. Major changes are underway in the upcoming Mesos 0.19.0 release, which will introduce the pluggable containerizer functionality. We decided to wait for 0.19.0 to be released before making a pull request for this feature. Instead, a modified .hpi plugin file was created from this Jenkins Mesos plugin branch and has been included in the Vagrant dev setup.

[attach] 2342[/attach] [attach] 2343[/attach]

1. Creating the Jenkins Mesos Docker job

Now that the Jenkins scheduler had registered as a framework in Mesos, it started receiving resource offers from all the Mesos slaves. The next step was to create a Jenkins job that would be launched on a Mesos slave whose resource offer satisfied the cloud configuration requirements.

5.1 Creating a Docker Tomcat 7 application container image

Jenkins first needed a Docker container base image that packaged the application code and dependencies as well as a web server. For demonstration purposes, here’s a sample Docker Tomcat 7 image created from this Github repository:

[code] hashish/tomcat7[/code] Every application’s Git repository would be expected to have its unique Dockerfile with whatever combination of Java/PHP/Node.js pre-installed in a base container. In the case of our Java apps, we simply built the .war file using Maven and then inserted it into the Docker image during build time. The Docker image was then tagged with the application name, version, and timestamp, and then uploaded into our private Docker registry.

5.2 Running a Jenkins Docker job

For demonstration purposes, the following example assumes that we are building a basic Java web application. [attach] 2344[/attach] [attach] 2345[/attach] [attach] 2346[/attach] [attach] 2347[/attach] [attach] 2348[/attach] [attach] 2349[/attach] Once Jenkins built and uploaded the new application’s Docker image containing the war, dependencies, and other packages, this Docker image was launched in Mesos and scaled up or down to as many instances as required via the Marathon APIs.

Miscellaneous points

Our Docker integration with Mesos is going to be outdated soon with the 0.19 release. Our setup was against Mesos 0.17 and Docker 0.9. You can read about the Mesos pluggable containerizer feature in this blog and in this ticket. The Mesosphere team is also working on the deimos project to integrate Docker with the external containerization approach. There is an old pull request against the Mesos Jenkins plugin to integrate containerization once it’s released. We will update our setup accordingly when this feature is rolled out. We’d like to add a disclaimer that the Docker integration in the above post hasn’t been tested at scale yet; we will do our due diligence once Mesos 0.19 and deimos are out.

For different build dependencies, you can define a build label for each. A merged PR already specifies the attributes per label. Hence, a Docker container image of choice can be added per build label.

Conclusion

This concludes the description of our journey, giving a good overview of how we ran a distributed CI solution on top of Mesos, utilizing resources in the most efficient manner and isolating build dependencies through Docker.

prot = protocol ,是指你启动 svn 时所采用的协议，例如 http, svn 等

应该就是个 bug，没处理好。

[i=s] 本帖最后由 laofo 于 2014-5-12 16:41 编辑

@julyclyde : 对无营收部门的定价很难。2008 年康盛搞过一轮自救，各部门都要赚钱，结果：5d6d 违反承诺给各小论坛强插广告，系统技术支持部出去卖 IT 外包服务，不知道行政和财务咋做的

@scmroad配置管理之路 这都是问题。搞了内部也要合算之后，内部部门之间的支持都要算钱，结果造成每个部门都自成体系。

51job 上有这个职位信息，可以去那里投

jenkins 分 master 和 slave，需要至少要两台机子，至于 linux 还是 windows 没限制。 jenkins slave 要装在一台可以访问 clearcase 库的机子上。只要通过 clearcase 命令行得到 clearcase server 上的代码就可以了。不一定要和 clearcase server 装到一起。 如果 clearcase 的插件自带内部支持 clearcase 签出代码，那那台 jenkins slave 上连 clearcase 命令行都不用装了。

忘记在哪了

是不是 2.2.0_1 版本太老了，你试下稍微新一点的。