容器技术反例：哪些不适合利用Docker实现？

51CTO.com快译】 此篇文章，将为大家详细介绍那些不适合利用Docker实现的技术。

一）容器中的数据或者日志

容器适合处理无状态且仅需要短期运行的应用。这意味着我们不应将数据或者日志存储在容器内——否则其会在容器终止时一并消失。相反，利用分卷映射将其持久存储于容器之外。ELK堆栈可用于存储及处理日志。如果所管理分卷曾在测试流程中使用，那么请在dockerrm命令中添加-v将其移除。

二）容器IP地址

每套容器都拥有自己的IP地址。多套容器彼此通信以创建同一应用，例如部署在应用服务器上的应用即需要与数据库对话。在运行过程中，会不断有旧容器关闭，新容器开启。依靠容器IP地址意味着我们需要不断更新应用配置方能保持这种通信能力。相反，我们应当为其创建专门的服务，用于容纳动态变化的容器引用逻辑名称，并借此实现基本的负载均衡功能。

三）容器中运行单一进程

每个Dockerfile都会使用一个CMD与ENTRYPOINT。通常来讲，CMD会利用脚本以执行部分镜像配置，而后启动该容器。不要尝试在该脚本中使用多个进程。大家应当在创建Docker镜像时遵循分离原则的方针，否则会令容器在管理、日志收集以及更新方面遭遇更多难题。大家可以考虑将应用拆分成多套容器，并对其进行逐一管理。

四）不要使用docker exec

docker exec命令会在运行中的容器内开始一条新命令。其适用于利用docker exec -it {cid} bash实现shell附加。然而除此之外，容器本身应该已经运行有该进程。

五）保持镜像精简

创建一个新目录，并将Dockerfile及其它相关文件保存在其中。另外，考虑使用.dockeringore以移除任何日志、源代码等，而后再进行镜像创建。确保移除一切已经被解压的下载软件包。

六）利用运行中的容器创建镜像

应使用docker commit命令创建新镜像。这种方式适用于容器已经发生改变的情况。不过由此创建的镜像不可重现。相反，我们应在Dockerfile中进行修改，终止现有容器，并利用更新后的镜像启动新容器。

七）Docker镜像中的安全凭证

不要将安全凭证存储在Dockerfile当中。其将以明文形式存在并被检入存储库内，这将引发潜在的安全威胁。使用-e将密码指定为环境变更。而后，可利用--env-file读取文件中的环境变量。另一种方案是利用CMD或者ENTRYPOINT指定一套脚本。该脚本负责将凭证由第三方处提取出来并用于配置应用。

八）latest标签

很多朋友可能习惯利用couchbase启动镜像。如果未指定标签，那么容器会默认使用couchbase:latest镜像。此镜像可能并非最新，而是引用某个陈旧版本。需要强调的是，将应用引入生产流程要求配合一套采用特定镜像版本的完全受控环境。确保始终使用正确的标签以运行容器——例如使用couchbase:enterprise-4.5.1而非couchbase。

九）镜像不匹配

不要在开发、测试、分段以及生产环境内使用不同的图像或者标签。作为“选定来源”的镜像应仅创建一次，并被推送至存储库内。该镜像应被用于各类不同环境。在某些情况下，大家可以考虑在WAR文件上运行单元测试，而后再创建镜像。不过请注意，任何系统集成测试都应当在生产环境实际使用的镜像中完成。

十）发布端口

不要利用-P以发布全部公开端口，因为如此一来大家将能够运行多套容器并发布其公开端口。这样做亦意味着全部端口都将公开发布。相反，请使用-p以发布特定端口。

【云原生 | 27】Docker部署运行开源消息队列实现RabbitMQ AMQP架构中有两个主要组件：Exchange和Queue，两者都在服务端，又称Broker，由RabbitMQ实现的。客户端通常有Producer和Consumer两种类型
Jenkins + Docker + Github 实现自动化部署 Maven 项目 Jenkins搭配Docker结合Github实现自动化部署Maven项目，部署前端项目其实也类似如此，部署前端的文章也已经在规划中啦~ 本文更加偏向于实操，阅读完的收获 1、清楚怎么使用Docker安装 Jenkins 2、明白如何利用Jenkins部署一个Maven项目 3、知晓Jenkins如何结合Github实现自动化部署