使用 Podman Desktop 转变容器工作流

在过去六个月里，Podman Desktop 社区一直稳步发展并不断壮大，为今年晚些时候发布 1.0 版本做准备。最近发布的几个版本在用户体验、文档等方面做出了改进，扩大了对开发人员工具的支持，并且新增了多个能与第三方工具集成的扩展插件。

这项工作具有重要意义。当今的软件开发并非易事。系统错综复杂，而且开发涉及的不仅仅是编写代码。开发人员需要全面了解资源、集成、编排等众多内容。从本地开发软件服务，一直到编排系统中的生产，如果没有无缝衔接的路径，可能会给开发人员带来沉重负担。

Podman Desktop 致力于为开发人员减轻负担、降低复杂性，使开发人员能够使用图形用户界面（GUI）更轻松地与 容器 和 Podman 中运行的容器集交互，便捷地安装、配置和更新容器引擎。

简而言之，它提供了一条路径，让开发人员可以在无缝衔接的工作流中，从应用切换到容器、容器集再到成熟的 Kubernetes。正如我的同事 Ian Lawson 最近在其撰写的入门指南中提到：“Podman Desktop 确实减轻了在本地构建镜像和托管容器的烦恼。”

理论上，容器可以为开发和生产提供一致的环境。也就是说，当开发人员在本地使用容器时，他们知道应用所处的当前运行环境将与之后生产中部署的环境相同。这有助于避免依赖项冲突或配置不匹配等环境相关问题。但实际上，情况并非总是如此。尤其是在涉及安全考量、本地容器编排和其他更具体的功能时，情况可能很快就会变得非常复杂。

要打造出高度可移植的混合载体，开发人员需要确保在容器中本地开发的应用可以轻松迁移到不同的环境，如预演环境、测试环境或生产环境。这可以减少部署应用所需的时间和工作量，因为开发人员可以在不同的环境中使用相同的容器镜像。为了享受这些优势，对应用开发人员而言，拥有一个易于使用的环境尤为重要，这不仅可以减轻打包和配置应用的负担，还有助于在云环境中更加无缝地执行本地设置。这样，开发人员就可以聚焦于最重要的事情：应用代码。

虽然软件开发生命周期有明确的定义，并且始终从源代码开始，但后续步骤在很大程度上取决于各个部门的需求及其流程。有些部门可能更喜欢使用特定的云服务进行测试，而另一些部门则依赖于内部预演环境或各种云托管产品。Podman Desktop 中的扩展 API 不仅支持创建自定义扩展，还有助于培育一个开放的生态系统，使社区和合作伙伴能够将更多功能引入到 Podman Desktop 中，成为开源创新引擎的一部分。

虽然在本地运行单个容器有助于测试，但对于实际项目来说，很少有应用是独立存在的。大多数打包在容器中的应用都依赖于数据库、消息传递基础架构或其他下游依赖项来正常运行。对开发人员而言，在本地测试容器编排同样重要，因为这不仅有助于快速启动依赖项，还能在 GitOps 流程接管之前进行快速测试。开发人员的最终目标是从本地 Kubernetes 配置开始，经过预演阶段后，部署到生产环境中。虽然 Podman Desktop 有助于为容器一键式生成 YAML，但我们知道，基于 Compose 的传统配置仍然存在。为了更轻松地过渡到 Kubernetes，Podman Desktop 现支持开发人员使用 Compose 规范同时运行多个容器。Podman Compose 需要 Compose YAML 文件，其中对需要通信的容器做了定义。这是朝着直接在本地使用生产就绪型 Kubernetes 清单迈出的重要一步。

Podman Desktop 正蓄势待发，我们对未来的发展充满期待。您可以前往 https://podman-desktop.io，了解有关 Podman Desktop 项目的更多信息并下载所需内容。如果您不太了解 Podman Desktop，我建议您阅读红帽开发人员博客上的“什么是 Podman Desktop？开发人员概述”。