Жизненный цикл разработки для Apache NiFi

Question

Я понимаю, что с NiFi, как их определяет его документ, «Постоянное улучшение происходит в производстве». Таким образом, это не может использоваться как традиционный инструмент разработки. Однако для проекта, над которым я работаю, было решено, что это инструмент, который мы будем использовать, поэтому я бы предпочел не обсуждать достоинства этого, поскольку понимаю, что будут какие-то проблемы.

Например, если я ввожу изменения в существующую среду (от постановки на производство), и в месте назначения были живые изменения, они будут перезаписаны. Поэтому у меня есть вопросы о том, как организовать жизненный цикл разработки.

• Можно ли объединить изменения, которые были сделаны несколько разработчиками параллельно (слияние экспортируемых файлов шаблоны XML)? Я предполагаю, что слияние каких-либо значительных изменений может быть затруднено, но не пыталось это сделать.
• Как до управлять версированием изменений? Я предполагаю, что вы можете экспортировать всю свою конфигурацию в качестве шаблона и проверить это на контроль версий?
• Как сделать развернуть поток на другой сервер? Можете ли вы просто развернуть развертывание NiFi на складе, а затем обновить его из экспортированного шаблона (как упоминалось выше), используя API-интерфейс NiFi REST?
• Как управлять развертыванием в различной среде, которая может иметь различной конфигурации? Вам нужно обновить XML-файл шаблона? Или я могу динамически его вытащить из чего-то вроде Zookeeper?

Answer 1

Как автор оригинала, который вы цитировали, а член PMA Apache NiFi PMC, позвольте мне начать с того, что вы задаете большие вопросы, и я могу оценить, откуда вы пришли. Вероятно, нам следует улучшить вводный документ, чтобы лучше отражать проблемы, которые вы поднимаете.

У вас все в порядке, что текущий подход заключается в создании шаблонов потоков, а затем вы можете отправить это управление версией. Кроме того, люди автоматизируют развертывание этих шаблонов, используя скрипты, взаимодействующие с API REST от NiFi. Но мы можем и должны делать гораздо больше, чем нам нужно сделать работу по управлению потоком данных проще, независимо от того, являетесь ли вы разработчиком, который пишет именно то, что будет развернуто, или вы - человек, ориентированный на операции, который должен собрать эти штуки самостоятельно.

1. Управление и управление версиями потоков [1] должно быть проще и централизованно управляться совместно с несколькими кластерами и средами [2].
2. Мы должны убедиться, что значения, специфичные для окружающей среды, легко отображаются в заданную среду, но шаблоны все еще переносимы [3].
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