deployment - Apache NiFi的开发生命周期

我意识到，对于NiFi，正如他们的文档定义的那样，“生产中持续改进”。因此，这不适合用作传统的开发工具。然而，对于我正在研究的项目，已经确定这是我们将要使用的工具，所以我宁愿不讨论这个的优点，因为我意识到会有一些问题。

例如，如果我将更改推送到现有环境（从登台到生产）并且目标中有实时编辑，它们将被覆盖。所以我对如何组织开发生命周期有疑问。

是否有可能合并更改由多个开发人员并行完成（合并导出的xml模板文件）？我猜合并任何重大变化都可能很困难，但没有尝试过。
如何管理版本控制更改？我假设您可以将整个配置导出为模板并将其检入版本控制？
如何将流部署到其他服务器？您是否可以部署一个库存NiFi部署，然后使用NiFi REST API从导出的模板（如上所述）更新它？
如何管理部署到可能具有不同配置的不同环境？你需要更新模板XML文件吗？或者我可以动态地从Zookeeper中获取它吗？

作为您引用的项目的原始作者和Apache NiFi PMC的成员，让我首先说您提出了很多问题，我可以欣赏您来自哪里。我们应该改进介绍文件，以更好地反映您提出的问题。

您说得对，当前的方法是创建流的模板，然后您可以将其提交给版本控制。人们也可以使用与NiFi的REST API交互的脚本自动部署这些模板。但是，我们可以而且应该做的远远超过我们必须使数据流管理工作更容易，无论您是开发人员是否准确地编写将要部署的内容，或者您是否是一个以操作为中心的人必须放置这些部分在一起。

流程[1]的管理和版本控制应该更容易并集中管理，以便在多个集群和环境中共享[2]。
我们需要确保环境特定值很容易映射到给定的环境，但模板仍然是可移植的[3]。
我们需要使多用户/多租户用户体验更加直观和自然[4]。

1和2的元素将出现在即将发布的1.0版本中，第3项将在即将发布的版本中完全涵盖。在多开发人员案例的同时，我认为将他们自己的本地实例视为单元测试的地方是有意义的。他们的流程，然后使用共享的临时或生产环境。要记住的关键是，对于许多流程和使用NiFi的方法，可以让给定流程模板的多个实例执行每个实例馈送数据的实时馈送。该流程的结果/输出可以连接到实际传送到某处或简单地接地。通过这种方式，它很像源代码控制中的分支心智模型，如Git。你可以选择你考虑哪一个＆＃39;生产＆＃39;如果你愿意的话，图表上的流量只是一个正在进行的功能分支。对于那些来自更传统方法的人来说，这并不明显，我们需要做更多的事情来描述和证明这一点。但是，我们也应该支持更传统的方法，这就是我所关联的一些功能提案将启用。

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

[2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Registry

[3] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry

[4] https://cwiki.apache.org/confluence/display/NIFI/Multi-Tentant+Dataflow

Apache NiFi的开发生命周期

1 个答案: