Docker常见问题总结（持续更新）
时间： 15:30:44
&&&& 阅读：86
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&一、镜像相关问题1、如何批量清理临时镜像文件？&&&&#docker rmi $(DOCKER IMAGES& -qf dangling=true)2、如何查看镜像支持的环境变量？&&&&#docker run IMAGE env3、本地的镜像文件都存放在哪里？&&&&与Docker相关的本地资源都存放在/var/lib/docker/目录直，以aufs文件系统为例，其中container目录存放容器信息，graph目录存放镜像信息，aufs目录下存放具体的镜像层文件。4、构建Docker像应该遵循哪些原则？&&&&整体原则上，尽量保持镜像功能的明确和内容的精简，要点包括：尽量选取满足需求但较小的基础系统镜像，例如大部分时候可以选反地debian:wheezy或debian:jessie镜像，仅有不足百兆大小；清理编译生成文件、安装包的缓存等临时文件；安装各个软件时候指定准确的版本号，并避免引入不需要的依赖；从安全角度考虑，应用要尽量使用系统的库和依赖；如果安装应用时候需要配置一些特殊的环境变量，在安装后要还原不需要保持的变量值；使用Dockerfile创建镜像时候要添加.dockerignore文件或使用干净的工作目录。5、碰到网络问题，无法pull镜像，命令行指定http_proxy无效，怎么办？&&&&在Docker配置文件中添加export http_proxy=&http://&PROXY_HOST&:&PROXY_PORT&&，之后重启Docker服务即可。二、容器相关问题1、容器退出后，通过docker ps命令查看不到，数据会丢失么？&&&&容器退出后会处于终止（exited）状态，此时可以能过docker ps -a 命令查看。其中的数据也不会丢失，还可以通过docker start命令来启动它。只有删除掉容器才会清除所有数据。2、如何停止所有正地运行的容器？&&&&docker kill $(docker ps -q)3、如何清理批量后台停止的容器？&&&&docker rm -f $(docker ps -qa)4、如何获取某个容器的PID信息？&&&&docker& inspect& --format '{{ .State.Pid }}' &CONTANINERID or NAME&5、如何获取某个容器的IP地址?&&&&dpcler& &inspect& --format& '{{ &NetworkSettings.IPAddress }}'&&&CONTANINERID or NAME&6、如何给容器指定一个固定IP地址，而不是每次重启容器IP地址都会变？&&&&目前Docker并没有提供直接的对容器IP地址的管理支持，可以在网上查找容器网络配置创建点对点连接的案例，来手动配置容器的静态IP。或者在容器启动后，再手动进行修改。7、如何临时退出一个正在交互的容器的终端，而不终止它？&&&&按Ctrl-p Ctrl-q。如果按Ctil-c往往会让容器内应用进程终止，进而会终止容器。8、使用docker port 命令映射容器的时，系统报错“Error: No Public port& '80' published for xxx” ,怎么办？&&&&创建镜像时Dockerifle要通过EXPOSE命令指定正确的开放端口；容器启动时指定PublishAllPort=true。9、可以在一个容器中同进运行多个应用进程么？&&&&一般并不推荐在同一个容器内运行多个应用进程。如果有需求，可以通过一些额外的进程管理机制，比如supervisord来管理所运行的进程。可以参考10、如何控制容器占用系统资源（CPU MEM）的份额？&&&&在使用docker create命令创建容器或使用docker run创建并启动容器的时候，可以使用-c | --cpu-shares[=0] 参数来调整容器使用CPU的权重；使用 -m | --memory[=MEMORY]参数来调整容器使用内存的大小。参考资料：《Docker技术入门与实战 第2版》标签：&&&&&&&&&&&&原文地址：http://blog.51cto.com/ganbing/2052074
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！docker容器如何优雅的终止详解
转载 & & 投稿：daisy
最近公司在试验如何将项目部署到docker容器中去，这其中涉及到一个技术环节，那就是如何让docker容器优雅的终止。所谓优雅终止，指的就是程序在退出前有清理资源，保存必要中间状态，持久化内存数据的机会。下面通过这篇大家一起由简单到复杂逐一考量一下。
在Docker大行其道的今天，我们能够非常方便的使用容器打包我们的应用程序，并且将它在我们的服务器上部署并运行起来。但是，谈论到如何停掉运行中的docker容器并正确的终止其中的程序，这就成为一个非常值得讨论的话题了。
事实上，在我们日常的项目当中，这是我们经常需要面对和处理的问题：
&&&& 场景A：假如我们打包在容器中的程序，提供HTTP方式的服务，负责处理各种HTTP requests并返回结果，我们必然希望在容器被停掉的时候，能够让程序有时间把已经在处理中的请求继续处理完毕，并返回结果给客户端。
&&&& 场景B：又比如我们打包在容器中的程序，负责写入数据到某个数据文件中，我们希望程序能够在容器被停掉的时候，有时间把内存中缓存的数据持久化到存储设备中，以防数据丢失。
&&&& 场景C：再比如现在流行的微服务架构中，一般会有服务发现的机制，也即每一个微服务在启动之后，都会主动把自己的地址信息注册到服务发现模块当中，让其他的服务可以知道自己的存在。而在容器被停掉的时候，微服务需要即时从服务发现模块中注销自己，以防止从API Gateway而来的请求被错误的路由到了已经被停止掉的微服务。
如上的各种场景中，都要求打包在容器中的应用程序能够被优雅的终止(也即gracefully shutdown)，这种gracefully shutdown的方式，允许程序在容器被停止的时候，有一定时间做一些后续处理操作，这也是我们需要进一步探讨的话题。
docker stop 与 docker kill 的区别
Docker本身提供了两种终止容器运行的方式，即docker stop与docker kill。
docker stop
先来说说docker stop吧，当我们用docker stop命令来停掉容器的时候，docker默认会允许容器中的应用程序有10秒的时间用以终止运行。所以我们查看docker stop命令帮助的时候，会有如下的提示:
→ docker stop --help
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop one or more running containers
Print usage
-t, --time int Seconds to wait for stop before killing it (default 10)
在docker stop命令执行的时候，会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。在容器中的应用程序，可以选择忽略和不处理SIGTERM信号，不过一旦达到超时时间，程序就会被系统强行kill掉，因为SIGKILL信号是直接发往系统内核的，应用程序没有机会去处理它。在使用docker stop命令的时候，我们唯一能控制的是超时时间，比如设置为20秒超时:
docker stop --time=20 container_name
docker kill
接着我们来看看docker kill命令，默认情况下，docker kill命令不会给容器中的应用程序有任何gracefully shutdown的机会。它会直接发出SIGKILL的系统信号，以强行终止容器中程序的运行。通过查看docker kill命令的帮助，我们可以看到，除了默认发送SIGKILL信号外，还允许我们发送一些自定义的系统信号：
→ docker kill --help
Usage: docker kill [OPTIONS] CONTAINER [CONTAINER...]
Kill one or more running containers
Print usage
-s, --signal string Signal to send to the container (default "KILL")
比如，如果我们想向docker中的程序发送SIGINT信号，我们可以这样来实现：
docker kill --signal=SIGINT container_name
与docker stop命令不一样的地方在于，docker kill没有任何的超时时间设置，它会直接发送SIGKILL信号，以及用户通过signal参数指定的其他信号。
其实不难看出，docker stop命令，更类似于Linux系统中的kill命令，二者都是发送系统信号SIGTERM。而docker kill命令，更像是Linux系统中的kill -9或者是kill -SIGKILL命令，用来发送SIGKILL信号，强行终止进程。
在程序中接收并处理信号
了解了docker stop与docker kill的区别，我们能够知道，docker kill适合用来强行终止程序并实现快速停止容器。而如果希望程序能够gracefully shutdown的话，docker stop才是不二之选。这样，我们可以让程序在接收到SIGTERM信号后，有一定的时间处理、保存程序执行现场，优雅的退出程序。
接下来我们可以写一个简单的Go程序来实现信号的接收与处理，程序在启动过后，会一直阻塞并监听系统信号，直到监测到对应的系统信号后，输出控制台并退出执行。
// main.go
package main
"os/signal"
func main() {
fmt.Println("Program started...")
ch := make(chan os.Signal, 1)
signal.Notify(ch, syscall.SIGTERM)
if s == syscall.SIGTERM {
fmt.Println("SIGTERM received!")
//Do something...
fmt.Println("Exiting...")
接下来使用交叉编译的方式来编译程序，让程序可以在Linux下运行:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o graceful
编译好之后，我们还需要打包程序到容器中运行。于是，我们还得有个Dockerfile。在这里，我们选择使用体积小又轻盈的alpine镜像作为基础镜像，打包这个Go程序:
from alpine:latest
MAINTAINER Timothy
ADD graceful /graceful
CMD ["/graceful"]
这里需要避开的一个坑，是Dockerfile中CMD命令的用法。
CMD命令有两种方式：
CMD /graceful
使用 CMD command param1 param2 这种方式，其实是以shell的方式运行程序。最终程序被执行时，类似于/bin/sh -c的方式运行了我们的程序，这样会导致/bin/sh以PID为1的进程运行，而我们的程序只不过是它fork/execs出来的子进程而已。前面我们提到过docker stop的SIGTERM信号只是发送给容器中PID为1的进程，而这样，我们的程序就没法接收和处理到信号了。
CMD [“/graceful”]
使用 CMD [“executable”,”param1”,”param2”] 这种方式启动程序，才是我们想要的，这种方式执行和启动时，我们的程序会被直接启动执行，而不是以shell的方式，这样我们的程序就能以PID=1的方式开始执行了。
话题转回来，我们开始执行容器构建操作，打包程序：
docker build -t registry.xiaozhou.net/graceful:latest .
打包过后的镜像，才6MB左右:
λ Timothy [workspace/src/graceful] → docker images
REPOSITORY
registry.xiaozhou.net/graceful
20 hours ago
启动并运行容器:
λ Timothy [workspace/src/graceful] → docker run -d --name graceful b2210a85
查看容器运行状态:
λ Timothy [workspace/src/graceful] → docker ps -a
CONTAINER ID
fd18eedafd16
"/graceful"
3 seconds ago
Up 2 seconds
查看容器输出，能看到程序已经正常启动：
λ Timothy [workspace/src/graceful] → docker logs graceful
Started...
接着我们要使用docker stop大法，看程序能否响应SIGTERM信号:
λ Timothy [workspace/src/graceful] → docker stop graceful
最后，查看容器的日志，检验输出：
λ Timothy [workspace/src/graceful] → docker logs graceful
Started...
SIGTERM received!
Exiting...
以上就是这篇文章的全部内容了，用docker kill命令，可以简单粗暴的终止docker容器中运行的程序，但是想要优雅的终止掉的话，我们需要使用docker stop命令，并且在程序中多花一些功夫来处理系统信号，这样能保证程序不被粗暴的终止掉，从而实现gracefully shutdown。希望本文的内容对大家的学习或者工作能有所帮助，如果有疑问大家可以留言交流。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具&nbsp>&nbsp
&nbsp>&nbsp
linux教程 &nbsp>&nbsp
Docker 的现状与未来
摘要：Docker-迄今为止发生的那些事情Docker是一个专为Linux容器而设计的工具集,用于‘构建、交付和运行’分布式应用。它最初是DotCloud的一个开源项目,于2013年3月发布。这个项目越来越受欢迎,以至于DotCloud公司都更名为Docker公司(并最终出售了原有的PaaS业务)。Docker1.0是在2014年6月发布的,而且延续了之前每月更新一个版本的传统。Docker1.0版本的发布标志着Docker公司认为该平台已经充分成熟,足以用于生产环境中(由该公司与
Docker - 迄今为止发生的那些事情Docker 是一个专为 Linux 容器而设计的工具集,用于‘构建、交付和运行’分布式应用。它最初是 DotCloud 的一个开源项目,于2013年3月发布。这个项目越来越受欢迎,以至于 DotCloud 公司都更名为 Docker 公司(并最终出售了原有的 PaaS 业务)。Docker 1.0是在2014年6月发布的,而且延续了之前每月更新一个版本的传统。
Docker 1.0版本的发布标志着 Docker 公司认为该平台已经充分成熟,足以用于生产环境中(由该公司与合作伙伴提供付费支持选择)。每个月发布的更新表明该项目正在迅速发展,比如增添一些新特性、解决一些他们发现的问题。该项目已经成功地分离了‘运行’和‘交付’两件事,所以来自任何版本的 Docker 镜像源都可以与其它版本共同使用(具备向前和向后兼容的特性),这为 Docker 应对快速变化提供了稳定的保障。
Docker 之所以能够成为最受欢迎的开源项目之一可能会被很多人看做是炒作,但是也是由其坚实的基础所决定的。Docker 的影响力已经得到整个行业许多大企业的支持,包括亚马逊, Canonical 公司, CenturyLink, 谷歌, IBM, 微软, New Relic, Pivotal, 红帽和 VMware。这使得只要有 Linux 的地方,Docker 就可以无处不在。除了这些鼎鼎有名的大公司以外,许多初创公司也在围绕着 Docker 发展,或者改变他们的发展方向来与 Docker 更好地结合起来。这些合作伙伴们(无论大或小)都将帮助推动 Docker 核心项目及其周边生态环境的快速发展。
Docker 技术简要综述Docker 利用 Linux 的一些内核机制例如 cGroups、命名空间和 SElinux 来实现容器之间的隔离。起初 Docker 只是 LXC 容器管理器子系统的前端,但是在 0.9 版本中引入了 libcontainer,这是一个原生的 go 语言库,提供了用户空间和内核之间的接口。
容器是基于 AUFS 这样的联合文件系统的,它允许跨多个容器共享组件,如操作系统镜像和已安装的相关库。这种文件系统的分层方法也被 Dockerfile 的 DevOps 工具所利用,这些工具能够缓存成功完成的操作。这就省下了安装操作系统和相关应用程序依赖包的时间,极大地加速测试周期。另外,在容器之间的共享库也能够减少内存的占用。
一个容器是从一个镜像开始运行的,它可以来自本地创建,本地缓存,或者从一个注册库(registry)下载。Docker 公司运营的 Docker Hub 公有注册库,为各种操作系统、中间件和数据库提供了官方仓库存储。各个组织和个人都可以在 docker Hub 上发布的镜像的公有库,也可以注册成私有仓库。由于上传的镜像可以包含几乎任何内容,所以 Docker 提供了一种自动构建工具(以往称为“可信构建”),镜像可以从一种称之为 Dockerfile 的镜像内容清单构建而成。
容器 vs. 虚拟机容器会比虚拟机更高效,因为它们能够分享一个内核和分享应用程序库。相比虚拟机系统,这也将使得 Docker 使用的内存更小,即便虚拟机利用了内存超量使用的技术。部署容器时共享底层的镜像层也可以减少存储占用。IBM 的 Boden Russel 已经做了一些基准测试来说明两者之间的不同。
相比虚拟机系统,容器具有较低系统开销的优势,所以在容器中,应用程序的运行效率将会等效于在同样的应用程序在虚拟机中运行,甚至效果更佳。IBM 的一个研究团队已经发表了一本名为[虚拟机与 Linux 容器的性能比较]的文章11。
容器只是在隔离特性上要比虚拟机逊色。虚拟机可以利用如 Intel 的 VT-d 和 VT-x 技术的 ring-1 硬件隔离技术。这种隔离可以防止虚拟机突破和彼此交互。而容器至今还没有任何形式的硬件隔离,这使它容易受到攻击。一个称为 Shocker 的概念攻击验证表明,在 Docker 1.0 之前的版本是存在这种脆弱性的。尽管 Docker 1.0 修复了许多由 Shocker 漏洞带来的较为严重的问题,Docker 的 CTO Solomon Hykes 仍然说,“当我们可以放心宣称 Docker 的开箱即用是安全的,即便是不可信的 uid0 程序(超级用户权限程序),我们将会很明确地告诉大家。”Hykes 的声明承认,其漏洞及相关的风险依旧存在,所以在容器成为受信任的工具之前将有更多的工作要做。
对于许多用户案例而言,在容器和虚拟机之间二者选择其一是种错误的二分法。Docker 同样可以在虚拟机中工作的很好,这让它可以用在现有的虚拟基础措施、私有云或者公有云中。同样也可以在容器里跑虚拟机,这也类似于谷歌在其云平台的使用方式。像 IaaS 服务这样普遍可用的基础设施,能够即时提供所需的虚拟机,可以预期容器与虚拟机一起使用的情景将会在数年后出现。容器管理和虚拟机技术也有可能被集成到一起提供一个两全其美的方案;这样,一个硬件信任锚微虚拟化所支撑的 libcontainer 容器,可与前端 Docker 工具链和生态系统整合,而使用提供更好隔离性的不同后端。微虚拟化(例如 Bromium 的 vSentry 和 VMware 的 Project Fargo)已经用于在桌面环境中以提供基于硬件的应用程序隔离,所以类似的方法也可以用于 libcontainer,作为 Linux内核中的容器机制的替代技术。
‘容器化’ 的应用程序几乎所有 Linux 应用程序都可以在 Docker 容器中运行,并没有编程语言或框架的限制。唯一的实际限制是以操作系统的角度来允许容器做什么。即使如此,也可以在特权模式下运行容器,从而大大减少了限制(与之对应的是容器中的应用程序的风险增加,可能导致损坏主机操作系统)。
容器都是从镜像开始运行的,而镜像也可以从运行中的容器获取。本质上说,有两种方法可以将应用程序放到容器中,分别是手动构建和 Dockerfile。
手动构建手动构建从启动一个基础的操作系统镜像开始,然后在交互式终端中用你所选的 Linux 提供的包管理器安装应用程序及其依赖项。Zef Hemel 在‘使用 Linux 容器来支持便携式应用程序部署’的文章中讲述了他部署的过程。一旦应用程序被安装之后,容器就可以被推送至注册库(例如Docker Hub)或者导出为一个tar文件。
DockerfileDockerfile 是一个用于构建 Docker 容器的脚本化系统。每一个 Dockerfile 定义了开始的基础镜像,以及一系列在容器中运行的命令或者一些被添加到容器中的文件。Dockerfile 也可以指定对外的端口和当前工作目录,以及容器启动时默认执行的命令。用 Dockerfile 构建的容器可以像手工构建的镜像一样推送或导出。Dockerfile 也可以用于 Docker Hub 的自动构建系统,即在 Docker 公司的控制下从头构建,并且该镜像的源代码是任何需要使用它的人可见的。
单进程?无论镜像是手动构建还是通过 Dockerfile 构建,有一个要考虑的关键因素是当容器启动时仅启动一个进程。对于一个单一用途的容器,例如运行一个应用服务器,运行一个单一的进程不是一个问题(有些关于容器应该只有一个单独的进程的争议)。对于一些容器需要启动多个进程的情况,必须先启动 supervisor 进程,才能生成其它内部所需的进程。由于容器内没有初始化系统,所以任何依赖于 systemd、upstart 或类似初始化系统的东西不修改是无法工作的。
容器和微服务全面介绍使用微服务结构体系的原理和好处已经超出了这篇文章的范畴(在 InfoQ eMag: Microservices 有全面阐述)。然而容器是绑定和部署微服务实例的捷径。
大规模微服务部署的多数案例都是部署在虚拟机上,容器只是用于较小规模的部署上。容器具有共享操作系统和公用库的的内存和硬盘存储的能力,这也意味着它可以非常有效的并行部署多个版本的服务。
连接容器一些小的应用程序适合放在单独的容器中,但在许多案例中应用程序需要分布在多个容器中。Docker 的成功包括催生了一连串新的应用程序组合工具、编制工具及平台作为服务(PaaS)的实现。在这些努力的背后,是希望简化从一组相互连接的容器来创建应用的过程。很多工具也在扩展、容错、性能管理以及对已部署资产进行版本控制方面提供了帮助。
连通性Docker 的网络功能是相当原始的。在同一主机,容器内的服务可以互相访问,而且 Docker 也可以通过端口映射到主机操作系统,使服务可以通过网络访问。官方支持的提供连接能力的库叫做 libchan,这是一个提供给 Go 语言的网络服务库,类似于channels。在 libchan 找到进入应用的方法之前,第三方应用仍然有很大空间可提供配套的网络服务。例如,Flocker 已经采取了基于代理的方法使服务实现跨主机(以及底层存储)的移植。
合成Docker 本身拥有把容器连接在一起的机制,与元数据相关的依赖项可以被传递到相依赖的容器中,并用于环境变量和主机入口。如 Fig 和 geard 这样的应用合成工具可以在单一文件中展示出这种依赖关系图,这样多个容器就可以汇聚成一个连贯的系统。CenturyLink 公司的 Panamax 合成工具类似 Fig 和 geard 的底层实现方法,但新增了一些基于 web 的用户接口,并直接与 GitHub 相结合,以便于应用程序分享。
编制像 Decking、New Relic 公司的 Centurion 和谷歌公司的 Kubernetes 这样的编制系统都是旨在协助容器的部署和管理其生命周期系统。也有许多 Apache Mesos (特别是 [Marathon(马拉松式)持续运行很久的框架])的案例(例如Mesosphere)已经被用于配合 Docker 一起使用。通过为应用程序与底层基础架构之间(例如传递 CPU 核数和内存的需求)提供一个抽象的模型,编制工具提供了两者的解耦,简化了应用程序开发和数据中心操作。有很多各种各样的编制系统,因为许多来自内部系统的以前开发的用于大规模容器部署的工具浮现出来了;如 Kubernetes 是基于谷歌的 Omega 系统的,Omega 是用于管理遍布谷歌云环境中容器的系统。
虽然从某种程度上来说合成工具和编制工具的功能存在重叠,但这也是它们之间互补的一种方式。例如 Fig 可以被用于描述容器间如何实现功能交互,而 Kubernetes pods(容器组)可用于提供监控和扩展。
平台(即服务)有一些 Docker 原生的 PaaS 服务实现,例如 Deis 和 Flynn 已经显现出 Linux 容器在开发上的的灵活性(而不是那些“自以为是”的给出一套语言和框架)。其它平台,例如 CloudFoundry、OpenShift 和 Apcera Continuum 都已经采取将 Docker 基础功能融入其现有的系统的技术路线,这样基于 Docker 镜像(或者基于 Dockerfile)的应用程序也可以与之前用支持的语言和框架的开发的应用一同部署和管理。
所有的云由于 Docker 能够运行在任何正常更新内核的 Linux 虚拟机中,它几乎可以用在所有提供 IaaS 服务的云上。大多数的主流云厂商已经宣布提供对 Docker 及其生态系统的支持。
亚马逊已经把 Docker 引入它们的 Elastic Beanstalk 系统(这是在底层 IaaS 上的一个编制系统)。谷歌使 Docker 成为了“可管理的 VM”,它提供了GAE PaaS 和GCE IaaS 之间的中转站。微软和 IBM 也都已经宣布了基于 Kubernetes 的服务,这样可以在它们的云上部署和管理多容器应用程序。
为了给现有种类繁多的后端提供可用的一致接口,Docker 团队已经引进 libswarm, 它可以集成于众多的云和资源管理系统。Libswarm 所阐明的目标之一是“通过切换服务来源避免被特定供应商套牢”。这是通过呈现一组一致的服务(与API相关联的)来完成的,该服务会通过特定的后端服务所实现。例如 Docker 服务器将支持本地 Docker 命令行工具的 Docker 远程 API 调用,这样就可以管理一组服务供应商的容器了。
基于 Docker 的新服务类型仍在起步阶段。总部位于伦敦的 Orchard 实验室提供了 Docker 的托管服务,但是 Docker 公司表示,收购 Orchard 后,其相关服务不会置于优先位置。Docker 公司也出售了之前 DotCloud 的PaaS 业务给 cloudControl。基于更早的容器管理系统的服务例如 OpenVZ 已经司空见惯了,所以在一定程度上 Docker 需要向主机托管商们证明其价值。
Docker 及其发行版Docker 已经成为大多数 Linux 发行版例如 Ubuntu、Red Hat 企业版(RHEL)和 CentOS 的一个标准功能。遗憾的是这些发行版的步调和 Docker 项目并不一致,所以在发布版中找到的版本总是远远落后于最新版本。例如 Ubuntu 14.04 版本中的版本是 Docker 0.9.1,而当 Ubuntu 升级至 14.04.1 时 Docker 版本并没有随之升级(此时 Docker 已经升至 1.1.2 版本)。在发行版的软件仓库中还有一个名字空间的冲突,因为 “Docker” 也是 KDE 系统托盘的名字;所以在 Ubuntu 14.04 版本中相关安装包的名字和命令行工具都是使用“Docker.io”的名字。
在企业级 Linux 的世界中,情况也并没有因此而不同。CentOS 7 中的 Docker 版本是 0.11.1,这是 Docker 公司宣布准备发行 Docker 1.0 产品版本之前的开发版。Linux 发行版用户如果希望使用最新版本以保障其稳定、性能和安全,那么最好地按照 Docker 的安装说明进行,使用 Docker 公司的所提供的软件库而不是采用发行版的。
Docker 的到来也催生了新的 Linux 发行版,如 CoreOS 和红帽的 Project Atomic,它们被设计为能运行容器的最小环境。这些发布版相比传统的发行版,带着更新的内核及 Docker 版本,对内存的使用和硬盘占用率也更低。新发行版也配备了用于大型部署的新工具,例如 fleet(一个分布式初始化系统)和etcd(用于元数据管理)。这些发行版也有新的自我更新机制,以便可以使用最新的内核和 Docker。这也意味着使用 Docker 的影响之一是它抛开了对发行版和相关的包管理解决方案的关注,而对 Linux 内核(及使用它的 Docker 子系统)更加关注。
这些新发行版也许是运行 Docker 的最好方式,但是传统的发行版和它们的包管理器对容器来说仍然是非常重要的。Docker Hub 托管的官方镜像有 Debian、Ubuntu 和 CentOS,以及一个‘半官方’的 Fedora 镜像库。RHEL 镜像在Docker Hub 中不可用,因为它是 Red Hat 直接发布的。这意味着在 Docker Hub 的自动构建机制仅仅用于那些纯开源发行版下(并愿意信任那些源于 Docker 公司团队提供的基础镜像)。
Docker Hub 集成了如 Git Hub 和 Bitbucket 这样源代码控制系统来自动构建包管理器,用于管理构建过程中创建的构建规范(在Dockerfile中)和生成的镜像之间的复杂关系。构建过程的不确定结果并非是 Docker 的特定问题——而与软件包管理器如何工作有关。今天构建完成的是一个版本,明天构建的可能就是更新的版本,这就是为什么软件包管理器需要升级的原因。容器抽象(较少关注容器中的内容)以及容器扩展(因为轻量级资源利用率)有可能让这种不确定性成为 Docker 的痛点。
Docker 的未来Docker 公司对核心功能(libcontainer),跨服务管理(libswarm) 和容器间的信息传递(libchan)的发展上提出了明确的路线。与此同时,该公司已经表明愿意收购 Orchard 实验室,将其纳入自身生态系统。然而 Docker 不仅仅是 Docker 公司的,这个项目的贡献者也来自许多大牌贡献者,其中不乏像谷歌、IBM 和 Red Hat 这样的大公司。在仁慈独裁者、CTO Solomon Hykes 掌舵的形势下,为公司和项目明确了技术领导关系。在前18个月的项目中通过成果输出展现了其快速行动的能力,而且这种趋势并没有减弱的迹象。
许多投资者正在寻找10年前 VMware 公司的 ESX/vSphere 平台的特征矩阵,并试图找出虚拟机的普及而带动的企业预期和当前 Docker 生态系统两者的距离(和机会)。目前 Docker 生态系统正缺乏类似网络、存储和(对于容器的内容的)细粒度版本管理,这些都为初创企业和创业者提供了机会。
随着时间的推移,在虚拟机和容器(Docker 的“运行”部分)之间的区别将变得没那么重要了,而关注点将会转移到“构建”和“交付”方面。这些变化将会使“Docker发生什么?”变得不如“Docker将会给IT产业带来什么?”那么重要了。
作者:Chris Swan 译者:disylee 校对:wxy
以上是的内容，更多
的内容，请您使用右上方搜索功能获取相关信息。
若你要投稿、删除文章请联系邮箱：zixun-group@service.aliyun.com,工作人员会在五个工作日内给你回复。
云服务器 ECS
可弹性伸缩、安全稳定、简单易用
&40.8元/月起
预测未发生的攻击
&24元/月起
为您提供0门槛上云实践机会
你可能还喜欢
你可能感兴趣
阿里云教程中心为您免费提供
Docker 的现状与未来相关信息，包括
的信息，所有Docker 的现状与未来相关内容均不代表阿里云的意见！投稿删除文章请联系邮箱：zixun-group@service.aliyun.com，工作人员会在五个工作日内答复
售前咨询热线
服务与支持
账号与支持
关注阿里云
International}