神刀安全网

CoreOS上的Fleet,第二部分

【译者的话】紧接前一篇文章( http://dockone.io/article/119 8),这篇文章是介绍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-unitslist-unit-fileslist-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 (翻译:伍健源)

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » CoreOS上的Fleet,第二部分

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址