Jenkins的使用

一、Jenkins是什么\有什么用\与GitLab的对比

Jenkins是一个开源的自动化服务器，主要用于持续集成和持续部署（CI/CD）项目。 它允许团队通过自动化来加速软件开发过程，管理和控制软件交付的整个生命周期，包括构建、文档、测试、打包、部署、静态代码分析等。

Jenkins的前身是Hudson，由Sun公司在2004年启动，并于2005年发布了第一个版本。 Hudson在2007年开始逐渐取代其他开源构建工具，成为持续集成领域的主流工具。 然而，在2010年Oracle收购Sun公司后，由于商标名称“Hudson”的所有权问题，项目的主要贡献者和Oracle之间产生了分歧。 因此，在2011年1月，社区投票决定将项目名称从“Hudson”更改为“Jenkins”。

关于Jenkins名字的由来，它来源于一个叫做"Servant Jenkins"的虚构角色，他是一位绅士的仆人。这个名称旨在反映出Jenkins工具的主要目的：为开发者提供服务。 这个名字象征着Jenkins作为一个服务于开发者的工具，帮助他们自动化构建和部署流程。

---

Jenkins是一个开源的自动化服务器，主要用于构建、测试和部署软件项目。它提供了一个易于使用的界面，可以通过简单的配置来实现持续集成和持续交付。Jenkins的主要功能包括自动化构建、测试和报告、持续集成、自动化部署以及可扩展性。Jenkins的主要用途包括持续集成和持续交付、自动化测试等。

GitLab是一个集成了版本控制、持续集成/持续交付(CI/CD)、项目管理和协作的完整DevOps平台。GitLab CI/CD用于存储和管理代码、自动化CI/CD流程、跟踪问题、保护代码安全和协作。

Jenkins与GitLab的对比：

1. 集成与自动化：

   • Jenkins是一个高度可定制的自动化服务器，可以与各种工具和服务集成，如Git、GitHub、Bitbucket等。
   • GitLab提供了与GitLab其他功能的紧密集成，包括代码管理、问题跟踪、代码审查等。

2. 易于使用：

   • GitLab提供了一个简单直观的用户界面，使得CI/CD管道的设置和配置更加容易。
   • Jenkins虽然功能强大，但需要一定的技术专业知识来设置和配置，学习曲线较陡峭。

3. 性能：

   • GitLab以其快速、可靠的性能而闻名，具有内置的缓存和并行处理功能。
   • Jenkins在运行大型且复杂的管道时可能会遇到性能问题，需要手动优化以确保性能。

4. 安全：

   • GitLab具有内置的安全功能，提供代码扫描、漏洞管理和容器扫描等功能。
   • Jenkins严重依赖插件来实现安全功能，这可能会使确保管道安全变得具有挑战性。

5. 成本：

   • GitLab提供免费和付费计划，免费计划包括小团队CI/CD所需的大部分功能。
   • Jenkins是一个开源工具，可以免费使用，但设置和维护可能需要大量资源，这可能会增加总体成本。

6. 社区和支持：

   • Jenkins拥有一个大型且活跃的社区，提供广泛的文档、插件和资源。
   • GitLab也有一个不断增长的社区，并提供商业支持选项。

总的来说，Jenkins和GitLab CI/CD都是强大的CI/CD工具，选择哪一个取决于你的具体需求和偏好。GitLab提供了一个集成的解决方案，而Jenkins则更加灵活，可以通过插件进行定制。

---

Jenkins是一个开源的自动化服务器，它主要用于自动化各种任务，包括构建、测试和部署软件项目。以下是Jenkins实现自动化部署的具体方法和步骤：

1. 安装与启动：

   • 首先，确保服务器已安装Java环境，然后下载Jenkins的WAR包进行安装。在命令行中执行java -jar jenkins.war来启动Jenkins。启动成功后，通过浏览器访问http://localhost:8080即可看到Jenkins的欢迎页面。

2. 配置网络与安全：

   • 在初次使用Jenkins时，需要设置管理员账号和密码。设置完成后，进入系统设置，配置网络设置和代理设置（如果有需要）。

3. 安装插件：

   • 为了实现自动化部署，需要安装一些插件来支持工作。例如，安装Git插件来支持从Git仓库获取代码。在“管理插件”页面搜索并安装所需的插件。

4. 配置构建任务：

   • 在Jenkins中，构建任务是通过“新建构建任务”来创建的。选择“自由风格”项目，然后填写项目名称。在“配置”页面中，需要配置源码管理、构建触发器和构建环境三个部分。

5. 配置构建步骤：

   • 在构建步骤中，可以配置自动化部署的具体操作。例如，使用“执行shell”步骤来运行一些命令，这些命令可以是自动化部署脚本或命令行指令。

6. 查看构建结果：

   • 配置完成后，保存并开始构建任务。构建结果会显示在Jenkins主页上。如果构建失败，可以通过查看日志来诊断问题。如果需要查看更详细的日志信息，可以打开Jenkins的Web界面并查看相应构建任务的日志。

7. 持续集成与持续部署（CI/CD）：

   • 通过Jenkins自动化部署的实践，可以逐渐完善CI/CD流程。通过自动化测试和静态代码分析来保证代码质量，通过自动化部署来提高开发效率。同时，还可以通过Jenkins的插件和扩展来实现更多的功能，例如蓝绿部署、灰度发布等。

8. 使用Pipeline：

   • Jenkins的Pipeline功能可以将构建、测试、打包、部署等步骤串联起来，自动化地将应用程序从开发环境推送到生产环境。Pipeline通过Jenkinsfile定义，可以在源码管理系统中进行版本控制。

9. 主从架构：

   • Jenkins的主从架构允许在多台机器上分布构建任务，提高构建和部署的效率。

10. 插件支持：

    • Jenkins拥有广泛的插件支持，这些插件可以扩展Jenkins的功能，包括自动化部署、安全、报告等。

通过这些步骤和功能，Jenkins能够实现从代码提交到自动上线的全流程自动化，减少人为错误，提升软件发布的效率和质量。

---

Jenkins是一个功能强大的自动化服务器，适用于多种类型的项目，尤其是那些需要频繁构建、测试和部署的软件开发项目。以下是一些特别适合使用Jenkins的项目类型：

1. 大型软件开发项目：对于规模较大、复杂度较高的软件开发项目，Jenkins提供了强大的自动化构建和测试能力，能够显著提高开发效率和质量。

2. 持续集成/持续部署（CI/CD）项目：Jenkins是CI/CD流程的核心工具之一，能够自动化地从代码仓库中获取代码更改，触发构建任务，运行测试，并将软件部署到指定的环境中。

3. 多语言、多技术栈项目：Jenkins支持多种编程语言和工具，通过丰富的插件生态系统，可以轻松扩展其功能，支持各种开发流程和工具的集成，因此特别适合那些涉及多种语言和技术栈的项目。

4. 需要频繁迭代和发布的项目：对于需要快速迭代和发布的项目，如互联网产品、移动应用等，Jenkins的自动化构建和部署能力能够显著缩短发布周期，提高响应速度。

5. 对构建和测试环境有严格要求的项目：Jenkins提供了丰富的构建配置选项，允许用户自定义构建步骤、触发器、构建后操作和通知机制，因此特别适合那些对构建和测试环境有严格要求的项目。

6. 需要分布式构建的项目：Jenkins支持分布式构建，可以将构建任务分发到多个节点上并行执行，从而提高构建效率。这对于大型项目或需要处理大量构建任务的项目来说是一个显著的优势。

7. 需要详细构建和测试报告的项目：Jenkins提供了详细的构建历史和工作流视图，以及构建和测试的报告生成功能，这对于需要详细跟踪和记录构建和测试过程的项目来说非常有用。

8. 需要与其他工具集成的项目：Jenkins具有强大的插件机制，可以与各种版本控制系统、构建工具、测试框架、通知系统等集成，因此特别适合那些需要与其他工具协同工作的项目。

总的来说，Jenkins适用于那些需要高度自动化、频繁迭代和发布、对构建和测试环境有严格要求、需要详细构建和测试报告以及需要与其他工具集成的软件开发项目。通过合理配置和使用Jenkins，可以显著提高项目的开发效率和质量，降低人工操作的风险和成本。

---

二、Jenkins的安装与配置

Jenkins的安装方式

Jenkins的安装与配置可以根据不同操作系统和环境有所不同。以下是在不同环境下安装和配置Jenkins的一般步骤：

官网权威的安装方式：RedHat系列的Jenkins的安装

在Linux上安装Jenkins：

1. 安装Java：
   Jenkins需要Java环境，因此首先需要安装Java。对于大多数Linux发行版，可以使用包管理器安装Java。

   sudo apt-get update
   sudo apt-get install openjdk-11-jdk
   

Jenkins和JDK各版本的兼容性：

具体见官网：Java Support Policy

2. 下载Jenkins：
   访问Jenkins官方网站下载最新版本的Jenkins WAR文件。

3. 启动Jenkins：
   使用Java命令启动Jenkins。

   java -jar jenkins.war
   

这将在http://localhost:8080启动Jenkins。

4. 解锁Jenkins：
   第一次启动Jenkins时，需要解锁。访问http://localhost:8080，页面会显示一个初始管理员密码。这个密码可以在/var/lib/jenkins/secrets/initialAdminPassword文件中找到（对于Linux）。复制这个密码并粘贴到Jenkins的解锁页面。
   
   如：96877ec39fb541ca86389e6ce6fd20cd

