第四部分 运维

• 第二十三章 配置管理Ansible与Saltstack
• • 1、配置管理系统
  • 2、Ansible
  • 3、Saltstack
• 第二十四章 虚拟化（略）
• 第二十五章 容器
• 第二十六章 持续集成与交付 CI/CD

第二十三章 配置管理Ansible与Saltstack

1、配置管理系统

最常用的CM系统：Ansible、Salt、Puppet、Chef

配置管理术语解读

Ansible易用
Saltstack快

两者都需要借助yaml

2、Ansible

Ansible没有服务器守护进程，也不在客户端安装自己的软件，所以它实际上就是一组命令（其中最值得注意的是ansible-plybook、ansible-vault，以及ansible），安装在你希望用于管理客户端的系统上。

Ansible的主配置文件的默认位置位于/etc/ansible/ansible.cfg。推荐将下列行添加到文件末尾。

[ssh_connection]
pipelining = true

这两行启用了SSH的流水线特性（pipelining），能够显著提高性能。

Ansible能够轻松地将系统范围的配置和个人配置结合起来。不要删除系统配置，只需通过创建~/.ansible.cfg并设置清单文件和角色目录的位置来覆盖它。

[defaults]
inventory = ./hosts
roles_path = ./roles

清单是客户端系统的列表，角色是将客户端配置的各个方面进行抽象的操作集。

客户端设置

• SSH访问；
• python解释器
• 客户端并不会向Ansible自报家门，所以你要将其添加到Ansible的主机清单中。在默认情况下，清单是一个名为/etc/ansible/hosts的文件。

  [wedservers]
  www[01:100].example.com
  [dbservers]
  db-[a:f].example.com
  

• 例如，下列命令使用扩展匹配表达式选择了webservers组，对组中的每个成员执行Ping操作。

  $ ansible 'web*' -m ping
  

任务列表
Ansible将操作称之为“任务”（task），将单个文件中的任务集合称之为任务列表（task list）。和大部分Ansible配置一样，任务列表也都是YAML，所以文件名后缀为.yml。

变量赋值：每个主机都拥有各自以YAML格式定义的一组变量。默认情况下，这些定义保存在/etc/ansible/host_vars和/etc/ansible/group_vars目录下以主机或组命名的文件中。如果需要，可以使用.yml作为文件名后缀。

如下：将sudoers文件的位置和管理员的用户名，将这些信息放入单独的变量文件中，比如说，group_vars/all/admin.yml

sudoers_path: /etc/sudoers
admins:
    - { username: kolor }
    - { username: kolor }

admins的值是一个散列数组，通过迭代该数组来创建所有账户。迭代通过with_items（它是任务的属性，并不是任务执行的操作）

- name: Create personal groups for admins
  groups: name={{ item.username }}
  with_items: "{{ admins }}"
- name: Create admin accounts
  user:
    name: "{{ item.username }}"
    comment: "{{ item.fullname }}"
    group: "{{ item.username }}"
    groups: wheel
  with_items: "{{ admins }}"

从YAML和JSON的角度来看，各项任务形成了一个列表。左侧空白处的每个破折号表示开始了一项新任务，任务本身用散列描述。

state参数
在Ansible中，操作模块经常根据你所请求的state执行不同的任务。例如，对于package模块，state=present会安装该软件包，state=absent会删除该软件包，state=lastest确保该软件包存在且是最新的。

具体看：https://blog.csdn.net/qq_39578545/article/details/106795139

3、Saltstack

Salt的通信总线在服务端使用TCP端口4505和4506，确保位于服务器和客户端之间的防火墙或分组过滤器允许这些端口上的流量通过。

无论是在主服务器还是客户端（minion），Salt的配置文件都位于/etc/salt。

Salt在设置变量值的配置文件（pillar）和定义操作的配置文件（states）之间保持分离。这种区分一直延伸到顶层：你必须为这两个配置层级结构安排不同的位置。两者默认位于/srv之下，后者相当于/etc/salt/master文件。

file_roots:
	base:
		- /srv/salt
pillar_roots:
	base:
		- /srv/pillar	

Pillar是在master端求值，然后作为单个统一的JSON层级结构传递给minion。

