在前段时间实践了一把 docker,这里就记录以下 docker 使用体验,也算是对近期使用 docker 的一个总结.
docker 的使用场景
我想这应该是最重要的一个点了,虽然上篇文章已经说过 docker 的使用场景了,但是经过实践后对 docker 的使用有了新的认识.
我之前所理解的 docker 是运行一个服务,这个服务满足于某一个需求,具体如查询天气这样的一个网站,其中 docker 中还包含了这个程序所需的一切,比如运行这个程序的所有服务(运行环境、数据库等).
在使用 docker 之后,我发现 docker 的使用场景应该还可以提供一个更小的服务,比如上面所说的天气查询的服务,那么提供天气查询所需的一些基础服务完全可以由几个单独的 docker 容器提供.
以上是我对 docker 使用场景的一点思考,觉得对又觉得不对,我想这也是对 docker 使用不多的问题.事实上前端领域需要使用 docker 的场景并不多,如果没有需求硬上 docker 我认为是没有意义的.
对 docker 容器的一些操作
由于错误的使用 docker(其实也不算是全错),没有使用 docker build,使用 docker commit 进行更新镜像,产生了很多不必要的 none 镜像.既然产生了,就需要删除:
1 | docker rmi $(docker images -q -f dangling=true) |
以下是对容器操作的一些总结:
1 | // 杀死所有正在运行的容器 |
对 docker 使用的一些常见误区(基本算是转载)
不要在容器中存储数据
容器可能被停止，销毁，或替换。一个运行在容器中的程序版本 1.0，应该很容易被 1.1 的版本替换且不影响或损失数据。有鉴于此，如果你需要存储数据，请存在卷中，并且注意如果两个容器在同一个卷上写数据会导致崩溃。确保你的应用被设计成在共享数据存储上写入。
不要将你的应用发布两份
一些人将容器视为虚拟机。他们中的大多数倾向于认为他们应该在现有的运行容器里发布自己的应用。在开发阶段这样是对的，此时你需要不断地部署与调试；但对于质量保证与生产中的一个连续部署的管道，你的应用本该成为镜像的一部分。记住：容器应该保持不变。
不要创建超大镜像
一个超大镜像只会难以分发。确保你仅有运行你应用/进程的必需的文件和库。不要安装不必要的包或在创建中运行更新（yum 更新）。
不要使用单层镜像
要对分层文件系统有更合理的使用，始终为你的操作系统创建你自己的基础镜像层，另外一层为安全和用户定义，一层为库的安装，一层为配置，最后一层为应用。这将易于重建和管理一个镜像，也易于分发。
不要为运行中的容器创建镜像
换言之，不要使用“docker commit”命令来创建镜像。这种创建镜像的方法是不可重现的也不能版本化，应该彻底避免。始终使用 Dockerfile 或任何其他的可完全重现的 S2I（源至镜像）方法。
不要只使用“最新”标签
最新标签就像 Maven 用户的“快照”。标签是被鼓励使用的，尤其是当你有一个分层的文件系统。你总不希望当你 2 个月之后创建镜像时，惊讶地发现你的应用无法运行，因为最顶的分层被非向后兼容的新版本替换，或者创建缓存中有一个错误的“最新”版本。在生产中部署容器时应避免使用最新。
不要在单一容器中运行超过一个进程
容器能完美地运行单个进程（http 守护进程，应用服务器，数据库），但是如果你不止有一个进程，管理、获取日志、独立更新都会遇到麻烦。
不要在镜像中存储凭据。使用环境变量
不要将镜像中的任何用户名/密码写死。使用环境变量来从容器外部获取此信息。有一个不错的例子是 postgres 镜像。
使用非 root 用户运行进程
“docker 容器默认以 root 运行。（…）随着 docker 的成熟，更多的安全默认选项变得可用。现如今，请求 root 对于其他人是危险的，可能无法在所有环境中可用。你的镜像应该使用 USER 指令来指令容器的一个非 root 用户来运行。”（来自 Docker 镜像作者指南）
不要依赖 IP 地址
每个容器都有自己的内部 IP 地址，如果你启动并停止它地址可能会变化。如果你的应用或微服务需要与其他容器通讯，使用任何命名与（或者）环境变量来从一个容器传递合适信息到另一个。
参考文章:删除所有已经停止的容器
转载文字:使用 Docker 容器，这些错误千万别犯
[越努力，越幸运！]