在 jelastic 平台上发展 devops 方法的概念，这次我们很高兴向您展示这个专门系列的第三个指南。今天文章中描述的新解决方案不仅通过确保项目生命周期管理，而且还简化了 jenkins 持续集成服务器配置过程，从而提供了更大的自动化。

这是通过结合两种先进技术实现的：jelastic 可插入附加组件和 云脚本 操作——下一代云中应用程序和服务器管理解决方案，jelastic 团队目前正在大力开发。特别是，这样的集成允许自动创建作业模板的完整列表，只需要稍微调整一下（通过设置一个 url 到包含所需项目的存储库的操作，而不是默认的）来完成 jenkins 服务器调整。

这种实现的真正效率在处理多个项目的情况下得到最大程度的体现，而不是无数的逐步手动配置，需要正确设置每个 jenkins 服务器，您需要创建一个单个附加组件只需一次。随后，只需单击几下即可将其轻松应用于所需的环境，只需调整几个与用户相关的参数。这种方法可以为后续的每次安装节省更多的时间。

由于本文与 “用于在 jelastic 私有云中持续交付的 devops 工具” 系列的前两部分紧密相连，我们将定期引用它们以避免重复描述相同的步骤。这就是为什么我们建议您在继续之前先熟悉这些指南：

一般准备

首先，让我们提醒您一些必须完成的安排，以确保最佳的 DevOps 体验：

您的 jelastic 安装应包括分别分配给开发、测试和生产团队的三个单独的硬件集：

由于我们所指的持续应用程序交付方法的核心是 jenkins 服务器，因此您需要有一个运行适当软件的环境。正如您在本系列之前的指南中所记得的那样，使用嵌入式 jelastic 市场变得相当容易，可以通过适当的网站页面或直接通过仪表板访问它。

我们之前已经详细考虑了这些步骤，因此我们相信您不会在这里遇到任何麻烦。

使用云脚本配置詹金斯

正如本指南的介绍中已经提到的，jenkins 服务器设置阶段的大部分工作将自动化。为此，应首先在代码中实施适当的配置，随后在您的应用程序服务器上使用 jenkins 处理执行这些配置。在 jelastic，这可以通过准备一个特殊的 json 清单文件来完成，该文件被集成到平台中，将代表一个可插入的 附加组件 ，任何用户都可以直接通过仪表板轻松运行。

创建附加组件

让我们开始为我们的附加组件构建基础，以便能够进一步将其应用于所需的 jelastic 环境：

以管理员用户身份登录到您的 jca 面板，然后使用左侧的主菜单导航到市场部分。

进入后，展开顶部窗格中的添加列表并选择附加选项。

在打开的编辑器中，粘贴以下结构的通用代码模板：


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

突出显示的参数应替换为适当的数据 - 在这里您需要定义有关您的包的一般信息并指定它打算执行的操作：

package_name – 附加组件名称，它将在用户的仪表板上命名（例如 jenkins 配置 ）
logo_url – 链接到将用作包图标的图像（您可以通过复制和指定此 url 使用我们的默认图像）
custom_code – 逗号分隔的 shell 命令列表，将在附加组件的设备上运行

虽然前两个设置很明显，但最后一个需要更详细地考虑，因此本指南的下一节将专门介绍所需操作脚本的细节。

编写脚本

在我们的示例中，jenkins 集成工具安装在 tomcat 7 之上，因此使用的所有命令都将基于其规范。我们打算通过编写以下操作脚本来自动化该过程：

上传设置作业所需的脚本。
配置詹金斯本身。
创建和链接作业以自动引导应用程序完成整个生命周期。

此外，我们将更详细地检查每一点，并根据此流程准备清单的核心。

注意： 下面我们为您提供示例代码，需要根据您的应用程序的具体情况进行修改。为了确保正确完成并正确编写所有操作脚本，我们建议对您的代码进行初步测试。这可以通过创建一个单独的环境来完成，该环境具有与您正在创建的附加组件相同的拓扑结构（即在我们的案例中部署了 jenkins 应用程序的 tomcat 7 ）并使用 ssh 直接在计算节点的容器内运行调整后的命令。如果您在这方面需要任何帮助，请参阅有关用于 jenkins 故障排除的 devops 附加组件的完整指南，其中还包括对所呈现的每个操作的预期结果的描述。

因此，让我们揭示如何在适当的云脚本选项的帮助下轻松完成上述建议的过程。随后，所有这些都需要插入，而不是清单示例中的 custom_code 参数，按照下面描述的相同顺序。

