小项目有必要用docker吗，项目为什么用docker

大家好，关于小项目有必要用docker吗很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于项目为什么用docker的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！

项目为什么用docker

回答之前，先反问一个问题：为什么不用Docker呢？

Docker出现之前，有现在还在用的VMWare虚拟机，有Ghost，部分解决了服务器安装配置的琐碎工作，但是没有解决运行环境的问题。比如常见的环境不一致的问题：开发环境能运行，测试生产环境有bug？还有就是每次新服务器、新环境搭建时无穷无尽的问题。

那么Docker出现后，整个环境被打包起来，也就是将所有安装配置代码化自动化了，结合资源编排和云服务，可以秒启一个集群化的web服务系统，如果没有容器技术是做不到的。Docker是使用最普遍的容器技术，事实上的容器技术标准。

推荐看一个Docker秒启Web服务的视频：

我可以举几个例子，就可理解为什么要用docker?

用传统的方式上线一个WEB项目，我们的一般做法是在线上服务器中，安装WEB服务器，然后装好数据库，装好其他需要的软件最后把本地己打包好的代码上传至服务器，然后重启就好了。

如果一台服务器上要部署多个项目，每个项目之间无论是在资源的使用，还是之间的冲突。都会让人崩溃。更别提有不同的开发语言和开发团队。

现在我们有docker，可以用docker把应用直接打包封装到一个容器中。容器之间有着进程之间的隔离，在容器中操作不会影响到其他容器的使用。

以前开发一套应用，必须开发机上安装环境，测试机上安装环境，然后部署的服务器上安装环境，而且由于使用的机器不是同样的操作系统，所以有时会出现在本机上没问题，测试时有出问题，甚至开发测试都没问题，一上线就BUG满满。估计大家遇到过与测试之间撕B的场景。

用上docker，无论是在开发机，测试机，生产环境以容器运行，使应用在三种环境下保持一致。

对比虚拟机，docker占用资源更小。而且可以提高服务器的资源利用率。

Docker可以将复杂的应用程序运行环境部署打包，这样就避免开发人员或者运维人员反复部署相同的应用程序运行环境。在如今云计算盛行的情况下，分布式应用和管理变得简单了。基本上云计算服务平台都提供了现成的群集计算服务，这些群集服务无一例外都是基于docker镜像构建的。群集应用的要求就是每个节点的应用程序版本以及环境要一致，一个docker镜像就是一个虚拟主机，只要放到容器中即可实现单机独立运行的效果，大大简化了分布式群集应用的实现过程

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

云计算、大数据，移动技术的快速发展，加之企业业务需求的不断变化，导致企业架构要随时更改以适合业务需求，跟上技术更新的步伐。毫无疑问，这些重担都将压在企业开发人员身上；团队之间如何高效协调，快速交付产品，快速部署应用，以及满足企业业务需求，是开发人员亟需解决的问题。Docker技术恰好可以帮助开发人员解决这些问题。

为了解决开发人员和运维人员之间的协作关系，加快应用交付速度，越来越多的企业引入了DevOps这一概念。但是，传统的开发过程中，开发、测试、运维是三个独立运作的团队，团队之间沟通不畅，开发运维之间冲突时有发生，导致协作效率低下，产品交付延迟，影响了企业的业务运行。Docker技术将应用以集装箱的方式打包交付，使应用在不同的团队中共享，通过镜像的方式应用可以部署于任何环境中。这样避免了各团队之间的协作问题的出现，成为企业实现DevOps目标的重要工具。以容器方式交付的Docker技术支持不断地开发迭代，大大提升了产品开发和交付速度。

此外，与通过Hypervisor把底层设备虚拟化的虚拟机不同，Docker直接移植于Linux内核之上，通过运行Linux进程将底层设备虚拟隔离，这样系统性能的损耗也要比虚拟机低的多，几乎可以忽略。同时，Docker应用容器的启停非常高效，可以支持大规模的分布系统的水平扩展，真正给企业开发带来福音。

Docker很大程度上解决了上述问题，提高开发和运维的工作效率，提高企业的工作效率。

