Martin解读Serverless

Serverless 不意味着没有服务器,而是从应用可以在一个抽象层上忽略它的存在,而只关注在功能实现上和自身的请求处理上;每一个功能实现在不是单纯的业务逻辑处理的代码,相反每个功能调用具有了 server 的特质,进化成为了一个具有自省、自知和自治的工作负载单元;他们更像是能够衍生出其它新功能单元的生物体。这样整个 Serverless 应用架构之内,每个生命可以衍生下去,子子孙孙无穷匮也。

本文编译了:https://blog.docker.com/2016/06/building-serverless-apps-with-docker/ 一下是正文内容。

处在这技术日新月异的时代里,新的技术浪潮经常对当前的技术产生着威胁和颠覆。在编写应用的时候我们目前经常谈论到“Serverless”技术。它的核心思想是把应用作为一系列的功能/function来部署,这些功能在需要的时候被按需部署。服务器管理应该是不需要去操心的事情,所有功能被按需调用,被运行在群集之上。

但是 Serverless 里不意味着没有 Docker,事实上 ”Docker 就是 Serverless”。你可以用 Docker 来容器化这些功能,然后按需地运行在 Swarm 群集上。Serverless 是一种构建分布式计算的应用的方法,而 Docker 是完美的构建和运行他们的平台。

从Server 到 Serverless

那么我们如何来编写 Serverless 的应用?让我们先看下这个例子:“一个有5个子服务组成的投票应用”

它的结构如下:

  • 两个 web 前端
  • 一个后台的处理投票的 worker 服务
  • 一个处理投票的消息队列
  •  一个数据库

那个后台处理投票的进程是非常容易成为转换为 Serverless 架构的目标。在投票应用内,我们可以运行一点类似于下面的代码,来执行后台任务:


import dockerrun

client = dockerrun.from_env()

client.run("bfirsh/serverless-record-vote-task", [voter_id, vote], detach=True)

Worker 和消息队列能用按需在 Swarm 上运行的容器来替换,并自动地按需扩容。

我们甚至可以消除掉 web 前端。我们可以这么做:用 Docker 容器来相应每一个HTTP 请求,每个 HTTP 请求都用一个自生长的跑着轻量 HTTP 服务器的容器来处理。之前使用的是长时间持续运行的 HTTP 服务器,现在变成了具有 HTTP 相应和处理能力的按需跑起来的容器,而且他们能自动地扩容来支持所有访问请求。

我们新的架构大概如下图所示:

其中红色的方块是需持续长期运行的服务,而绿色方块成了按需被调用的 Docker容器。这样这个应用变成了只有少数几个需要被管理的 long-running 服务,在相应请求的时候使用原生的 Swarm 扩容能力,处理能力的上限是 Swarm 群集的上限。

具体如何实现

这里有三个有用的技巧,可以在你的程序中使用:

  1. 把你代码中的 function 作为按需拉起的 Docker 容器
  2. 使用 Swarm 在群集上运行这些容器
  3. 从容器里面运行这些功能容器,绕过了一个 Docker API socket

使用以上技术的组合,程序执行负载发生的可能性将和您如何架构你的应用相关。运行后台任务就是一个非常适合的例子,但是整个应用中的其它工作负载也是有可能的,例如:

  • 考虑到延迟,用启动一个容器来服务所有用户的 HTTP 请求可能是不现实的。可是你可以写一个内置的负载均衡逻辑,让它知道何时需要主动地自动扩容 Web 前端自身,通过在 Swarm 群集上运行更多 web 处理容器。
  • 一个 MongoDB 容器可以在 Swarm 上成为一个具有自省能力的架构,它能自动地运行出正确数量的 shard 和 replica 容器。

接下来

我们已经得到了这些激进的新工具,用做构建应用的抽象层,我们隐约看到了如何深入下去的可能性。我们依然像长时间以来在一堆服务器上构建应用一样,而以后可以来利用 Swarm 能按需地在基础架构里的任何地方执行功能代码的能力。

希望这些能够给您一些如何构建应用的新思路,但是我们还需要你们的帮助。我们已经有的是一些构建 Serverless 应用的基础功能,然而他们依然不是很完备,我们需要更好的工具、库、样例程序,文档等等。

这个 Github 库有一些工具、库、代码和文章的链接。基于此,如果您想学习更多的话,请共享任何相关的链接,这样我们可以开始协作在一起。

大家一起来搞,并祝 hacking 愉快!

