约1分钟后,Docker容器被杀死 [英] Docker container is killed after ~1 minute

查看:1826
本文介绍了约1分钟后,Docker容器被杀死的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我做了一个非常小的凤凰框架应用程序(只有稍微修改,当你运行:mix phoenix.new)。我一直在尝试在Docker容器中部署它。容器正在运行时它工作正常,但它始终在启动后一分钟内死亡,并显示Killed消息。无论我是否要求要求似乎都不重要。我尝试观看码头事件,并得到以下内容:

  $ docker events 
2016-04-09T16:24 :02.538602484-04:00 container create
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f
(image = gcr.io / myprojectname / myapp:v2,name = amazing_bhabha)

2016-04-09T16:24: 02.550438045-04:00容器附件
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f
(image = gcr.io / myprojectname / myapp:v2,name = amazing_bhabha)

2016-04-09T16:24:02.599731705 -04:00网络连接
c64a1439c8095f82ab0fea5c48b563c8aac7256d6064b3189b0bc8d052d69fe4
(name = bridge,type = bridge,container = ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f)

2016-04-09T16:24:02.600048755-04:00容器开始
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f
(image = gcr.io / myprojectname / myapp:v2,name = amazing_bhabha)

2016-04-09T16:24:53.858352733-04:00容器死
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f
(name = amazing_bhabha,image = gcr.io / myprojectname / myapp:v2)

2016-04-09T16:24:53.930349810-04:00网络断开
c64a1439c8095f82ab0fea5c48b563c8aac7256d6064b3189b0bc8d052d69fe4
(container = ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f,name = bridge,type = bridge)

对Docker和Elixir来说还是很新的,所以我不知道我能做什么其他的研究。这里有一个类似的问题:我运行一个码头集装箱,但是几分钟后,它被自己杀死了



但我不知道如何或如果OP曾解决过提前感谢任何提示。如果还有其他可以帮助的其他信息,请让我知道。



编辑1:我了解到docker ps -a实际上会告诉我退出代码,我还没找到别的地方我的所有容器都有137个错误代码。我的docker VM有4GB的内存,所以我尝试运行一个-m = 3g标志,但得到相同的结果。我也没有看到Windows进程资源管理器方法3GB中的任何进程。



编辑2:我的容器内存限制多了一点,发现容器生命的时间与我允许多少内存直接相关。所以我创建了一个全新的项目(mix --no-brunch --no-ecto phoenix.new),复制了我的Dockerfile,并尝试构建并运行它。它给了我完全相同的结果。这导致我相信我的问题出在我的Docker文件或我的运行应用程序。



Dockerfile:

  FROM marcelocg / phoenix 
维护者Arcaten
RUN echo $ PWD
#Copy source
添加。 ./
#Get依赖项
RUN yes | mix local.hex
RUN yes | mix deps.get
#compile
RUN yes | mix compile
RUN ls -l
EXPOSE 4000
#Run server
ENTRYPOINT yes | MIX_ENV = dev mix phoenix.server

Build:



docker build -t hello_phoenix

  

运行:

 code> docker run -p 4000:4000 -m = 512m hello_phoenix 

它运行大约7秒钟,并退出一个137错误代码。



编辑3:由于我收到OOMKill:在我的容器中,我尝试移动其他方向我从我的运行命令中删除了内存封。我仍然得到相同的结果,但现在OOMKill被设置为false,我的检查的所有内存数现在读为0.此外,StopSignal现在设置为15

解决方案

问题是 yes | part。
当涉及到stdin和输入时,Erlang VM的行为与常规程序的行为不同。它将缓冲您投掷的任何输入,并且使用 yes | 给您一个无限的yeses流。因为没有更多的内存,所以这些是缓冲的和内存增长,直到进程被系统杀死。



使用<$ c $任何使用Elixir / Erlang的任何东西都可以使用Elixir / Erlang,而且运行时间很短,您可以在运行内存之前完成这些任务,但仍然不是很棒想法。


