Centos7将一个应用部署成service服务

参考文章：参考文章1参考文章2

测试环境部署应用太多，每次重启的都要执行很多的命令，于是决定想定制成一个服务，使用的时候就更加的方便。

前言

1. systemctl 命令简单使用

#开启网络服务
systemctl start network.service
#停止网络服务
systemctl stop network.service
#重启网络服务状态
systemctl restart network.service
#查看网络服务状态
systemctl status network.serivce

2. systemctl status命令查询服务状态说明

● halo.service
   Loaded: loaded (/etc/systemd/system/halo.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2020-03-26 11:01:40 CST; 3 months 5 days ago
  Process: 10344 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 10421 (java)
   CGroup: /system.slice/halo.service
           └─10421 /usr/local/jdk1.8/bin/java -server -Xms256m -Xmx256m -jar /root/.halo/halo-latest.jar

上面的输出结果含义如下。

Loaded行：配置文件的位置，是否设为开机启动
Active行：表示正在运行
Main PID行：主进程ID
Status行：由应用本身提供的软件当前状态
CGroup块：应用的所有子进程
日志块：应用的日志

正文

LINUX .service 文件详解

【unit】块

[Unit]  #服务的说明 
Documentation
# 指定服务的文档，可以是一个或多个文档的URL路径。
Description=nginx  # 描述服务
After=network.target remote-fs.target nss-lookup.target # 描述服务类别
After=docker.socket early-docker.target network.target
Requires=docker.socket early-docker.target

# Requires
# 依赖的其他 Unit 列表，列在其中的 Unit 模块会在这个服务启动的同时被启动，并且如果其中有任意一个服务启动失败，这个服务也会被终止。

# Wants
# 与 Requires 相似，但只是在被配置的这个 Unit 启动时，触发启动列出的每个 Unit 模块，而不去考虑这些模块启动是否成功。

# After
# 与 Requires 相似，但会在后面列出的所有模块全部启动完成以后，才会启动当前的服务。

# Before
# 与 After 相反，在启动指定的任一个模块之前，都会首先确保当前服务已经运行。

# BindsTo
# 与 Requires 相似，但是一种更强的关联。启动这个服务时会同时启动列出的所有模块，当有模块启动失败时终止当前服务。反之，只要列出的模块全部启动以后，也会自动启动当前服务。并且这些模块中有任意一个出现意外结束或重启，这个服务会跟着终止或重启。

# PartOf
# 这是一个 BindTo 作用的子集，仅在列出的任何模块失败或重启时，终止或重启当前服务，而不会随列出模块的启动而启动。

# OnFailure
# 当这个模块启动失败时，就自动启动列出的每个模块。

# Conflicts
# 与这个模块有冲突的模块，如果列出模块中有已经在运行的，这个服务就不能启动，反之亦然。

【service】块配置详解

这一块是 .service 文件独有的，也是对于服务配置最重要的一部分。这部分的配置相当的多（服务生命周期控制和服务上下文配置），此处只对常用的参数进行说明。

• Type 服务的类型。常用的有 simple（默认）和 forking。默认的适用于大多数场景，所以没有特殊需要可以不配置该参数。而如果服务程序启动后会通过 fork 系统调用创建子进程，然后关闭应用程序本身进程的情况，则应该将 Type 的值设置为 forking，否则 systemd 将不会跟踪子进程的行为，而认为服务已经退出。
• RemainAfterExit 值为 true、false或者yes、no，默认为false。当配置为true时，systemd会只负责启动服务进程，之后服务即便推出，也会认为在运行中。这个配置主要是提供给一些并非常驻内存，而是启动注册后立即退出然后等待消息按需启动的特殊类型服务使用。
• ExecStart 这个参数每个 .service 文件都会有，制定服务启动的命令。每个配置文件只会有一个生效。
• ExecStartPre 制定在 ExecStart 命令执行之前的操作，可以有多个，按照配置的顺序执行。
• ExecStartPost 在 ExecStart 之后执行，也可以有多个。
• TimeoutStartSec 启动服务时的等待的秒数，如果超过这个时间服务任然没有执行完所有的启动命令，则 systemd 会认为服务自动失败。这一配置对于使用 Docker 容器托管的应用十分重要，由于 Docker 第一次运行时可以能会需要从网络下载服务的镜像文件，因此造成比较严重的延时，容易被 systemd 误判为启动失败而杀死。通常对于这种服务，需要将 TimeoutStartSec 的值指定为 0，从而关闭超时检测。
• ExecStop 停止服务执行的命令
• ExecStopPost 在 ExecStop 执行完成之后执行。
• TimeoutStopSec 停止服务等待的秒数，如果超过时间没有停止，会使用 SIGKILL 信号强制杀死。
• Restart 用于指定什么情况下重启。常用值（no、on-success、on-failure、on-abnormal、on-abort、always）默认 no，即不会自动重启。

no（默认值）：退出后不会重启
on-success：只有正常退出时（退出状态码为0），才会重启
on-failure：非正常退出时（退出状态码非0），包括被信号终止和超时，才会重启
on-abnormal：只有被信号终止和超时，才会重启
on-abort：只有在收到没有捕捉到的信号终止时，才会重启
on-watchdog：超时退出，才会重启
always：不管是什么退出原因，总是重启
对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设为on-abnormal。

• RestartSec 如果服务需要被重启，该值为服务重启前的等待秒数
• ExecReload 重新加载服务所需执行的命令
• Environment 为服务添加环境变量
• EnvironmentFile 指定加载一个包含服务所需的环境变量列表的文件
• Nice 服务进程的优先级，值越小优先级越高，默认为0，-20为最高级，19为最低优先级
• WorkingDirectory 指定服务的工作目录
• RootDirectory 指定服务进程的根目录（ / 目录），如果配置了这个参数后，服务将无法访问指定目录以外的任何文件。
• User 指定运行服务的用户，会影响服务对本地文件系统的访问权限。
• Group 指定运行服务的用户组，会影响服务对本地文件系统的访问权限。

【Install】 块配置说明

这个段中的配置与 Unit 有几分相似，但是这部分配置需要通过 systemctl enable 命令来激活，并且可以通过 systemctl disable 命令禁用。另外这部分配置的目标模块通常是特定启动级别的 .target 文件，用来使得服务在系统启动时自动运行。Target的含义是服务组，表示一组服务。WantedBy=multi-user.target指的是，本服务所在的 Target 是multi-user.target。这个设置非常重要，因为执行systemctl enable .service命令时，.service的一个符号链接，就会放在/etc/systemd/system目录下面的multi-user.target.wants子目录之中。

WantedBy
和前面的 Wants 作用相似，只是后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。

RequiredBy
和前面的 Requires 作用相似，同样后面列出的不是服务所依赖的模块，而是依赖当前服务的模块。

Also
当这个服务被 enable/disable 时，将自动 enable/disable 后面列出的每个模块。

定制服务

配置文件主要放在/usr/lib/systemd/system目录，也可能在/etc/systemd/system目录，在相应的目录下创建配置文件，按照上述规则使用文本编辑器，保存退出。

systemctl daemon-reload
# 重新加载配置文件
systemctl restart *
# 重启相关服务