深入浅出CoreOS（三）：Systemd和Fleet
本文讲的是深入浅出CoreOS（三）：Systemd和Fleet，
【编者的话】Systemd并不是CoreOS特有的服务。本质上说Systemd是没有依附于任何一个Linux发行版的独立项目，但是很多发行版Linux都在青睐Systemd管理服务的优势，所以CoreOS选择了它。Fleet是管理CoreOS和部署app的工具。有了Fleet，你就可以把整个CoreOS集群当做一台节点来处理。让我们一起学习关于此方面的内容。
这是深入浅出CoreOS系列文章中的第三篇，也是最后一篇。
在 上一篇 文章中，我们学习了cloud-config配置文件，在代理模式下运行etcd，以及关于etcd集群的一些常规设置。这篇文章中，我们将探讨Systemd、Unit文件、Fleet和Fleetctl。
Systemd概述
Systemd是CoreOS用于初始化系统的工具。它能提供许多强大的功能，例如启动服务、停止服务、监控和重启进程等。在CoreOS中，Systemd既可以用来管理Docker容器的生命周期，又可以管理不同系统的启动任务。要想进一步学习Systemd，必须要深入查看一系列关于Systemd的博客。不过，在此我们只讨论需要CoreOS上的Docker容器上操作所需要的一些Systemd知识。
更多关于Systemd的内容，可以参考 官方文档 。
Unit文件
Systemd为每一个守护进程记录一个初始化结构文件，我们称之为Unit文件。Systemd系统取代了传统系统为每一个守护进程初始化一次脚本的做法。这样的记录会有很多不同种类的Unit文件，但是我们只会关注可以运行Docker容器的服务类型Unit文件。下面列表，按照顺序是一个服务Unit（service unit）生命周期内的过程，以及作用描述：
- ExecStartPre: ExecStart之前运行的命令（指定在启动执行 ExecStart 的命令前的准备工作，可以有多个，如前面第二个例子中所示，所有命令会按照文件中书写的顺序依次被执行。编者注）
- ExecStart:运行这个Unit最主要的命令（这个参数是几乎每个 .service 文件都会有的，指定服务启动的主要命令，在每个配置文件中只能使用一次。编者注）
- ExecStartPost：ExecStart 运行完成后要执行的命令（指定在启动执行 ExecStart 的命令后的收尾工作，也可以有多个。编者注）
- ExecReload：当使用 systemctl重新加载服务所需执行的命令
- ExecStop：通过执行systemctl 确认Unit服务失败或者停止时执行的命令
- ExecStopPost：ExecStop 执行完成之后所执行的命令（指定在 ExecStop 命令执行后的收尾工作，也可以有多个。编者注）
- RestartSec：在重启服务之前系统休眠时间（很有效的防止失败服务少于100ms重启一次）（如果服务需要被重启，这个参数的值为服务被重启前的等待秒数。编者注）
下面我们演示创建一个
Hello_world.service
的简单Unit文件：
[Unit] Description=HelloWorldApp After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker rm busybox1 ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --rm --name busybox1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop busybox1 [Install] WantedBy=multi-user.target
让我们仔细来看一下刚才创建这个Unit文件:
- Description： 可以在Systemd日志展示（可以通过journalctl和Systemdctl来检查日志文件）
- After=docker.service 和 Requires=docker.service 意思是只有docker.service启动后才可以被激活。当然也可以定义自己的动作.你也可以使用多个After来做限制，多个after使用空格分开即可
- =- 是Systemd忽略错误的一个语法.在这种情况下，docker会发挥一个非0的退出码，如果想停止一个不存在的容器，这对我们来说并不是一个错误。
- ExecStartPre=-/usr/bin/docker rm busybox1 如果 busybox1镜像存在，则删除它。 如果镜像不存在，则脚本继续往下运行。
- ExecStartPre=/usr/bin/docker pull busybox 将从注册中心获取最新的busybox
- ExecStart= 当Unit开始启动，这里允许你执行想运行的命令。但是不要用-d来启动Docker容器，因为这样讲组织docker作为一个子进程被启动. Systemd会认为进程已经退出，相应的Unit也会停止。
- ExecStop=/usr/bin/docker stop busybox1 busybox1容器将会被停止.
- WantedBy=multi-user.target" 当启动 multi-user.target时，Systemd将会将获取Unit。
如果要启动一个新的Unit，必须使用Systemd创建symlink，然后启动文件：
$ sudo systemctl enable /etc/Systemd/system/hello.service $ sudo systemctl start hello.service
要验证Unit是否启动，我们可以检查正在运行的容器列表：
Docker ps
然后，通过journalctl命令输出Unit，如下：
$ journalctl -f -u hello.service -- Logs begin at Fri 2014-02-07 00:05:55 UTC. -- Feb 11 17:46:26 localhost docker[23470]: Hello World Feb 11 17:46:27 localhost docker[23470]: Hello World Feb 11 17:46:28 localhost docker[23470]: Hello World [...]
-u指的是unit，-f指的是一起，可以按CTRL+C随时退出。Systemd服务Unit（services unit）只能运行在一台机器上。它只能用于单任务的场景，比如下载文件或者重启机器等。
更多关于Systemd Units的知识， 请参考文档 。
FLEET 概述
Fleet运行在Systemd上层，在集群层次控制Systemd，负责创建分布式Systemd：
要想把服务发布进集群，就必须提交合规范的Systemd unit。
FLEETCTL
Fleetctl是官方推荐的控制fleet unit工具，它可以在本地或者远程CoreOS集群使用。Fleetctl命令类似于systemctl命令，必须在命令前面加上sudo命令在配合使用。Fleetctl命令可以直接在集群上运行。或者如果你喜欢从外部主机执行fleetctl（即你的工作站），可以通过SSH把系统环境变量作为参数传递给集群机器，像这样：$ export FLEETCTL_TUNNEL=remote_machines_ip
让我们看一下你可以执行的任务，列出所需的命令。
开始Unit服务：
$ fleetctl start hello_world.service
检查Unit服务状态：
$ fleetctl status hello_world.service
停止服务：
$ fleetctl stop hello_world.service
查看服务文件：
$ fleetctl cat hello_world.service
提交服务：
$ fleetctl submit hello_world.service
查看日志：
$ fleetctl journal hello_world.service
SSH访问服务
$ fleetctl ssh hello_world.service
服务列表：
$ fleetctl list-units
列举集群机器：
$ fleetctl list-machines
Unit 文件
Fleet主要是依赖Unit文件交互的。对于Systemd Unit，它定义了想要做什么以及fleet应该如何去做，在集群中Fleet安排一到多台机器，Fleet安排一个有效的Unit文件。在[X-Fleet]部分留意fleet的一些特殊部分，可以用来替换Systemd Unit的[install]部分。其余Systemd部分保持与fleet相同。我们一起看一下特殊的部分配置：
- MachineID: 规定每一个机器的唯一字符串编号
- MachineOf: 对那些有特定Unit，限制的机器才可以有
- MachineMetadata: 限制那些有特定元数据的机器
- Conflicts: 防止一个Unit使用其他Unit名字glob-matching合并其它Unit
- Global: 在所有集群机器上规定这个Unit
上面所有的都在Unit文件的[X-Fleet]部分。除非Unit文件上MachineMetadata提供配置Global=true，否则我们认为这个文件是无效的。如果你想在所有集群或者MachineMetadata指定值得机器上规定相同的Unit，全局Unit文件就非常有用了。
下面我们来看一下上述提到的Fleet Unit中使用的hello_world.service文件：
[Unit] Description=HelloWorldApp After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker rm busybox1 ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --rm --name busybox1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop busybox1 [X-Fleet] MachineMetadata=group=hw_webservers Conflicts=hello_world@*
例子中的
hello_world@*
是做什么的？
好的，让我们来说说
hello_world@1.service
and
hello_world@2.service
两个完全相同的文件。
在集群上启动：
$ fleetctl start hello_world@*
这两个Fleet文件都部署在
MachineMetadata=group=hw_webservers
配置的服务器，配置
Conflicts=hello_world@*
意图是防止一个Unit使用了
global-matching
与Unit文件冲突。
让我们看另一个
hello_world.service
Unit文件的例子。
规定集群中所有的机器：
[X-Fleet] Global=true
规定机器上有
some_other_unit.service
Unit：
[X-Fleet] MachineOf=some_other_unit.service
规定Unit机器的编号为：562999f8
[X-Fleet] MachineID="562999f8"
获取机器ID：
$ fleetctl list-machines
关于fleet Unit更多的只是， 参考官方文档 。
集群中运行一个容器
你要做的就是提供一个严格格式的【install】部分Unit文件，如下：[Unit] Description=hello_docker After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker rm busybox1 ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --rm --name busybox1 busybox /bin/sh -c "while true; do echo Hello Docker; sleep 1; done" ExecStop=/usr/bin/docker stop busybox1
注意：如果你是手动运行docker命令，请确保不要在命令行中复制运行命令在分离模式中开启一个容器，这种做法将会使会造成容器运行几秒钟后自动退出。
总结
这篇文章中：- 为Systemd写入Unit文件
- 如何用Fleet创建分布式Systemd
- 为Fleet写入Unit文件
请不要忘了系列的上两篇文章，在 第一篇 我们讲述了CoreOS的基础原理 ，自动升级，发布渠道，集群发现等。在 第二篇 文章中，我们熟悉了cloud-config，etcd等。
下一个系列中，主要学习Docker。
原文链接：CoreOS Overview, Part Three（翻译：张亚龙）
原文发布时间为：2016-02-25
本文作者：ylzhang
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：深入浅出CoreOS（三）：Systemd和Fleet
