好久没用kvm虚拟话了，之前有台物理机配置比较高，就借助kvm虚拟化技术虚拟了几台虚拟机做实验完，但是今天启动报如下错误：

[root@kvm-labs kvm]# virsh start centos7-lab-node1

error: Failed to start domain centos7-lab-node1

error: unsupported configuration: Unable to find security driver for model selinux

根据错误提示，怀疑是系统selinux的问题，但是发现selinux是disabled，难道要强制用selinux，不合理啊。重新梳理逻辑，kvm虚拟机是可被定义的，是不是定义的配置文件中有selinux相关定义，那是不是可以去掉，经过实验还真ok，解决步骤如下。

1. 进入虚拟机配置文件目录

cd /etc/libvirt/qemu/

# 如果你构建环境修改过默认路径，根据实际情况进入

2. 编辑虚拟机配置文件

vim  centos7-lab-node1.xml



  .....................

   <input type='tablet' bus='usb'>

      <address type='usb' bus='0' port='1'/>

    </input>

    <input type='mouse' bus='ps2'/>

    <input type='keyboard' bus='ps2'/>

    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>

      <listen type='address' address='0.0.0.0'/>

    </graphics>

    <video>

      <model type='cirrus' vram='16384' heads='1' primary='yes'/>

      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

    </video>

    <memballoon model='virtio'>

      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>

    </memballoon>

    <rng model='virtio'>

      <backend model='random'>/dev/urandom</backend>

      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>

    </rng>

  </devices>

 <seclabel type='dynamic' model='selinux' relabel='yes'/>

</domain>

如上，删除<seclabel type='dynamic' model='selinux' relabel='yes'/> , 然后保存退出。

3. 重新定义配置文件

virsh define ./centos7-lab-node1.xml

然后重新执行virsh start centos7-lab-node1 就可以了。

如果想迁移虚拟机的存储路径也可以关机，修改配置文件下的存储路径，并将.qcow2文件移动到相应的目录下即可.

<disk type='file' device='disk'>

      <driver name='qemu' type='qcow2'/>

      <source file='/data/kvmdata/centos7-lab-node1.qcow2'/>

      <target dev='vda' bus='virtio'/>

      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>

</disk>

修改完成后，然后重新定义配置文件，重启虚拟机即可。

1. 重启系统，在选择进入系统界面按字母e

2. 在rhgb前添加’rw’ ,在行末添加 ‘init=/bin/sh’ ,按 ‘Ctrl+x’ 进入系统

进入系统后，修改密码

echo "www.baidu.com | passwd --stdin root

touch /.autorelabel

exec /sbin/init

等待一会，点击回车，进入重启。

什么是CVSS

通用弱点评价体系(CVSS)是由NIAC开发、FIRST维护的一个开放并且能够被产品厂商免费采用的标准。利用该标准，可以对弱点进行评分，进而帮助我们判断修复不同弱点的优先等级。

CVSS(Common Vulnerability Scoring System)，即”通用漏洞评分系统”，是一个”行业公开标准，其被设计用来评测漏洞的严重程度，并帮助确定所需反应的紧急度和重要度”。

它的主要目的是帮助人们建立衡量漏洞严重程度的标准，使得人们可以比较漏洞的严重程度，从而确定处理它们的优先级。CVSS得分基于一系列维度上的测量结果，这些测量维度被称为量度(Metrics)。漏洞的最终得分最大为10，最小为0。

得分7~10的漏洞通常被认为比较严重，得分在4~6.9之间的是中级漏洞，0~3.9的则是低级漏洞。

CVSS系统包括三种类型的分数：基本分数、暂时分和环境分。

基本得分和临时得分通常由安全产品卖主、供应商给出，因为他们能够更加清楚的了解漏洞的详细信息；

环境得分通常由用户给出，因为他们能够在自己的使用环境下更好的评价该漏洞存在的潜在影响。

所以应该是基于漏洞库的扫描, 需要预先知道该漏洞的威胁值？

就是说漏洞应该预先有脆弱性等级，系统的安全性评估是综合各个漏洞来进行的?

CVSS 2.0 计算方法： 通用漏洞评估方法CVSS 3.0 计算公式及说明 - caya - 博客园 (cnblogs.com)

一些指标具有不确定性和复杂性，会导致完全的定量分析困难。3个客观性指标和11个主观性指标。下一步：指标量化（客观性指标量化和主观性指标量化）。

CVSS评分计算方法

A. 基本评价(Base Metric)

基本评价指的是该漏洞本身固有的一些特点及这些特点可能造成的影响的评价分值

基础评价 = 四舍五入(10 * 攻击途径 攻击复杂度 认证 ((机密性 机密性权重) + (完整性 完整性权重) + (可用性 可用性权重)))

B.生命周期评价(Temporal Metric)

是针对最新类型漏洞（如: 0day漏洞）设置的评分项，因此SQL注入漏洞不用考虑。

因此这里也列举出三个与时间紧密关联的要素如下：

生命周期评价 =四舍五入(基础评价 可利用性 修复措施 * 未经确认)

C.环境评价(Environmental Metric)

