Apache NiFi的開發生命週期

我意識到，隨着NiFi，他們的文檔定義它，「持續改善發生在生產」。所以這不適合用作傳統的開發工具。然而，對於我正在研究的項目，已經決定這是我們將使用的工具，所以我不想辯論這個優點，因爲我意識到會出現一些問題。Apache NiFi的開發生命週期

例如，如果我將更改推送到現有環境（從分段到生產）並且在目標中進行了實時編輯，它們將被覆蓋。所以我對如何組織開發生命週期有疑問。

是否有可能合併更改這是由多個開發人員並行執行的（合併導出的XML模板文件）？我猜合併任何重大變化可能很困難，但沒有嘗試過。
如何管理版本的變化？我假設您可以將您的整個配置導出爲模板並將其檢入版本控制？
如何將流程部署到不同的服務器？您可以只部署一個庫存NiFi部署，然後使用NiFi REST API從導出的模板（如上所述）更新它？
如何管理部署到可能有不同配置的不同環境？你需要更新模板XML文件嗎？或者我可以從Zookeeper之類的東西中動態獲取它？

來源

2016-06-20 Mike

作爲您引用的項目的原始作者和Apache NiFi PMC的成員，讓我開始說您提出了很好的問題，並且我可以欣賞您來自哪裏。我們可能應該改進介紹文件以更好地反映你所提出的問題。

您說得對，目前的方法是創建流程的模板，然後您可以將其提交到版本控制。人們也可以通過使用與NiFi的REST API交互的腳本來自動部署這些模板。但是，無論您是開發人員編寫準確部署的內容，還是您是以操作爲重點的人員，都必須自己將這些部分組合在一起，我們可以也應該做的遠遠超過我們的數據流管理工作。

管理和流量的版本[1]應該更容易和集中管理被跨多個羣集和環境共享[2]。
我們需要確保特定於環境的值很容易映射到給定的環境中，但模板仍然是可移植的[3]。
我們需要讓多用戶/多租戶用戶體驗更加直觀和自然[4]。

1和2的元素將出現在即將發佈的1.0版本中，第3項完全包含在即將發佈的版本中。在多開發者案例的同時，我認爲他們有必要將自己的本地實例作爲「單元測試」流程的地方，然後使用共享的分段或生產環境。要記住的關鍵是，對於許多流程和NiFi的方法，可以讓一個給定流程模板的多個實例執行每個實例的數據實時饋送。該流程的結果/輸出可以通過接線實際上交付到某個地方或者簡單地接地。通過這種方式，它非常類似於Git等源代碼控制中的分支心智模型。如果您願意，您可以選擇哪一個您認爲是「生產」，而圖上的流程只是一個正在進行的功能分支。對於來自更傳統方法的人來說，這並不明顯，我們需要做更多的工作來描述和演示這一點。但是，我們也應該支持更傳統的方法，這就是我所鏈接的一些功能建議將會啓用的功能。

[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

來源

2016-06-21 02:00:17

它看起來像[1]，[2]和[3]是尚未實施。你能否提供一個關於如何解決當前版本中的陳述問題的更新？我認爲現在人們只是導入和導出模板。這有一些缺點，例如沒有真正的更新選項，您可以刪除舊版本並讀取新版本。 –

你是對的沒有真正的更新選項（對於現有的過程組）。今天的常見模式是推送新版本的進程組，然後更改提供該組的連接。這可以通過幾個REST調用以編程方式完成。用於流程管理，進程組變量和版本控制組件的apache nifi註冊表都與最新版本中的後兩者保持同步。下一版本看起來很可能已經爲版本化流程集成了apache nifi註冊表，並且在那一刻您將獲得真正的更新！應該很酷。 –

Apache NiFi的開發生命週期

回答

相關問題