5. 安装推荐的插件：
   解锁后，Jenkins会提示你安装推荐的插件。可以选择安装或稍后手动安装。

6. 创建管理员用户：
   创建一个管理员用户，输入用户名和密码。

7. 完成安装：
   完成上述步骤后，Jenkins安装完成，可以开始使用。

在Windows上安装Jenkins：

1. 安装Java：
   下载并安装Java运行环境（JRE）或Java开发工具包（JDK）。

2. 下载Jenkins：
   从Jenkins官网下载Windows版本的安装程序。

3. 运行安装程序：
   双击下载的.msi文件，按照提示完成安装。

4. 启动Jenkins服务：
   安装完成后，Jenkins将自动启动。你也可以通过Windows服务管理器手动启动Jenkins服务。

5. 访问Jenkins：
   在浏览器中访问http://localhost:8080，按照Linux安装中的步骤解锁Jenkins、安装插件和创建管理员用户。

配置Jenkins：

1. 系统配置：

   • 在Jenkins的系统配置页面，可以设置Jenkins的全局配置，如Jenkins URL、构建历史记录、系统消息等。

2. 安装插件：

   • 在“管理Jenkins” > “管理插件”中，可以安装、更新和管理插件。

3. 配置工具：

   • 在“管理Jenkins” > “全局工具配置”中，可以配置JDK、Maven、Git等工具的路径。

4. 设置权限：

   • 在“管理Jenkins” > “管理用户”中，可以添加用户和设置权限。

5. 创建新任务：

   • 在Jenkins首页，点击“新建”来创建新的任务（Job）。配置任务的源码管理、构建触发器、构建环境等。

6. 配置构建步骤：

   • 在任务配置中，添加构建步骤，如执行shell脚本、调用Gradle/Maven等。

7. 配置后构建操作：

   • 在任务配置中，设置构建成功后的操作，如发送通知、发布Javadoc等。

8. 使用Pipeline：

   • 对于复杂的构建流程，可以使用Jenkins Pipeline来定义和执行构建流程。

9. 备份和恢复：

   • 定期备份Jenkins的数据和配置，以便在需要时恢复。

10. 监控和日志：

    • 监控Jenkins的性能和日志，以便及时发现和解决问题。

这些步骤提供了Jenkins安装和配置的基本框架。根据具体需求，可能还需要进行更详细的配置和优化。

（可选）配置启动用户为root（一定要是root吗??何时需要root?）

配置Jenkins的启动用户为root并不是必要的，而且在大多数情况下，这是不推荐的做法。以下是几个关键点来解释为什么：

1. 安全性：运行Jenkins（或任何服务）作为root用户会带来安全风险。如果Jenkins的进程被恶意利用，攻击者将拥有root权限，这可能导致系统被完全控制。因此，出于安全考虑，最好以非root用户运行Jenkins。

2. 权限管理：Jenkins在执行构建任务时可能需要访问文件系统和其他资源。如果Jenkins以root用户运行，它将拥有对系统的完全访问权限，这可能会导致不必要的权限过度，增加了误操作和安全风险。相反，可以通过配置适当的权限和使用sudoers文件来安全地授权Jenkins执行需要更高权限的操作。

3. 最佳实践：在Linux系统中，最佳实践是尽可能以非特权用户运行服务。这样可以限制服务的权限，减少潜在的损害。如果Jenkins需要执行特定的命令或访问特定的文件，可以通过配置文件系统权限或使用sudo来实现，而不是将整个Jenkins服务以root用户运行。

4. 灵活性和控制：使用非root用户运行Jenkins可以提供更好的灵活性和控制。例如，可以为Jenkins用户配置特定的sudo权限，允许它执行特定的管理任务，而不需要全局root权限。

5. 系统和Jenkins的配置：大多数Jenkins的安装和配置指南推荐使用默认的jenkins用户，而不是root。这是因为Jenkins的Omnibus包（用于Red Hat和Debian系统）已经预配置了jenkins用户和组，并且提供了适当的权限设置。

综上所述，配置Jenkins的启动用户为root并不是必要的，也不是推荐的做法。应该遵循安全最佳实践，以非root用户运行Jenkins，并在需要时通过适当的权限管理策略来授权Jenkins执行特定的任务。

---

配置Jenkins的启动用户为root并不是常规推荐的做法，因为这会带来安全风险。然而，在某些特定的场景下，可能需要将Jenkins配置为以root用户运行。以下是一些可能需要配置JENKINS_USER="root"的情况：

1. 权限问题：在构建项目后需要执行一些需要root权限的shell命令时，可能会出现权限不足的情况，导致构建失败。在这种情况下，为了解决权限问题，可能会将Jenkins的启动用户设置为root。

2. Docker和Kubernetes操作：当Jenkins和Kubernetes master安装在同一台机器上，并且需要通过Jenkins pipeline执行shell命令来更新已经运行的容器时，由于k8s通常是以root用户运行的，为了能够操作kubectl，Jenkins可能需要有root权限。

3. 系统配置：在某些特定的系统配置中，可能需要Jenkins以root用户运行以访问特定的系统资源或执行系统级别的操作。

4. NFS权限问题：在Kubernetes中部署Jenkins时，如果Jenkins容器以非root用户启动，而NFS服务器上的目录是以root用户启动的，可能会遇到权限问题。在这种情况下，可能需要将Jenkins的启动用户设置为root以解决权限问题。

总的来说，将Jenkins配置为以root用户启动是一个特定情况下的解决方案，通常不推荐这样做，因为它会增加安全风险。在大多数情况下，应该尽量避免以root用户运行Jenkins，而是通过配置适当的权限和使用sudoers文件来安全地授权Jenkins执行需要更高权限的操作。

---

在Jenkins中将JENKINS_USER设置为root通常不是一个推荐的做法，因为这会带来安全风险。但是，如果你确实需要这样做，以下是一些可能的方法来配置Jenkins以root用户运行：

对于Jenkins WAR文件运行方式：

1. 直接使用命令行：
   如果你通常是通过命令行启动Jenkins WAR文件，可以通过以下方式以root用户运行Jenkins：

   sudo java -jar jenkins.war
   

   这将使用root用户启动Jenkins。

2. 设置环境变量：
   你可以在启动Jenkins之前设置JENKINS_USER环境变量，但请注意，这通常不会改变Jenkins的运行用户，除非你的启动脚本或服务管理器支持这个变量：

   export JENKINS_USER=root
   java -jar jenkins.war
   

对于Jenkins服务运行方式（使用init脚本或systemd）：

1. 修改init脚本：
   如果你使用的是基于init的系统（如使用/etc/init.d/jenkins），你可以编辑init脚本，将Jenkins的启动命令更改为使用root用户。例如：

   sudo nano /etc/init.d/jenkins
   

   找到启动Jenkins的行，将其更改为：

   sudo -u root java -jar /path/to/jenkins.war
   

   然后重新启动Jenkins服务：

   sudo service jenkins restart
   

2. 修改systemd服务文件：
   如果你使用的是基于systemd的系统，你可以编辑Jenkins的systemd服务文件：

   sudo nano /etc/systemd/system/jenkins.service
   

   找到ExecStart行，将其更改为：

   ExecStart=/usr/bin/java -jar /path/to/jenkins.war
   

   然后添加以下行来指定用户：

   User=root
   Group=root
   

   保存并重新加载systemd配置：

   sudo systemctl daemon-reload
   sudo systemctl restart jenkins
   

注意事项：

• 安全性：再次强调，以root用户运行Jenkins会带来安全风险。确保你了解这些风险，并且这是你确实需要的。
• 权限管理：如果你需要Jenkins执行特定的需要高权限的操作，考虑使用sudo或su命令来限制权限，而不是将整个Jenkins服务以root用户运行。
• 文件权限：确保Jenkins的家目录和所有相关文件的权限设置正确，以便root用户可以访问。

在实际操作中，通常推荐的做法是创建一个具有必要权限的非root用户，并以该用户运行Jenkins，同时通过适当的权限管理策略来控制对系统资源的访问。

（可选）配置提升的Jenkins的插件的下载速度下载源

vim /var/lib/jenkins/hudson.model.UpdateCenter.xml 

将下面的地址替换成国内下载源地址即可


或者在网页中配置:
插件管理里面的URL设置：

配置Jenkins的插件

git插件

gitlab插件

maven插件

ssh插件

sonar插件

Jenkins的Sonar插件是指用于将SonarQube集成到Jenkins持续集成/持续部署（CI/CD）流程中的插件。SonarQube是一个开源的平台，用于持续检查代码质量，它能够检测代码中的错误、漏洞、代码异味（code smells）以及技术债务等。

什么是SonarQube

SonarQube通过对代码库进行静态代码分析来评估代码质量。它支持多种编程语言，并且可以集成到开发流程中，帮助开发团队提高代码质量、减少技术债务，并及早发现潜在的代码问题。

Jenkins的Sonar插件有什么用

1. 代码质量分析：

   • Jenkins的Sonar插件允许在构建过程中自动触发SonarQube的代码质量分析。
   • 它将代码提交到SonarQube服务器进行分析，并生成详细的代码质量报告。