minion
minion设置：/etc/salt/minion中设置master，修改完文件后重启salt-minion。

master: salt.example.com
id: new-client.example.com

salt-master可以接受来自任意机器的客户端注册，只要这些机器能够访问到它，但是你必须在主配置服务器上使用salt-key命令批准之后，各个客户端才能变为活动状态。

$ sudo salt-key -l unaccepted
$ sudo salt-key -yA

接受key之后通过test模块检测服务器的连通性。
$ sudo salt new-client.example.com test.ping

new-client.example.com看起来像是个主机名，但其实并非如此。
它只是机器的Salt ID，该ID是一个字符串，默认和主机名一样，
但可以在/etc/salt/minion文件中将其设置为喜欢的任何内容，如上所示

minion匹配
示例：

base:
  '*.example.com':
    - baseline
  'G@os:FreeBSD':
    - freebsd

其中，星号匹配example.com中的所有客户端ID。这里可以只用’*’，这是一个扩展匹配模式。前缀G@用于匹配grain值。所要检查的grain名为os，所要查找的值为freebsd，此处也可以使用扩展匹配。

另外一种比较直观的写法。

'os:FreeBSD':
	- match: grain
	- freebsd

不过@的写法能够清晰地扩展成设计括号和布尔操作的复杂表达式。

匹配的grain或pillar的值是什么，可以通过

$ salt minion grains.items
或
$ salt minion pillar.items

saltstack的state.sls和state.highstate之区别
state.sls默认的运行环境是base环境，但是它并不读取top.sls（top.sls定义了运行环境以及需要运行的sls）。关于state.sls的官方文档说明如下：

salt.modules.state.sls(mods, saltenv='base', test=None, exclude=None, queue=False, env=None,**kwargs)

这里saltenv指的是运行环境，默认是base环境。

state.highstate: 这个是全局的所有环境，以及所有状态都生效。它会读取每一个环境的top.sls，并且对所有sls都生效。

具体看：https://blog.csdn.net/qq_39578545/article/details/114994167

第二十四章 虚拟化（略）

Hypervisor
Hypervisor，又称虚拟机监视器（英语：virtual machine monitor，缩写为 VMM），是用来建立与执行虚拟机器的软件、固件或硬件。被Hypervisor用来执行一个或多个虚拟机器的电脑称为主体机器（host machine），这些虚拟机器则称为客体机器（guest machine）。

KVM：https://blog.csdn.net/qq_39578545/article/details/115052958

第二十五章 容器

Docker：https://blog.csdn.net/qq_39578545/article/details/107741565

K8s：https://blog.csdn.net/qq_39578545/category_10080396.html

第二十六章 持续集成与交付 CI/CD

Jenkins：https://blog.csdn.net/qq_39578545/article/details/115042126

Git：https://blog.csdn.net/qq_39578545/article/details/115584985

CI&CD:

• 持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次， 主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
• 持续交付的目的是最小化部署或发布过程中团队固有的摩擦，它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。
• 持续部署是一种更高程度的自动化，无论何时代码有较大改动， 都会自动进行构建／部署。

我们可以通过jenkins工具平台实现全自动部署+测试，是一个可扩展的持续集成引擎，是一个开源软件项目，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。Jenkins非常易于安装和配置，简单易用。方便如下人员：

1. 开发人员：写好代码，不需要自己进行源码编译、打包等工作，直接将代码分支存放在SVN、GIT仓库即可。 war 源码多 自动把代码放到服务器上面
2. 运维人员：减轻人工干预的错误率，ansible 一键完成了 同时解放运维人员繁杂的上传代码、手动备份、更新

安装Jenkins并关联Gitlab：https://blog.csdn.net/weixin_45310323/article/details/107497121

基于gitlab和jenkins的自动化部署实例：https://blog.csdn.net/aaaaaab_/article/details/82012044

git官方的第三方服务集成jenkins：https://gitee.com/help/articles/4193#article-header13
自动化运维系列二：Jenkins与gitlab实战：https://blog.csdn.net/pcn01/article/details/105412495
利用gitlab的webhook触发jenkins：https://www.jianshu.com/p/2b2c204dcbe2

安装Jenkins出现以下情况：该Jenkins实例似乎已离线。