任何一项新技术的出现，都需要一个发展过程，比如云计算为企业所接受用了将近五年左右时间，OpenStack技术也经历了两、三年才受到人们的认可。因此，虽然Docker技术发展很快，但技术还不够成熟，对存储的灵活的支持、网络的开销和兼容性方面还存在限制，这是Docker没有被企业大范围使用的一个主要原因。另外一个原因是企业文化是否与DevOps运动一致，只有企业支持DevOps，才能更大地发挥Docker的价值。最后一个原因就是安全性问题，Docker对于Linux这一层的安全的隔离还有待改进，才能进一步得到企业的认可。

当服务器运行多个应用程序时，为了防止应用程序之间所需的环境依赖产生冲突或误操作影响，所以需要做好隔离，最大限度利用服务器资源环境，docker就把它变成了一个个沙盒。沙盒与沙盒之间互不影响

这是一个容器，为了防止一个项目的程序运行异常影响其他项目程序的正常运行，可以理解为隔离不同项目的程序，简单来说类似于一个虚拟的盒子或系统，里面运行独立的项目程序，共享系统底层资源。

docker跟项目有什么关系，运维玩就行了

生产环境,测试环境中,Docker 可以做什么

Docker是容器管理工具

Docker

是一个轻量级、便携式、与外界隔离的容器，也是一个可以在容器中很方便地构建、传输、运行应用的引擎。和传统的虚拟化技术不同的是，Docker

引擎并不虚拟出一台虚拟机，而是直接使用宿主机的内核和硬件，直接在宿主机上运行容器内应用。也正是得益于此，Docker

容器内运行的应用和宿主机上运行的应用性能差距几乎可以忽略不计。

但是 Docker本身并不是一个容器系统，而是一个基于原有的容器化工具 LXC用来创建虚拟环境的工具。类似 LXC的工具已经在生产环境中使用多年，Docker则基于此提供了更加友好的镜像管理工具和部署工具。

Docker不是虚拟化引擎

Docker第一次发布的时候，很多人都拿 Docker和虚拟机 VMware、KVM和 VirtualBox

比较。尽管从功能上看，Docker和虚拟化技术致力于解决的问题都差不多，但是 Docker

却是采取了另一种非常不同的方式。虚拟机是虚拟出一套硬件，虚拟机的系统进行的磁盘操作，其实都是在对虚拟出来的磁盘进行操作。当运行 CPU

密集型的任务时，是虚拟机把虚拟系统里的 CPU

指令“翻译”成宿主机的CPU指令并进行执行。两个磁盘层，两个处理器调度器，两个操作系统消耗的内存，所有虚拟出的这些都会带来相当多的性能损失，一台虚拟机所消耗的硬件资源和对应的硬件相当，一台主机上跑太多的虚拟机之后就会过载。而

Docker就没有这种顾虑。Docker运行应用采取的是“容器”的解决方案：使用 namespace和 CGroup

进行资源限制，和宿主机共享内核，不虚拟磁盘，所有的容器磁盘操作其实都是对/var/lib/docker/

的操作。简言之，Docker其实只是在宿主机中运行了一个受到限制的应用程序。

从上面不难看出，容器和虚拟机的概念并不相同，容器也并不能取代虚拟机。在容器力所不能及的地方，虚拟机可以大显身手。例如：宿主机是

Linux，只能通过虚拟机运行 Windows，Docker便无法做到。再例如，宿主机是 Windows，Windows并不能直接运行

Docker，Windows上的 Docker其实是运行在 VirtualBox虚拟机里的。

Docker使用层级的文件系统

前面提到过，Docker和现有容器技术 LXC等相比，优势之一就是 Docker提供了镜像管理。对于 Docker

而言，镜像是一个静态的、只读的容器文件系统的快照。然而不仅如此，Docker

中所有的磁盘操作都是对特定的Copy-On-Write文件系统进行的。下面通过一个例子解释一下这个问题。

例如我们要建立一个容器运行 JAVA Web应用，那么我们应该使用一个已经安装了 JAVA的镜像。在

Dockerfile（一个用于生成镜像的指令文件）中，应该指明“基于 JAVA镜像”，这样 Docker就会去 Docker Hub

