urbancode使用方法

    技术2022-07-20  80

    DevOps是一项用于连续软件交付的企业功能,可以使组织抓住市场机会,对客户反馈做出更快React,并平衡速度,成本,质量和风险。 通过在整个软件交付生命周期中应用精益和敏捷原则,DevOps可以帮助组织交付差异化且引人入胜的客户体验,缩短实现价值的时间,并提高创新能力。 IBM提供了多种软件产品来支持DevOps实施。 在本文中,我们将从设计方面到实现细节来描述如何使用IBM UrbanCode Deploy来实现连续交付解决方案。

    本文基于我们在SoftLayer上实施DevOps for Workload Automation as a Service项目的案例研究。

    设计您的连续交付解决方案

    设计阶段对于创建连续交付解决方案很重要。 在此您可以将功能支持和培训要求转换为初步和详细的设计。

    在此阶段,您:

    识别组件。 定义连续交付工作流程。 定义环境。

    识别组件

    在解决方案生命周期的设计阶段,您将设计一个体系结构,该体系结构显示解决方案各组件之间的相互关系。 这些组件是您将包含在连续交付解决方案中的所有软件组件。

    在我们的案例研究中,我们确定了工作负载自动化即服务(WAaaS)体系结构中的两个主要组件: 工作负载自动化主设备和动态工作负载控制台 。

    对于每个已标识的组件,设计可以在特定组件上运行的所有部署,配置和操作流程。

    在我们的环境中,我们确定了以下过程:

    Workload Automation Master组件流程 部署过程以更新组件 将工作负载从主主服务器组件转移到备用主服务器的操作过程 将工作负载从备份主服务器转移到主服务器的操作过程 部署后执行运行状况检查的操作过程 动态工作负载控制台组件流程 部署过程以更新组件 将组件加入集群配置的操作过程 使组件脱离集群配置的操作过程 部署后执行运行状况检查的操作过程

    设计所有流程。 指定组成每个过程的所有逻辑步骤。

    部署流程

    通过在本机部署或临时部署之间进行选择来开始部署过程设计阶段。

    本机部署使用官方产品安装。 这种方法可以实现快速简便的实现。 缺点是部署非常耗时,并且所使用的工件很大。 在连续交付解决方案中,通常,在组件上进行的更新基于很少的更改,并且不需要完全升级产品。 我们建议这种方法用于复杂的更新过程。 临时部署实现了将更改部署到组件上所需的所有步骤。 与本地部署相比,此方法花费更少的钱来部署更改。 在此部署期间使用的工件要小于在本机部署中使用的工件。 您在UrbanCode Deploy中构建的流程使您可以更好地控制要执行的步骤。 这种方法需要复杂的设计和实现。

    要选择正确的方法,请评估不同方面的利弊。 您要考虑:

    就部署中新流程的开发而言,本机安装的可用性。 分解安装的可能性较小,可以减少构建和部署时间。 要安装的工件的大小。 在我们的案例中,组件的图像必须通过Internet传输到SoftLayer云。

    在WAaaS项目中,我们分析了Master(参见表1)和Dynamic Workload Console(参见表2)的不同方法。

    表1. Workload Automation Master组件的安装方法比较
    工作负载自动化主组件 本机安装 临时部署 实施时间 3天 30天 部署时间 15分钟 10分钟 工件尺寸 1.6 GB 约800 MB
    表2. Dynamic Workload Console的安装方法比较
    动态工作负载控制台 本机安装 临时部署 实施时间 3天 5天 部署时间 40分钟 10分钟 工件尺寸 1.2 GB 400兆字节

    由于Workload Automation Master组件的安装过程中涉及的步骤数和复杂性,我们认为本机安装更加方便。 但是,对于Dynamic Workload Console部署,我们选择了临时方法。

    确定安装方法后,必须创建逻辑流程的设计,并标识组成每个逻辑流程的所有步骤。

    我们基于IBM Installation Manager进行Workload Automation Master组件的本地安装。 更新(部署)的步骤是:

    下载软件包(工件)。 停止Workload Automation Master进程。 配置响应文件。 使用配置的响应文件运行静默安装。

    使用临时方法更新(部署)Dynamic Workload Console的步骤是:

    下载程序包。 停止动态工作负载控制台进程。 部署WARs文件。 解压有效载荷。 启动动态工作负载控制台进程。

    运作程序

    操作过程用于定义在部署新版本的组件之前和之后要执行的操作。 在我们的WAaaS项目中,我们确定了Workload Automation Master和Dynamic Workload Console的几个操作流程。

    操作流程设计阶段是您为每个已标识的流程定义步骤时。 例如,将工作负载从主工作负载自动化主节点移动到备份(辅助节点)的操作过程需要四个步骤:

    识别主节点 将工作负载从主要转移到次要 在主节点上停止进程 在辅助节点上启动过程

    定义环境

    在设计阶段,定义连续交付解决方案中将包括的所有环境非常重要。

    在此阶段,确定您的测试和生产环境。

    在我们的WAaaS项目中,我们确定了三个主要环境:

    质量保证(QA)环境 暂存环境 生产环境

    对于每个环境,请确定包括哪些节点,然后为每个节点部署哪些组件。

    您还必须为每个节点标识网络。

    在WAaaS项目中:

    QA环境中的所有节点都在IBM网络中 登台环境中的所有节点都在SoftLayer云中,并与一个登台帐户关联 生产环境中的所有节点都在SoftLayer云网络中,并且与生产帐户相关联。

    尽管生产和登台节点都在SoftLayer云上,但它们位于不同的网络上。

    定义连续交付工作流程

    从上一节中设计的组件和环境开始,根据何时以及如何在不同环境中部署和配置组件来设计连续交付的流程。 从整个工作流程开始,并定义环境之间的关系。

    在WAaaS项目中,整个工作流程始于开发活动。 在构建验证测试(BVT)成功完成之后,将构建复制到构建存储库中。 一旦有新的构建可用到构建存储库中,就开始QA环境更新并执行自动测试用例。

    如果自动测试用例成功完成,则构建将通过QA认证,并且过渡环境将自动更新。 分阶段自动测试成功完成后,构建即可用于生产环境,并且在批准过程后也会进行更新。

    定义总体工作流程后,必须为每个特定环境定义工作流程:在环境中部署组件的顺序以及前提条件和前提条件。

    例如,在WAaaS项目中,我们将QA环境的工作流程定义为:

    并行更新所有组件 运行测试自动化 通过质量检查认证版本

    使用Urbancode Deploy实施持续交付解决方案

    完成设计规范后,您可以开始实施阶段。 您必须配置环境,并将标识的组件实现为UrbanCode Deploy组件,将环境实现为UrbanCode Deploy应用程序环境,并将工作流实现为应用程序进程。

    实施解决方案所需的步骤是:

    物理环境安装和配置 组件实施 应用实施

    对于每个UrbanCode Deploy对象(资源,环境,组件,应用程序),必须指定可以读取,修改和使用特定对象的团队 。

    在团队中,您可以定义不同的角色。 每个角色都可以具有特定的权限,例如,读取,修改,删除等。

    您可以在设置>安全性中配置安全性设置。

    物理环境安装和配置

    首先,设置环境。

    在WAaaS DevOps解决方案中,我们设置了环境,如图1所示。

    图1.工作负载自动化即服务DevOps解决方案架构

    对于UrbanCode Deploy安装,我们使用两个虚拟机托管在vSphere服务器上,用于数据库,而一个虚拟机用于UrbanCode Deploy服务器本身。

    对于第一个实现,我们选择了一个简单的解决方案,即使用Windows®机器和MSSQL服务器,以及Linux®RHEL 6机器用于UrbanCode Deploy服务器。

    在RHEL计算机的安装过程中,我们为/ , /var , /usr , /home , /opt和/tmp定义了单独的逻辑卷,禁用了防火墙,并将运行级别设置为3。

    UrbanCode Deploy计算机还从网络文件系统(NFS)服务器安装共享,以用作安装映像的存储库,这在管理磁盘空间方面增加了更多灵活性。

    从UrbanCode Deploy服务器,我们必须管理多个独立的环境,SoftLayer网络中的登台和生产环境以及可能更多的远程环境。

    可以使用VPN来访问SoftLayer网络。 但是由于VPN不是我们实验室的选择,因此我们使用了另一种方法。 由于我们在部署计算机时分配了公共IP地址,因此我们决定利用此接口在服务器和中继之间建立通信。

    我们在SoftLayer环境中定义的Linux RHEL 6计算机上安装了UrbanCode Deploy中继代理,其中一台用于环境。 这些机器在SoftLayer网络中具有专用接口和公用接口。

    我们配置了iptables来丢弃公共接口上任何端口上的连接,但源于IBM公共地址的SSH连接除外。 SSH设置为仅在公用地址上接受公用密钥身份验证。

    然后,UrbanCode Deploy服务器在127.xxx接口上建立到远程中继服务器的SSH连接,将服务器的端口转发到中继,并将中继端口转发到服务器。

    例如,对于生产环境,我们使用以下命令:

    ssh -f -n -N -x -R 8080:localhost:8080 -R 8443:localhost:8443 -R 7918:localhost:7918 -R 1099:localhost:1099 -L 127.0.0.3:7916:localhost:7916 -L 127.0.0.3:20080:localhost:20080 -L 127.0.0.3:36829:localhost:36829 -o StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes -M -S /tmp/ssh-${remote_user}@${production_relay}:${ssh_port} -p ${ssh_port} -l ${remote_user} $ {production_relay}

    此命令启动后台SSH进程,该进程将中继端口转发到环回地址127.0.0.3,并将服务器端口转发到中继。 使用ControlMaster和ControlPath选项,我们可以轻松地检查连接是否仍在工作(使用OpenSSH -O选项),并根据需要重新启动它。 我们设置了一个定期作业,每五分钟检查一次连接,并在需要时重新启动它。 因此,UrbanCode Deploy服务器使用不同环回地址上的相同端口与每个中继进行通信,并允许我们支持所需的所有远程环境。 该功能帮助我们管理在SoftLayer的两个不同云中创建的过渡和生产环境。

    为了在SoftLayer环境中加快传输速度,我们还在远程端设置了一个远程存储库。 我们在中继上安装了Apache HTTP服务器,并导出了包含安装映像的目录。 代理使用curl和wget等标准工具访问图像,从而最大程度地减少了我们实验室中的网络流量。

    组件实施

    首先,您必须为在设计阶段确定的每个组件定义一个新的UrbanCode Deploy组件。

    定义组件:

    配置源存储库。 指定组件属性。 实施组件流程。

    配置源存储库

    每个组件都需要定义源存储库,其中将包含工件的不同版本。 在WaaaS DevOps项目中,我们使用版本化的文件系统作为源存储库。 我们将UrbanCode Deploy配置为自动导入版本,如图2所示。

    图2. UrbanCode Deploy中的组件定义

    每次有新版本的组件时,都会将其复制到文件系统上的/ ucd_data / DEVOPS / WAaaS_Master / <version_id>路径中,然后UrbanCode Deploy会将其导入。

    您可以选择Versions选项卡来监视导入到系统中的所有版本,如图3所示。

    图3. UrbanCode Deploy中的组件版本列表

    在“ 系统”>“设置”>“工件清理”中,我们定义了一个清理策略以仅保存最新的四个版本。

    图4. UrbanCode Deploy中的清理策略定义

    指定组件属性

    您必须使用在组件级别定义了默认值的参数。 例如,可以将特定组件的安装路径定义为属性。 该值很可能将针对每种环境和资源进行自定义。 但是,在组件级别定义默认值会很有用。 您可以从“ 组件”>“配置”选项卡>“组件属性”中定义新的组件属性 。

    实施组件流程

    组件流程描述了在组件上运行的自动化任务。 组件流程可以在组件上部署,安装,卸载,更新或运行其他任务。 您可以从Component-> Processes定义新的组件流程。

    图5. UrbanCode Deploy中的组件流程创建

    有不同的过程类型:

    部署部署一个组件版本为目标的资源和成功运行后,更新库存。 配置部署是仅配置的部署,没有组件版本或构件。 此设置将配置(使用属性或配置模板)应用于目标代理,然后更新资源配置清单。 在给定组件版本的情况下, Operational运行任意步骤,并且不会添加或删除任何工件或配置。

    组成过程由步骤组成。 可用步骤在“可用插件步骤”列表中列出。 UrbanCode Deploy提供了几个实用程序步骤和插件。

    在我们的组件过程中,我们使用了几种类型的实用程序步骤和插件。 例如,我们使用了:

    下载工件,以将工件从IBM UrbanCode Deploy存储库下载到代理。 Shell脚本 ,用于在计算机上运行Shell脚本。 解压缩以解压缩ZIP文件。 设置/获取属性以检索IBM UrbanCode Deploy属性(资源,组件)的值。 向版本添加/删除状态以向当前组件版本添加和删除状态。 替换令牌可将特定令牌替换为具有值的列表。 这些值可以在步骤中直接指定,也可以引用UrbanCode Deploy属性。 运行组件进程以运行另一个组件进程。 运行通用流程以运行通用流程。

    对于每个组件处理步骤,可以定义:

    前提

    前提条件是JavaScript,它定义了该步骤可以运行之前必须存在的条件。 条件必须解析为true或false 。 在WAaaS项目中,我们使用前提条件在运行步骤properties.get("<properties_to_verify>") == "false"之前验证属性的值。 (<properties_to_verify>允许的值为true和false。)

    后处理脚本

    后处理脚本在步骤完成后运行。 通常,后处理脚本可确保发生预期的结果。 在WAaaS项目中,我们使用后处理脚本在可从其他步骤使用的属性中设置步骤的输出。

    例如,我们定义了以下后处理脚本:

    properties.put("result", "default"); if (properties.get("exitCode") != 0) { properties.put(new java.lang.String("Status"), new java.lang.String("Failure")); } else { properties.put("Status", "Success"); scanner.register("^Output", function(lineNumber, line) { var temp=line.split("="); var out=temp[1]; properties.put("result",out); }); scanner.scan(); }

    该脚本将当前步骤的输出的一部分设置为称为result的属性的值。

    使用方法scanner.register("^Output", function(lineNumber, line)在输出中找到以输出字符串开头的行。然后脚本在"="之后标识字符串,并将其设置为名为result的属性。例如,如果步骤的Output=value1为Output=value1 ,则属性结果值将为value 1 。

    您可以在步骤之间传递属性值。 如果在使用后处理脚本的步骤中设置特定属性,则可以在其他步骤中使用语法${p:<stepName/PropertyName>}使用此属性。

    组件处理流程

    必须将所有组件处理步骤组合在一起以创建处理流程。 在流程中,您可以使用步骤来加入前面的步骤,切换以创建条件步骤,依此类推。

    可以根据步骤的结果(成功,失败或两者)指定不同的流程。

    图6. UrbanCode Deploy中的组件流程设计

    由于组件流程可能很复杂,因此可以使用步骤运行组件流程来帮助创建子流程并在流程中使用子流程。

    图7显示了为Update Master流程实现的组件流程的示例。

    图7.为Update Master实现的组件过程示例

    定义应用

    在实施持续交付解决方案时,在创建组件和安装代理之后,必须创建一个应用程序。

    UrbanCode Deploy中的应用程序将必须一起部署的所有组件组合在一起。 他们通过定义每个组件的不同版本以及定义组件在生产过程中必须经历的不同环境来做到这一点。 应用程序还映射了组件在每个环境中所需的组成主机和系统(称为资源)。

    这些应用程序还实现了自动部署,回滚和类似任务。 这些任务称为流程。 但是,在应用程序级别,过程仅与部署和相关任务所需的组件和资源有关。 相反,组件过程与正在运行的命令和相关任务有关。

    图8. UrbanCode Deploy中的应用程序创建

    在UrbanCode Deploy上定义环境

    从刚刚创建的应用程序开始,创建一个新环境。

    图9.在UrbanCode Deploy中创建应用程序环境

    在资源选项卡中,指定组成您的环境的所有资源。 您可以使用子文件夹来构建环境定义。

    添加组成环境的所有代理之后,请为每个代理关联特定的组件。

    图10.将组件与UrbanCode Deploy中的资源相关联

    批准定义

    如果需要环境批准,请在环境的配置选项卡中选中标志“需要批准”。 您还可以定义一个免除进程列表,一个无需批准即可在此环境上启动的应用程序进程列表。

    图11. UrbanCode Deploy中的批准流程定义

    最后,在批准过程选项卡中定义特定的批准过程。

    图12. UrbanCode Deploy中的批准流程定义

    环境门

    在UrbanCode Deploy中,您可以指定在通过建立门将应用程序提升到环境之前必须满足的条件。 门是在环境级别定义的; 一个环境可以有一个或多个条件。 盖茨提供一种机制来确保:

    除非组件版本具有Gate指定的状态,否则无法将其部署到环境中。 申请反映了商定的促销质量标准。 提前进行的应用程序具有可审核的签名。

    在环境上运行应用程序流程时,必须使用在环境门中指定的状态来标记流程中包括的每个组件版本。

    在WaaaS项目中,我们定义了以下约束:

    要在登台环境中安装的版本必须标记为QA_OK(质量保证正常)。 要在生产环境上安装的版本必须标记为STAGING_OK。

    您可以在“组件”选项卡“ 状态”中将状态手动添加到版本中,也可以使用添加/删除状态到版本步骤由组件进程自动添加。

    图13. UrbanCode Deploy中的环境门定义

    高级环境定义

    要定义动态环境,请阅读“ 使用UrbanCode Deploy管理动态云环境中的持续交付 ”(developerWorks,2014年)。

    要在SoftLayer上定义远程存储库,请阅读“ 使用UrbanCode Deploy管理动态云网络上的远程存储库 ”(developerWorks,2014年)。

    将组件与应用程序关联

    您必须在应用程序中指定要在应用程序过程中使用的所有组件。 选择您的应用程序,选择Components选项卡,然后添加所需的所有组件,如图14所示。

    图14. UrbanCode Deploy中应用程序中组件的定义

    属性定义

    我们在上一节中介绍了组件属性,但是您可以根据组成组件的环境或资源在流程中使用许多不同的属性。

    例如,由于要安装的资源的原因,您要安装组件的安装路径可能会有所不同。 该过程应通用,并应在所有环境中使用。 因此,可以将安装路径指定为变量属性。 可以在不同级别定义该属性:

    组件级别是属性的默认值。 因此,如果未在环境或资源级别指定它,则使用此值进行设置。 环境级别在组件或环境的“ 属性”选项卡下定义。 虽然两者都使用相同的语法,但后者不与任何特定组件关联。 在关联的环境或组件上提供值。 在组件环境上设置的值将覆盖直接在环境属性上设置的具有相同名称的值。 并由${p:environment/< property_name >}引用。 资源级别属性可以包括内置代理属性和任何自定义属性。 每个属性在资源上都有一个选项卡,并由${p:resource/< property_name >}引用。

    如果在多个位置定义了属性,则其值取决于属性的优先级 。 以下列表定义了从最高到最低的优先顺序:

    处理 组件版本 资源资源 代理商 环境 零件 应用 系统

    在UrbanCode Deploy上定义连续交付工作流程

    定义环境后,您可以开始定义应用程序流程。 应用程序流程(如组件流程)是使用流程编辑器创建的。 UrbanCode Deploy提供了几个常见的处理步骤。 否则,将为为其关联的组件定义的过程组装应用程序过程。

    可以为每个关联的组件定义不同的步骤,例如:

    安装 卸载 回滚 每个版本的运行过程 套用设定

    您可以将每个应用程序处理步骤定义为仅在具有特定标记的资源上运行。

    图15.将流程执行限制为特定的标记资源

    图16显示了WAaaS QA环境的应用程序示例。

    图16.一个应用程序流程设计的样本

    运行申请流程

    您可以按需运行应用程序进程,也可以安排它。 要运行一个进程,请转到Application> Environment选项卡,然后单击运行图标(粗体箭头),如图17所示。

    图17. UrbanCode Deploy中的运行流程界面

    每次创建新版本的组件时,也可以定义特定的应用程序进程在环境上运行。 转到组件>配置,然后选中“创建新版本后运行进程”,然后选择应用程序进程和应用程序环境。

    商业利益

    持续交付是一种新兴的软件开发方法,可以自动化和改善软件交付。 目的是实现在不影响质量的前提下,快速,可靠,反复向客户推出增强功能和错误修复功能。

    连续交付可带来两个重要的业务收益:

    它使您能够更快地将产品推向市场,从而使您能够从目标市场获得真正的反馈。 如果您的业务计划从根本上存在缺陷,那么您希望尽快发现这一点,而不是花了数月甚至数年的时间来投入资金来实施项目。 持续交付使您能够适应客户的需求并响应他们的要求。 随着持续交付提供的流程大大降低了软件交付的风险,成本变得更加可预测,特别是与长期项目结束时传统的大爆炸版本相比。

    结论

    我们为您提供了一个简单的指南,以基于我们的案例研究WAaaS DevOps项目的示例创建连续交付解决方案。 在这个项目中,UrbanCode Deploy使我们能够在短短几周内创建整个解决方案。


    翻译自: https://www.ibm.com/developerworks/cloud/library/cl-softlayer-urbancode-trs/index.html

    相关资源:Urbancode Deploy User Guide
    Processed: 0.008, SQL: 9