Closing General Session 的主题是 Moby Dock‘s Cool Hacks ; 从字面意思上看,这个主题的意思是“超萌码头酷黑客”的意思。我已经看到了关于最后一天开幕主题演讲的评论,说是“剑指商业”什么的;而我认为 Docker 从开始的第一天,无论它是否开源,它都是为了商业利益而已。话在说回到开源,Docker 只是完美的应用了开源软件这种实践而已;而且docker 把开源这种模式应用的如此成功,并在商业上也如此让人眼红和侧目,这也算是开源软件商业化登峰造极的一种极端性个案。个人认为开源无疑是在软件行业中做出爆款技术当之无愧的首选的实践方式。我在红帽碰到很多参与开源十几二十年的老黑客,他们不乏会表达关于开源纯洁性沦丧的抱怨;我对此也非常理解和认同。而我更认同开源可以对软件技术带来无比活力的这个积极的方面。

言归正传,小编我还是“模拟现场”播报一下大会闭幕主题演讲的盛况。这是大会的结束的 session,现场的人数明显的少于第一天开幕式的人。在十几分钟内,人们稀稀拉拉的进入了会场。会场中的座位大约还有一部分空位。美女Mano 和 黑客Kristie 作为主要演讲人上台。美女上台后先用手机自拍了几下。两个人开始宣布,Docker 大会之后举行为期一个月的黑客大赛,这是我们的传统,Docker 大会虽然今天会结束,而docer 黑客大赛将从今天开始。我们来请大家欣赏三个非常酷的黑客项目演示。

本次大会的录音点这里 http://www.ximalaya.com/32280565/sound/17388272

黑客演示1:微服务自毁平台

Jeff 登场。Jeff 开始讲述微服务的故事,我们都在试图让基础架构做到冗余,容所有的服务都冗余,让群集能够自愈;但是故障,断网,宕机还是会发生。我们所做的这些真的能够保证业务不宕机么,服务不终端么?你怎么能确认这一点?因此回归到故障的发生上吧?如果服务要出故障,请让它有规律的发生。请程序猿和 ops 都投入到故障处理的战斗中,以此为契机来优化和改造应用,让应用变的更加强壮。我们都听说过混乱猴子,而 Jeff 团队正式帮人们构建一堆这样的工具的人。

有一个思路是:如何让我的系统的服务出故障,如何主动的在系统中注入故障。我们需要一种特殊的编排工具来在系统中模拟和触发故障的发生。我用容器做工具平台来触发故障注入的动作。当然这个故障是在容器架构的微服务系统中触发这个动作。

Jeff 开始做这个 Demo。说:如果你的”网络没有故障,天下太平。“其实这很无聊的说,有木有?有木有?我现在开始用工具来注入 网络延迟的网络故障吧! 。用一个基于策略的工具。配置一个网络故障模拟的策略,故障什么时间发生,发生多久。这里设计一个每10秒钟注入一次网络延迟故障提高到600ms 的故障。然后配置故障影响的范围,这里使用 Docker 的 lable 来做故障发生节点的选择的条件。符合标签的系统将受到这次故障影响。我们的这个故障模拟编排系统,帮您提前体验故障的发生。现在你看故障发生了,从这些容器里面 ping google 的网络延迟比之前大多了, 目前延迟到了600ms。希望你们能开始体验和使用这个而工具。

黑客演示2:Serverless 架构的应用不是梦

Ben 是大家在 Docker 大会喜闻乐见的一个黑客,他经常给做 demo 和 session。他绝对符合超萌的标准。

40906 (1)

Ben 开讲,Serverless 是如何做的?ben 认为 Serverless 是一种全新的应用编程的思路,而 docer 可以很好的支持这种思路,并实现和执行这种思路。docer 群集可以让Serverless引用按需执行,并让该应用的底层变得资源冗余并路由可达。ben 开始演示 他的几张 slides, 说 Sererless == docker这个概念。本开始讲解:如何用Serverless架构来实现投票应用的改造。如何把这个5个服务模块的纯粹容器微服务系统转换为 serverless 架构的应用。开始修改源代码,把发入队列的票,变成一个处理投票的容,把 http 服务器变成一个 CGIHander()服务;但是 nodejs 不支持 CGIhander,肿么办?我用 perl 重写了这部分,为毛用 perl,被忘了它乃是古董级的黑客神器的好不好,呵呵!改造完之后的系统架构如下。架构是把处理 postgresql 意外的模块都重写了。数据库保留在最下层。这种Serverless重构实践遵从的原则如下。

