深入浅出CoreOS(三):Systemd和Fleet

简介: 本文讲的是深入浅出CoreOS(三):Systemd和Fleet,【编者的话】Systemd并不是CoreOS特有的服务。本质上说Systemd是没有依附于任何一个Linux发行版的独立项目,但是很多发行版Linux都在青睐Systemd管理服务的优势,所以CoreOS选择了它。
本文讲的是深入浅出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:
coreos-overview-3-0.png

要想把服务发布进集群,就必须提交合规范的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
目录
相关文章
|
4月前
|
Prometheus Kubernetes 监控
云原生|kubernetes |使用Prometheus监控k8s cAdvisor篇(进阶篇--- 一)(centos操作系统)
云原生|kubernetes |使用Prometheus监控k8s cAdvisor篇(进阶篇--- 一)(centos操作系统)
327 0
|
9月前
|
存储
KubeSphere 基础知识,KubeSphere 入门了解
KubeSphere 基础知识,KubeSphere 入门了解
253 0
|
30天前
|
边缘计算 Kubernetes Linux
KubeSphere平台安装系列之三【Linux多节点部署KubeSphere】(3/3)
KubeSphere平台安装系列之三【Linux多节点部署KubeSphere】(3/3)
27 1
|
Kubernetes API 调度
Kubernetes必备知识: CNI
CNI的全称是 Container Network Interface,即容器网络的 API 接口。 它是 K8s 中标准的一个调用网络实现的接口。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式。实现了这个接口的就是 CNI 插件,它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、flannel、Terway、Weave Net 以及 Contiv。
1941 0
Kubernetes必备知识: CNI
|
4月前
|
Kubernetes Cloud Native Linux
云原生|kubernetes |kubelet服务加入系统守护进程supervisor(centos7系统下演示通过)
云原生|kubernetes |kubelet服务加入系统守护进程supervisor(centos7系统下演示通过)
57 0
|
11月前
|
存储 监控 关系型数据库
Ceph的核心组件的介绍(基于nautilus版本)
Ceph的核心组件的介绍(基于nautilus版本)
180 0
|
开发工具 git Docker
Docker社区版中Kubernetes开发
Docker社区版已经提供了对Kubernetes的支持。但是由于其安装过程依赖的镜像服务在国内访问很不稳定,很多朋友都无法配置成功。我们提供了一个简单的工具帮助大家开启Kubernetes功能
33869 0
|
Linux 调度 Docker
CoreOS 入门
本文讲的是CoreOS 入门【编者的话】本文是一篇 CoreOS 入门文章。分别介绍了 CoreOS 的三个主要组件——配置和服务发现、应用程序管理和调度以及应用程序,对一些概念进行了解释,并初步介绍了一些 CoreOS 的高阶组件供读者探索。
5408 0