很多人最终还是决定使用 Docker 解决问题。 Docker 的优点很多,比如:
1、一体化——将操作系统、库版本、配置文件、应用程序等全部打包装在容器里。从而保证 QA 所测试的镜像 (image) 会携带同样的行为到达生产环境。
2、轻量——内存占用极小,只为主要过程分配内存。
3、快读——一键启动,就像启动常见的 linux 过程一样快。
原文:https://my.oschina.net/cllgee...
尽管如此,众多用户仍然只是把容器当做常见的虚拟机,而忘记了容器的一个重要特性:
正因为这一特点,一些用户需要改变他们对容器的观念,为了更好的使用与发挥 Docker 容器的价值,有一些事情是绝对不应该做的:
1.不要在容器(container)中存储数据
容器可能会被中断、被替换或遭到破坏。在容器中运行的 1.0 版应用程序很容易就会被 1.1 版取代,而不会对数据造成影响或导致数据丢失。因此,如果需要存储数据,请存储在卷 (volume) 中。在这一情况下,还应注意两个容器是否会在同一个卷上写入数据,这将导致损坏。请确保应用程序适用于写入共享的数据存储。
2. 不要分两部分传送应用程序 有些人把容器当作虚拟机
所以他们大多会认为,应该将应用程序部署到现有正在运行的容器中。在需要不断部署和调试的开发阶段,可能确实如此;但对于 QA 和生产的持续交付 (CD) 渠道,应用程序应当是镜像的一部分。切记:容器转瞬即逝。
3. 不要创建大尺寸镜像
大尺寸的镜像难以分配。请确保仅使用必需文件和库来运行应用程序。不要安装不必要的数据包,也不要运行“更新”(yum update),这些操作会把大量文件下载到新的镜像层。
4. 不要使用单层镜像
为了有效利用多层文件系统,请始终为操作系统创建属于自己的基本镜像层,然后为用户名定义创建一个层,为运行时安装创建一个层,为配置创建一个层,最后再为应用程序创建一个层。这样,重新创建、管理和分配镜像就会容易些。
5. 不要从正在运行的容器中创建镜像
换句话说,不要使用"docker commit"命令来创建镜像。这一镜像创建方法不可复制,因此应完全避免使用。请始终使用 Dockerfile 或其他任何可完全复制的 S21(从源代码到镜像)方法,如此一来,如果存储在源代码控制存储库 (GIT) 中,就可以跟踪 Dockerfile 的变更情况。
6. 不要只使用“最新版”标签
最新版标签就像 Maven 用户的“快照”(SNAPSHOT) 一样。容器具有多层文件系统这一基本特征,所以我们鼓励使用标签。相信谁也不愿意在构建了几个月的镜像后,突然发现应用程序因为父层(即 Dockerfile 中的 FROM)被新版本取代而无法运行(新版本无法向后兼容或从构建缓存中检索的“最新“版有误)这样的意外吧?在生产过程中部署容器时也应避免使用”最新版“标签,这是因为无法跟踪当前运行的镜像版本。
7. 不要在单个容器中运行一个以上进程
容器只运行一个进程(HTTP 守护进程、应用程序服务器、数据库)时效果最佳,但如果运行一个以上进程,在管理和检索日志以及单独更新进程时就会遇到很多麻烦。
8. 不要在镜像中存储证书及使用环境变量
不要在镜像中对任何用户名/密码进行硬编码操作。请使用环境变量从容器外部检索信息。Postgres 镜像就是这一原理的极佳诠释。
9. 不要以 root 权限运行进程
“默认情况下,Docker 容器以 root 用户权限运行。随着 Docker 技术日趋成熟,能够使用的安全默认选项越来越多。目前,要求 root 对其他用户来说较为危险,另外,不是所有环境都能够使用 root。镜像应使用 USER 指令来为容器的运行指定非 root 用户。”(摘自《Docker 镜像作者指南》(Guidance for Docker Image Authors))
10. 不要依赖 IP 地址
每个容器都有自己的内部 IP 地址,如果启动然后停止容器,内部 IP 地址可能会发生变化。如果你的应用程序或微服务需要和另一个容器进行通信,请使用环境变量在容器之间传递相应的主机名和端口。
11. 监控容器 Docker
监控已经越来越受到开发者们的重视,实时监控 Docker 的方法,这里推荐 Cloudinsight。 不同于一些需要自写脚本的监控手段,Cloudinsight 作为一家免费的 SaaS 服务,能够一键监控 Docker,且拥有很棒的可视化界面。除此之外,Cloudinsight 还支持多种操作系统、数据库等的监控,能够一体化展示所有被监控的系统基础组件的性能数据。
再送你一份Docker学习资料大全:
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。