2

三个原则翻译一下:

  1. 把每个模块的核心功能打包,并作为容器来运行。解读:这意味着把所有服务模块组重构,把每个服务模块中的核心功能代码作为一个在容器里面跑的对象。这里其实牵扯到很深的业务重构和应用重构,程序猿或将抛弃以前的代码,甚至以前所习惯使用的程序开发堆栈。

  2. 把这些容器用 Docker 的 Swarm 跑起来。解读:docker 原生的Swarm 编排能力将为您的应用提供,功能的运行,workload 的分布,服务的冗余,服务的路由等等支持;这样的架构能支持到 Serverless 的应用的模型。

  3. 从容器中去运行其它容器。解读:容器编排平台或将不是容器生命起源的唯一起点,容器里面的应用可能可以决定系统中需要滋生出什么样的容器,当然说的是需要实现和运行什么功能的容器。

好了,目前为止,ben 的心的应用重构完成,还是用 docker-compose up 启动了改造之后的应用。现在看到了这个 serverless 的应用工作正常。

Ben 说:我们在这demo 了 serverless  应用的改造的过程,可以看到 docker 是如何支持这种应用架构的。你可以打包 web front 为服务,它自动的在 Swarm 群集上无限延展这个服务。成为分布式计算的架构。还可以打包微服务的其它应用模块为 Serverless 应用架构。欢迎大家 参与到我的 Serverless github 项目中,和我一起互动,把 Serverless 在 docker 上的应用搞起来。https://github.com/bfirsh/serverless-docker 这里包括了以上演示的应用。

黑客演示3:在线更新的无人机

这个团队做 in the air update 无人机实时演示。无人机其实是树莓派加他们的 docker 软件系统。这是一个嵌入式系统的设计。

3

4

5

实时新旧系统的切换秘密在这里。新版的容器会先运行起来,新系统用一个队列来接收旧系统的数据,这些数据是新旧系统交接的必要的数据,系统会判断需要多长时间,需要收集那些数据来完成这个交接的过程。直到旧系统到新系统的割接完毕。

程序猿开始更新 v1的代码,加入了摄像头实时视频功能。更新提交了 v2的镜像文件。在下图可以实时的监视到无人机的状态。

6

1

无人机在在线更新软件中。并没有掉地上哈哈哈!

6.1

右下角是新版本软件的摄像头把大会现场的视频拍摄,并实时传递到控制台的效果。此图上面的那个图,中间凸起震荡的那个块是无人机软件升级实时更新的过程。

本黑科技演示完毕。

hackathon 黑客大赛启动

主此人再次上台启动了黑客大赛。

7

为期一个月的 hackathon 正式开始。

最后看点

CEO CTO 上台感谢赞助商。所罗门开始讲黑客骚扰现象。号召大家通过 http://hackharassment.com 网站来抵制中现象。

Bump UP 是通过手环实现的,人们的手环彼此碰撞会在系统中增加一个点数。宣布了碰撞点数最多的前5名,感谢他们在本次大会中,积极的和其它人互动和沟通,请他们去领奖。所罗门号召所有现场的人再次相互碰撞手环,系统系统的点数增加到两百万。来解锁 Docker 奖学金基金。很快大家碰撞起来。奖学金解锁。

感谢进三千名的社区 贡献者,感谢 docker 的员工。所有人发来的自拍形成了一个西雅图拼图。最后大会圆满结束。

看到最后的才能做最后的评论。这更感觉是一个黑客大会,引入了 docker 对社会的责任感的概念。商业财富越大的人社会责任感应该更多。更像是黑客公司商业成功之后,继续创新,并开始践行自己的社会责任的大会。大会并没有结束,黑客大赛在接下来的一个月里将在全球各地延续。

看点:开场乌龟引起了喵星人大战,首次有吉祥物开启的科技盛会。 和往常一样 CEO 和 CTO 挑大梁将首日 keynote。 所罗门提出了 Docker 技术发展的三个核心方向和着眼点,并在每个方向上做了新技术发布。 1. 开发者体验提升, 正式发布 Docker for Mac/Windws 2. 编排能力的提升,正式发布 Docker 1.12 ,其中有四项能力提升;这是要废掉所有其他编排器的节奏啊~ 3. 运维体验提升,正式发布 beta.docker.com ;这是和公有云深度结合的产品,分为 AWS 和 Azure 两个模块。 一共有三个实景演示,都没有出现问题,演示很成功。