2. 集成到CI/CD流程：

   • 插件使得SonarQube可以无缝集成到Jenkins的CI/CD流程中，确保每次代码提交或合并请求（MR/PR）都会触发代码质量检查。
   • 这有助于自动化代码审查过程，并在代码合并到主分支之前识别问题。

3. 质量门禁（Quality Gates）：

   • SonarQube的“质量门禁”功能允许设置代码质量的阈值。如果代码质量不满足预设的标准，构建会失败，这样可以阻止低质量的代码被合并。
   • Jenkins的Sonar插件支持这些质量门禁，确保只有符合质量标准的代码才能通过。

4. 历史趋势和比较：

   • 插件可以帮助追踪代码质量的历史趋势，比较不同版本之间的代码质量变化。
   • 这有助于团队理解代码质量的变化，并采取相应的改进措施。

5. 问题追踪和修复：

   • 通过Jenkins的Sonar插件，开发人员可以直接在Jenkins界面中查看SonarQube报告的问题。
   • 开发人员可以更容易地定位问题，并在Jenkins中直接修复这些问题。

6. 报告和通知：

   • Jenkins可以配置为在SonarQube分析完成后发送通知，例如通过邮件或其他集成工具。
   • 这有助于团队成员及时了解代码质量分析的结果。

7. 自定义和扩展：

   • Jenkins的Sonar插件支持自定义SonarQube分析参数，以适应特定的项目需求。
   • 它还允许与其他Jenkins插件集成，以实现更复杂的构建和部署流程。

总的来说，Jenkins的Sonar插件是一个强大的工具，它将代码质量分析集成到自动化构建和部署流程中，帮助团队提高代码质量，减少技术债务，并确保软件的可靠性和安全性。

pipeline插件

Jenkins存放插件的目录：

/var/lib/jenkins/plugins/

---

Jenkins支持多种类型的插件，以扩展其功能和适应不同的使用场景。以下是一些主要的插件类型及其用途：

1. 代码管理插件：

   • 支持集成不同的版本控制系统，如Git、Subversion等。

2. 项目及视图插件：

   • 允许用户使用目录管理项目，支持嵌套目录和视图创建，如Folders Plugin。

3. 构建触发插件：

   • 支持多种构建触发方式，包括周期性触发、远程触发、基于代码变更的触发等，如Gerrit Trigger、GitLab Hook、GitHub Integration等。

4. 构建参数插件：

   • 提供丰富的参数类型，支持参数间动态关联、多层级参数、隐藏参数等，如nodelabelparameter、Hidden Parameter等。

5. 构建任务及环境插件：

   • 提供构建前后清理工作空间、设置构建描述、构建名字等功能，如Workspace Cleanup、description setter等。

6. 构建通知插件：

   • 支持构建状态通知，包括邮件通知、Slack通知等，如Mailer、Slack Notification Plugin。

7. 容器化Slave插件：

   • 支持将Jenkins Slave节点容器化，如Docker Plugin、Kubernetes Plugin。

8. 安全和权限插件：

   • 提供细粒度的访问控制和用户认证，如Matrix Authorization Strategy Plugin、PAM Authentication plugin、LDAP Plugin等。

9. CI/CD Pipeline插件：

   • 支持Pipeline的定义和执行，如Pipeline Plugin，包括Declarative Pipeline和Scripted Pipeline。

10. 其他实用插件：

    • 包括但不限于邮件扩展、HTTP请求、Xvfb（虚拟X服务器）、Job Generator、Job DSL Plugin等。

这些插件使得Jenkins能够适应各种不同的自动化需求，从代码管理到构建、测试、部署，再到通知和安全控制，Jenkins插件系统提供了强大的扩展能力。

通过本地文件安装插件

.hpi文件是Jenkins插件的安装包文件，它代表“Hudson Plugin Interface”，是Jenkins插件的分发格式。每个.hpi文件都是自包含的，包含了运行插件所需的所有代码、图像和其他资源。

.hpi文件与Jenkins插件的关系非常密切，因为它们是插件的安装包。当用户从Jenkins的更新中心下载插件或者手动上传插件时，插件就是以.hpi文件的形式存在的。

在Jenkins中，插件可以自动从更新中心下载，包括它们的依赖关系，这些插件被打包成.hpi文件。当插件通过Jenkins的Web UI安装时，.hpi文件会被重命名为.jpi扩展名，并且存储在JENKINS_HOME/plugins目录下。这种重命名是Jenkins在手动安装时将.hpi文件转换为.jpi文件的一部分，以确保在重启后上传的版本可以覆盖现有版本。

总的来说，.hpi文件是Jenkins插件的安装包，与Jenkins插件的使用和分发密切相关。

---

*三-pre、代码上线大致流程

GitLab中创建项目

提供给开发提交代码

创建分支

• 可以按照项目功能创建分支
• 可以按照开发人员的名字创建不同开发人员写的代码的分支
• 可以按照项目的版本创建分支

可以配置分支保护避免其他人随便访问修改

提交代码到对应的分支

提交审核工单 是否将分支合并

从GitLab中的拉取对应的仓库版本代码

后端代码编译 构建

使用工具(sonarqube)代码质量检测

灰度发布

在负载均衡器上摘除需要更新的机器

将代码推送到那个需要更新的机器的站点目录

绑定测试域名 对代码进行功能等测试

如果测试没有问题 就将该机器重新接入负载均衡器中

如果有问题 那么回滚

三、Jenkins与GitLab仓库配合实现将Web应用代码自动化部署到Web服务器

三-1、基本流程

Jenkins是一个开源的自动化服务器，可以用于自动化各种任务，包括构建、测试和部署软件。GitLab是一个基于Web的Git仓库管理系统，提供代码库、代码审查、项目管理和CI/CD（持续集成/持续部署）等功能。Jenkins与GitLab配合实现自动化部署的基本流程如下：

1. 配置GitLab

首先，在GitLab上创建一个项目，并将您的Web应用代码推送到这个项目中。

2. Jenkins与GitLab集成

• 安装GitLab插件：在Jenkins中安装GitLab插件，以便Jenkins可以与GitLab集成。
• 配置GitLab服务器：在Jenkins的系统配置中，添加GitLab服务器的连接信息，包括GitLab的URL、访问凭证等。

3. 创建Jenkins项目

在Jenkins中创建一个新的项目，并配置以下内容：

• 源代码管理（SCM）：指定GitLab项目作为源代码管理工具，并输入项目的Git仓库地址。同时，配置相关的凭据，以便Jenkins可以拉取代码。
• 构建触发器：设置触发构建的条件，常见的有：
  • 轮询SCM：Jenkins定时检查GitLab仓库中的变化。
  • Webhooks：GitLab在代码推送后通过Webhook通知Jenkins触发构建。

注：这里的“Git仓库地址”可识别的前提是Jenkins机器的是提前安装了git命令且Jenkins机器登录用户的ssh-keygen生成的公钥是存储到Gitlab页面的ssh密钥配置中的
且Jenkins机器与gitLab仓库的机器之间需要进行如下的指纹验证EDSA：

4. 配置构建和部署

• 构建步骤：定义构建步骤，例如编译代码、运行测试等。
• 部署步骤：定义部署步骤，这可能包括：
  • 使用SSH连接到部署服务器。
  • 将构建好的应用文件（例如WAR、JAR包或静态文件）复制到部署服务器。
  • 在部署服务器上执行部署脚本，如重启Web服务器或应用服务器。

---

这句话中的“构建”一词通常指的是在软件开发过程中，将源代码转换成可执行程序的过程。这个过程可能包括多个步骤，比如编译代码（将高级编程语言转换成机器语言）、链接（将编译后的代码与库文件合并成一个单一的可执行文件）、运行测试（确保代码按照预期工作）等。简而言之，“构建”就是将代码从原始形式转换成可以在计算机上运行的形式的一系列操作。

---

5. 配置Webhook

在GitLab项目设置中，找到Webhooks部分，并添加Jenkins的Webhook URL。这样，每当代码被推送到GitLab时，GitLab就会发送一个POST请求到Jenkins，触发一个新的构建。

6. 构建和部署

• 当代码被推送到GitLab仓库时，根据配置的触发器，Jenkins会自动开始构建过程。
• Jenkins会从GitLab拉取最新的代码，执行构建步骤，如果构建成功，接着执行部署步骤。
• 部署步骤会将应用部署到Web服务器，并确保应用可以正常运行。

7. 监控和日志

• Jenkins提供了构建历史和日志，方便监控构建和部署过程。
• 如果构建或部署失败，Jenkins会提供失败的详细信息，帮助开发者快速定位问题。

通过以上步骤，Jenkins与GitLab的集成可以实现代码的自动化构建和部署，提高开发效率，减少人为错误，并加快软件交付的速度。这种集成还支持持续集成和持续部署的实践，使得开发团队能够快速响应需求变化，持续改进软件产品。

三-2、能否单独使用GitLab实现上面的自动化部署到Web服务器

是的，GitLab本身提供了一个强大的CI/CD功能，允许您直接在GitLab中配置和实现自动化部署流程，而不需要依赖外部的CI/CD工具如Jenkins。GitLab CI/CD通过.gitlab-ci.yml文件来定义构建和部署的流程。以下是使用GitLab实现自动化部署的基本步骤：

