Red Hat展现云端技术力 强势助攻企业数码转型
- 尤嘉禾／台北
-
随着疫情蔓延，不仅造成在线云端网安需求爆量，连带刺激企业加速推动数码转型。此一形势迫使多数企业IT部门加快移动、积极规划混合云策略，期望在满足公司业务服务所需资源之余，也让企业从云原生技术得利，如愿促进营运体质的强化。
为协助企业加速前进，Red Hat于日前特别举办「Red Hat Innovation Day云端技术暨数码转型解决方案」在线研讨会，大举铺陈开放式混合云基础架构、自动化管理、云端原生应用程序开发、高效能Linux、容器与Kubernetes等多项关键技术，期盼带领企业IT从业人员提升云端基础架构与开发技能，跻身企业数码转型的强力助攻手。
RHEL for Edge，助用户迅速布建边缘运算节点
Red Hat首席资深解决方案架构经理游政杰率先开讲，以「Red Hat Enterprise Linux(RHEL)的创新与演进」为题发表演说。他指出全球约有百万个开源社群，有的历史悠久、有的为后起之秀，如何从其中萃取创意精华、组合成对企业有利且易于安装使用的方案，一直是Red Hat致力实现的愿景。
Red Hat赞助一些社群，同样秉持开源精神，免费提供广大用户使用其成果，并以此作为企业级方案的雏型，透过适当组成与验证，若确认达到一定的稳定度，便启动QA程序，将它转变为商用产品，为客户提供稳定生命周期保障与对应服务支持。像是Fedora，即属于Red Hat赞助的社群。
另一为人熟知的CentOS社群，其实与Red Hat无直接关系，只是CentOS将RHEL的开放原始码重新打包与编译、形成自己的版本，提供众多用户使用。但不少用户期望将一些源自CentOS的应用效益，转移至Red Hat企业级产品，却事与愿违；因企业级产品讲求稳固安全，不轻易采用未经测试的元件。
为此CentOS创立新的发行版本(Distribution)「CentOS Stream」，自我定位在Fedora之后、RHEL之前，不像CentOS处于价值链最下游，相对适合发展RHEL下一版本雏型。
游政杰解释，每个开源版本皆有专注领域，Fedora发展RHEL下一个大版本，如Red Hat于5月发表最新版RHEL 9，Fedora就着手研发RHEL 10。CentOS Stream发展RHEL下一个小版本，如RHEL 8.6问世、CentOS Stream就发展RHEL 8.7雏型。反观CentOS是RHEL追随者，版本是切齐的，故对社群开发并无助益，CentOS Stream即可化解此问题，有望让开源创新的反馈回路(Feedback Loop)回归正轨。
关于刚问世的RHEL 9，相较于RHEL 8有一些改变，例如SELinux的Disable方式出现调整；此外废止SCP SSH拷贝档案的指令，鼓励用户转而采用SFTP。此外也有许多不变之处，包括提供长达10年的生命周期支持，并持续发展软硬件认证生态，确保用户在企业级应用中获得最大支持。
值得一提，RHEL 9在安全性部份出现显着优化，包含改善SSSD Logging、改善SELinux效能、整合最新OpenSSL 3、SSH缺省允许禁止Root Login、停用SHA-1加密机制、运用新的 Cgroup 2来管控资源；此外支持subuid机制，以确保容器安全性。
至于RHEL 9内含的Kernal 5.14，亦有新功能，像是整合WireGuard轻量级VPN、支持最新加密机制与更快速的回应时间，同时还支持Core Scheduling功能，好处是帮助使用者进行更妥善的效能规划与安排，也一并增强安全隔离、避免受到类似Spectre或Meltdown弱点影响。
RHEL可支持多种环境，包括x86、IBM Mainframe或Power System，并支持云端环境、地端虚拟环境，甚至也开始支持ARM。另一方面，RHEL因应快速崛起的边缘运算趋势，顺势提供RHEL for Edge版本，标榜能做到零接触部署，可藉由轻量方式、自动安装完所有OS与相关设定；用户亦可在RHEL for Edge上直接以容器方式部署应用程序，并藉由容器映像档(Image)封装的一致性，确保应用程序的部署趋于标准化，加速拓展到世界各角落。
另外RHEL 9以Podman作为容器Runtime，其中有一功能对管理者颇有助益，可针对容器执行Auto Update，若Update完却出现问题，还可利用容器回撤机制加以补救，大幅减少人工维护时间与心力。Edge版OS本身也可像容器一样运作，假使你需要做系统升级，可安装另一映像档在背景，避免影响Runtime，等到下次Reboot时，新的Runtime就会取代旧的Runtime，可确保Downtime最小化。
借助Ansible平台，轻松达成IT维运自动化
Red Hat资深解决方案架构师陈柏青强调，过去一年来，IT维运自动化已从「Nice to Have」跃升为「Must to Have」，重要性节节攀高。其中Ansible Automation Platform在整个企业IT自动化的应用也越来越广泛，利用这个高效、简单、易于分享个工具减少了IT日常维运负荷与提高重要工作执行时的安全性。
综观Red Hat Ansible的Playbook，主要内含Plays、Modules及Plugins三大角色。一个Playbook可以有许多Plays，Plays内含许多Task、即是我们希望脚本能帮忙执行的内容，当然也包含Modules、Plugins，这些都是组成Plays的重要元件。惟IT环境变化甚大，故企业会因应运行目标的不同，创建自己的模块与插件、在自己的平台上运行，倘若此脚本分享给其他用户，往往会出现不匹配，为此Red Hat想出一个方法，将Modules和Plugins打包成为Collections，一个Collection连同脚本运行，会主动呼叫需要的模块与插件，以及此Collection的使用方法、测试方法。
陈柏青说，Collection由目录形式组成，在档案结构中置入Modules、Plugins、Role、Docs、Tests等素材，让使用者轻松汇入并使用。显见Collection极为重要，有助让整个组织的自动化程度愈趋成熟与快速。企业除可自行编写Collection里的Modules或Plugins外，亦可取用社群写好的Collection，或从Red Hat Automation Hub下载对于组织有必要性的Collection。
不可讳言，运行Collection仍需借助函式库(Library)、Python程序，使用者须确保它们版本的统一化。此时可利用「Execution Environments」这样的新概念，将所需Collection、Library、Runtime通通打包为一个容器映档；如此就算接获他人分享的Collection，也不必担心因环境的Library或Code版本不同、导致运行脚本时发生状况。
另外企业在创建自动化内容时，可利用几项实用工具。首先是Ansible-Navigator，用于检视Execution Environments内容，举凡拥有哪些Collections、Inventories、Plugins，皆可透过指令来监看；它也可以运行一些Playbooks，将Playbooks指令简化为「ansible-navigator run」来执行。其次为Ansible-Builder，可协助用户收集设定好的Collections、Libraries、Codes，整合为一个Execution Environment。
活用Podman／Buildah／Skopeo，展开容器化旅程
Red Hat客户技术经理廖伟翔表示，许多企业已体认容器为大势所趋，但从传统架构要转到容器化，常会有的疑问是「要从哪里开始？」从何跨出第一步确实是企业 IT 转型上常见的疑问，如果容器化被形容是一段旅程，旅程可能有一个比较远的、长期的目标，可能最终是要做到 Container Orchestration、上云，或甚至到混合云，但所有旅程总会有一个最初的起步点、跨出的第一步，因此藉由这个议程，分享如果企业内部已正在使用RHEL，如何在RHEL上透过Podman作为展开容器化旅程的起点。
Linux容器其实技术上就是Linux Process，但透过Namespace及Cgroup技术做到隔离环境与资源控管。它与VM的差异，在于不以一个个OS为单位，而以应用程序为单位，由于 是共享Kernel，故相对于VM有着更轻量化与节省资源的优点。
Linux Namespace 为Linux提供的Kernel级别环境隔离方法，透过PID、IPC、UTS、Mount、Network、User等不同类别的Namespace来做到不同类别的隔离，如果要比喻的话，假设Host为一间公寓，Namespace可以形容为房间，房间的人只能看到与使用到自己房内物品。
在透过Namespace做到隔离环境后，容器内的Process仍可能任意使用主机资源，可能衍生资源竞争并影响容器运行。此时即需一个容器资源控管机制，可由Linux Kernel的Control Group(Cgroup)功能来负责；Cgroup可限制Process使用的 CPU、存储器、I/O 等资源，并执行优先层级的控制。如果使用同样的公寓房间比喻的话，可以想像成是房间自来水或是用电量的这类资源的限制。
「千里之行，始于足下。假设您的组织已经在使用RHEL，您可利用RHEL搭配Podman开启您容器化旅程的第一步。」廖伟翔说， Logo是「三只小海豹」的Podman是由 Pod Manager简称而来，其中的Pod与Kubernetes(K8s)的Pod是一样概念，可容纳一或多个容器管理单位；Podman指令兼容于Docker CLI，故熟悉Docker的用户几乎都能无缝衔接，但即便Podman与Docker操作方式一致，但底层运作架构则不同，相较于Docker，Podman有它的独特优势，包括「Rootless」，在建立容器时不一定需要 Root权限，有助提升系统安全，以及「Daemonless」，不需像Docker需要Daemon ，可直接呼叫OCI Runtime的RunC。
另外在RHEL上还有两项搭配Podman的容器工具分别为为Buildah、Skopeo。Buildah可以用于创建容器映像档，如透过from/run/copy/add/commmit指令，或从 Containerfiles或Dockerfiles建立容器映像档。Skopeo则可用于查询线上映像档的信息。
虽然每个容器执行的应用程序彼此独立、互不干扰，但Podman主要是在单台主机的使用情境，假设企业的使用需求较大、单机资源不敷使用，即需扩展主机，此时便亟需利用Orchestration(如Red Hat OpenShift、K8s)针对Multi-Node情境执行新旧资源的统合调度，不必耗时费工进行主机汰换。
而若企业已采用OpenShift或K8s，Podman是否即无用武之地？其实不然，Podman可将容器／Pod导出成K8s兼容的YMAL档，也可执行K8s YAML档。换言之企业若有 OpenShift或K8s营运环境，开发人员即可使用Podman在本地开发容器内容与进行简单测试，然后再Lift到K8s环境。
以一致的营运、部署与使用模式，实现极大化商业价值
担纲压轴讲师的Red Hat资深全球顾问卓俊宇，阐述如何运用OpenShift在多云环境实践商业价值。他透露，曾有企业问到，公有云上也有容器编排服务，相形之下OpenShift有何优势？他将顺势揭晓个中答案。
卓俊宇归纳，常见的云环境有三。第一是混合云，即云地结合的情境，通常地端为核心中心，云端是扩充中心，企业可利用云扩展服务节点，允许突发性大流量进入，又能兼顾法遵与机敏数据保全需求。第二是多重云，企业把云视为商品，端看哪个平台便宜、或最能满足所需功能，便考虑选用。第三是聚合云(Poly Cloud)，象徵混合云的专业化延伸，诉求一个应用服务可同时撷取不同公有云的优点，如AWS的S3、Azure的AD、GCP的AI/ML，汇整多云优势来满足企业当下业务目标。
谈到为何以OpenShift执行云策略？系因OpenShift提供弹性的产品模式，可适应各种云策略。其应用方式包括：一、作为标准化容器平台，让企业使用既有功能。二、采取托管模式，选项包括Red Hat OpenShift Dedicated、ARO(Azure Red Hat OpenShift)、ROSA(Red Hat OpenShift Service on AWS)等。三、启用Red Hat OpenShift Platform Plus，较OpenShift标准版多出ACS与ACM两项功能，后者作为中控管理系统，前者用于检视环境的安全状况。
上述三种方案皆可支持混合云、多重云、聚合云不同架构，意谓用户即使迁移新的云环境，也不必学习操作新的管理工具，即可藉由OpenShift一以贯之，维持一致的营运、部署与使用方式。
深究OpenShift可望为企业带来的商业价值，首先为「利润增长」，让企业加快至少30%的Time to Market速度，带动盈利与市占的同步增长。其次为「成本优化」：由于不管在什麽环境都能维持一致，让用户无需重新学习与适应，加上亦能促使企业策略或资产走向标准化与重用，故可减少建置与维运成本。
第三是「风险避免」，提供Compliance Operator工具，帮助企业监管所有应用的合规性，亦透过「6项流程＋12道工法」建构强力安全把关机制、严格确保上游开源软件元件的安全性，另藉由标准化平台特质，协助企业消弭供应商锁定(Vendor Locking)风险。第四为「达成策略目标」，主要藉由自动化、标准化功能及一致性体验，减少企业IT人力资源的耗损，让他们有余力做更有价值的事情。
大致上来说，企业可藉由OpenShift化繁为简，把任何想要连接的点、顺畅地串连起来，实现最大化商业价值，并可准确地测量你的云策略对商业目标所带来的影响；更重要的，OpenShift让企业获取最具选择性、保护性、平衡性的云战略科技，持续安全地扩展及执行现代化工作负载。
总括而论，本次在线论坛全面揭示开源技术创新的云开发环境、营运管理及各大知名开源专案，从而透过这些前沿技术发展趋势的分享，协助企业从容因应数码转型挑战，打造更高效、敏捷、弹性及安全的工作环境。
