网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

日志索引：日志对于诊断错误至关重要，尤其在容器退出，文件系统消失后显得更为重要。我们特意避免了修改应用程序的日志行为（比如强制它们重新定向到系统日志），并且允许它们继续写日志到文件系统。运行100个日志代理似乎是错误的做法，所以我们创建一个后台程序去处理以下重要任务：

运行在host端，并订阅Docker event；

在容器启动时，配置日志索引来监视容器；

容器销毁时，删除索引指令。

为了确保容器退出时，所有的日志都被编入索引，你可能需要稍微延迟容器的销毁。

统计：Shopify在几个级别（系统，中间件和应用程序）上都生成了运行时统计，得到的结果通过代理或应用程序代码转述。

许多我们的统计结果可以通过StasD传输，幸运的是我们可以配置Datadog的host端去接收容器传来的流量，通过适当的配置，就可以将StasD接收的地址传给容器；

由于容器从本质上来说就是进程树，所以一个host端的系统监控代理可以看到容器边界共享一个单一的系统监控也是自由的；

从一个更加以容器为中心的角度出发，来考虑Docker和Datadog的集成，会添加Docker metrics到host端的监控代理；

应用级别的metrics大多数运行得还可以，它们或者通过StasD发送事件，或者直接和其它服务对话。为一个容器指定名字很重要，这样一来metrics也更容易读。

Kafka：我们使用Kafka来实时处理从Shopify堆栈到合作伙伴的事件。我们使用Ruby on Rail代码来发布Kafka事件，生成信息，然后放到SysV消息队列。一个Go语言写的后台程序会在队列中取出消息发送给Kafka。这减少了Ruby进程的时间，我们也能更好地应对Kafka服务器的事故。有一点不好的是，SysV消息队列是IPC namespace的一部分，所以我们不能用来连接container:host。我们的解决方案是在host上添加一个socket端，用来将消息放到SysV队列。

100定律的使用需要一定的灵活性。一些情况下，仅仅需要写一下组件的“黏合器”，也可以通过配置来达到目的。最终，你应该获得一个容器，内含你的应用程序运行所需的东西，以及一个提供了Docker托管和共享服务的主机环境。

随着环境的就绪，我们可以把注意力转到程序的容器化上来。

我们更倾向于thin container能准确地做一件事。例如一个unicorn（Unicorn是一个Unix和局域网/本地主机优化的HTTP服务器）master和工作线程服务web请求，或者一个Resque（Resque使用Redis创建后台任务，存储进队列，并随后执行。它是Rails下最常用的后台任务管理工具之一）工作线程服务一个特定的队列。thin container允许细粒度的缩放比例（一般是指远程方法调用的接口的颗粒大小），以满足需求。例如，我们可以增加检查垃圾邮件攻击响应的 Resque工作线程的数目。

我们发现采取一些标准约定对于在容器中的代码布局会有用处：

应用程序总是root在容器内部的/app下；

应用程序通常通过单个端口发布服务；

我们还确立了一些容器化git repo（repo封装了对git的操作）的约定：

/container/files 拥有一个在其建立时就被直接复制进容器的文件树，举个例子，请求 Splunk 索引的应用程序日志，它添加/container/files/etc/splunk.d/inputs.conf 文件进你的git repo就足够了（控制日志索引的责任转移到开发者，这是一个微妙而重大的转变，过去这都是运维管理员的工作）；

/container/compile是一个 shell 脚本，编译您的应用程序，并生成一个随时可运行的容器。建立此文件并适应您的应用程序，是最复杂的地方；

/container/roles.json保存命令行以机器可读的形式用来运行该工作负载。很多我们的应用程序以多个角色，运行相同代码库，一些处理 web 流量同时处理后台任务。这部分的灵感来自 Heroku 的 procfile。以下是一个示例的roles.json文件：

我们用一个简单的Makefile驱动建立，也可以本地运行。我们的 Dockerfile 看起来像这样：取消编译阶段的目标是产生一个是即刻准备运行的容器。Docker关键的优势之一就是在容器启动时超级快速启动而不被损坏因为额外的工作。为了实现这一目标您需要了解您的整个部署过程。 举几个例子：