• Mount，对挂载点（文件系统）的隔离

这些隔离机制都是Linux内核的namespace机制实现，也是Docker容器设计的精髓。

就好像原来是一个300平米的大房子，就住着一家人，卧室、厨房、卫生间这一家人独享。可是房子太大完全可以住三个家庭，不仅能公摊一部分费用，还能为主家带来额外的收益。那么就要对这个大房子重新进行规划设计，满足三个家庭的需要，制定一些生活制度，有些资源是可以共享的，但关键资源就必须隔离开，保护隐私嘛！其实大家说到底还是在一个大房子内平等的生活。

用了这个比喻其实就是告诉大家，你就把Docker理解为一个房子多个家庭的规划安排包租婆，Docker管理了很多的容器服务，容器服务就是在宿主机上跑着的，例如MySQL、Nginx、微服务等等都是容器服务，大家都是在一个OS上平等的运行着，只不过进了自己房间，你对别人房间的情况就一无所知了。那么这不仅保护了各个服务之间不会产生对资源争用，而且还能根据预先入户的协议，分配好CPU、内存、磁盘的容量。这样大家住在一起也是明明白白的，谁也不能沾了谁的便宜。当然了对外的网络端口还是需要各家分配不同的。

有了这个本事，你就能在有限的云资源上跑很多服务啦！我自己做的公司网站跑在阿里云的ECS CentOS7，就跑了三个Docker容器：Nginx、MySQL、Wordpress，我才给分配了512M内存，够抠门吧，但是运行地妥妥的，只是物理内存是在太小，有时候重启服务，OS报内存资源就不够了，必须把Docker也重启，清空一下内存就好了。

我给当时老东家的两个互联网平台产品用了三台ECS性能不错的服务器，4核，16G内存，足足跑了50多个微服务和其他基础服务，真的是把资源榨得是干干净净。关键还有服务日志隔离、环境变量隔离、全局配置隔离等待，好处实在太多了。关键对我们产品在互联网架构上的Devops提供了良好的基础支撑，我可以在一台虚拟机上跑两套微服务，一套生产、一套测试，测试好的微服务升级版本号，变成新的生产微服务，老的微服务进入过渡替换期。

连接互联网不是必要的。可以内部搭建Docker Registry服务。我曾经就是在阿里云的多台机器的其中一台做了Registry服务，然后让其他机器通过内网的5000端口访问就可以了，记得给每台服务器的Docker服务都配置一下都不走SSL。

我们也只有远程发布才让自己的开发客户端，访问Nginx的HTTP SSL端口，反向代理到Registry仓库，那么就需要在服务端装一个Docker版的nginx，因为公网尽量走HTTPS。如下图所示：

关于内网怎么装Docker的问题，你需要先找一个能上网的机器，通过Docker hub做好你自己的Docker images，最好会dockfile怎么做，这是个脚本技术，主要有一些本地化和参数优化需要再做一下Docker images，然后Docker push到内网私有register服务仓库就可以了，其他内网机器只要Docker pull命令，就可以使用你制作的Docker images了。

windows系统下开发，就下载安装windows的Docker desktop使用和mac版本一样。

一般Docker更新的方式，都是pull下来新的images，然后重启容器，当然也有一些讨巧的办法，通过对Docker内的发布程序目录镜像到本地目录，那么每次只上传程序包，更新服务器本地目录之后再进行Docker重启，这种方式免去了Docker体量太大，上传慢的问题。

但是这些都需要重启容器，不算真正意义上的热更新，在线业务系统往往允许的抖动时长会很严苛，而且即便是Docker镜像在测试环境都已经测试的没有问题了，放到生产服务器上也不能没有经过验证就直接替换，若是web系统，我建议用api网关+Docker-compose+多版本运行的方式来实现热更新，而且这也会使得升级抖动的影响降到最低。如下图所示：T 为测试，P为生产，v1、v2就是Docker-compose的多版本发布，通过API网关重定向微服务新版本跳转，实现最小升级抖动。

具体意思我简要说一下，就是让Docker-compose作为你的应用发布的整体，这样无论是微服务也好，单体应用也好，就都统一作为一个单元部署管理了！

然后对需要更新的新版本程序，发布出新版本的Docker-compose，qa验证无误后，再由api网关实现动态切换，Docker热更新的大体思路就是这样。

Docker映射配置文件的时候，一定是先要有这个文件，记住，而不是等其内部会创建这个文件，否则它只会创建出目录。

因此Docker映射文件不存在就走映射目录了。

所以第一种方式：是配置文件已经存在，也就是自己上传到服务器自定义配置目录，然后Docker直接映射过去，这时候映射文件或者映射目录一个道理。

第二种方式：配置目录映射到自定义目录，容器运行过程脚本自动化写入，那么配置目录的各项文件就需要在容器初始化过程中，由脚本对镜像内的打包配置文件完成写入。

其实我做过一个Redis的优化过的生产级的Docker，走的是第一种方式，需要你自己上传一下配置，可以看看我的gitee源代码仓库，gitee仓库也就做了这一个面向Redis中文化、性能调参过的Dockerfile以及配置文件。在gitee中搜索“读字节” 有个我写的不错的单机版Redis Dockerfile文件，里面对性能做过优化，大家可以用来学习。

总之在目前Kubernetes如日中天的时代，我们有时候要冷静思考一下，到底我们有必要搞得那么复杂吗？难道Docker还不够用吗？如果配合上Portainer这种在线免费的Docker管理工具，能让你的云上服务群管理的很好。

但是有一点是有门槛的，那就是玩Docker一定要不断历练自己的Linux能力，包括脚本编写能力，因为有些Docker Images并不能按照你的实际环境满足你的使用需求，需要自建Dockerfile，我就在以前的工程中配合Maven编写了自己的Dockerfile和Shell脚本，微服务从打包到发布，一气呵成，而且可以灵活去选择哪个微服务进行更新。这就真的需要深刻的去理解Linux了。

实际上面对更复杂的K8s，熟悉Linux这个问题一样是绕不过去的。因此还是关键的那一步，容器时代，用好容器引擎是从简单的Docker开始，并且在搞定程序之外历练自己的Linux功力，你的技术将提升得更快！