传统部署项目演化以及Docker价值

比如说做了一个传统项目的开发,比如说购物网站,最后打成war包,去放到Linux上部署,但是这样的成本是很高的,因为为了去部署一个用户量并不是很大的购物网站,你需要买一个机器,并且在上面部署应用,而它只用了你系统相对应一个相当少的资源,此时你会发现有资源的浪费,并且你买台机器的成本相对来说比较高,而且如果你想迁移其它机器上的时候,你会发现有兼容性的问题.

传统的VM Ware

解决办法就是把物理机进行虚拟化的技术,然后在虚拟机里面去装操作系统,再将我们的应用去进行一个部署在上面,将我们整个物理机的资源去进行隔离性的应用.

img

比如基础设施(infrastructure),然后在这个基础设施上去安装操作系统(Operation System),然后选取一个虚拟化技术(Hypervisor),在这个基础之上用VM去做虚拟化,然后在每一个VM里面去安装对应的操作系统,此时此刻,在某种程度当中能够将原来的一个硬件资源去进行一个充分的利用.

但是此时有一种情况就是你电脑是8核cpu,16G内存,此时你开启一个VM的时候,它就会找你主机去申请一个2核的cpu资源和4G内存,此时可能这个虚拟机VM里面的APP A可能往往也不一定能把这个资源全部用到,所有还会有资源的浪费.因为VM要那么多资源还是为了支持内部的Operating System(操作系统),相当来说还是比较重的.

Docker

我们能不能根据不同的操作系统去搞一个类似JVM(一次编译,到处运行)的东西,Docker Engine,Docker引擎帮我们屏蔽了不同的操作系统,能够方便我们的移植.

Docker部署一个应用相当于new了一个Java对象, Docker Engine相当于JVM,Docker部署的任何一款应用相当于一个是class模版一个是对象, 你在Docker部署的应用或者是资源可以认为是Docker image模版,而你根据每一个image去创建的Java对象可以理解为Containers,一个Docker Image可以创建出多个Containers出来.

这是一种容器化的技术,你运行的任何应用,所包含的一个资源都可以称为是一个一个的containers.以前的jvm不管实例化多少个对象都是共享一个物理主机资源.

而Docker的Container如果你需要多少资源也是直接和物理主机要资源,所以这样的设计的好处就是Containers直接共享物理主机资源,就不需要VM Ware 这样一启动就直接找主机要资源, 所以Docker占用的资源就比较小.

img

最下层是Infrastructure(基础设施),然后安装的操作系统(Host Operation System),然后是Docker引擎,每一个APP 其实就是一个Container,而一个一个的Container运行在Docker之上,每一个Container是根据Docker Image模版去创建出来的.

比如说部署一个项目, 先有代码配置文件依赖环境,变成Docker Image , 再变成Containers ,如果安装Redis的话,先变成Docker Image,最后变成Containers,如果是安装Tomcat的话,也是先变成Image,最后变成Containers

Docker主要用途

  1. 提供一次性的环境。比如,本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。

  2. 提供弹性的云服务。因为 Docker 容器可以随开随关,很适合动态扩容和缩容。

组建微服务架构。一个微服务会有很多app,用Docker部署的方式是最合适不过的了.

猜你喜欢

转载自blog.csdn.net/qq_41489540/article/details/114017203