老铁们，大家好，相信还有很多朋友对于docker compose优缺点和生产不建议用docker的相关问题不太懂，没关系，今天就由我来为大家分享分享docker compose优缺点以及生产不建议用docker的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！
本文目录
Docker（容器）技术会给IT带来哪些改变
谢邀！
我们将应用大规模运行在docker环境已经超过一年时间了，在使用这个过程中我们踩过不少的坑，也在实际使用过程中发现docker不如最初设想的那么美好。尽管如此，我们还是一致认为，docker对整个IT组织都是友好的，能有效提升我们的业务交付效率。
以下是我们基于kubernets集群环境下使用Docker的一些改变和总结：
1、减少环境对应用的影响，有助于IT组织实现应用环境的标准化；
其镜像技术可以有效的屏蔽环境对代码的影响，基本可以做到开发、测试、生产在运行环境上完全一致，通过Docker我们实现了过去几年都未能推动的技术栈、环境统一管理能力（之前有技术栈，但迟迟未能落地）；
2、有效帮助IT组织快速构建开发验证、测试及生产环境；
因为业务复杂度高，各应用系统之间耦合度非常高，我们在构建测试环境时需要耗费的精力非常大，通过kubernets的编排和docker镜像管理能力，我们实现了快速复制整套应用集成环境的能力（当然，docker不解决数据层的问题）
3、提升运维的应用运行环境的交付速度；
构建应用环境（不管是开发还是测试），不需要创建虚拟机、部署中间件等过程，几乎可以做到分钟级提供。
当然，在使用过程中，我们也发现有些功能不如设想的那么美好：
1、资源利用率，提升真的很有限，基于docker的不稳定性等，实际还看不到这部分的收益；
2、弹性伸缩不如想象中的那么好用，但还是提升了运维在应用扩容上的效率；
3、管理docker集群本身的容量花费的精力比想象中的要高；
4、持久化、混合部署是当前docker环境的最大挑战。
k8s真的要放弃docker自己做容器么
先说结论，不是
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#changed
kubernetes1.20版本的changelog里面写到
Deprecation
Dockersupportinthekubeletisnowdeprecatedandwillberemovedinafuturerelease.Thekubeletusesamodulecalled"dockershim"whichimplementsCRIsupportforDockerandithasseenmaintenanceissuesintheKubernetescommunity.Weencourageyoutoevaluatemovingtoacontainerruntimethatisafull-fledgedimplementationofCRI(v1alpha1orv1compliant)astheybecomeavailable.(#94624,@dims)[SIGNode]
大意是，Kubelet中的Docker支持已经进入淘汰阶段，将在未来移除。原因是Kubelet中使用dockershim组件为Docker提供了CRI支持，Kubernetes认为维护这个组件是有问题的。建议用户评估并迁移到CRI支持更完善的运行时上。
其中引用了9月提出的PR#94624。其中提出，为了使用Docker，从moby进行了大量移植开发了dockershim嵌入到Kubelet之中。Kubelet和CRI的正确沟通方式是像containerd、cri-o这样。各自使用独自的进程，互相以gRPC进行对接。Docker目前仍然是主流，进行迁移需要广而告之并逐步推进。
通俗的说就是，Kubernetes是通过CRI来对接容器运行时的，而Docker本身是没有实现CRI的，所以Kubernetes内置了一个“为Docker提供CRI支持”的dockershim组件。现在Kubernetes宣布不再维护这个组件了，大概的意思就是：Docker虽然好用，但那是对人来说的，Kubernetes又不是人，不需要那些花里胡哨的东西！
Kubernetes这是话里有话，说白了就是：我特么以前为了兼容你，我集成在我自己这里，现在我就想自己单纯一点，要么你自己写CRI的接口要么就再见。
目前docker公司还没有回应。
那这个对我们开发、运维有什么影响呢？
目前来看没太大的影响，如果你在生产环境使用kubernetes，那你以后可能要逐渐迁移至containerd、cri-o这样的容器进行时，比如红帽公司开发的podman
docker compose优缺点
DockerCompose是一个用于定义和运行多容器Docker应用程序的工具。它使用YAML文件来配置应用的服务、网络和卷等相关信息。下面是DockerCompose的一些优点和缺点：
优点：
1.简化应用部署：DockerCompose允许以声明式的方式描述应用程序的组成部分和相关配置，使得部署变得更加简单和可重复。通过一个命令，可以一键启动整个应用的多个容器。
2.容器编排和协调：DockerCompose提供了容器级别的编排和协调功能。可以轻松定义容器之间的关系和依赖关系，例如定义服务之间的链接和通信方式，同时可指定启动顺序和依赖关系。
3.简化开发环境配置：使用DockerCompose可以轻松搭建复杂的开发环境，将开发所需的多个组件和服务组合在一起。开发人员可以在任何地方轻松地复制和部署相同的开发环境，有效避免了"在我的机器上能运行"的问题。
4.可移植性和可重用性：DockerCompose文件具有可移植性，可以在不同的环境（开发、测试、生产等）中部署和运行应用程序。同时，DockerCompose文件是可重用的，可以在类似的项目中进行共享和重用。
缺点：
1.学习曲线：对于初学者而言，学习DockerCompose可能需要一定的时间和学习成本。需要了解和理解其完整的命令集和配置文件的结构。
2.不适用于复杂应用：对于过于复杂或需要高度定制的应用，DockerCompose的能力可能有限。在这种情况下，可能需要考虑使用更高级的容器编排工具。
3.不适用于大规模部署：DockerCompose适用于较小规模的部署，但对于大规模的集群管理和应用编排，可能需要考虑使用更强大的编排工具，例如Kubernetes。
综上所述，DockerCompose简化了应用的部署和管理，提供了容器级别的编排和协调功能，但也有学习曲线，不适用于复杂和大规模部署。根据具体的需求和上述优缺点进行评估，选择是否使用DockerCompose。
docker容器与虚拟机有什么区别
谢邀~
我们单位最近在推docker，已经在开发测试环境使用（稍显落后），下面我就谈谈自己的Docker的理解，以及Docker和虚拟机的区别。
虚拟机先说说什么是虚拟机：在一台物理机器上，利用虚拟化技术，虚拟出来多个操作系统，每个操作系统之间是隔离的。
说起来有些绕，那么我们看看虚拟机的架构图，就容易理解了。例如我们要在一台物理机器运行三个Java项目，彼此之间隔离。
从下往上看，解释起来其实很简单：
最下面的一层就是物理机，可以是服务器，设置是一台个人电脑；
电脑上需要安装操作系统，比如我们安装了win10的操作系统；
再往上就是虚拟机软件了，比如我们常用的VirtualBox、VMWare，它们的作用是模拟计算机硬件；
继续向上，就是虚拟机模拟出来的操作系统了；
在虚拟的操作系统中，安装所需的软件、组件等。比如我们需要在虚拟操作系统中安装JDK、Tomcat等；
最后就是具体的应用了，例如部署到Tomcat中。
Docker再说说什么是Docker，找了一句官方的解释：Docker是开源的应用容器引擎。是不是又一头雾水？我们还是先看看Docker的架构图。
依然从下往上看：
最下面两层，概念同上。
往上，可以看做Docker容器的管理器。
依赖和应用都被打包成了Docker镜像。例如，JDK、Tomcat、应用都被打包在了一起，运行在Docker容器里，容器和容器间是隔离的。
这里提示：Linux支持Docker，Windows和MacOS的话，不直接支持（win10专业版好像可以直接支持，不过我都是安装Linux的虚拟机，在上面跑Docker）。
Docker和虚拟机的区别从两者的架构图上看，虚拟机是在硬件级别进行虚拟化，模拟硬件搭建操作系统；而Docker是在操作系统的层面虚拟化，复用操作系统，运行Docker容器。
Docker的速度很快，秒级，而虚拟机的速度通常要按分钟计算。
Docker所用的资源更少，性能更高。同样一个物理机器，Docker运行的镜像数量远多于虚拟机的数量。
虚拟机实现了操作系统之间的隔离，Docker算是进程之间的隔离，虚拟机隔离级别更高、安全性方面也更强。
虚拟机和Docker各有优势，不存在谁替代掉谁的问题，很多企业都采用物理机上做虚拟机，虚拟机中跑Docker的方式。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。好了，关于docker compose优缺点和生产不建议用docker的问题到这里结束啦，希望可以解决您的问题哈！
