怎么在docker 中启动一个daemon
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了怎么在docker 中启动一个daemon相关的知识,希望对你有一定的参考价值。
参考技术A dockerrun指定的命令如果不是那些一直挂起的命令(比如运行top,不断echo),就是会自动退出的。-d命令是设置detach为true,根据官方的文档,意思是让这个命令在后台运行,但并不是一直运行(我们在一个正常的linux
terminal中运行/bin/bash,运行完了也就完了,不会一直挂着等待响应的,所以确实没办法用daemon方式来跑/bin/bash)。
这个地方官方早期和现在的文档也确实有些前后不一致,现在是detach,早期的文档说指定-d以daemon方式来运行容器,可能存在一定的误解。
另外,如果你需要跑容器里的bash,直接运行docker
run
-i
-t
container_name
/bin/bash
就可以了,如果觉得参数比docker
attach多,可以设置一个别名(alias)来解决:
alias
dockerbash='docker
run
-i
-t
container_id
/bin/bash'
设置好别名后,直接运行dockerbash就可以进入容器的bash了
docker daemon中的userland-proxy选项
参考技术A docker启动时可以在配置文件中指定启动项,如下:新建/etc/default/docker文件,指定docker守护进程的启动配置:
从docker daemon的角度,添加了userland-proxy的起停开关
首先介绍userland-proxy一直以来的作用。众所周知,在Docker的桥接bridge网络模式下,Docker容器是通过宿主机上的NAT模式,建立与宿主机之外世界的通信。然而在宿主机上,一般情况下,进程可以通过三种方式访问容器,分别为:<eth0IP>:<hostPort>, <containerIP>:<containerPort>,以及<0.0.0.0>:<hostPort>。实际上,最后一种方式的成功访问完全得益于userland-proxy,即Docker Daemon在启动一个Docker容器时,每次为容器在宿主机上映射一个端口,都会启动一个docker-proxy进程,实现宿主机上0.0.0.0地址上对容器的访问代理。
当时引入userland-proxy时,也许是因为设计者意识到了0.0.0.0地址对容器访问上的功能缺陷。然而,在docker-proxy加入Docker之后相当长的一段时间内。Docker爱好者普遍感受到,很多场景下,docker-proxy并非必需,甚至会带来一些其他的弊端。
影响较大的场景主要有两种。
第一,单个容器需要和宿主机有多个端口的映射。此场景下,若容器需要映射1000个端口甚至更多,那么宿主机上就会创建1000个甚至更多的docker-proxy进程。据不完全测试,每一个docker-proxy占用的内存是4-10MB不等。如此一来,直接消耗至少4-10GB内存,以及至少1000个进程,无论是从系统内存,还是从系统CPU资源来分析,这都会是很大的负担。
第二,众多容器同时存在于宿主机的情况,单个容器映射端口极少。这种场景下,关于宿主机资源的消耗并没有如第一种场景下那样暴力,而且一种较为慢性的方式侵噬资源。
如今,Docker Daemon引入- -userland-proxy这个flag,将以上场景的控制权完全交给了用户,由用户决定是否开启,也为用户的场景的proxy代理提供了灵活性
原文地址: http://www.dataguru.cn/thread-544489-1-1.html
以上是关于怎么在docker 中启动一个daemon的主要内容,如果未能解决你的问题,请参考以下文章
在/etc/docker/下 创建daemon.json重新加载后docker无法启动问题 /etc/docker/daemon.json编辑不了 找不到
docker daemon中的userland-proxy选项