每个漏洞会造成的影响大小都与用户自身的实际环境密不可分，因此可选项中也包括了环境评价，这可以由用户自评。（用户扫描配置时填写）

环境评价 = 四舍五入<(生命周期评价 + [(10 -生命周期评价) *危害影响程度]) *目标分布范围>

评分与危险等级

传统的应用发布模式

如果你经历体验过传统的应用发布，你可能就会觉得CICD有足够吸引你的地方，反之亦然。一般一个研发体系中都会存在多个角色：开发、测试、运维。当时我们的应用发布模式可以能是这样的：

• 开发团队在开发环境中完成软件开发，单元测试，测试通过，提交到代码版本管理库;
• 开发同学通知运维同学项目可以发布了，然后运维同学下载代码进行打包和构建，生成应用制品;
• 运维同学使用部署脚本将生成的制品部署到测试环境，并提示测试同学可以进行产品的测试;
• 测试同学开始进行手动、自动化测试，测试完成后提醒运维同学可以进行预生产环境部署;
• 运维同学开始进行预生产环境部署，然后测试同学进行测试，测试完成后，开始部署生产环境。

当然我描述的可能只是其中的一部分，手动操作很多、出现的问题很多。上面看似很流畅的过程，其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致：开发人员本地测试成功后提交代码，运维同学下载代码进行编译却出现了错误。

存在的问题:

1. 错误发现不及时: 很多错误在项目的早期可能就存在，到最后集成的时候才发现问题;
2. 人工低级错误发生: 产品和服务交付中的关键活动全都需要手动操作;
3. 团队工作效率低: 需要等待他人的工作完成后才能进行自己的工作;
4. 开发运维对立: 开发人员想要快速更新，运维人员追求稳定，各自的针对的方向不同。

经过上述问题我们需要作出改变，如何改变？

什么是CICD

软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的机会。

此方法有三种主要方法，每种方法都将根据最适合您的策略的方式进行应用。

持续集成 CI(Continuous Integration)

在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。

开发人员通常使用一种叫做CI Server的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作，这些测试通常被称为单元测试（Unit tests）。

代码集成以后，当所有的单元测试通过，史蒂夫和安妮就得到了一个绿色构建（Green Build）。这表明他们已经成功地集成在一起，代码正按照测试预期地在工作。然而，尽管集成代码能够成功地一起工作了，它仍未为生产做好准备，因为它没有在类似生产的环境中测试和工作。

CI是需要对开发人员每次的代码提交进行构建测试验证。确定每次提交的代码都是可以正常编译测试通过的。在没有持续集成服务器的时候，我们可以写一个程序来监听版本控制系统的状态，当出现了push动作则触发相应的脚本运行编译构建等步骤。现在有了专业的持续集成服务器后，我们借助持续集成服务器来实现版本控制系统中代码提交触发构建测试等验证步骤。

持续合并开发人员正在开发编写的所有代码的一种做法。通常一天内进行多次合并和提交代码，从存储库或生产环境中进行构建和自动化测试，以确保没有集成问题并及早发现任何问题。

开发人员提交代码的时候一般先在本地测试验证，只要开发人员提交代码到版本控制系统就会触发一条提交流水线，对本次提交进行验证。

持续交付 CD (Continuous Delivery)

Continuous Delivery (CD) 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。

持续交付CD：是基于持续集成的基础上，将集成后的代码自动化的发布到各个环境中测试（DEV TEST UAT STAG），确定可以发布生产版本。这里我们可以借用制品库实现制品的管理，根据环境类型创建对应的制品库。一次构建，到处运行。

• 开发环境发布：我们可以将开发环境产出的制品部署进行测试，没有问题后上传到测试环境的制品库中。
• 测试环境发布：此时通知测试人员可以进行测试环境发布测试，获取测试环境制品库中的制品，发布到测试环境验证。验证通过将制品上传到预生产环境制品库。
• 预生产环境发布：获取预生产环境制品，进行部署测试。测试成功后可以将制品上传到生产库中。
• 手动部署生产环境。

持续交付是超越持续集成的一步。不仅会在推送到代码库的每次代码更改时都进行构建和测试，而且，作为附加步骤，即使部署是手动触发的，它也可以连续部署。此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。

持续部署 CD(Continuous Deploy)

如果真的想获得持续交付的好处，应该尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障。于是有了持续部署。

通常可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中。持续部署 会更进一步，并自动将更改推送到生产中。类似于持续交付，持续部署也是超越持续集成的进一步。不同之处在于，您无需将其手动部署，而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。

持续部署CD：是基于持续交付的基础上，将在各个环境经过测试的应用自动化部署到生产环境。其实各个环境的发布过程都是一样的。应用发布到生产环境后，我们需要对应用进行健康检查、添加应用的监控项、 应用日志管理。

我们通常将这个在不同环境发布和测试的过程叫做部署流水线， 持续部署是在持续交付的基础上，把部署到生产环境的过程自动化。

参考:

https://blog.csdn.net/weixin_40046357/article/details/107478696

http://www.idevops.site/gitlabci/chapter01/01/

https://www.jianshu.com/p/654505d42180