本文讲的是CoreOS上的Fleet，第二部分，【译者的话】紧接前一篇文章，这篇文章是介绍fleet的一些命令，用来管理托管在它之上的服务的。
在我前一篇文章中，我们学到了fleet当一个集群中的节点挂了时，是怎么重新安排服务来让程序保持可用。描述具体点，就是原本在挂了的节点上跑的代码会自动迁移到集群中其它的可用节点上。从外部看来，你的应用平滑运行如斯。
如果你有兴趣了解fleet是如何适配CoreOS的更多细节，我们可以深入了解之前一篇关于self-sufficient containers的文章。
在这篇文章里，我会介绍下与fleet交互的一些命令。这为后续的介绍fleet的更多高级功能的文章打一个基础。但是在我们开始介绍这些命令前，我们先重新看一遍单元配置文件。因为后面介绍的那些命令，多数就是在操作单元配置文件的。
单元配置文件
如你所知，单元配置文件定义了你要在集群中跑的服务。可以想成它就是fleet管理应用的方式。
你可能会想：“我可以手工操作来跑应用么？” 当然可以咯，不过如果你这么做，fleet就不能得知这个应用的情况，因此也不能管理这个应用。所以我们还是需要用fleet的单元配置文件来定义这个应用成fleet里的服务。
所以，我们应该怎么用fleet的单元配置文件？
首先，让我们来看一下那些我们可用来加载并运行单元配置文件的命令。然后我们再看其他的fleet命令。
启动一个服务
通过fleet运行一个服务，需要几个必要的步骤。
第一步是，上传单元配置文件到fleet去。 单元配置文件必须是上传到集群中XXXX的机器去。只有这样才可以启动这个服务。fleetctl的CLI工具有这些步骤所需的全部命令了。
我们来看看submit命令。
Submit
submit这条命令可以把单元配置文件提交到fleet去。然后fleet就会读取文件的内容到内存去，然后就可进行后面的操作。
看起来就像这样的：
$ fleetctl submit myapp.service
你的myapp.service文件现在就会被fleet读取到了。
然后，你就可以用list-unit-files命令来看单元配置文件是不是已经被提交了。
像这样：
$ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET myapp.service 0d1c468 inactive inactive -
如你所见，单元配置文件已经被提交了，但是还没有安排它到集群中的节点去。
如果想看已经提交了的单元配置文件的内容，你可以敲以下的命令：
$ fleetctl cat myapp.service [Unit] Description=My Service After=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill hello ExecStartPre=-/usr/bin/docker rm hello ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop hello
注意，如果你重新提交一次单元配置文件，fleet不会在内存中更新该单元配置文件的内容的。如果你想更新它，你必须移除后重新提交。
Load
一旦提交了你的单元配置文件，下一步就是安排它到机器上面去跑了。
当我们安排一个单元配置时，fleet会决定集群中哪台机器是跑该单元配置的最优选择。fleet会根据单元配置文件的内容跟集群中每一台机器的最近工作卷来下决定。然后fleet就将单元配置文件传到目标机器，并且将其加载到机器的systemd中去。
你可以用load命令来加载并安排单元配置，像这样：
$ fleetctl load myapp.service Unit myapp.service loaded on 43cb4dc3.../172.31.9.57
现在，如果你再查看一下单元配置文件，你就会看到它已经被加载了，而且你还看到目标节点的IP地址。
像这样：
$ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET myapp.service 0d1c468 loaded loaded 43c.../172.31.9.57
我们现在就可以用list-units命令来展示已经安排好或者在跑着的单元配置还有它们的状态。
像这样：
$ fleetctl list-units UNIT MACHINE ACTIVE SUB myapp.service 43cb4dc3.../172.31.9.57 inactive dead
Start
要启动一个单元配置，你需要用start命令。命令可以让单元配置在已经加载好的机器上启动。
像这样启动一个单元配置：
$ fleetctl start myapp.service Unit myapp.service launched on 43cb4dc3.../172.31.9.57
然后你可以这样再检查一下单元配置文件的列表：
$ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET myapp.service 0d1c468 launched launched 43cb.../172.31.9.57
如你所见，单元配置的状态的是launched了，注意：DSTATE一列的意思是期望的状态，而STATE一列的意思是实际的状态。如果这两列是匹配的，则表示操作没问题了。
你也可以接着这么检查：
$ fleetctl list-units UNIT MACHINE ACTIVE SUB myapp.service 43cb4dc3.../172.31.9.57 active running
要注意的是，list-unit-files输出的是，list-units输出的是关于systemd状态等等的信息。这些信息都是从被安置了单元配置文件的机器的守护进程直接收集到的。所以这看到的信息是比较直观地暴露出该服务在机器上的状态。
ACTIVE一列显示的是单元配置的概括性的状态描述，而SUB则是更低层次的描述。
移除一个服务
我们刚才学到的每一个命令都有与之对应的相反功能的命令。
Stop
用stop这命令，可以将运行中的服务停止。这命令作用是跑着服务的机器本机的systemd执行定义在单元配置文件里面的stopping命令。
你可以这样子做：
$ fleetctl stop myapp.service Unit myapp.service loaded on 43cb4dc3.../172.31.9.57
如你所见，这服务的状态回复到loaded状态。这服务是仍然加载在机器中的systemd的。只是并没有运行。
我们可以这样来确认下状况：
$ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET myapp.service 0d1c468 loaded loaded 43cb.../172.31.9.57
Unload
如果你想将单元配置从目标机器中的systemd去除，而又还保留在fleet中，你可以卸下这个单元配置。
如果该单元配置是active状态的，它会先被停止了，然后才卸下。
你可以这样子做：
$ fleetctl unload myapp.service Unit myapp.service inactive
现在，你就可以再检查一下状态：
$ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET myapp.service 0d1c468 inactive inactive -
你可以看到，单元配置被标记为inactive。另外，它也没有了目标机器的信息。
Destroy
如果你希望完全地将单元配置从fleet中去除掉，你可以用destroy命令。该命令将会先把单元配置所定义的服务停止，然后从机器中卸下该单元配置，最后才从fleet中去除。
像这样运行：
$ fleetctl destroy myapp.service Destroyed myapp.service
前面也说过了，如果你修改了单元配置文件，你必须先销毁该单元配置，再重新提交，然后启动它。那是因为单元配置文件一旦被提交到fleet，它是静态的，不可被更新的。
获取服务状态
我们已经看到两个命令都可以获取到状态信息了，list-units和list-unit-files。list-units命令会列出全部安排在机器上的单元配置。list-unit-files命令则会展示全部fleet上全部的单元配置文件，以及还有它的预期状态，跟实际状态。
但是如果我们觉得这样的信息还不足够呢？
幸运的是，还有两个命令可以用来获取单个服务更加具体的信息。
Status
status命令反馈回来的信息是跑着单元配置的机器的systemctl的状态。
这看起来是像这样的：
$ fleetctl status myapp.service ● myapp.service - My Service Loaded: loaded (/run/fleet/units/myapp.service; linked-runtime; vendor preset: disabled) Active: active (running) since Fri 2016-03-25 14:02:24 UTC; 51min ago Process: 2965 ExecStartPre=/usr/bin/docker pull busybox (code=exited, status=0/SUCCESS) Process: 2954 ExecStartPre=/usr/bin/docker rm hello (code=exited, status=0/SUCCESS) Process: 2945 ExecStartPre=/usr/bin/docker kill hello (code=exited, status=1/FAILURE) Main PID: 2977 (docker) Memory: 11.4M CPU: 435ms CGroup: /system.slice/myapp.service └─2977 /usr/bin/docker run --name hello busybox /bin/sh -c while true; do echo Hello World; sleep 1; done Mar 25 14:53:35 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:36 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:37 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:38 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:39 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:40 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:41 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:42 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:43 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 14:53:44 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World
如你所见，我们最终可证实我们定义的单元配置正如预期运行着。
Journal
如果你希望只是看下某单元配置的服务的日志儿不是完整的执行信息。你可以单独使用journal命令。
如下：
$ fleetctl journal hello.service -- Logs begin at Fri 2016-03-25 10:08:44 UTC, end at Fri 2016-03-25 16:19:04 UTC. -- Mar 25 16:18:55 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:18:56 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:18:57 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:18:58 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:18:59 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:19:00 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:19:01 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:19:02 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:19:03 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World Mar 25 16:19:04 ip-172-31-9-57.ap-southeast-1.compute.internal docker[2977]: Hello World
默认情况下，只会显示最新的10行
你可以用--lines参数来调整行数：
$ fleetctl journal --lines 20 hello.service
也可以用-f参数：
$ fleetctl journal -f hello.service
这个功能类似于tail -f，让你实时看到新增部分的日志。
结尾
在这篇文章中，我们看到了：
用来提交，加载和启动单元配置的命令
用来停止，卸下和销毁单元配置的命令
用来检查单元配置状态的命令
这是这fleet系列的第二篇文章，我的第一篇文章介绍了单元配置跟粗略看了一遍fleet的功能，这系列的下一篇文章，我们将会讲解下fleet的API。
原文链接： Fleet on CoreOS, Part Two（翻译：伍健源）
原文发布时间为：2016-06-03
本文作者：Coolxwu
本文来自合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：CoreOS上的Fleet，第二部分