现场录音

点上面的播放键,播放整场录音。请注意中间的数秒钟乃至数十秒的中断是正常,请快进收听。

开场

屏幕上出现了乌龟开始做 demo,运行了一个容器。 猫咪大战,混乱了,猫星人入侵了。猫叫~~乱作一团··· 发生了什么? dockercon16 吹起了号角。 乌龟再次出现在电脑上,运行了另外一个容器惊喜,这次是美妙的音乐。 调皮的乌龟折腾完了之后,主题曲想起来。4000多人的场子,大家很期待。

CEO Ben Golub 演讲

2

Ben Golub CEO 出场。 Today we are all docker blue. 欢迎所有人。 我们和前两年的不同,我们发布了1.0 等等。 谈了很多 Docker 取得的成就。 感谢和表扬了社区。 感谢2900+贡献者。 社区的状态动态,每周超过300 PR,三分之二来自 Docker 公司之外。 docker meetup 的状况, 250+城市举行,125K 人参加聚会。 内容构建方面,docker hub 上有 460K 个应用,到目前为止有4.1B 此镜像下载。 感谢 docker 的生态社区。 讲述了这两年的使用场景的变化。Docker 逐渐成为了企业级的应用。 所有穿着红色衣服的起立,他们是 Dockr 公司的员工,感谢他们,请鼓掌。 感谢今年的赞助商。 向 Demo Gods 致敬,给神献上祭品,保证后续的演示顺利。 we pray to the old codes and the new.

CTO 所罗门演讲

所罗门出场。 我去,4000多人在场,我老爸也在家看我视频直播。 很荣欣大家来参加,感谢大家来参会。 谁参加过 DockerCon14? 我们要开始做很多的 demo 在会议过程中。 最精彩的部分是,我们来自全球各个行业的不同层面,多样性简直是不可思议。原因是:Programming is changing the world. 我们在一起的原因是:Docker 是编程创新的助力工具。 We’re building Docker incrementally, in the open. 最好的工具目前看不是那些软件工具巨人的公司提供的,而是来自社区和群众的创新,是你们指引着我们构建了愈来愈多的工具。 社区告诉我们几个方面需要努力。

1 开发者体验

构建最好的工具,这个工具需要有这些特质:

  1. get out of the way;

  2. adopt to you;

  3. make the powerful simple

我们努力地践行着这些理念。 Docker for Mac/Windows 将是最无缝的开发者体验。 Making things easy is really hard. 我们在寻找最佳的系统工程师,我们收购了 Unikernel 公司。 在移动游戏行业里面找到最佳的设计者。

第一个演示 – Docker for Mac

演示者登台。 我是个开发者,今天第一天上班。 安装了 Docker for Mac 打开这个应用,启动它。 克隆

git clone viting-app 

运行

docker-compose up

打开投票应用的两个web界面。 我不知道这个应用是什么,但是一个命令就启动了所有5个服务。 我发现了程序的 bug。 是否我第一天上班就能修复它? 分析了一下程序架构图。 查看 docker-compose.yml 文件。 找到了一个 debug 显示的的那一行。 在代码中加入了 live debug 的断点。 开始 review 代码,发现了奇怪的地方。 找到了 git 上的代码,增加了评论,提出源码结果计算方法有问题。 现在删除了有问题的哪一行代码。 删除了断点。 用 live debug 的方式修复代码。 回到程序界面,发现 bug 没了。 做 git commit 提交修正后的代码。 查看了该应用在 staging 环境的情况,发现也有相同的结果计算的问题。 进入该环境的 Docker Cloud界面,看到了这个运行环境。 查看 result 服务的构建策略是自动构建。 Docker Cloud 自动接收了新的代码,Staging 环境的构建完成并通过了测试脚本,程序正常了。 查看云里的 Staging 环境的 bug 也被除掉了。demo 结束。

Splice 的 CTO Matt 案例分享

Splice 的 CTO Matt;我们做的是个音乐服务的技术,我们构建的服务像是给音乐人用的 github。 每天都有人上传上很多 TB 的音乐数据。 我们在 Mac 上开发,在 Linux 上部署。 我们使用多种数据存储。 Docker 让我们保持多种环境的一致,降低了 debug 的时间。 所有的程序运行在容器中。 我们一天更新线上的业务20多次。 Developer 的第一天工作就能为业务提供价值。 我们使用 Docker for Mac。

2 Orchestration 编排能力

