有人知道如何处理JNLP连接的Linux到Linux Jenkins代理问题吗?
我每20天左右就会看到这些攻击,我用的是centos7代理主机2.223 jenkins和remoting 4.2。
我们的作业通过docker插件在临时的docker contains中运行它们的许多步骤,我们目前使用devicemapper作为我们的docker存储驱动程序。当这种情况发生时,似乎docker确实处于一定的负载下,但我还没有详细的统计数据来支持这一理论
docker.image.inside {
...
}
字符串
当发生这种情况时,控制器会报告代理主机脱机,并且两者仍然在同一个AWS VPC中,具有相同的安全组,因此它们之间的连接应该仍然是可能的(我上次没有检查它,因为我们有其他火灾要处理)。
我听说这可能与插件和复杂的管道代码有关。我在主机消息中没有看到太多,当我尝试将其与Jenkins控制器的日志匹配时,还没有看到一个模式。
我也想知道切换到ssh代理插件是否会使问题变得不那么严重,我可能会尝试在主机上启用更多的日志记录,希望能捕捉到更多的细节。
请让我知道你是如何处理这一点,如果你已经看到它或任何建议。
01:51:49 agent.host java: INFO: Failed to synchronize IO streams on the channel hudson.remoting.Channel@...:JNLP4-connect connection to jenkins.edgewise.devops/#.#.#.#:50000
01:51:49 agent.host java: java.lang.InterruptedException
01:51:49 agent.host java: at java.lang.Object.wait(Native Method)
01:51:49 agent.host java: at hudson.remoting.Request.call(Request.java:177)
01:51:49 agent.host java: at hudson.remoting.Channel.call(Channel.java:997)
01:51:49 agent.host java: at hudson.remoting.Channel.syncIO(Channel.java:1730)
01:51:49 agent.host java: at hudson.Launcher$RemoteLaunchCallable$1.join(Launcher.java:1328)
01:51:49 agent.host java: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
01:51:49 agent.host java: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
01:51:49 agent.host java: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
01:51:49 agent.host java: at java.lang.reflect.Method.invoke(Method.java:498)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:931)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:905)
01:51:49 agent.host java: at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:857)
01:51:49 agent.host java: at hudson.remoting.UserRequest.perform(UserRequest.java:211)
01:51:49 agent.host java: at hudson.remoting.UserRequest.perform(UserRequest.java:54)
01:51:49 agent.host java: at hudson.remoting.Request$2.run(Request.java:369)
01:51:49 agent.host java: at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
01:51:49 agent.host java: at java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:51:49 agent.host java: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
01:51:49 agent.host java: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
01:51:49 agent.host java: at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:117)
01:51:49 agent.host java: at java.lang.Thread.run(Thread.java:748)
02:01:01 agent.host systemd: Created slice User Slice of root.
02:01:01 agent.host systemd: Started Session 784 of user root.
02:15:05 agent.host dhclient[1092]: DHCPREQUEST on eth0 to #.#.#.#ort 67 (xid=0x6...)
02:15:05 agent.host dhclient[1092]: DHCPACK from #.#.#.#xid=0x6...)
02:15:07 agent.host dhclient[1092]: bound to #.#.#.# -- renewal in 1587 seconds.
02:32:00 agent.host java: Oct 23, 2020 2:32:00 AM hudson.remoting.Request$2 run
02:32:00 agent.host java: INFO: Failed to send back a reply to the request hudson.remoting.Request$2@...: hudson.remoting.ChannelClosedException: Channel "unknown": Protocol stack cannot write data anymore. It is not open for write
型
1条答案
按热度按时间tzcvj98z1#
鉴于:
devicemapper是受支持的,但在生产环境中需要direct-lvm,因为loopback-lvm在零配置时性能非常差。devicemapper是CentOS和RHEL的推荐存储驱动程序,因为它们的内核版本不支持overlay 2。但是,CentOS和RHEL的当前版本现在支持overlay 2,这是现在推荐的驱动程序。
在代理主机上执行switching storage driver to overlay2似乎是降低此问题风险的正确操作