ker技术分析和总结.docx

对于用户来说，可能一开始在不了解的情况下会对容器报以拒绝的态度，但是在尝到容器的甜头、体验到它的强大性能之后，相信大家最终是无法抵挡其魅力的。容器技术能够解决 对于用户来说，可能一开始在不了解的情况下会对容器报以拒绝的态度，但是在尝到容器的甜头、体验到它的强大性能之后，相信大家最终是无法抵挡其魅力的。容器技术能够解决 IT 业目前面临的很多问题，而且优势也很明显，比如说： 1、容器具有不可变的特性。 虚拟化新技术：Docker 技术 容器将操作系统、程序库、配置文件、路径和应用程序打包在一起运行，也就是说，我们在做 容器将操作系统、程序库、配置文件、路径和应用程序打包在一起运行，也就是说，我们在做 QA 测试的时候整个镜像是什么样，投入到产品环境以后就是什么样，其性能不会有任何差距。 2、容器都非常轻量。 单个容器的内存占用很小，不像其他进程动辄占用上万 单个容器的内存占用很小，不像其他进程动辄占用上万 MB 的内存空间，容器只会给主进程分配内存，可以有效降低系统开销。 3、容器的速度更快。 虚拟机的启动时间一般都在分钟级，容器的启动速度可以达到秒级，启动容器就跟启动 虚拟机的启动时间一般都在分钟级，容器的启动速度可以达到秒级，启动容器就跟启动 linux 进程一样快。虽然容器的好处这么多，但是有很多用户还不了解，还认为容器跟一般的虚拟 机没什么差别。实际上，容器是可销毁的，这是容器跟虚拟机之间最大的差别。容器的存在 周期很短，只要用户使用完毕，就可以立即销毁容器，所以用“朝生暮死”来形容也不算过分。 在对容器进行使用和维护时，我们应该充分利用容器的这个特性，不要再把容器当成一般的虚拟机来看待，不然就真的大材小用了。在实际使用过程中，为了最大限度地发挥容器的优势，有些错误还是少犯为妙。我总结出了下面几个要点供大家参考，在跑容器的时候大家最好还是尽量遵照这几条原则： 1) 不要将数据储存在容器中。 容器随时都可以停止、销毁或迁移，比方说，一个容器里运行的应用版本是 容器随时都可以停止、销毁或迁移，比方说，一个容器里运行的应用版本是1.0，我们分分钟就可以把这个应用升级到 1.1，同时还不会对数据造成任何影响。所以如果用户想要存数据的话，最好是用数据卷来存储。不过在用卷存数据的时候大家还是要注意一点，如果有两 个容器共用一个数据卷，都往里面写数据的话，是有可能造成程序崩溃的。我们在设计应用程序的时候应该考虑到这一点，为保万无一失，应用程序应该具备特定的机制，以确保在往 共享数据存储区写入数据的时候不会出错。 2) 不要把应用程序分块交付。 在部分用户看来，容器跟虚拟机没什么两样，所以有些人往往会把应用程序部署到当前运行 在部分用户看来，容器跟虚拟机没什么两样，所以有些人往往会把应用程序部署到当前运行的若干个容器中。这种做法在开发阶段没有太大的问题，因为做开发的时候我们会很频繁地进行部署和调试，但是到了持续交付（CD）阶段，下一步就是QA 测试和正式投产了，这种做法就不太适合了。在这一阶段，我们应该充分考虑到容器的不可变特性，最好是将应用程序打包到一个镜像中交付。 3) 不要把镜像体积建得很大。 镜像越大，就越难发布。镜像中只包含必要的文件和 镜像越大，就越难发布。镜像中只包含必要的文件和 library 就可以了，能让应用或者进程 运行起来就行。千万不要在镜像中安装些没必要的东西，在构建镜像的时候要避免使用 运行起来就行。千万不要在镜像中安装些没必要的东西，在构建镜像的时候要避免使用 yum 这种 update 命令，免得系统自动下载很多不相干的文件到新镜像层中。4) 建镜像的时候不要只建一层。 大家都知道， 大家都知道，Docker 的文件系统是分层的，在建镜像的时候我们应该这么建，将操作系统单独建一层，作为基础镜像，然后用户名定义文件、运行时安装环境、配置文件都要分别建 一层镜像，最后才是应用镜像层。这么做的话，我们以后重建、管理以及发布镜像的时候就要轻省得多了。 5) 不要把本地运行的容器转成镜像。 换句话说就是创建镜像的时候不要用“ 换句话说就是创建镜像的时候不要用“docker commit”命令来创建。用这种办法建镜像是完全不可取的，因为这种办法是不能重复的。我们在建镜像的时候应该从 Dockerfile 创建， 或者用其他 S2I（从源文件构建镜像）的方式来创建，这样镜像才具有可再生性，而且如果我们把镜像存在 git 之类提供版本控制能的系统里的话，还可以对 Dockerfile 的改动进行跟踪。 6) 给镜像打 tag 的时候不要只打“latest”。 latest latest 其实就相当于 Maven 里头的“快照”。因为容器的文件系统是分层的，我们最好是给镜像多打几个 tag。如果