Registry上下载提前构建好的 JAVA镜像。然后再 Dockerfile中指明下载并解压 Apache Tomcat软件到/opt/tomcat

文件夹中。这条命令并不会对原有的 JAVA镜像产生任何影响，而仅仅是在原有镜像上面添加了一个改动层。当一个容器启动时，容器内的所有改动层都会启动，容器会从第一层中运行/usr/bin/java

命令，并且调用另外一层中的/opt/tomcat/bin

命令。实际上，Dockerfile中每一条指令都会产生一个新的改动层，即便只有一个文件被改动。如果用过 Git

就能更清楚地认识这一点，每条指令就像是每次 commit，都会留下记录。但是对于 Docker

来说，这种文件系统提供了更大的灵活性，也可以更方便地管理应用程序。

我们Spantree的团队有一个自己维护的含有 Tomcat的镜像。发布新版本也非常简单：使用 Dockerfile

将新版本拷贝进镜像从而创建一个新镜像，然后给新镜像贴上版本的标签。不同版本的镜像的不同之处仅仅是一个 90 MB大小的 WAR

文件，他们所基于的主镜像都是相同的。如果使用虚拟机去维护这些不同的版本的话，还要消耗掉很多不同的磁盘去存储相同的系统，而使用 Docker

就只需要很小的磁盘空间。即便我们同时运行这个镜像的很多实例，我们也只需要一个基础的 JAVA/ TOMCAT镜像。

Docker可以节约时间

很多年前我在为一个连锁餐厅开发软件时，仅仅是为了描述如何搭建环境都需要写一个 12页的 Word文档。例如本地 Oracle

数据库，特定版本的

JAVA，以及其他七七八八的系统工具和共享库、软件包。整个搭建过程浪费掉了我们团队每个人几乎一天的时间，如果用金钱衡量的话，花掉了我们上万美金的时间成本。虽然客户已经对这种事情习以为常，甚至认为这是引入新成员、让成员适应环境、让自己的员工适应我们的软件所必须的成本，但是相比较起来，我们宁愿把更多的时间花在为客户构建可以增进业务的功能上面。

如果当时有 Docker，那么构建环境就会像使用自动化搭建工具 Puppet/ Chef/ Salt/ Ansible

一样简单，我们也可以把整个搭建时间周期从一天缩短为几分钟。但是和这些工具不同的地方在于，Docker

可以不仅仅可以搭建整个环境，还可以将整个环境保存成磁盘文件，然后复制到别的地方。需要从源码编译 Node.js吗？Docker

做得到。Docker不仅仅可以构建一个 Node.js环境，还可以将整个环境做成镜像，然后保存到任何地方。当然，由于 Docker

是一个容器，所以不用担心容器内执行的东西会对宿主机产生任何的影响。

现在新加入我们团队的人只需要运行 docker-compose up

命令，便可以喝杯咖啡，然后开始工作了。

Docker可以节省开销

当然，时间就是金钱。除了时间外，Docker还可以节省在基础设施硬件上的开销。高德纳和麦肯锡的研究表明，数据中心的利用率在 6%-

12%左右。不仅如此，如果采用虚拟机的话，你还需要被动地监控和设置每台虚拟机的 CPU硬盘和内存的使用率，因为采用了静态分区(static

partitioning)所以资源并不能完全被利用。。而容器可以解决这个问题：容器可以在实例之间进行内存和磁盘共享。你可以在同一台主机上运行多个服务、可以不用去限制容器所消耗的资源、可以去限制资源、可以在不需要的时候停止容器，也不用担心启动已经停止的程序时会带来过多的资源消耗。凌晨三点的时候只有很少的人会去访问你的网站，同时你需要比较多的资源执行夜间的批处理任务，那么可以很简单的便实现资源的交换。

虚拟机所消耗的内存、硬盘、CPU都是固定的，一般动态调整都需要重启虚拟机。而用 Docker的话，你可以进行资源限制，得益于

CGroup，可以很方便动态调整资源限制，让然也可以不进行资源限制。Docker