1. 创建.gitlab-ci.yml文件

在您的GitLab项目的根目录下创建一个.gitlab-ci.yml文件，这个文件定义了CI/CD的管道（pipeline），包括各种阶段（stages），如build、test和deploy。

2. 定义构建和部署步骤

在.gitlab-ci.yml文件中定义构建和部署的步骤。例如：

stages:
  - build
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."
    - ./gradlew build # 假设您使用Gradle作为构建工具

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the application..."
    - 'which rsync || (apt-get update -y && apt-get install rsync -y)'
    - rsync -avz --delete build/ deploy_user@deploy_server:/path/to/webserver_directory
  only:
    - master # 只在master分支上部署

3. 配置部署凭据

为了使GitLab能够访问您的Web服务器，您需要在GitLab项目的设置中配置部署凭据：

• 添加部署凭据：在项目的Settings > CI/CD > Variables中添加新的变量，例如DEPLOY_SERVER、DEPLOY_USER和DEPLOY_PATH，分别用于存储部署服务器的地址、用户名和目标路径。
• SSH密钥：生成SSH密钥对，并在GitLab项目的Settings > Repository > SSH keys中添加公钥。确保私钥保存在安全的地方，GitLab CI/CD运行器将使用它来访问您的服务器。

4. 触发CI/CD管道

当您推送代码到GitLab仓库时，GitLab CI/CD会自动触发管道。您可以在项目的CI/CD > Pipelines中查看管道的运行状态。

5. 监控部署

GitLab提供了详细的管道和作业日志，您可以在CI/CD > Pipelines中查看每个部署作业的输出，以监控部署过程。

6. 处理部署失败

如果部署失败，GitLab会显示错误信息，您可以根据日志信息进行调试和修复。

使用GitLab CI/CD的好处是，您可以完全在GitLab中管理代码、构建和部署流程，无需额外的CI/CD服务器或工具。这简化了管理流程，并使得整个开发、构建和部署流程更加一体化。此外，GitLab CI/CD还支持环境、动态环境、手动部署批准等高级功能，以适应更复杂的部署需求。

三-3、Jenkins使用Shell脚本+参数化构建过程

*不使用“参数化构建传参给脚本”的脚本

例如：

Jenkins的参数化构建是什么及具体如何使用

---

在Jenkins中使用“参数化构建过程”以及配合“Build step”中的“执行shell”的过程可以分为以下几个步骤：

1. 启用参数化构建过程

首先，你需要在Jenkins中创建一个自由风格的项目。在项目的配置页面中，找到“General”部分，并勾选“参数化构建过程”选项。这样，你就可以为构建任务添加参数了。

2. 添加参数

在“参数化构建过程”选项被勾选后，你可以添加不同类型的参数，例如字符串参数、布尔参数、选择参数等。这些参数可以在构建过程中被引用，以实现不同的构建行为。

3. 在构建步骤中使用参数

在“构建”选项卡中，你可以添加任意数量的构建步骤。在构建步骤中，你可以使用特殊的变量来引用传递的参数。例如，如果你传递了一个名为“BRANCH”的参数，则可以使用${BRANCH}来引用该参数的值。

4. 执行shell构建步骤

在构建步骤中，你可以选择“Execute shell”选项来执行shell命令。在“Command”文本框中输入你想要在Linux终端执行的命令。你可以输入多个命令，每行一个。

5. 使用参数执行shell命令

在“Execute shell”步骤中，你可以直接使用之前定义的参数。例如，如果你有一个参数名为BRANCH，你可以在shell命令中使用${BRANCH}来动态地执行针对不同分支的构建操作。例如：

git checkout ${BRANCH}
git pull
mvn clean install

这样，每次构建时，你都可以输入不同的分支名称作为参数，Jenkins将执行相应的shell命令来构建指定的分支。

6. 保存并构建项目

完成配置后，保存你的项目。然后，在“构建”选项卡中点击“立即构建”，或者在“控制台”中输入build来触发构建。在构建过程中，Jenkins将显示传递的参数值，以便你进行调试和验证。

通过以上步骤，你可以灵活地使用Jenkins的参数化构建功能，结合“执行shell”步骤来实现自动化构建和部署的不同需求。

---

使用“参数化构建传参给脚本”的脚本

• 已知Jenkins从GitLab拉取的文件将保存到/root/.jenkins/workspace/deploy_webapp1目录下
  这里的“deploy_webapp1”是当前Jenkins任务名

• 可以在.jenkins中创建一个scripts目录，将脚本文件放于这个目录中，

• 执行的脚本deploy_to_webservers.sh的示例代码:

#!/bin/bash
# Author: Lotus43
# Description: deploy the webapp to webservers

cd /root/.jenkins/workspace

zip -r webapp1.zip deploy_webapp1

staging_webserver_ip="172.16.1.7"
staging_webserver_pwd="1"

production_webserver_ip="172.16.1.8"
production_webserver_pwd="1"

case $ENVIRONMENT in
        "staging")
                sshpass -p ${staging_webserver_pwd} ssh-copy-id -i /root/.ssh/id_rsa.pub root@${staging_webserver_ip} -o StrictHostKeyChecking=no

                sshpass -p ${staging_webserver_pwd} rsync -avz webapp1.zip root@${staging_webserver_ip}:/opt/

                ssh ${staging_webserver_ip} "cd /opt/ && unzip webapp1.zip"
                ;;
        "production")
                sshpass -p ${production_webserver_pwd} ssh-copy-id -i /root/.ssh/id_rsa.pub root@${production_webserver_ip} -o StrictHostKeyChecking=no &>/dev/null

                sshpass -p ${production_webserver_pwd} rsync -avz webapp1.zip root@${production_webserver_ip}:/opt/ &> /dev/null

                ssh ${production_webserver_ip} "cd /opt/ && unzip webapp1.zip"
                ;;
esac

Jenkins"Build Steps"的配置页面示例：
那么任务开始时，参数化构建开启时将自动传给脚本一个参数（脚本中会调用这个参数）)

执行结果：

全部输出信息如下：

Started by user admin43
Running as SYSTEM
Building in workspace /root/.jenkins/workspace/deploy_webapp1
The recommended git tool is: NONE
No credentials specified
 > git rev-parse --resolve-git-dir /root/.jenkins/workspace/deploy_webapp1/.git # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git@gitlab.lotus431.com:lotus43/webapp1.git # timeout=10