我们听到很多 happy user 的故事。 感谢所有7万多 Docker for Mac beta 的反馈参与者。 我宣布 Docker for Mac/Widnwos beta 完全开放下载。 很多人告诉我们需要在 Orchestration 上更加努力。 它在 ship 方面提供支持,能发布你整个的应用,让你不再关心单个的容器。 Orchestration是个技术活,只有专家才能干。很少人能做这个工作。 可是用户怎么能即不出现手头人才短缺,又不被某些厂商在这方面给技术锁定呢? 更好的方法是什么? Docker 1.12 将内置编排功能。 最佳的编排技术将是 Docker 自己。

3

我们先提前介绍一些它的新功能。

  • Swarm mode

  • Cryptographic node identity

  • Docker Service API

  • Build-in Routing Mesh

非常简单的演示,你就明白了。 欢迎第三个 编排的演示 Docker 1.12 技术。

第二个演示 – docker swarm 功能演示

两个人上场。 用一个新的机器,上面只安装了 docker。 有三个节点。 第一个节点上初始化群集 docker swarm init 第二个节点上加入群集 docker swarm join 在第三个节点上加入群集 docker swarm join 三节点的群集建立完成。

为毛它没有让输入任何安全的信息和选项,这就对了,我们有内置的 PKI 安全通讯机制。 所有节点都有自己的身份标识。密钥定期自动变化。所有通讯都可以追述到发起者的身份。

你们都懂 docker run 子命令。 docker service 命令是新来的子命令。 service 的定义是将要维持服务的状态。

docker service create --name voting-app -p 5000 
docker service ls


所有的服务只启动了一个容器,分布在三个节点上。

看到投票应用页面显示了。

浏览器访问了第一个节点的 ip:5000 ,然后第二个节点的 ip:5000 端口,发现实际上访问到了第一个节点上的的容器。这就是新的容器路由的功能。所有的节点访问这个服务的端口,都可以路由到该服务的容器里。

docker service scale 6

现在扩容服务的容器。 每次刷新页面,页面上容器的ID都在变,这是群集内置的 round robin 负载均衡策略,把访问分发到所有容器。这就是内置的负载均衡功能。

我们升级这个 app 吧。

docker service update 


演示容器镜像文件的更新 选择另外一个 tag 的镜像来升级 现在我们可以对电影投票了

滚动升级可以支持 加上一次升级2个容器的升级选项,因此它现在是做两个一次的服务容器升级,直到所有容器都升级结束。

我们说的自愈功能是说,能让应用可以在机器宕机的时候,业务也不中断。 请把有两个容器的 node3 关机。 调度器现在自动在 node2上长出刚才运行在 node3上的那两个容器。保持6个容器的服务配置。

演示成功,并没有出问题。

Zenly 的创始人案例分享

所罗门高兴的再次上台。 这说明我们的祭品生效了,演示没有出毛问题。 docker 1.12 在几周后就发布,Docker for Mac beta 版本上现在就有这些功能。你们这些已经安装的现在就可以尝试这些功能。 我们自由的扩容业务应用,而服务速度不受到影响。 在大规模的关键业务中的部署才是目标。我们请 Zenly 的兄弟们上台。

Zenly 的人喝了两杯祭品的冰咖啡上台了。 我们有1M 用户,是最近的三个月内获得的。 500M events/day 一共才 6 engineers 我们运行业务在云上。 我们现在把部分业务迁移回自己的物理机。 我们在10台物理机上运行部分业务。 部分运行在 GCE 上。 我们感觉按需扩容很爽。

3 运维体验

我们谈到开发者体验,业务编排。 群众还告诉我们“Ops experience” 运维体验是需要关注第三个侧面。 Docker 应该深度和云基础架构集成。

beta.docker.com 发布

我宣布beta.docker.com 发布。包括 docker for aws 和 docker for Azure 是最原生的 AWS 和 Azure 体验。是和云基础架构最深的集成。 现在可以用 AWS CloudFormation 来部署 Swarm 群集。 可以自动配置所有的负载均衡端口等配置。

www.docker.com/dab 发布

www.docker.com/dab 是新的可移植多容器应用打包格式。 这是新的 ops 体验。是让 developer 和 Ops 更容易工作在一起的方案。

第三个演示 – 云运维体验

Developer:我想赶紧回家。我还需要赶紧交货。

docker compose bundle 