I made a very small Phoenix Framework app (only slightly modified from what you get when you run: mix phoenix.new). I've been trying to deploy it in a Docker container. It works fine while the container is running, but it always dies within a minute of startup with a message of "Killed." Whether I make requests to it or not does not seem to matter. I tried watching the docker events, and got the following:

$ docker events
2016-04-09T16:24:02.538602484-04:00 container create 
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f
(image=gcr.io/myprojectname/myapp:v2, name=amazing_bhabha)

2016-04-09T16:24:02.550438045-04:00 container attach
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f   
(image=gcr.io/myprojectname/myapp:v2, name=amazing_bhabha)

2016-04-09T16:24:02.599731705-04:00 network connect 
c64a1439c8095f82ab0fea5c48b563c8aac7256d6064b3189b0bc8d052d69fe4
(name=bridge, type=bridge, container=ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f)

2016-04-09T16:24:02.600048755-04:00 container start
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f 
(image=gcr.io/myprojectname/myapp:v2, name=amazing_bhabha)

2016-04-09T16:24:53.858352733-04:00 container die 
ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f 
(name=amazing_bhabha, image=gcr.io/myprojectname/myapp:v2)

2016-04-09T16:24:53.930349810-04:00 network disconnect
c64a1439c8095f82ab0fea5c48b563c8aac7256d6064b3189b0bc8d052d69fe4 
(container=ef45a768723c64125c717a7b40ee7513e477f27339c6266bd28cc3084c60e11f, name=bridge, type=bridge)

I'm still very new to Docker and Elixir, so I'm not sure what other research I can do into this. There is a similar sounding question here: I run a docker container,but after few minutes , it was killed by himself

But I'm not sure how or if the OP ever resolved it. Thanks in advance for any hints. Please let me know if there's any other information I can get that might help.

Edit 1: I learned that docker ps -a will actually tell me the exit code, which I haven't found elsewhere. All of my containers are exiting with a 137 error code. My docker VM has 4GB of memory, so I tried running with a -m=3g flag but got the same result. I also did not see any processes in the Windows process explorer approach 3GB.

Edit 2: I played around a bit more with the memory limit on my container and found that the time the container lives is directly correlated to how much memory I allow it. So I created a totally new project (mix --no-brunch --no-ecto phoenix.new),copied my Dockerfile, and tried to build and run it. It gave me exactly the same results. This leads me to believe that my problem is in my Dockerfile or how I'm running the app.

Dockerfile:

FROM marcelocg/phoenix
MAINTAINER Arcaten
RUN echo $PWD
#Copy source
ADD . ./
#Get dependencies
RUN yes | mix local.hex
RUN yes | mix deps.get
#compile
RUN yes | mix compile
RUN ls -l
EXPOSE 4000
#Run server
ENTRYPOINT yes | MIX_ENV=dev mix phoenix.server

Build:

docker build -t hello_phoenix .

Run:

docker run -p 4000:4000 -m=512m hello_phoenix

And with that, it runs for about 7 seconds and exits with a 137 error code.

Edit 3: Since I was getting "OOMKill":true in my containers, I tried moving in the other direction. I removed the memory cap from my run commands. I still get the same result, but now "OOMKill" is set to false and all of the memory numbers from my inspects now read 0. Also, the StopSignal is now set to "15"

解决方案

The problem is the yes | part. The Erlang VM behaves differently from regular programs when it comes to the stdin and input. It will buffer whatever input you throw at it, and with yes | you give it an infinite stream of yeses. Those yeses are buffered and memory grows until the process is killed by the system, because there's no more memory left.

It is generally a bad idea to use yes | with anything using Elixir/Erlang, even more so with long running tasks - with short running ones you have a chance at completing them before you run out of memory, but it's still not a great idea.

这篇关于约1分钟后,Docker容器被杀死的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