这是我们建议创建的脚本的第一部分：


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

在这段代码中，您可以识别将脚本（它们是设置 jenkins 作业所必需的）上传到容器的过程。之前，我们手动完成此操作并详细考虑了所有内容，因此在这里，我们将提醒您需要注意的一些关键点（在上面的示例中突出显示）：

/opt/tomcat/demo – 将存储所有脚本信息的文件夹的完整路径（我们将使用 demo ，但您可以创建和使用任何其他所需的目录 – 只是不要忘记在任何地方指定正确的路径在你的代码中）
curl -fssl file_url -o file_name – 此命令启动容器内的文件上传；对于此示例，我们需要以下脚本：
- install.sh – 以指定用户身份自动登录，并根据 jelastic 清单文件创建拓扑设置的新环境
- transfer.sh – 根据环境转移特性将环境所有权传递给指定用户
- migrate.sh – 将环境重新定位到指定的硬件集（硬节点组）
- runtest.sh – 在我们的示例中，它模拟测试活动以用于演示目的，因此我们不提供其代码。如果需要，根据您的应用程序的具体情况创建您自己的一个，并规定将其与其余脚本一起上传

请注意 ，在应用之前，必须根据您的平台设置通过替换以下参数来额外调整上面链接的每个脚本模板：

/path/to/scripts/ – 与您在上面设置的路径相同（在我们的例子中 为 /opt/tomcat/demo ）
{cloud_domain} – 您的 jelastic 平台域名
{jca_dashboard_appid} – 您的仪表板 ID，可以在 jca > 关于 部分的 platform.dashboard_appid 参数中看到
{jca_appstore_appid} – 应用商店 ID，列在同一部分（ platform.appstore_appid 参数）
{url_to_manifest} – 链接到根据我们的文档创建的 jelastic 清单文件（我们将使用与以前相同的文件 – 它设置了两个由 nginx 负载平衡器前端的 tomcat 应用程序服务器）

此外，第三个字符串定义了变量文件的创建以及上传的脚本，旨在用于进一步存储自动生成的环境名称以及您的应用程序的不同版本。

代码的第二部分将删除所有现有的（即在初始工具部署期间自动安装的）jenkins 插件，以防止不兼容问题或它们的版本与即将到来的配置不匹配：


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

之后，您需要移动到主 .jenkins 目录，并通过上传和提取适当的 plugins.zip 存档将必要的插件和配置文件添加到 jenkins 集成器，而不是删除的插件和配置文件。


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

我们建议使用我们为这个例子准备的包，它已经包含了所有必要的模块。但是，如果需要，您可以用其他插件补充它，或者只打包您自己的 zip 存档——在这种情况下，请注意它应该包含几个强制性工具（即： scm api 插件 、 git 插件 、 git 客户端插件 、 环境文件插件 ) 并且所有这些都应该放在存档内的插件文件夹中。

下一段代码上传并提取另一个所需的包（ jobs.zip ），它将根据里面的数据设置 jenkins 作业。


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

存档结构应如下所示：一个通用作业文件夹，其中可能包含多个目录，以适当的作业命名。每个此类目录都应包含 config.xml 文件（其中指定了所有必需的配置）和带有空 legacyids 文件的 builds 文件夹。我们已经准备了这样一个档案，其中包含创建作业的设置，专门用于建议的应用程序生命周期流程的每个步骤：

创建环境 > 构建和部署 > 开发测试 > 迁移到质量检查 > 质量检查测试 > 迁移到生产环境

请注意 ，如果您使用脚本文件夹的自定义路径，则需要在我们的示例包中编辑 构建和部署 作业，因为它包含该目录中文件的定义位置：


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

其他一切可能保持原样，但是，如果需要，您也可以对其进行编辑或添加自己的工作。

5. 最后，定义服务器的重启以应用所有已执行的配置。


 {
    "jpstype": "update",
    "jpsversion": "0.3",
    "application": {
     "name": "package_name",
     "logo": "logo_url",
     "type": "java",
     "oninstall": {
         "executeshellcommands": {
             "nodetype": "tomcat7",
             "commands": [
                     custom_code
             ]
         }
     }
    }
}

组合在一起，所有这些代码部分将自动执行几乎所有必需的 jenkins 配置。

因此，现在您可以按照上面的建议将它们放在适当的命令清单部分中——您将得到类似于以下内容的内容：