代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
非官方地址，例如：dl.dockerpool.com。
Docker自1.3.0版本之后，加强了对镜像安全性的验证，需要手动添加对非官方仓库的信任。
DOCKER_OPTS=”–insecure-registry dl.dockerpool.com:5000”
重启docker服务即可。
Docker利用Linux内核中很多安全特性来保证不同容器之间的隔离，并且通过签名机制来对镜像进行验证。
大量生产环境的部署证明，Docker虽然隔离性无法与虚拟机相比，但仍然具有极高的安全性。
LXC是在Linux上相关技术实现的容器，docker则在如下的几个方面进行了改进：
1、移植性：通过抽象容器配置，容器可以实现一个平台移植到另一个平台。
2、镜像系统：基于AUFS的镜像系统为容器的分发带来了很多的便利，通是共同的镜像层只需要存储一份，实现高效率的存储。
3、版本管理：类似于GIT的版本管理理念，用户可以更方便的创建、管理镜像文件。
4、仓库系统:仓库系统大大降低了镜像的分发和管理的成本。
5、周边工具：各种现有的工具（配置管理、云平台）对docker的支持，以及基于docker的pass、Cl等系统，让docker的应用更加方便和多样。
容器退出后会处于终止（exited）状态， 此时可以通过docker ps -a查看。
其中的数据也不会丢失，还可以通过docker [container] start命令来启动它。只有删除掉容器才会清除所有数据。
可以使用docker [container] inspect --format ' {{ . State.Pid }} '< CONTAINER ID or NAME>命令。
方式一：docker inspect
通过docker inspect命令不仅能查看环境变量，还能查看容器其它相关信息，非常丰富，以Json格式输出。
docker inspect centos
可读性还可以，但也不算很高，可以通过grep命令过滤一下：
$ docker inspect centos | grep SERVER "SERVER_PORT=80"
或者可以解析一下Json文本：
$ docker inspect -f '{{range $index, $value := .Config.Env}}{{println $value}}{{end}}' centosPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
方式二：doecker exec env
这种方式获取的环境变量就跟我们平时获取linux环境变量是一样的了。只是在容器跑了个env命令而已。如下：
$ docker exec centos envPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOSTNAME=f8b489603f31HOME=/root
Docker hub是一个基于云的注册表服务，允许您链接到代码存储库，构建镜像并测试它们，存储手动推送的镜像以及指向Docker云的链接，以便可以将镜像部署到主机。它为整个开发流程中的容器镜像发现，分发和变更管理，用户和团队协作以及工作流自动化提供了集中资源。
四种状态：运行、已停止、重新启动、已退出。
使用快捷键Ctrl+p，后Ctrl+q，如果按Ctrl+c会使容器内的应用进程终止，进而会使容器终止。
docker优点
1、部署方便
你一定还有印象，在我们最开始学习编程的时候，搭建环境这一步往往会耗费我们好几个小时的时间，而且其中一个小问题可能需要找很久才能够解决。你还会得到关于环境搭建方面的团队其他成员的求助。而有了容器之后，这些都变得非常容易，你的开发环境就只是一个或者几个容器镜像的地址，最多再需要一个控制部署流程的执行脚本。或者进一步将你的环境镜像以及镜像脚本放入一个git项目，发布到云端，需要的时候将它拉到本地就可以了。
2、部署安全
当我们收到一个bug反馈的时候，很多时候心里面的第一反应一定是“我本地是好的啊”！这种情况的发生就在于环境的不一致，我们在开发过程中的调试往往不能保证其他环境的问题，但是我们却要为此买单，这真是一件令人苦恼的事情。有了容器之后，这将很少发生。我们可以通过容器技术将开发环境和测试环境以及生产环境保持版本和依赖上的统一，保证代码在一个高度统一的环境上执行。而测试环境的统一，也同样能解决CI流程对环境的要求。
3、隔离性好
不管是开发还是生产，往往我们一台机器上可能需要跑多个服务，而服务各自需要的依赖配置不尽相同，假如说两个应用需要使用同一个依赖，或者两个应用需要的依赖之间会有一些冲突，这个时候就很容易出现问题了。所以同一台服务器上不同应用提供的不同服务，最好还是将其隔离起来。而容器在这方面有天生的优势，每一个容器就是一个隔离的环境，你对容器内部提供服务的要求，容器可以自依赖的全部提供。
4、快速回滚
容器之前的回滚机制，一般需要基于上个版本的应用重新部署，且替换掉目前的问题版本。在最初的时代，可能是一套完整的开发到部署的流程，而执行这一套流程往往需要很长的时间。在基于git的环境中，可能是回退某个历史提交，然后重新部署。这些跟容器技术相比都不够快，而且可能会引起新的问题（因为是基于新版本的修改）。而容器技术天生带有回滚属性，因为每个历史容器或者镜像都会有保存，而替换一个容器或者某个历史镜像是非常快速和简单的。
5、成本低
这可能是一个最明显和有用的优点了，在容器出现之前，我们往往构筑一个应用就需要一台新的服务器或者一台虚机。服务器的购置成本和运维成本都很高，而虚机需要占用很多不必要的资源。相比之下，容器技术就小巧轻便的多，只需要给一个容器内部构建应用需要的依赖就可以了，这也是容器技术发展迅速的最主要原因。
6、管理成本更低
随着大环境的发展，docker等容器的使用和学习的成本也是愈发降低，成为更多开发者和企业的选择。
docker缺点
1、隔离性
基于hypervisor的虚机技术，在隔离性上比容器技术要更好，它们的系统硬件资源完全是虚拟化的，当一台虚机出现系统级别的问题，往往不会蔓延到同一宿主机上的其他虚机。但是容器就不一样了，容器之间共享同一个操作系统内核以及其他组件，所以在收到攻击之类的情况发生时，更容易通过底层操作系统影响到其他容器。当然，这个问题可以通过在虚机中部署容器来解决，可是这样又会引出新的问题，比如成本的增加以及下面要提到的问题：性能。
2、性能
不管是虚机还是容器，都是运用不同的技术，对应用本身进行了一定程度的封装和隔离，在降低应用和应用之间以及应用和环境之间的耦合性上做了很多努力，但是随机而来的，就会产生更多的网络连接转发以及数据交互，这在低并发系统上表现不会太明显，而且往往不会成为一个应用的瓶颈（可能会分散于不同的虚机或者服务器上），但是当同一虚机或者服务器下面的容器需要更高并发量支撑的时候，也就是并发问题成为应用瓶颈的时候，容器会将这个问题放大，所以，并不是所有的应用场景都是适用于容器技术的。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
