您的位置:首页 > 运维架构 > Docker

理解docker部署springboot-为什么要用docker(六)

2017-12-18 14:16 621 查看
为什么要用docker,在最开始接触docker的时候,我们应该都能看到下边的这段话,下边的摘自这里,这可能就是当时拥抱docker的原因,写这个的目的主要是回过头来结合我对docker的实践说一下对下边这些的理解,当然我的理解和大神比起来肯定是小巫见大巫,但是有观点还是要表达出来的,有问题继续更新,我坚信学习就是踩着自己的坑往上爬(否定之否定,再继续否定,就离真理不远了)

原文:更高效的利用系统资源

原文:由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销,Docker 对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度,都要比传统虚拟机技术更高效。因此,相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。

个人理解:如果把docker容器本身作为一个单位的,那确实是比整个Linux虚拟化这一套要精简很多的,最后那就话,暂时还没有实践出来,过程可以看上一篇博客

原文:更快速的启动时间

原文:传统的虚拟机技术启动应用服务往往需要数分钟,而 Docker 容器应用,由于直接运行于宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

个人理解:如果算上虚机的开机时间再算上项目的启动时间确实很长啊,但是你部署项目的时候难道要重启虚机?我实践的结果是不管你在虚机上还是在docker镜像中,springboot项目本身启动的时间没有发生任何变化,至于秒级、甚至毫秒级的启动时间,没有体会的到。

原文:一致的运行环境

原文:开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致,导致有些 bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境,确保了应用运行环境一致性,从而不会再出现 「这段代码在我机器上没问题啊」 这类问题。对开发和运维(DevOps)人员来说,最希望的就是一次创建或配置,可以在任意地方正常运行。

个人理解:这确实是一个可以保证的事情,所有的东西都打包成一个镜像移动来移动去都是一样的不会发生任何变化。

原文:使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建,并结合持续集成(Continuous Integration) 系统进行集成测试,而运维人员则可以直接在生产环境中快速部署该镜像,甚至结合持续部署(Continuous Delivery/Deployment) 系统进行自动部署。而且使用 Dockerfile 使镜像构建透明化,不仅仅开发团队可以理解应用运行环境,也方便运维团队理解应用运行所需条件,帮助更好的生产环境中部署该镜像。

个人理解:所有的东西都在Dockerfile上,所有的人员都可以通过Dockerfile查看其中的依赖。

原文:更轻松的迁移

原文:由于 Docker 确保了执行环境的一致性,使得应用的迁移更加容易。Docker 可以在很多平台上运行,无论是物理机、虚拟机、公有云、私有云,甚至是笔记本,其运行结果是一致的。因此用户可以很轻易的将在一个平台上运行的应用,迁移到另一个平台上,而不用担心运行环境的变化导致应用无法正常运行的情况。

个人理解:一个镜像搞定所有问题

原文:更轻松的维护和扩展

原文:Docker 使用的分层存储以及镜像的技术,使得应用重复部分的复用更为容易,也使得应用的维护更新更加简单,基于基础镜像进一步扩展镜像也变得非常简单。此外,Docker 团队同各个开源项目团队一起维护了一大批高质量的官方镜像,既可以直接在生产环境使用,又可以作为基础进一步定制,大大的降低了应用服务的镜像制作成本。

个人理解:在很多的开放的仓库中都有共享的镜像在里边,也可以自己发布,修改拓展,总之很多东西你不需要从头开始,站在了巨人的肩膀上了
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  docker