热门标签:

  • 管家
  • 当前位置:首页>管家
CoreOS实践指南(三):系统服务管家Systemd
发布时间:2015-03-19 16:10 作者:义乌搬家公司、义乌家政公司 [] [] []

【编者按】作为一个操作系统,CoreOS 采用了高度精简的系统内核及外围定制,将许多原本需要复杂人工操作或者第三方软件支持的功能在操作系统级别进行了实现,同时剔除了其他对于服务器系统非核心的软件,比如GUI和包管理器。来自ThoughtWorks的软件工程师林帆将带来“漫步云端:CoreOS实践指南”系列文章,带大家了解CoreOS的精华和推荐的实践方法。本文为基础第三篇:系统服务管家Systemd。

CoreOS实践指南(三):系统服务管家Systemd

作者简介:

林帆,生在80后尾巴的IT攻城狮,ThoughtWorks成都办公室CloudOps小组成员,平时喜欢在业余时间研究DevOps相关的应用,目前在备考AWS认证和推广Docker相关技术。

在系列教程的第一篇里我们已经提到了Systemd,它主要的设计目标是克服传统Linux主流启动程序SysVinit 固有的缺点,提高系统的启动速度。相比同类的 SysVinit 竞争者,例如Ubuntu 的 upstart,Systemd 的设计更加前卫,简单来说,它的设计思路借鉴了Mac系统的启动程序Launchd。事实上Systemd的作用远不仅是启动系统,它还接管了系统服务的启动、结束、状态查询和日志归档等职责,并支持定时任务和通过特定事件(如插入特定USB设备)和特定端口数据触发的任务。在CoreOS的世界里,推荐的做法是使用Systemd来管理所有用户服务,包括运行在应用容器(如Docker)中的服务。

值得指出的是,Systemd并不是CoreOS特有的服务。本质上说Systemd是没有依附于任何一个Linux发行版的独立项目,由于Systemd的作者Lennart Poettering 就职于红帽,整个项目实际由RedHat公司主导。虽然RedHat Linux直到2014年中旬才用上Systemd,但RedHat旗下的Fedora早在2011年时就已经引进了Systemd作为其启动管理程序了。

在开始使用Systemd之前,先了解一下Systemd有哪些特别之处。

Systemd 的设计理念
  • 尽可能启动更少进程
  • 当SysVinit 程序初始化系统的时,会将所有可能用到的后台服务进程全部运行起来。然而用户需要等待系统将所有服务都启动完成之后,才能够登录。这种做法会带来两个问题:系统的启动时间过长和系统资源的浪费。

    Systemd 提供了服务按需启动的能力,使得特定的服务只有在被真正请求的时候才启动。特别是具体硬件相关的服务,比如蓝牙服务仅在蓝牙适配器被插入时才需要运行,打印服务仅在打印机连接或程序要打印时才需要运行,甚至sshd服务也只需要在用户使用ssh连接到服务器时才需要启动。这种能力是建立在对Systemd对DBus总线或特定Socket端口监听的特性上的,这种设计相比于传统启动程序具有颠覆性的进步。 

  • 尽可能将更多进程并行启动
  • 在SysVinit的时代,将每个服务项目编号的方式依次执行启动脚本。后来Ubuntu的Upstart解决了没有直接依赖的启动项之间的并行启动。而Systemd通过Socket缓存、DBus缓存和建立临时挂载点等方法进一步解决了启动进程之间的依赖,做到了所有系统服务并发启动,这一设计同样是Systemd独具特色的创意。当然,对于用户自定义的服务,Systemd允许配置其启动依赖项目,从而确保服务按必要的顺序运行,稍后会详细描述具体的使用方法。 

    CoreOS实践指南(三):系统服务管家Systemd


    Systemd启动模型与其它启动模型的对比

  • 采用 Cgroup 跟踪和管理进程的生命周期
  • Cgroup的全称是controller group,是将任意进程进行分组化管理的Linux内核功能,最初由Google的工程师提出,从Linux内核版本2.6.24正式启用。拿Android来说,它的应用程序隔离就是使用的这种技术。而很长一段时间里,在更广阔的服务器领域,一直并没有一种主流的服务管理程序能够充分利用这种早已在手机端带来广泛好处的特性。

    而Systemd正是Cgroup方面的行家,它的出现正好弥补了这个领域的缺漏。通过Cgroup,Systemd不仅实现了服务之间的访问隔离,还能够限制特定应用程序对系统资源访问配额(比如CPU的用量、内存的量),以及精确的管理服务的生命周期。在这篇文章的后面部分会讲述相关操作具体的做法。

  • 统一管理服务日志
  • 使用Systemd 必须知道的还有它的伙伴:Journald日志服务,这个服务的设计初衷是克服现有syslog服务的日志内容易伪造和日志格式不统一等缺点,而它现在已经是Systemd的一个标准子服务了。Journald用二进制格式保存所有日志信息,用户需要使用 journalctl 命令来查看日志信息。在这篇文章的后面会介绍如何查看服务的日志。 
    第一个Hello World服务
  • Unit和Target
  • 先介绍两个概念,Unit和Target。

    Unit是Systemd管理服务的基本单元,可以认为每个服务就是一个Unit,并使用一个Unit文件定义。Unit文件中需要包含相应服务的描述、属性以及需要运行的命令。在CoreOS中服务运行的命令通常是一系列的容器操作,而将具体的服务进程封装在容器中。

    Target是Systemd中用于指定服务启动组的方式(相当于SysVinit中的“运行级别”,如果不清楚这个概念也没有关系,搜索“Linux运行级别”可以查到很多相关文章)。每次系统启动的时候都会运行与当前系统相同级别Target关联的所有服务,如果服务不需要跟随系统自动启动,则完全可以忽略这个Target的内容。通常来说我们大多数的Linux用户平时使用的都是“多用户模式”这个级别,对应的Target值为“multi-user.target”。

  • Hello World服务的Unit文件
  • 只说不做假把式,现在我们来用Systemd创建一个简单的系统服务。

    在这个系列的上一节内容里,我们创建了一个由3个CoreOS虚拟机节点组成的集群,在这节中,我们只需要使用到其中的任意一个,比如coreo-01节点。首先使用ssh连接进入这个节点(这种方法适用于Linux/Mac用户,对于Windows用户需使用Putty客户端, 具体参考)。

    vagrant ssh core-01

    登录成功后提示符变成 “core@core-01 ~ $” ,祝贺你又向CoreOS迈出了重要一步,接下来就可以开始在CoreOS里面玩耍了。

    Systemd约定,服务的Unit文件需放置在 /etc/systemd/system 或  /usr/lib/systemd/system 目录中,但由于在CoreOS的后一个目录是只读分区(整个/usr目录挂载的都是只读的系统分区),因此我们通常会将用户定义的Unit服务文件放在在/etc/systemd/system目录中。进入这个目录,新建一个叫“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” 
    [Install] 
    WantedBy=multi-user.target

    本站关键词:义乌家政公司 义乌搬家公司 义乌保姆月嫂 义乌钟点工

    Copyright©义乌市一心一意家政公司 All rights reserved. design by 义乌搬家公司

    地址:义乌市稠江街道楼下村一区 电话:13355891119

    本站部分信息来源于互联网,不代表本站观点或立场,转载如有侵权,请来电告知,我们将及时处理.