带有GitOps的阿帕奇·卡夫卡是什么样子的？

任何运行Apache Kafka数据基础设施并运行在Kubernetes上的人，都有可能以这种方式定义您的基础设施。

如果您在Kubernetes上运行，您可能会使用操作符作为CI/CD工具链的一部分来自动化部署。

采用GitOps是自然发展，因此您的环境的状态在Git(或任何代码库)中进行管理，自动化系统确保部署的状态与repo保持一致。

我们发现，在Kafka和Kubernetes等技术上管理流和微服务的应用程序环境方面，尤其缺乏成熟度和最佳实践。

GitOps在DataOps中扮演着越来越重要的角色。DataOps通过分散的数据管理、自动化、自助服务和降低操作数据所需的技能来促进数据产品的加速交付。GitOps带来了标准化、治理和自动化。

这是我们最近在一些活动中谈论的话题，包括今年的卡夫卡峰会(Kafka Summit)和DevOps.com：

当我们希望在DataOps之后实现实时应用程序的自动化时，我们需要考虑的不仅仅是自动化应用程序部署。我们需要将正确的数据治理控制定义为软件交付的一部分。

缺乏良好的治理将降低对数据的可及性和信任度，并降低在下游使用数据的信心。治理应涵盖数据的可访问性、可用性、质量、完整性和机密性。

我们希望最了解数据的App创建者能够将治理控件定义为单个包，然后通过标准工作流对其进行审查。

示例：数据分析师构建他们自己的数据处理应用程序，但他们也定义发布应用程序所需的治理和遵从性控制。这使得应用程序的性能参数掌握在他们手中-他们决定是什么让它成为生产就绪和企业级的。

在Kubernetes上部署Kafka时，可能是这样的：分析师以某种形式(如SQL)定义应用逻辑，包括：

然后可以将其推送到Git，通过您的标准Git工作流和创建的合并请求进行管理，从而触发构建管道在您的不同环境中部署。

如果您正在与卡夫卡合作并进行此操作，我们需要考虑两个方面：

Lens为数据从业者(开发人员、分析师，甚至商业用户)提供全面的体验，通过确保所有数据都已编目、可访问和可浏览，构建部署在Kafka&；Kubernetes数据平台上的实时应用程序。

Lens CLI客户端允许将您的“数据景观”导出为声明性配置。例如，下面是一个表示Avro模式的YAML文件：

这是我们看到大多数组织采用的方法。团队将使用Kafka、Kafka Connect、Kubernetes或您运行应用程序的任何地方的各种API推送到Git，这将在任何CI/CD(如Jenkins)中触发部署管道。这也使得Jenkins很难监控所需的状态并确保与Git的一致性。

当然，您还需要打开防火墙以允许Jenkins进入您的数据平台。

您可以使用Kubernetes运算符来推送所需的状态。但是，Jenkins或您的CI/CD工具仍然需要渗透数据平台环境，这可能会增加安全风险。然后，您可以使用Kubernetes运算符(如Strimzi的)来监控所需的状态，并通过API将该状态应用到Kafka。此方法通常用于操作Kafka基础设施、纵向扩展代理等，而不是在数据层(主题、ACL等)操作。

Pull方法仍然基于运算符模式，但通过监视Git而不是监视Kubernetes。

操作员是镜头操作员，可以在您的数据平台内部或外部运行。操作员与镜头对话，镜头将所需状态应用于数据平台，包括任何实时应用程序。例如，对于任何使用镜头流SQL的人来说，这将在Kubernetes上部署应用程序。

当然，所需的状态将在单独的镜头环境中创建，并在推送到Git之前通过CLI导出为config。

此拉入部署方法的优势在于，通过不需要您的CI/CD来访问您的基础设施，它提供了更安全的环境，它还确保您的应用程序在Git中得到保护、治理和审计，状态受到积极监控，并且能够随时回滚。

您现在可以在免费的Kafka+镜头对接开发箱中练习GitOps。如果您有兴趣及早接触镜头运营商：现在就通过表格或通过Slake与我们联系。