Red Hat举办实机体验营，助企业淬链现代化应用程序开发能力
- 尤嘉禾／台北
-
随着数码浪潮持续推移，身为「创新者」的企业老板，对于数码转型难免产生愈来愈多的憧憬，期望藉由将应用转移上云，借此享有前所未有的高扩充性、高可用性、降低成本…等效益，进而让商业运转得更为顺畅。但身为下属的「实践者」，对于接踵而来的改变，却怀抱着不安与恐惧。
尽管这些实践者深知现今全球软件开发都往云原生、容器化、微服务化等路线靠拢，也明了必须落实这些基本功，才能满足老板心中的宏愿。无奈碍于知识落差、抗拒一次性修改、生怕无法展现实际效益…等阻力，使得现代化应用开发进度载浮载沈，经过许久依然不符合老板的期待。
为了帮助大家加速解决种种难题，Red Hat于日前举办「现代化应用开发实机体验营」，透过迥异于一般研讨会的独特实践体验，既有资深讲师阐释企业组织如何善用Red Hat OpenShift Container Platform（RHOCP）与相关产品，顺利在混合云平台上展开现代化应用程序开发旅程；亦针对开发人员与技术专家，手把手提供实机体验环境，让学员们更加理解如何重构应用，并将新的应用程序部署至RHOCP，接着在RHOCP平台上实践应用程序的持续整合／持续部署（CI/CD）。
OpenShift转型平台，助企业畅游云原生旅程
Red Hat台湾资深解决方案架构师Michael Suen，率先登场讲述「现代化应用开发概观与趋势」。他强调云原生是转型关键，而云原生转型平台的三大基石，涵盖了「从瀑布型到CI／CD开发维运」、「从数据中心到任一云」、「从单体式到微服务」。
至于容器之于云原生的优势，在于它能够更高效地利用系统资源、更快的启动速度、云地一致的运行环境、持续交付与部署、更轻松的迁移，以及更轻松的维护与扩展。也就是说，虽然容器开发并非为了呼应上述三大基础所应运而生的技术，但却能完全美契合这些趋势脉络。
因此，企业可凭藉基于容器及Kubernetes（K8s）的混合云策略，渐进式的上云，以确保On-premise投资不会打水漂，且基于开源技术100%兼容于产业标准规范；更重要的，企业可藉由一致的技术栈，维持相同的DevSecOps体验，随需横跨不同的公有云。
但企业也必须认知到，投入云原生转型，最迫切需要的是平台，而非工具；此转型平台上既要有操作系统及基础平台，同时也需要云端管理和自动化系统、以及管理工具。Red Hat OpenShift不仅蕴含从底层到上层、从纵向到横向等完整转型平台要素，且一举整合了大量适合企业容器平台的专案，因而能全面兼顾PaaS三种使用者角色「开发、维运、网安」的作业需求，让他们在共同环境中无缝协作，齐力驱动CI／CD交付链的流畅运行。
现代化应用开发平台，不单是容器平台而已
Michael Suen接着说，企业转型之所以需要借助云原生平台，系因它蕴含了多重价值，可协企业一举实现多重目的。首先是「现代化现行应用」，需要利用此先进开发平台来改进旧系统，以降低营运成本并缩短应用部署生命周期。其次是「部署新应用」，在保持安全性及高品质的前提下，让新的应用服务和功能快速推陈出新。再者为「软件供应链安全」，在整个建构、部署与运行过程中，能够提供安全并保护应用服务。
第四是「持续部署」，采用一致且内建的安全防护机制，达到跨混合云环境自动建构及交付应用服务。第五是「环境一致性」，可确保云地一致的交付和营运模式。最后是「DevOps 平台」，利用自助的DevOps平台，建立开发者的应用服务开发交付体验。
由此可见，足以全面涵盖上述所有环节的OpenShift，并非只是Kubernetes（K8s），正确来说可以是K8s-powered应用平台。
主要是因为，一个完整的云原生开发生命周期，必须能支持「赋能开发团队」，意即自助开发平台、微服务开发语言、快速开发验证体验。换言之在大规模开发、构建、部署和运行容器应用的前提下，K8s仅是偌大平台当中的一个部分；亦可支持「自动化安全流水线」，支持持续整合及安全左移，并提供软件安全及稽核纪录；此外还要能「持续投入生产」，具有可追踪的自动化部署、洞察应用及零信任实践。
所以，一个完善的应用开发平台绝对不等于容器平台，另需要整合开发工具及服务，如此才能让应用交付更加快速。
具体来说，OpenShift之所以在容器平台市场掌握47.8%高占有率，遥遥领先其他品牌，正是因为它超越了单纯的容器平台层次，不仅富含完整的云和地平台管理功能，更能支撑横跨云和地的一致开发体验，使企业能够凭藉一致的指令、一致的工具链、一致的技术力…等倚仗，朝向云原生目标顺利推进，过程中无踩坑或跌跤之虞。
欲实践DevOps，首先须从形塑文化着手
Red Hat台湾解决方案架构师Dennis Chou，进一步分享「如何在Red Hat OpenShift Container Platform上实践应用持续整合与持续部署」个中要领。
他表示，时至今日大家对于DevOps已不再陌生，而且它也并不是新名词。简言之，它的目的是让开发者更快速交付业务功能、符合业务发展需求；与此同时，又能迎合维运团队力求运行环境稳定性的初衷，两造的期望能够完美兼顾，没有冲突矛盾。
至于如何导入DevOps？Dennis Chou提醒，并非从DevOps工具链中选用几套工具，就真的实现DevOps，必须确实发挥更快速的部署、更敏捷的开发，且让业务系统更快交付等功效，才算是符合要求。
因此实践DevOps的第一个重点，其实不在于采用什麽犀利的工具，而在于能否形塑出让开发人员、维运人员彼此更容易合作的流程。因此要想落实DevOps，首要之务其实是「文化」；唯有建立DevOps文化，才能真正消除开发和维运之间的壁垒，在相同技术架构上共同合作。至于要填补双方的Gap，在技术上有一项不可或缺的基石，便是自动化部署，如此方能达到更快速的变更与迭代，且将可能出现人为失误机率降到最低。
以四大关键指标，衡量DevOps实践成果
接下来，企业需要建立一个衡量机制，藉以判断DevOps的实践成果究竟是好是坏。大致上来说，这个衡量机制必须依循四个关键指标。第一是「交付时间」，意指从提交程序码，到运行至生产环境的所需时间。第二是「部署频率」，指的是部署上线到生产环境的频率。第三是「变更错误」，端看有多少百分比的变更出现错误，并且需要修改。第四则是「恢复时间」，究竟需要多久时间，才能从意外事件中恢复正常。
当然，关于这四个关键指标，各有各的持续精进方法。首先谈到如何缩短交付时间，重点就在于自动化，以往之所以耗时甚钜，主要症结就是人工部署、人工打包，若能将打包与部署、连同中间的测试过程通通导向自动化，就可望出现大幅改善。
其次谈到如何提高部署频率，透过敏捷式开发，尽可能缩小每次的部署量，就越少机会出现错误，也不必花太多时间进行程序整合，堪称立竿见影的做法。
至于如何减少变更错误率，如前所述，藉由自动化可减少人为错误，而每次部署的量越少，也就越能执行完整的测试，错误率就会显着降低。另可归功于一致性环境，即便有错误，通常会在前面的开发或测试阶段发现问题、及早除错，而容器即是打造一致性环境的关键技术。
最后谈及如何缩短恢复时间，可采用进阶部署策略，如蓝绿部署、金丝雀部署，并且搭配自动回滚策略，避免在生产环境中修改错误。
藉由Build、Tekton与GitOps，实践CI／CD流水线
更重要的，要改善四大问题，还可倚靠另一项重要解方，即是最基础的CI／CD Pipeline。依据云原生标准的CI／CD实践方式，分上下两块。针对下面的CD，OpenShift采用GitOps工具，上面的CI则采用Build、Pipeline两套工具。
Build负责将原始码打包成镜像档，再往下走到OpneShift的CI Pipeline「Tekton」（Tekton为K8s原生宣告式流水线服务）。Tekton的优点在于它是Serverless CI/CD，用户无须维护及管理CI服务器；其次它能够在包含所需依赖的个别独立容器中运行流水线，可扩展性甚高；再者它也能轻易整合Web、CLI、VS Code或IDE Plugins等各种开发工具。而用户可自行定义流水线，只要Tekton读取到定义，就能帮忙执行该任务。
关于流水线中的执行步骤，首先需定义Step、即为任务执行步骤。将这些Step组合在一起便成为一个Task，是流水线中最小的运行单位，而Step容器会在Task Pod中运行。再往上一层，就是完整的Pipeline流水线，负责定义Tasks执行顺序，并透过Workspaces共享Tasks之间的数据，且允许横跨不同Projects重复运用。
论及OpneShift用来作为CD工具的GitOps，是一组利用Git工作流来管理基础架构和应用程序配置的实践。它利用Git储存库作为真实来源，允许DevOps团队将丛集配置的整个状态储存在Git中，好让它的所有更改轨迹，都是可视化及可稽核的。
云原生平台所有的部署档皆以YAML形式撰写，用户可将YAML档存放到Git版控程序里，其中有专门的应用负责监控版控程序上的设定值，且会自动确保丛集与版控的设定状态相同，接着透过此方式进行宣告式部署。而GitOps除可用于部署应用程序外，另外也能执行基础建设管理，甚至可以延伸到其他细部应用，像是执行更为进阶的部署策略，抑或进行DR切换。
值得一提，RHOCP GitOps工具的上游专案为ArgoCD，它会比对Target State（应用的目标状态，存放在 Git）、Live State（应用的真实状态，即Pods等应用服务部署的情形），若发现两边不相符，就启动Sync流程。
标准CI／CD范例如下。当程序码交付到版控，便进入CI阶段，结束后会产生出可部署档案，最后进入CD阶段，把部署档布建到各环境。
启动安全措施，从CI／CD推进至DevSecOps
当用户开发完成、要部署至容器平台，需先描述应用，打包为镜像档。建议用户选择验证过的镜像档作为打包基底，且最好选择最小化镜像档，只因它更轻量，更易于快速启动，且因内容较少、可被攻击的漏洞更少。
当完成前述撰写后，连同Dockerfile、程序码放到Git，便进入CI阶段，会自动触发Image、Build Pipeline，此时将产生JAR档，需将它放到一个专门放JAR档的Repository里，再打包JAR档为镜像档，放至Image Registry。上传完成后有一步骤，需针对Registry做安全扫描，确保镜像档安全无虞，至此完成CI。再往下走即进入CD。把YAML档放上GitOps，再执行自动部署。
如何从CI／CD到DevSecOps？首先镜像档打包时要有安全来源，即Red Hat验证过的UBI，并搭配上述Image Registry的扫描程序。此外可在流水线中加入安全签章流程，先以打包好的镜像档做签章，确保不会被人擅自替换。另一方面可在整个部署完成后，启用持续侦测的安全机制，譬如Runtime Detection、ACS等。
技术交流工作坊，引导学员将应用迁移至RHOCP
活动的后半段，系由Red Hat台湾的Kai-Feng Chang等多名客户技术经理（TAM），联手举行技术交流工作坊。
TAM引导大批学员展开「将应用程序迁移至RHOCP」的实机演练，首先启动准备程序，让学员存取Red Hat备妥的Lab环境、VS Code Server、Gitea；接着利用MTA （Migration Toolkit for Applications）对应用进行评估与分析。
再藉由TAM的指点，使学员知道如何因应分析结果执行重构（Refactor）、然后部署至RHOCP。最终在RHOCP启用Pipeline 与GitOps，实现应用程序的持续整合与持续部署（CI／CD），为一整天的活动划下圆满句点。
