提醒和经验教训，要避免的陷阱
Photo by Belinda Fewings on Unsplash
这是docker最佳做法指南，只有一个类似的指南，我会尽我所能
老实说，当我们大多数时间在docker上工作时，我很多人绝对不知道我们在做什么。 仅仅因为您启动了一个Docker容器并且您的应用程序正在运行并不意味着您已经实现了一个好的解决方案—有时由于时间限制，我们陷入了复制粘贴docker镜像的陷阱，而没有真正理解底层的实现细节和细微差别 图像的构建方式。
在本篇文章中，我们将研究Docker反模式，也称为对重复出现的问题的常见反应，通常会导致我们实施无效和适得其反的解决方案，从而破坏我们的Docker堆栈。 我们来看看一些我们可能做错的事情。
我们需要那些标签
使用Docker镜像时，必须添加标签，因为它可以传达有关镜像的有用信息。 将标签视为您的Docker镜像ID的别名。 可以将标签与引用您历史记录中特定提交的Git标签进行比较。 因此，您可以在不同的时间点对Docker镜像进行版本控制。 忘记标记是一件微不足道的事情，它会带来一些反冲。 也就是说，如果未指定标签，则默认镜像将使用最新示例your_image_name：latest进行标注。
如果您经常进行此操作，则您的镜像可能实际上不是最新的，而是可能指向了较旧的版本。 始终确保使用适当的标签并遵守版本控制架构，例如语义版本控制。 这确保Docker镜像的用户可以保证兼容性并保持更新，并以可预测的方式利用正确的版本。
您可能要避免使用最新默认标签的另一件事是，例如在Dockfile中使用FROM python3：latest从Docker注册表中提取最新镜像。 乍一看，这似乎是个好主意，但一些意外的副作用是，每个最新的请求可能会衍生出与先前构建不同的整个docker镜像。 尝试破译破坏您的Docker镜像的内容可能很困难，因为从您的角度出发，您期望不可变。 因此，强烈建议为镜像使用特定标签（例如：python3：1.0.1）—这将确保您的Dockerfile保持不变。
在同一个容器中运行多个服务
是的，无论如何，您可以做到这一点-可能成功了，但这是您可能不想走这条路的两个原因。 当我们使用docker服务时，我们应该努力实现单一责任。 公认的最佳做法是，组成您的应用程序的每个不同服务都应在其自己的容器中运行-尝试将每项独立功能打包到单独的独立容器镜像中。
试图将多个服务添加到一个docker镜像中是很诱人的，将容器镜像视为虚拟机的想法也应该从人们的想法中删除。
一个容器中有多个服务，因此很难水平扩展您的应用程序。 Docker容器的核心概念是它们是瞬态的并且是为分发而设计的，这对于现代Web应用程序是理想的，瞬态特性简化了扩展和并发性，添加多个服务增加了管理此分发的难度。
此外，在单个容器上的多种服务使管理安全性变得更加困难且镜像大小过大，如果您担心的话，这可能会降低CI / CD的速度。 Docker文档在进一步详细说明方面做得很好。
使用标签对镜像进行分类
这绝不是反模式，但我认为这值得一提。 我在使用各种docker镜像时注意到的一件事是，有时这些镜像的创建者没有LABEL维护者标签。 如果发生错误或需要澄清时，此标记可在事件中设置图像的"作者"字段，如果图像是公开共享的，则更容易知道内部或外部与谁联系。 这绝不是您可以使用的唯一标签。 您可以根据需要定义各种标签，以对镜像进行分类，记录许可信息或对自动化有用的标签。
除维护者以外的多行标签
# Set one or more individual labels
LABEL com.example.version="0.0.1-beta"
LABEL vendor1="ACME Incorporated"
LABEL vendor2=ZENITH\ Incorporated
LABEL com.example.release-date="2021-02-12"
LABEL com.example.version.is-production=""
在docker 1.10之前的单行标签会创建新的docker层，因此，如果您使用最新的docker版本，则不必担心开销层。
LABEL vendor=ACME\ Incorporated \
com.example.i