修改/var/lib/jenkins/hudson.model.UpdateCenter.xml
该文件为jenkins下载插件的源地址，改地址默认jenkins默认为：https://updates.jenkins.io/update-center.json
其他国内备用地址（也可以选择使用）：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
http://mirror.esuni.jp/jenkins/updates/update-center.json

重新在浏览器上登录jenkins，并在linux机器上生成一对秘钥
# ssh-keygen -f ~/.ssh/jenkins #生成密钥对

系统管理–>系统设置，找到之前安装的Publish over SSH插件，Passphrase填写之前生成秘钥时设置的密码，没有则留空，Path to key留空，Key粘贴/root/.ssh/jenkins文件内容。

然后新增SSH Servers，填入对应的hostname，这就是PHP代码要发布的机器

接下来还需要把公钥拷贝到对应的hostname机器（web）上
Jenkins机器：

# cat jenkins.pub

hostname机器：

# cd ~/.ssh/
# vim authorized_keys				#写入内容

浏览器上测试连接有没有问题，点击Test Configuration，如果没问题，左侧会显示Success。

gitlab+jenkins服务简述：https://blog.csdn.net/aaaaaab_/article/details/82012044
GitLab是一个代码仓库，用来管理代码。Jenkins是一个自动化服务器，可以运行各种自动化构建、测试或部署任务。
所以这两者结合起来，就可以实现开发者提交代码到GitLab，Jenkins以一定频率自动运行测试、构建和部署的任务，帮组开发团队更高效的集成和发布代码。

配置gitlab的免密连接：

[root@localhost ~]# cd .ssh/
[root@localhost .ssh]# ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts
[root@localhost .ssh]# cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLfbD7Cp9UddglMLJgc+FHXXk54MrOi7ufyPhRcY2Ugibk8fIgnVKnhjxn5LjkXgqFb09hVeiM6iMnnn0/QkHLv6TuLAJkO5lFQWvivmzXZAvn/hbTyRoBX/Dokre0IGJSS+b/JUG9kXRYxt3GD38D6NbnCszkv+v/3VkzRvmkPxim2WsXu0tqUrU7ZmLxSehHQ0Rso9uChW3UeR+yEczOyuqOSxPuPJ1Vjm+K7KuyS+TPw49Uz/O9zD6bClWaFX8lrBZ6cxNXNSBfpJQqzPOdk/odTPeGyLx5/oiLC+iPpUjuhzBYHsgMTskTNOthcKNEzL9zStpNnC8rl2v2P0R3 root@localhost.localdomain

Access token：


qcbgha3JxqZTX1ZBDqc8
jenkins执行以下命令，通过qcbgha3JxqZTX1ZBDqc8获取认证

[root@jenkins ~]# curl -X PUT --header "PRIVATE-TOKEN: qcbgha3JxqZTX1ZBDqc8"   'http://10.0.100.129/api/v4/application/settings?allow_local_requests_from_hooks_and_services=true'

下图的Secret Toekn是jenkins触发器生成的 60d60e9f8499e16ce142adf4ddb34779，

然后回到gitlab项目的settings，URL是jenkins项目的地址，Secret Toekn是jenkins触发器生成的。

拉下去，点击Add webhook

准备推上去

[root@localhost demo]# git add hello.txt
[root@localhost demo]# git commit -m "add hello.txt"

*** Please tell me who you are.
Run
  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'root@localhost.(none)')

解决：
git config --global user.name "root"
git config --global user.email 123456@qq.com

git config --global user.email "你的邮箱就是git的邮箱"
git config --global user.name "你的用户名"

[root@web demo]# git add hello.txt
[root@web demo]# git commit -m "add hello.txt"
[master 6fb9c0c] add hello.txt
 1 file changed, 3 insertions(+)
 create mode 100644 hello.txt
[root@web demo]# git push origin master
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 287 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@10.0.100.129:root/demo.git
   242722d..6fb9c0c  master -> master

在jenkins网页可以看到提交信息，简单的gitlab集成Jenkins就是这样。后面还可以设置邮箱通知，

 
 
剩下的章节都是文绉绉，实际工作可能用不太到，就此，《Linux系统管理技术手册》就大致看完了。