容器内的应用对宿主机而言只是两个隔离的应用程序，并不是两个虚拟机，所以宿主机也可以自行去分配资源。

Docker有一个健壮的镜像托管系统

前面提到过，这个托管系统就叫做 Docker Hub Registry。截止到 2015年4月29日，互联网上大约有 14000

个公共的 Docker，而大部分都被托管在 Docker Hub上面。和 Github已经很大程度上成为开源项目的代表一样，Docker

官方的 Docker Hub则已经是公共 Docker镜像的代表。这些镜像可以作为你应用和数据服务的基础。

也正是得益于此，你可以随意尝试最新的技术：说不定有些人就把图形化数据库的实例打包成了 Docker镜像托管在上面。再例如

Gitlab，手工搭建 Gitlab非常困难，译者不建议普通用户去手工搭建，而如果使用 Docker

Gitlab，这个镜像则会五秒内便搭建完成。再例如特定 Ruby版本的 Rails应用，再例如 Linux上的.NET

应用，这些都可以使用简单的一条 Docker命令搭建完成。

Docker官方镜像都有 official标签，安全性可以保证。但是第三方镜像的安全性无法保证，所以请谨慎下载第三方镜像。生产环境下可以只使用第三方提供的 Dockerfile构建镜像。

Docker Github介绍：5秒内搞定一个 Gitlab

关于 Linux上的.NET应用和 Rails应用，将会在以后的文章中做详细介绍。

Docker可以避免产生 Bug

Spantree一直是“固定基础设置”（immutable

infrastructure）的狂热爱好者。换句话说，除非有心脏出血这种漏洞，我们尽量不对系统做升级，也尽量不去改变系统的设置。当添加新服务器的时候，我们也会从头构建服务器的系统，然后直接将镜像导入，将服务器放入负载均衡的集群里，然后对要退休的服务器进行健康检查，检查完毕后移除集群。得益于

Docker镜像可以很轻松的导入导出，我们可以最大程度地减少因为环境和版本问题导致的不兼容，即便有不兼容了也可以很轻松地回滚。当然，有了

Docker，我们在生产、测试和开发中的运行环境得到统一。以前在协同开发时，会因为每个人开发的电脑配置不同而导致“在我的电脑上是能运行的，你的怎么不行”的情况，而如今

Docker已经帮我们解决了这个问题。

Docker目前只能运行在 Linux上

前面也提到过，Docker使用的是经过长时间生产环境检验的技术，虽然这些技术已经都出现很长时间了，但是大部分技术都还是 Linux

独有的，例如 LXC和 Cgroup。也就是说，截止到现在，Docker容器内只能在 Linux上运行 Linux

上的服务和应用。Microsoft正在和 Docker紧密合作，并且已经宣布了下一个版本的 Windows Server将会支持

Docker容器，并且命名为 Windows Docker，估计采用的技术应该是Hyper-V

Container，我们有望在未来的几年内看到这个版本。

微服务为什么一定要用Docker

早在2013年的时候，docker就已经发行，然而那会还是很少人了解docker。一直到2014年，Martin Fowler提出了微服务的概念，两个不相干的技术终于走在了一起，创造了今天的辉煌！

近几年来，很多互联网关系开始跟风，构建docker+微服务的架构体系。然而，根据笔者观察发现，有些童鞋在使用过程中，只是会用，而根本不了解为什么使用docker，反正对他们来说，公司让用就用！而某些公司呢，虽然用上了docker，然而运维方式并没有发生改变，白白浪费了docker的大好性能

过去:曾记得12年那会，部门要上一个项目。那会，我是这么干的。直接去线上服务器，拷贝一个tomcat，然后改端口号，然后部署应用到webapps文件夹下，重启就好。而且我可以摸着良心说，现在还有很多传统企业是这么做的。

那么这么做的缺点？

很明显，应用之间相互影响。一个应用出现问题，该应用把线程池给拖垮了，这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐。如果还采用这种部署方式，你的应用和某个坑爹团队的应用部署在了同一台服务器上，至于结果，我相信你懂的。

现在:用上了docker容器后，将Docker可以将我们的应用程序打包封装到一个容器中，该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离，在容器中的操作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形！