[CoreOS 转载] CoreOS实践指南（四）：集群的指挥所Fleet

转载：http://www.csdn.net/article/2015-01-14/2823554/2

摘要：CoreOS是采用了高度精简的系统内核及外围定制的操作系统。ThoughtWorks的软件工程师林帆将带来“漫步云端：CoreOS实践指南”系列文章，介绍CoreOS精华和推荐的实践方法。本文为基础第四篇：集群的指挥所Fleet。

集群上的服务生命周期

刚刚的启动流程看起来很简单，不是么？在实际的使用中，如果为了省事，用Fleet启动一个服务，这样做就可以了。但这种做法其实会带来的服务管理上的麻烦，特别当启动出错的时候。因此比较全面的理解Fleet在背后默默做了哪些工作，详细的了解一下Fleet模型中，集群上的服务生命周期是很有必要的。

下面这个图描述了Fleet中的服务从初始到运行，最后终止结束的完整过程中实际存在的几个阶段。

        

Fleet中的服务生命周期        

• 提交服务

服务的提交阶段，这个步骤仅仅是在Fleet服务中完成的，目的是将指定的Unit文件添加到Fleet的记录缓存。此时Fleet并不会与Systemd进行通信。通过             fleetctl list-unit-files 和 fleetctl list-units 命令可以看到，Unit文件被提交后，并没有出现在后者的记录中。此时这个Unit文件已经被注册为一个Fleet可识别的Unit名称，但还不是一个可以执行的的服务。

$ fleetctl submit ${HOME}/hello.service             $ fleetctl list-unit-files             UNIT  HASH  DSTATE  STATE  TARGET             hello.service  4bff33d  inactive  inactive  -             $ fleetctl list-units             UNIT  MACHINE  ACTIVE  SUB

值得指出的是，这一步需要将完整的Unit文件路径作为参数传递给fleetctl，这也是服务在集群的整个Fleet生命周期中唯一一次需要提供完整路径的地方。

使用 fleetctl cat 命令可以打印出已经缓存了的Unit文件内容。

$ fleetctl cat hello.service                 [Unit]                 Description=Hello World                 After=docker.service                 Requires=docker.service                 [Service]                 TimeoutStartSec=0                 ExecStartPre=-/usr/bin/docker kill busybox1                 ExecStartPre=-/usr/bin/docker rm busybox1                 ExecStartPre=/usr/bin/docker pull busybox                 ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "while                true; do echo Hello World; sleep 1; done"                 ExecStop=/usr/bin/docker kill busybox1                 [X-Fleet]                 X-Conflicts=hello.service

和Systemd相似的，这里同样有一个容易犯错地方。由于Fleet已经缓存了整个Unit文件，之后如果原来的Unit文件内容发生改变，单纯的停止并重新启动服务并不会加载新变化的内容。此时若是需要让新的Unit文件被使用，需要重新提交这个文件，也就是再次执行这个submit操作。因此，这里再次强调使用者应该对Fleet管理服务的生命周期有一定了解。

• 加载服务

加载服务实际上是根据Unit文件的 X-Fleet 配置段条件，将服务传递到符合条件的特定节点的本地Systemd系统的过程，这个过程中Fleet通过DBus            API与节点的Systemd进行了通信。

$ fleetctl load hello.service               Unit hello.service loaded on 0acdd9bf.../110.0.2.15             $ fleetctl list-unit-files               UNIT  HASH  DSTATE  STATE  TARGET               hello.service  4bff33d  loaded  loaded  0acdd9bf.../10.0.2.15             $ fleetctl list-units               UNIT  MACHINE  ACTIVE  SUB               hello.service  0acdd9bf.../10.0.2.15  failed  failed

可以看到，现在         fleetctl list-units 已经识别到这个服务了。至此，这个服务的准备工作已经全部就绪。

• 启动服务

启动服务是完成的服务运行周期的最后一个步骤。如之前所提过的，这里如果传递的参数不是服务的名称而是Unit文件的路径，Fleet也会自动完成Unit文件的提交和加载，并启动相应服务。这种做法仅仅在手工操作时可取，若是在自动操作脚本中，假如服务启动出现异常，单纯的从脚本的输出中就很难判断是哪个环节出了问题，会带来管理和排查的困难。