产生了一个.dab 文件,齐活了。 把应用的 .dab 文件给 Ops 即可。 Ops:你的应用是 docker的么? 额的个神啊! 我喜欢在 AWS 上用Docker。 看我新建Stack的 AWS 向导,这里可以配置了一个新的 docker swarm 群集。 看我这有一个已经部署了100节点的群集。 所有网络、存储、负载均衡都不用手动配置。 复制 这个网址。 在 Mac 电脑的 shell 粘贴 ,后点击回车。 我们进入了命令行 docker for aws 的特殊的 shell 我能看的所有群集和主机的状态 把你的 .dab 文件给我,就欧了~ 用 USB copy 给你。 把文件 copy 给了 Ops scp .dab 文件到 swarm 群集中。 在进入 shell ls 能看的这个文件

docker deploy  voting-app  xxx.dab 


看这些所有服务都运行了

docker service ls
docker service update -p 80:80  voting-app
docker service update -p 8080:8080  result-app
docker service scale 


扩容这些服务的容器数量 打开浏览器确认应用部署结果,找到 ELB 的配置,配置已经自动生成了。 浏览器中访问 ELB 的80端口上看的投票页面 在 ELB 的 8080 端口看的结果页面 这下应用部署完毕。 原来你的 Ops 工作怎么这么简单啊!! I got go home ~~~

结束

所罗门感谢大家,所请访问 docker.com/getdocker 有需要的尽管说。 请在这几天内,尽量多的告诉我们,你们的需求和使用场景。 请告诉我们 what we build next ! thank you very much !!

注意

我是 Maritn Liu 为您播报本次大会的各种信息,对以上内容有任何问题和疑问请加我微信咨询,我的微信号是 martinliu_cn ,这篇文章也会在我的微信公众号(aws-faq)和 ”刀客微播报“上发布。以上会议记录中所有命令的操作并不是准确的演示者输入,尽量参考这些命令来想想其可能的参数和语法,如果你安装了最新版本的 Docker for Mac 可以自己试一下。

Amadeus uses next-generation containerized application platform with OpenShift from Martin on Vimeo.

以上视频来源于:https://blog.openshift.com/openshift-3-amadeus-red-hat-summit-session-recording-recap/

新建库

建立一个用户名开头的库,如我的github用户名是 martinliu, 新建的库的名字为 martinliu.github.io ; 这个库将是存放web页面的。包括该域名下的站点的所有相关页码代码文件和相关css,图片等文件。

更新并上传新库

参考的命令如下:

[bash] git clone https://github.com/martinliu/martinliu.github.io cd martinliu.github.io echo “Martin Liu’s Github Homepage” > index.html git add –all git commit -m “Initial commit” git push -u origin master [/bash]

打开浏览器测试你的网站,访问网址: http://martinliu.github.io , 你已经可以看到你的初始化页码了。

Jekyll博客系统

Github网站上推荐使用Jekyll创建和管理这个博客系统。它是支持Markdown语法,不需要使用数据库,纯文本的静态网站和博客系统。使用它可以建立和管理一个风格美观,容易管理的网站,生成的网页可以上传到以上生成的网站库中。

安装Jekyll系统

我的测试系统:Fedora 23。操作步骤如下。 安装依赖的包和ruby环境

[bash] dnf install ruby  ruby-devel gem gcc libffi redhat-rpm-config [/bash]

更用国内的rubygem源 [bash] gem source -r https://rubygems.org/ gem source -a http://mirrors.aliyun.com/rubygems/ gem update –system

gem install jekyll [/bash]

##本地测试jekyll站点 进入克隆到本地的库,并创建jekyll站点。

[bash] cd martinliu.github.io rm index.html

jekyll new . New jekyll site installed in /root/martinliu.github.io. [root@demo-w540 martinliu.github.io]# ls about.md     css       _includes   _layouts  _sass _config.yml  feed.xml  index.html  _posts [root@demo-w540 martinliu.github.io]# jekyll server Configuration file: /root/martinliu.github.io/_config.yml Source: /root/martinliu.github.io Destination: /root/martinliu.github.io/_site Incremental build: disabled. Enable with –incremental Generating… done in 0.205 seconds. Auto-regeneration: enabled for ‘/root/martinliu.github.io’ Configuration file: /root/martinliu.github.io/_config.yml Server address: http://127.0.0.1:4000/ Server running… press ctrl-c to stop. [/bash]

编辑站点的相关文件,测试成功之后,在上传到github上,然可到 maritnliu.github.io 上检查和本地的显示效果是否相同。