Tag: apache nifi
docker上的Nifi集群没有启动，只能在一个Node上工作
我试图在两个代理在Docker集群上安装Apache Nifi，单节点集群正在工作，同时在第二个节点上启动我得到下面的错误 我的堆栈跟踪 2017-09-13 06:00:52,640 INFO [main] oanadmin.AuditDataSourceFactoryBean Database not built for repository: jdbc:h2:./database_repository/nifi-flow-audit;AUTOCOMMIT=OFF;DB_CLOSE_ON_EXIT=FALSE;LOCK_MODE=3;LOCK_TIMEOUT=25000;WRITE_DELAY=0;AUTO_SERVER=FALSE. Building now… 2017-09-13 06:00:52,794 WARN [main] org.eclipse.jetty.webapp.WebAppContext Failed startup of context oejwWebAppContext@28dd038f{/nifi-api,file:///opt/nifi/work/jetty/nifi-web-api-1.3.0.war/webapp/,UNAVAILABLE}{./work/nar/framework/nifi-framework-nar-1.3.0.nar-unpacked/META-INF/bundled-dependencies/nifi-web-api-1.3.0.war} org.apache.nifi.web.NiFiCoreException: Unable to start Flow Controller. at org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:88) at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:876) at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:839) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1480) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1442) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:799) at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:540) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at […]
在使用Docker时如何将集群NiFi中的授权和用户文件外化？
我正在运行一个安全的NiFi集群，每个NiFi节点在一个Docker容器中运行。 我需要外部化用户和策略的状态，所以基本上这两个文件： authorizations.xml users.xml中 做这个的最好方式是什么？ 一个天真的方法，在非集群环境下工作得很好，就是在Docker容器中安装一个外部卷，并把authorizations.xml，users.xml文件放在那里。 使用这种方法，我可以移除NiFi Docker容器，稍后再运行它，而不用担心丢失任何更改。 最初我的第一个想法是在集群环境中做同样的事情，并将所有节点指向相同的物理文件。 但是据我所知，如果我这样做了，那么进行初始更改的NiFi节点会更新这些文件，随后群集中的所有其他节点最终都会尝试更新所有这些文件。 但是，它们已经被初始节点更新了，所以如果它们没有遇到已经存在的变化的问题，它们可能会遇到一个获得写文件句柄的问题。 另一种方法是定期将文件从NiFidocker集装箱写入外部位置。 这有点麻烦，但它引发了如何将文件放入NiFi Docker的问题。 我可以在启动时从外部卷复制它们。 但是当我在某个时候添加一个额外的节点时，它也会复制这些文件，并冒着与现有节点中的文件不同步的风险。 如果新节点能够以某种方式确定其他节点正在运行并且具有configuration（在这种情况下根本不会带入文件），并且一旦节点join集群后它们将由NiFidynamic地创build根据NiFi文件）。 但这可能不是那么容易做到的。 但是，也许只是确定是否有其他节点正在运行？ 我们可以让集群中的每个节点将这些文件外化。 也许这可能会导致一些竞争条件，但似乎不太可能。 更大的问题是，大多数情况下，我们会有很多版本的文件完全相同，这可能会激怒我们的客户，他们宁愿最多只有一个文件副本处理。