Fetching upstream changes from git@gitlab.lotus431.com:lotus43/webapp1.git
 > git --version # timeout=10
 > git --version # 'git version 1.8.3.1'
 > git fetch --tags --progress git@gitlab.lotus431.com:lotus43/webapp1.git +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision 62595d2fa4cefffed74f1cfdb4f1780bbb1f5aec (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 62595d2fa4cefffed74f1cfdb4f1780bbb1f5aec # timeout=10
Commit message: "删除 架构图.jpg"
 > git rev-list --no-walk 62595d2fa4cefffed74f1cfdb4f1780bbb1f5aec # timeout=10
[deploy_webapp1] $ /bin/sh -xe /tmp/jenkins791106232308274759.sh
+ echo 'Hello! We will start this deploy task .....'
Hello! We will start this deploy task .....
+ echo -------------
-------------
[deploy_webapp1] $ /bin/sh -xe /tmp/jenkins17051000056982322828.sh
+ echo 调用参数化构建的字符串参数BRANCH:
调用参数化构建的字符串参数BRANCH:
+ echo BRANCH值为：
BRANCH值为：
+ echo master
master
[deploy_webapp1] $ /bin/sh -xe /tmp/jenkins12506934337776420409.sh
+ echo 调用参数化构建的布尔参数:RUN_TESTS：
调用参数化构建的布尔参数:RUN_TESTS：
+ '[' false = true ']'
+ echo -------------
-------------
[deploy_webapp1] $ /bin/sh -xe /tmp/jenkins4206056723784285640.sh
+ echo 调用参数化构建的选项参数:ENVIRONMENT：
调用参数化构建的选项参数:ENVIRONMENT：
+ echo 'Deploying to production environment...'
Deploying to production environment...
+ sh /root/.jenkins/shell_scripts/deploy_to_webserver.sh
updating: deploy_webapp1/ (stored 0%)
updating: deploy_webapp1/.git/ (stored 0%)
updating: deploy_webapp1/.git/refs/ (stored 0%)
updating: deploy_webapp1/.git/refs/heads/ (stored 0%)
updating: deploy_webapp1/.git/refs/tags/ (stored 0%)
updating: deploy_webapp1/.git/refs/remotes/ (stored 0%)
updating: deploy_webapp1/.git/refs/remotes/origin/ (stored 0%)
updating: deploy_webapp1/.git/refs/remotes/origin/master (stored 0%)
updating: deploy_webapp1/.git/branches/ (stored 0%)
updating: deploy_webapp1/.git/description (deflated 14%)
updating: deploy_webapp1/.git/hooks/ (stored 0%)
updating: deploy_webapp1/.git/hooks/applypatch-msg.sample (deflated 41%)
updating: deploy_webapp1/.git/hooks/commit-msg.sample (deflated 44%)
updating: deploy_webapp1/.git/hooks/post-update.sample (deflated 27%)
updating: deploy_webapp1/.git/hooks/pre-applypatch.sample (deflated 36%)
updating: deploy_webapp1/.git/hooks/pre-commit.sample (deflated 46%)
updating: deploy_webapp1/.git/hooks/pre-push.sample (deflated 50%)
updating: deploy_webapp1/.git/hooks/pre-rebase.sample (deflated 59%)
updating: deploy_webapp1/.git/hooks/prepare-commit-msg.sample (deflated 46%)
updating: deploy_webapp1/.git/hooks/update.sample (deflated 68%)
updating: deploy_webapp1/.git/info/ (stored 0%)
updating: deploy_webapp1/.git/info/exclude (deflated 28%)
updating: deploy_webapp1/.git/HEAD (stored 0%)
updating: deploy_webapp1/.git/config (deflated 27%)
updating: deploy_webapp1/.git/objects/ (stored 0%)
updating: deploy_webapp1/.git/objects/pack/ (stored 0%)
updating: deploy_webapp1/.git/objects/info/ (stored 0%)
updating: deploy_webapp1/.git/objects/25/ (stored 0%)
updating: deploy_webapp1/.git/objects/25/23d803589acf81f7971e4653080198ed2c69eb (stored 0%)
updating: deploy_webapp1/.git/objects/80/ (stored 0%)
updating: deploy_webapp1/.git/objects/80/7ad60ea01576889465d9e503c2ff2d5a02faa7 (stored 0%)
updating: deploy_webapp1/.git/objects/e6/ (stored 0%)
updating: deploy_webapp1/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 (stored 0%)
updating: deploy_webapp1/.git/objects/91/ (stored 0%)
updating: deploy_webapp1/.git/objects/91/d72eaca1c51cacba2ccba92fa6e55104e54985 (stored 0%)
updating: deploy_webapp1/.git/objects/c9/ (stored 0%)
updating: deploy_webapp1/.git/objects/c9/ecaf3c5f42fec675c8ec4d5faecf0e5b564868 (stored 0%)
updating: deploy_webapp1/.git/objects/e3/ (stored 0%)
updating: deploy_webapp1/.git/objects/e3/f48c880250ddf3364a33ddce91a079808ab029 (stored 0%)
updating: deploy_webapp1/.git/FETCH_HEAD (deflated 10%)
updating: deploy_webapp1/.git/logs/ (stored 0%)
updating: deploy_webapp1/.git/logs/refs/ (stored 0%)
updating: deploy_webapp1/.git/logs/refs/remotes/ (stored 0%)
updating: deploy_webapp1/.git/logs/refs/remotes/origin/ (stored 0%)
updating: deploy_webapp1/.git/logs/refs/remotes/origin/master (deflated 74%)
updating: deploy_webapp1/.git/logs/HEAD (deflated 76%)
updating: deploy_webapp1/.git/index (deflated 39%)
updating: deploy_webapp1/README.md (stored 0%)
updating: deploy_webapp1/file1.txt (stored 0%)
updating: deploy_webapp1/upload_file_dir/ (stored 0%)
updating: deploy_webapp1/upload_file_dir/upload_file_name (deflated 10%)
updating: deploy_webapp1/.git/objects/9b/ (stored 0%)
updating: deploy_webapp1/.git/objects/9b/0419c030c7c5c70c19aaf4b628f2c78f5282fc (stored 0%)
updating: deploy_webapp1/.git/objects/24/ (stored 0%)
updating: deploy_webapp1/.git/objects/24/791ab6d1409defca7799fd253417a5090edcf3 (stored 0%)
updating: deploy_webapp1/.git/objects/04/ (stored 0%)
updating: deploy_webapp1/.git/objects/04/9452ba5ba6baddc75d0f7ca60d78c25e36f77e (deflated 0%)
updating: deploy_webapp1/.git/objects/1e/ (stored 0%)
updating: deploy_webapp1/.git/objects/1e/10f38e2d61bb49f431e90273ac60cfd9502383 (stored 0%)
updating: deploy_webapp1/.git/objects/9f/ (stored 0%)
updating: deploy_webapp1/.git/objects/9f/52965ff75b37798079c096c717129a4482d2e7 (stored 0%)
updating: deploy_webapp1/.git/objects/62/ (stored 0%)
updating: deploy_webapp1/.git/objects/62/595d2fa4cefffed74f1cfdb4f1780bbb1f5aec (stored 0%)
Archive:  webapp1.zip
   creating: deploy_webapp1/
   creating: deploy_webapp1/.git/
   creating: deploy_webapp1/.git/refs/
   creating: deploy_webapp1/.git/refs/heads/
   creating: deploy_webapp1/.git/refs/tags/
   creating: deploy_webapp1/.git/refs/remotes/
   creating: deploy_webapp1/.git/refs/remotes/origin/
 extracting: deploy_webapp1/.git/refs/remotes/origin/master  
   creating: deploy_webapp1/.git/branches/
  inflating: deploy_webapp1/.git/description  
   creating: deploy_webapp1/.git/hooks/
  inflating: deploy_webapp1/.git/hooks/applypatch-msg.sample  
  inflating: deploy_webapp1/.git/hooks/commit-msg.sample  
  inflating: deploy_webapp1/.git/hooks/post-update.sample  
  inflating: deploy_webapp1/.git/hooks/pre-applypatch.sample  
  inflating: deploy_webapp1/.git/hooks/pre-commit.sample  
  inflating: deploy_webapp1/.git/hooks/pre-push.sample  
  inflating: deploy_webapp1/.git/hooks/pre-rebase.sample  
  inflating: deploy_webapp1/.git/hooks/prepare-commit-msg.sample  
  inflating: deploy_webapp1/.git/hooks/update.sample  
   creating: deploy_webapp1/.git/info/
  inflating: deploy_webapp1/.git/info/exclude  
 extracting: deploy_webapp1/.git/HEAD  
  inflating: deploy_webapp1/.git/config  
   creating: deploy_webapp1/.git/objects/
   creating: deploy_webapp1/.git/objects/pack/
   creating: deploy_webapp1/.git/objects/info/
   creating: deploy_webapp1/.git/objects/25/
 extracting: deploy_webapp1/.git/objects/25/23d803589acf81f7971e4653080198ed2c69eb  
   creating: deploy_webapp1/.git/objects/80/
 extracting: deploy_webapp1/.git/objects/80/7ad60ea01576889465d9e503c2ff2d5a02faa7  
   creating: deploy_webapp1/.git/objects/e6/
 extracting: deploy_webapp1/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391  
   creating: deploy_webapp1/.git/objects/91/
 extracting: deploy_webapp1/.git/objects/91/d72eaca1c51cacba2ccba92fa6e55104e54985  
   creating: deploy_webapp1/.git/objects/c9/
 extracting: deploy_webapp1/.git/objects/c9/ecaf3c5f42fec675c8ec4d5faecf0e5b564868  
   creating: deploy_webapp1/.git/objects/e3/
 extracting: deploy_webapp1/.git/objects/e3/f48c880250ddf3364a33ddce91a079808ab029  
  inflating: deploy_webapp1/.git/FETCH_HEAD  
   creating: deploy_webapp1/.git/logs/
   creating: deploy_webapp1/.git/logs/refs/
   creating: deploy_webapp1/.git/logs/refs/remotes/
   creating: deploy_webapp1/.git/logs/refs/remotes/origin/
  inflating: deploy_webapp1/.git/logs/refs/remotes/origin/master  
  inflating: deploy_webapp1/.git/logs/HEAD  
  inflating: deploy_webapp1/.git/index  
 extracting: deploy_webapp1/README.md  
 extracting: deploy_webapp1/file1.txt  
  inflating: deploy_webapp1/进程管理2_to_learn.md  
   creating: deploy_webapp1/upload_file/
  inflating: deploy_webapp1/upload_file/dir1  
   creating: deploy_webapp1/upload_file_dir/
  inflating: deploy_webapp1/upload_file_dir/upload_file_name  
   creating: deploy_webapp1/.git/objects/9b/
 extracting: deploy_webapp1/.git/objects/9b/0419c030c7c5c70c19aaf4b628f2c78f5282fc  
   creating: deploy_webapp1/.git/objects/24/
 extracting: deploy_webapp1/.git/objects/24/791ab6d1409defca7799fd253417a5090edcf3  
   creating: deploy_webapp1/.git/objects/04/
  inflating: deploy_webapp1/.git/objects/04/9452ba5ba6baddc75d0f7ca60d78c25e36f77e  
  inflating: deploy_webapp1/架构图.jpg  
   creating: deploy_webapp1/.git/objects/1e/
 extracting: deploy_webapp1/.git/objects/1e/10f38e2d61bb49f431e90273ac60cfd9502383  
   creating: deploy_webapp1/.git/objects/9f/
 extracting: deploy_webapp1/.git/objects/9f/52965ff75b37798079c096c717129a4482d2e7  
   creating: deploy_webapp1/.git/objects/62/
 extracting: deploy_webapp1/.git/objects/62/595d2fa4cefffed74f1cfdb4f1780bbb1f5aec  
+ echo -------------
-------------
[deploy_webapp1] $ /bin/sh -xe /tmp/jenkins18322170272385628415.sh
+ echo 调用参数化构建的密码参数:DB_PASSWORD：
调用参数化构建的密码参数:DB_PASSWORD：
+ echo 密码参数DB_PASSWORD的值为：4439
密码参数DB_PASSWORD的值为：4439
+ echo -------------
-------------
Sending e-mails to: 2048935747@qq.com
Finished: SUCCESS

三-4、Jenkins使用WebHook自动触发构建

什么是Jenkins的WebHook及其实现的基本原理

Jenkins的Webhook是一种轻量级的事件通知机制，允许外部系统通过HTTP请求触发Jenkins的构建流程。以下是Webhook的基本原理和配置方法：

Webhook的基本原理

Webhook基于HTTP回调机制，当外部系统（如Git代码仓库）发生特定事件时（例如代码提交），它会向Jenkins发送一个HTTP请求。Jenkins接收到请求后，会根据预定义的规则触发相应的构建流程。这种方式不需要客户端不断轮询服务端的状态，而是服务端在事件发生时直接将数据发送到客户端，节省了系统资源并保证了数据的实时性。

Jenkins Webhook配置步骤

1. 安装必要的插件：确保Jenkins中已经安装了Git插件或其他相关插件，以便支持Git仓库的操作。
2. 创建或配置Job：在Jenkins中创建一个新的Job或配置现有的Job。在Job的配置页面中，找到源代码管理部分，选择Git作为代码仓库类型，并填写仓库地址。
3. 配置构建触发器：在Job的配置页面中，找到构建触发器部分，选择Poll SCM并设置轮询频率，这将让Jenkins定期检查Git仓库是否有新的提交，并触发构建。
4. 获取Webhook URL：在Jenkins项目配置页面的左侧菜单中，选择“配置”。然后在构建触发器部分，找到Webhook URL并复制它。这个URL将用于在Git仓库中配置Webhook。
5. 在Git仓库中设置Webhook：
   • 转到Git仓库的设置页面。
   • 点击“Webhooks”或“Hooks”选项。
   • 点击“Add webhook”按钮。
   • 在“Payload URL”字段中，填写Jenkins服务器的URL，通常格式为http://<jenkins_url>/generic-webhook-trigger/invoke?token=<your_token>，其中<your_token>是Jenkins中为该项目设置的认证Token。
   • 选择触发Webhook的事件，例如“Just the push event”或其他需要的事件。
   • 保存Webhook配置。

通过以上步骤，当Git仓库发生配置的事件时，Git仓库服务器会向Jenkins发送一个HTTP请求，Jenkins接收到请求后，根据预设的规则触发相应的构建任务，实现自动化构建和部署。

---

设置Git仓库的Webhook具体步骤会根据你使用的Git服务提供商（如GitHub、GitLab、Bitbucket等）有所不同，但大体流程是类似的。以下是一些常见Git服务提供商设置Webhook的步骤：

GitHub

1. 登录GitHub账户：访问GitHub并登录你的账户。

2. 选择仓库：点击右上角的“+”号，选择“Your repositories”（你的仓库），然后点击“New”创建新仓库或选择一个已有的仓库。

3. 进入设置：在仓库页面，点击“Settings”（设置）选项。

4. 找到Webhooks部分：在设置页面的左侧菜单中，点击“Webhooks”（Webhooks）。

5. 添加Webhook：点击“Add webhook”按钮。

6. 配置Webhook：

   • Payload URL：输入Jenkins服务器的Webhook URL，通常是http://<jenkins_url>/github-webhook/。
   • Content type：选择application/json。
   • Which events would you like to trigger this webhook?：选择触发Webhook的事件，如Just the push event。
   • Active：确保勾选此选项以激活Webhook。

7. 添加：点击“Add webhook”按钮完成添加。

GitLab

1. 登录GitLab账户：访问GitLab并登录你的账户。

2. 选择项目：点击“Projects”（项目），然后选择一个项目。

3. 进入设置：在项目页面，点击“Settings”（设置）选项，然后点击“Webhooks”（Webhooks）。

4. 添加Webhook：点击“Add webhook”按钮。

5. 配置Webhook：

   • URL：输入Jenkins服务器的Webhook URL，通常是http://<jenkins_url>/gitlab-webhook/。
   • Trigger：选择触发Webhook的事件，如Push events。
   • Enable SSL verification：根据需要选择是否启用SSL验证。

6. 添加：点击“Add webhook”按钮完成添加。

Bitbucket

1. 登录Bitbucket账户：访问Bitbucket并登录你的账户。

2. 选择仓库：点击“Repositories”（仓库），然后选择一个仓库。

3. 进入设置：在仓库页面，点击“Settings”（设置）选项，然后点击“Webhooks”（Webhooks）。

4. 添加Webhook：点击“Webhooks”旁边的“Add webhook”按钮。

5. 配置Webhook：

   • Title：给Webhook一个标题。
   • URL：输入Jenkins服务器的Webhook URL，通常是http://<jenkins_url>/bitbucket-webhook/。
   • Status：选择“Active”以激活Webhook。
   • Events：选择触发Webhook的事件，如Repository push。

6. 添加：点击“Save”按钮完成添加。

在配置Webhook时，确保Jenkins服务器的URL是正确的，并且Jenkins服务器能够接收来自Git服务提供商的HTTP请求。如果Jenkins服务器在私有网络中，你可能需要配置防火墙规则或使用反向代理来允许外部请求。此外，如果你的Jenkins服务器使用HTTPS，确保在URL中使用https://而不是http://。

Jenkins需要生成一个token、为什么要配置token

在Jenkins Webhook配置中设置“Secret Token”主要是出于安全性的考虑，它有以下几个用途：

1. 验证请求的来源：Secret Token是一种安全措施，用于验证发送到Jenkins的Webhook请求是否来自一个可信的源。当GitLab（或其他Git服务提供商）触发Webhook时，它会将这个Token包含在HTTP请求中。Jenkins会检查这个Token是否与预期的值匹配，以确保请求不是由未授权的源发起的。

2. 防止CSRF攻击：跨站请求伪造（CSRF）是一种攻击方式，攻击者诱使已登录的用户无意中执行非预期的操作。通过设置Secret Token，Jenkins可以防止这种攻击，因为攻击者很难获取到这个Token，从而无法伪造合法的Webhook请求。

3. 增强安全性：在Jenkins中配置Secret Token，可以增加一层安全保护。即使有人知道了Webhook的URL，如果没有正确的Token，他们也无法触发Jenkins的构建。

Secret Token与监控GitLab仓库是相关的，因为在GitLab中配置Webhook时需要使用到这个Token。具体步骤如下：

1. 在Jenkins中生成Token：在Jenkins项目的配置页面中，你可以点击“Advanced”按钮，然后点击“Generate”来生成一个Secret Token。

2. 在GitLab中配置Webhook：将Jenkins生成的Secret Token复制到GitLab项目的Webhook配置中。这样，每当GitLab检测到代码提交时，它会向Jenkins发送一个包含这个Token的HTTP请求。

3. 验证Token：Jenkins接收到来自GitLab的Webhook请求后，会验证请求中的Token是否与Jenkins中配置的Token一致。如果一致，Jenkins就会触发相应的构建任务。

通过这种方式，Secret Token确保了只有来自GitLab的合法请求才能触发Jenkins的构建，从而保护了Jenkins构建过程的安全性。

---

在Jenkins和GitLab的Webhook配置中设置“Secret Token”主要是为了验证请求的来源和增强安全性。以下是关于“Secret Token”的作用和是否需要经常更新的说明：

1. 作用：

   • 验证请求来源：Secret Token用于验证发送到Jenkins的Webhook请求是否来自一个可信的源，比如GitLab。当GitLab触发Webhook时，它会将这个Token包含在HTTP请求中。Jenkins会检查这个Token是否与预期的值匹配，以确保请求不是由未授权的源发起的。
   • 防止CSRF攻击：Secret Token有助于防止跨站请求伪造（CSRF）攻击，因为攻击者很难获取到这个Token，从而无法伪造合法的Webhook请求。
   • 增强安全性：配置Secret Token可以增加一层安全保护。即使有人知道了Webhook的URL，如果没有正确的Token，他们也无法触发Jenkins的构建。

2. 是否需要经常更新：

   • 通常，Secret Token不需要经常更新。它是一个一次性设置的安全措施，用于确保Webhook的安全性。除非有特定的安全需求或在Token泄露的情况下，否则没有必要频繁更改Secret Token。
   • 如果你认为Secret Token不再安全，比如可能被泄露，那么应该立即更新它以保护系统的安全性。
   • 在实际操作中，只有在需要提高安全性或者更换安全策略时，才需要更新Secret Token。

综上所述，Secret Token是Jenkins和GitLab Webhook配置中的一个重要安全特性，用于验证请求的合法性并防止未授权的访问。它不需要经常更新，除非出于安全考虑或Token泄露的情况。

GitLab的token的设置？？

Webhook请求访问Gitlab本地网络错误问题：

解决办法：

测试GitLab的仓库改变后是否Jenkins将自动触发部署任务

四、Jenkins使用Maven插件创建构建、部署Maven项目的任务

——部署Maven项目到Web服务器

四-1、Maven的介绍

---

Maven是什么

Maven是一个项目管理和构建自动化工具，主要服务于基于Java的项目管理和构建。它使用一个名为POM（Project Object Model，项目对象模型）的XML文件来描述项目的构建过程、依赖关系、编译配置等。Maven的核心功能包括依赖管理、项目构建、文档生成和代码质量检查等。

Maven的用途

1. 依赖管理：自动处理项目依赖，解决依赖冲突，无需手动下载和安装JAR文件。
2. 项目构建：标准化构建过程，可以快速编译、测试、打包和部署项目。
3. 项目管理：提供清晰的项目结构和生命周期管理。
4. 代码质量：集成代码质量检查工具，如Checkstyle、PMD等。
5. 文档生成：自动生成项目文档，如JavaDoc和Site。
6. 项目报告：生成项目报告，如代码覆盖率报告。
7. 继承和聚合：支持多模块项目构建，可以继承和聚合子模块的配置。

具体如何使用Maven

1. 安装Maven

• 下载Maven：从Apache Maven官方网站下载Maven。
• 解压并配置环境变量：将下载的Maven压缩包解压到一个目录，并设置环境变量M2_HOME指向该目录，将%M2_HOME%\bin添加到系统路径变量PATH中。

2. 配置Maven

• 编辑settings.xml文件：该文件位于M2_HOME/conf目录下，可以配置本地仓库位置、代理设置、镜像服务器等。

3. 创建Maven项目

• 使用IDE（如IntelliJ IDEA、Eclipse）创建Maven项目，IDE会帮助生成基本的POM文件。
• 或者，手动创建一个包含pom.xml文件的目录结构，pom.xml文件定义了项目的构建信息和依赖。

4. 编写POM文件

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>demo-project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

5. 使用Maven命令

在命令行中，进入项目根目录，使用以下Maven命令：

• 编译项目：mvn compile
• 运行测试：mvn test
• 打包项目：mvn package（会根据POM文件中的配置生成JAR或WAR文件）
• 安装项目到本地仓库：mvn install
• 部署项目到远程仓库：mvn deploy
• 运行项目：对于Web应用或其他可执行项目，可以使用mvn exec:java或其他插件来运行。

6. Maven生命周期

Maven有一系列的生命周期阶段，如clean、compile、test、package、verify、install和deploy。这些阶段可以组合成几个常用的生命周期，如clean、default（包含compile、test、package）、site等。

通过这些步骤，你可以开始使用Maven来管理Java项目的构建和依赖。Maven的强大之处在于其丰富的插件生态系统和约定大于配置的理念，这使得项目构建和管理变得更加标准化和自动化。

四-2、*Web配置Tomcat

yum install tomcat -y

touch /var/lib/tomcat/webapps/ROOT/index.jsp

echo "Hello,这是一个基于Tomcat运行的页面" >> /var/lib/tomcat/webapps/ROOT/index.jsp

在CentOS 7上安装、配置和启动Tomcat涉及几个步骤。以下是详细指南：

1. 安装Tomcat

步骤1：添加Tomcat仓库

首先，您需要添加Tomcat的YUM仓库。创建一个名为tomcat的新repo文件：

sudo vi /etc/yum.repos.d/tomcat.repo

在该文件中添加以下内容：

[tomcat]
name=Apache Tomcat Repository
baseurl=http://repo.maven.org/maven2/org/apache/tomcat/tomcat/9.0.57/bin/distribution
enabled=1
gpgcheck=0

请根据需要更改baseurl以指向正确的Tomcat版本。上面的URL是Tomcat 9.0.57版本的URL。

步骤2：安装Tomcat

使用YUM安装Tomcat：

sudo yum install tomcat

步骤3：验证安装

检查Tomcat是否已正确安装：

rpm -qa | grep tomcat

您应该看到列出的Tomcat包。

2. 配置Tomcat

步骤1：配置环境变量

编辑/etc/profile或~/.bash_profile文件，添加以下内容以设置CATALINA_HOME和更新PATH：

export CATALINA_HOME=/usr/share/tomcat
export PATH=$PATH:$CATALINA_HOME/bin

保存文件并重新加载配置：

source /etc/profile

或者如果您使用的是.bash_profile：

source ~/.bash_profile

步骤2：配置server.xml

Tomcat的配置文件server.xml位于$CATALINA_HOME/conf目录下。您可以根据需要编辑此文件，例如更改端口号、添加上下文路径等。

例如，要更改默认的HTTP端口从8080到8081：

<Connector port="8081" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

步骤3：配置用户

如果您需要配置Tomcat管理界面的访问权限，编辑$CATALINA_HOME/conf/tomcat-users.xml文件，并添加一个用户：

<tomcat-users>
  <role rolename="manager-gui"/>
  <user username="admin" password="password" roles="manager-gui"/>
</tomcat-users>

3. 启动Tomcat

步骤1：启动服务

使用systemd启动Tomcat服务：

sudo systemctl start tomcat

步骤2：设置开机启动

如果您希望Tomcat在系统启动时自动启动，可以使用以下命令：

sudo systemctl enable tomcat

步骤3：检查服务状态

检查Tomcat服务的状态以确保它正在运行：

sudo systemctl status tomcat

4. 访问Tomcat

在浏览器中输入http://your_server_ip:8081（或者您配置的其他端口），您应该能够看到Tomcat的默认欢迎页面。

5. 部署应用

将您的WAR文件放置在$CATALINA_HOME/webapps目录下，Tomcat会自动解压并部署应用。

以上是在CentOS 7上安装、配置和启动Tomcat的详细步骤。根据您的具体需求，您可能需要进行额外的配置和优化。

/usr/share/tomcat/webapps/ROOT和/var/lib/tomcat/webapps/ROOT的区别

在使用 yum install tomcat 安装Tomcat后，/var/lib/tomcat/webapps/ROOT 和 /usr/share/tomcat/webapps/ROOT 这两个目录在Tomcat中扮演着不同的角色，它们的主要区别如下：

1. 目录结构和用途：

   • /usr/share/tomcat/webapps/ 是Tomcat的默认Web应用程序部署目录。当你将一个Web应用程序（通常是WAR文件）放置在这个目录下时，Tomcat会自动解压缩并部署这个应用程序。这个目录包含了所有的Web应用程序，可以是静态的HTML页面，也可以是动态的Web应用程序。
   • /usr/share/tomcat/webapps/ROOT 是Tomcat的默认Web应用程序的根目录。当你访问Tomcat服务器而没有指定具体的Web应用程序名称时，Tomcat会自动将请求映射到ROOT目录下的文件。这个目录通常包含一个欢迎页面，当访问Tomcat服务器的根URL（例如 http://localhost:8080/）时，Tomcat会默认加载ROOT目录下的文件作为默认的主页。

2. 访问路径：

   • 将Web应用程序部署到webapps/目录下时，需要通过访问具体的应用程序名称来访问，例如 http://localhost:8080/myapp。
   • 将Web应用程序部署到webapps/ROOT/目录下时，可以直接通过根URL来访问应用程序，例如 http://localhost:8080/。

3. 项目部署和访问：

   • 如果你将Web应用程序的WAR文件或解压后的文件夹放在webapps/目录下，Tomcat会在启动时自动解压和部署这些应用程序。
   • 如果你将Web应用程序的文件直接放在ROOT目录下，Tomcat会将这些文件作为默认的Web应用程序来运行，这样在访问Tomcat的根URL时，就可以直接访问这些文件，而不需要指定应用程序的名称。

4. 符号链接：

   • 在使用yum安装Tomcat后，Tomcat相关的目录通常会通过符号链接到/usr/share/tomcat目录，包括webapps等，这使得配置和管理更加方便。
   • /var/lib/tomcat/webapps实际上是/usr/share/tomcat/webapps的符号链接，这意味着它们指向同一个物理位置。

总结来说，/var/lib/tomcat/webapps/ROOT和/usr/share/tomcat/webapps/ROOT在物理上是同一个位置，它们都是Tomcat中用于存放默认Web应用程序的目录。不同之处在于它们的访问路径和部署方式，以及它们在Tomcat中的作用。webapps/目录用于部署所有Web应用程序，而ROOT目录用于存放默认的主页和静态资源文件，可以直接通过根URL访问。

Tomcat的webapps目录和webapps下的ROOT目录的区别以及Tomcat的自动部署机制

在CentOS7中使用yum install tomcat安装Tomcat后，将.war文件放置于/usr/share/tomcat/webapps/ROOT目录下，然后执行systemctl start tomcat启动Tomcat服务，/usr/share/tomcat/webapps/ROOT目录中没有生成对应xxx目录的原因可能如下：

1. Tomcat的自动部署机制：通常情况下，当你将.war文件放置在webapps目录下时，Tomcat会在启动时自动解压这些.war文件，并在webapps目录下创建与.war文件同名的目录来存放解压后的应用文件。但是，ROOT目录是一个特例。

2. ROOT目录的特殊性：ROOT目录用于存放默认的Web应用程序，当访问Tomcat服务器的根URL（例如http://localhost:8080/）时，Tomcat会默认加载ROOT目录下的文件作为默认的主页。如果你将.war文件直接放入ROOT目录，Tomcat可能不会自动解压该文件，因为ROOT目录通常用于存放静态资源和默认页面，而不是作为自动部署目录。

3. 没有自动解压.war文件：如果你将.war文件放入ROOT目录，Tomcat可能不会像在webapps目录下那样自动解压.war文件。这意味着.war文件需要手动解压，或者通过配置Tomcat来实现自动解压。

4. 配置问题：如果Tomcat的配置文件（如server.xml）没有正确设置，或者.war文件的放置位置不正确，也可能导致.war文件不被自动解压。例如，如果.war文件没有放在webapps目录或其子目录下，Tomcat可能不会识别并解压该文件。

5. 权限问题：如果Tomcat服务运行的用户没有足够的权限去写入ROOT目录，那么即使.war文件被放置在ROOT目录下，Tomcat也无法解压该文件，因此不会生成对应的目录。

综上所述，如果你希望.war文件在Tomcat启动时被自动解压并部署，建议将.war文件放置在webapps目录下，而不是ROOT目录。如果确实需要将应用部署在ROOT目录下，你可能需要手动解压.war文件到ROOT目录，并确保Tomcat的配置允许这样做。

四-3、Jenkins上安装与配置Maven

yum install maven -y

mvn -version

修改Maven的下载源以便提升下载速度

vim /etc/maven/settings.xml

<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>*</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

四-4、Jenkins对从gitLab中获取到的Java项目使用Maven打包

# 进入含有pom.xml文件的目录中：
mvn clean package

---

Maven 是一个自动化构建工具，用于Java项目，它可以帮助我们进行项目构建、依赖管理等工作。以下是一些基本的 Maven 命令，用于将 Java 项目进行打包：

1. 安装 Maven：
   确保你已经在你的机器上安装了 Maven。可以通过在命令行中运行 mvn -v 来检查 Maven 是否已安装以及其版本。

2. 初始化 Maven 项目：
   如果你的项目不是一个 Maven 项目，你可以使用 mvn archetype:generate 命令来创建一个新的 Maven 项目，或者在现有的项目中添加 pom.xml 文件。

3. 构建项目：
   在项目的根目录下，运行以下命令来构建项目：

   mvn clean install
   

   • clean：清理项目，删除 target 目录下的所有生成的文件。
   • install：安装项目包到本地仓库，这样其他项目就可以作为依赖使用它。

4. 打包项目：
   根据你想要生成的包类型，可以使用不同的 Maven 插件。以下是一些常见的打包命令：

   • JAR：

     mvn package
     

     这将根据 pom.xml 中配置的打包方式（默认为 JAR）来打包你的项目。

   • WAR（对于Web应用）：

     mvn package
     

     确保 pom.xml 中的 <packaging> 标签设置为 war。

   • 可执行 JAR（包含所有依赖）：

     mvn package
     

     使用 Maven 插件如 maven-assembly-plugin 或 maven-shade-plugin 来创建一个包含所有依赖的可执行 JAR 文件。

5. 使用特定的 Maven 插件进行打包：
   如果你需要更复杂的打包需求，比如包含所有依赖的可执行 JAR，你可以在 pom.xml 中配置相应的插件。例如，使用 maven-assembly-plugin：

   <build>
       <plugins>
           <plugin>
               <artifactId>maven-assembly-plugin</artifactId>
               <configuration>
                   <archive>
                       <manifest>
                           <mainClass>com.example.MainClass</mainClass>
                       </manifest>
                   </archive>
                   <descriptorRefs>
                       <descriptorRef>jar-with-dependencies</descriptorRef>
                   </descriptorRefs>
               </configuration>
               <executions>
                   <execution>
                       <id>make-assembly</id> <!-- this is used for inheritance merges -->
                       <phase>package</phase> <!-- bind to the packaging phase -->
                       <goals>
                           <goal>single</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
       </plugins>
   </build>
   

   然后运行 mvn package 来生成包含依赖的 JAR 文件。

6. 查看生成的包：
   构建完成后，你可以在 target 目录下找到生成的包。

请根据你的具体项目需求和配置选择合适的命令和插件。如果你的项目有特定的打包需求，你可能需要在 pom.xml 文件中进行相应的配置。

---

执行mvn clean package之前：

执行之后，将在target目录下生成一个包（jar或war包或…），放入tomcat的webapps下，将会自动解析

四-5、将上面的maven打包好的Java应用包部署到Web服务器的站点中

上面的maven打包执行之后，将在target目录下生成一个包（jar或war包或…），放入Web服务器的tomcat的webapps下，将会自动解析

使用Jenkins的maven任务的支持的功能实现更快的部署

Maven的插件会自动构建代码生成Java包
好的，以下是在Jenkins中创建和配置Maven项目任务的详细步骤：

1. 安装必要的插件

在开始之前，请确保你已经安装了以下插件：

• Maven Integration plugin：用于集成Maven构建。
• Git plugin：如果你的项目使用Git作为版本控制系统。

如果没有安装，可以在Jenkins的管理界面中找到“管理插件”部分进行安装。

2. 创建新任务

1. 登录到Jenkins。
2. 点击“新建”来创建一个新的任务。
3. 输入任务名称，选择“构建一个Maven项目”作为项目类型，然后点击“确定”。

3. 配置源码管理

1. 在“源码管理”部分，选择你的版本控制系统（例如Git）。
2. 输入项目的仓库URL。
3. 如果需要，输入凭据信息（用户名和密码或SSH私钥）。

4. 配置构建触发器

1. 在“构建触发器”部分，你可以选择不同的触发方式：
   • 轮询SCM：定期检查源代码库中的变化。
   • GitHub hook trigger for GITScm polling：如果你使用GitHub，这个钩子可以在代码推送时触发构建。
   • 定时构建：设置一个Cron表达式来定时触发构建。

5. 配置构建环境

1. 在“构建环境”部分，你可以选择一些选项，例如：
   • 使用私有构建目录：为了避免构建之间的冲突。
   • 禁用工作目录的多配置并行使用：如果你不想并行构建多个配置。

6. 配置构建

1. 在“构建”部分，你可以添加构建步骤：
   • 使用Maven构建：选择这个选项，然后输入Maven目标和选项。例如，clean install。
   • 执行shell/批处理命令：如果你需要执行额外的shell命令，可以选择这个选项。

7. 配置构建后操作

1. 在“构建后操作”部分，你可以选择一些操作，例如：
   • 邮件通知：配置发送构建结果的邮件。
   • 发布JUnit测试结果：如果你的项目包含JUnit测试，可以选择这个选项来收集和报告测试结果。
   • 部署：如果你需要将构建结果部署到服务器，可以选择相应的部署插件。

8. 配置Maven

1. 在“构建”部分，点击“添加参数”按钮，然后选择“Maven版本”。
2. 选择“Jenkins”来使用Jenkins全局配置的Maven版本，或者选择“On the machine, choose from the drop-down list”来使用构建节点上安装的Maven版本。

*“全局配置”中的JDK的配置、Maven配置

根据Jenkins机器的Maven配置来配置：

9. 配置Maven设置

1. 同样在“构建”部分，点击“添加参数”按钮，然后选择“Maven Settings”。
2. 输入Maven的settings.xml文件的路径，或者选择一个已经配置好的Maven配置。

10. 保存并运行

1. 配置完成后，点击“保存”按钮保存你的配置。
2. 点击“立即构建”来手动触发一次构建，或者等待构建触发器自动触发构建。

以上步骤涵盖了在Jenkins中创建和配置Maven项目任务的基本流程。根据你的具体需求，可能还需要配置其他插件或选项。

---

在CentOS 7系统中，JAVA_HOME环境变量通常指向Java的安装目录。如果你已经安装了Java并且设置了JAVA_HOME环境变量，你可以通过以下几种方式来查看它：

方法1：使用echo命令

打开终端，输入以下命令：

echo $JAVA_HOME

如果JAVA_HOME环境变量已经设置，这个命令将显示Java的安装路径。

方法2：使用printenv命令

你也可以使用printenv命令来查看所有环境变量，包括JAVA_HOME：

printenv | grep JAVA_HOME

或者直接查看JAVA_HOME：

printenv JAVA_HOME

方法3：检查/etc/profile或~/.bash_profile

如果上述命令没有返回任何结果，说明JAVA_HOME环境变量可能没有设置。你可以检查全局环境变量文件/etc/profile或者用户级别的环境变量文件~/.bash_profile（或者~/.bashrc，取决于你的shell配置）来查看是否已经设置了JAVA_HOME。

打开/etc/profile文件：

cat /etc/profile | grep JAVA_HOME

或者打开用户级别的环境变量文件：

cat ~/.bash_profile | grep JAVA_HOME

或者：

cat ~/.bashrc | grep JAVA_HOME

方法4：检查Java安装目录

如果你不确定JAVA_HOME是否设置，或者想要找到Java的安装目录，你可以尝试查找Java的安装路径。Java通常安装在/usr/lib/jvm/目录下。你可以使用以下命令来查找：

ls /usr/lib/jvm/

这将列出所有安装在该目录下的Java版本。你可以根据你的需要设置JAVA_HOME环境变量为这些路径中的一个。

设置JAVA_HOME

如果你发现JAVA_HOME没有设置，你可以手动设置它。例如，如果你的Java安装在/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b09-1.el7_7.x86_64，你可以在你的~/.bash_profile或~/.bashrc文件中添加以下行：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b09-1.el7_7.x86_64

然后，运行以下命令使更改生效：

source ~/.bash_profile

或者：

source ~/.bashrc

现在，你应该可以使用echo $JAVA_HOME命令来查看JAVA_HOME的值了。

---

五、Jenkins使用Sonar插件进行代码质检

五-1、

五-2、

六、