$ fleetctl start hello.service               Unit hello.service launched on 0acdd9bf.../10.0.2.15             $ fleetctl list-unit-files               UNIT  HASH  DSTATE  STATE  TARGET               hello.service  4bff33d  launched  launched             0acdd9bf.../10.0.2.15             $ fleetctl list-units               UNIT  MACHINE  ACTIVE  SUB               hello.service  0acdd9bf.../10.0.2.15  activating             start-pre

刚刚启动的服务会处于start-pre状态（服务正在执行Unit文件中的ExecStartPre部分操作），几分钟后再次查看服务的状态，服务状态就会变为running了。

$ fleetctl list-units                   UNIT  MACHINE  ACTIVE  SUB                 hello.service  0acdd9bf.../10.0.2.15  active  running

• 停止服务

服务不能无休止的运行，终归有需要停止的时候。服务的停止同样会经过三个过程，依次为stop、unload和destroy，其本质上与启动过程一一对应。

$ fleetctl stop hello.service                       Unit hello.service loaded on 0acdd9bf.../10.0.2.15                     $ fleetctl unload hello.service                       Unit hello.service inactive                     $ fleetctl destroy hello.service                       Destroyed hello.service

服务移除后系统又回到了初始的状态。

$ fleetctl list-unit-files                           UNIT  HASH  DSTATE  STATE  TARGET                         $ fleetctl list-units                           UNIT  MACHINE  ACTIVE  SUB

• 服务自动启动

在一边阅读一边实际操作的读者可能已经发现，Fleet的管理工具fleetctl没有enable和disable这两个操作。实际上，只要服务通过fleetctl            start运行起来以后，就已经是自动启动的了。可以通过运行节点本地的Systemd证实（在做这个验证前最好移除之前通过Systemd添加的本地Hello服务，以免影响结果可信度）。

$ fleetctl ssh hello  # 跳转到运行Hello服务的节点             $ systemctl list-units | grep hello               hello2.service  loaded  active running  Hello World             $ systemctl list-unit-files | grep hello               hello2.service  enabled

服务状态和日志

Fleet同样具有跨节点查看服务状态和日志的能力。通过fleetctl status加上服务的名称就能查看服务的基本状态，而不用关心服务运行在哪一个节点上面。

$ fleetctl status hello.service                   ...                   Are you sure you want to continue connecting (yes/no)? yes                 <= 第一次使用的时候需要确认                   ● hello.service - Hello World                   ...                    Main PID: 4964 (docker)                     CGroup: /system.slice/hello.service                     └─4964 /usr/bin/docker run --name busybox1 busybox /bin/sh                 -c while true; do echo Hello World; sleep 1; done                   Jan 10 08:58:07 core-03 docker[4964]: Hello World                   Jan 10 08:58:08 core-03 docker[4964]: Hello World                   Jan 10 08:58:09 core-03 docker[4964]: Hello World                   ...

同样的方式可以查看到任意节点上查看服务输出的日志，相应的命令是 fleetctl journal 。顺带一提，当服务程序使用Systemd/Fleet的方式管理后，其运行过程中输出到std::out                     的内容都会被重定向到日志中。

$ fleetctl journal hello.service                       -- Logs begin at Sat 2015-01-10 02:41:59 UTC, end at Sat 2015-01-10                    08:58:56 UTC. --                       Jan 10 08:58:46 core-03 docker[4964]: Hello World                       Jan 10 08:58:47 core-03 docker[4964]: Hello World                       Jan 10 08:58:48 core-03 docker[4964]: Hello World                       ...

fleetctl fournal常用的参数有：指定输出日志行数的 --lines 和跟随日志输出的 --follow (或-f) 。

fleetctl journal --lines 20 hello.service                     fleetctl journal -f hello.service

小结

在这一篇中，我们详细了解了在CoreOS集群中通过Fleet查看和管理集群的操作。CoreOS中的Fleet服务通过Etcd（一种分布式数据存储服务）获得集群的服务信息并通过DBus接口操作Systemd控制集群中任意节点的服务状态，在CoreOS集群上提供了跨节点，分布式，高容错的服务部署和管理能力。

在下一篇中，我们会深入CoreOS的另一个服务模块，Fleet幕后的数据功臣——Etcd的使用。敬请期待。（作者/林帆  责编/周小璐）