使用Docker，Chef和Amazon OpsWorks进行集群范围的Java / Scala应用程序部署

Docker非常适合在单个节点上运行隔离的容器。但是，大多数软件系统都在多个节点上运行，因此，除了Docker之外，我们还需要某种方法来指定哪些容器应在哪些节点上运行。

MQPerf-deployment-blog-logos-1-300x216

我要解决的特定问题如下：我有两个Scala守护程序，我想在多个节点上运行（取决于配置，每个节点可以运行一个或两个守护程序）。我想要一种在集群中部署修改后的二进制文件的快速方法。我也不想花费太多时间来设置服务器。（我的Gentoo日子已经过去了。）

我到达的最终解决方案涉及Docker ， OpsWorks ， Chef和Vagrant 。但是，一步一步来。

顺便说一句-您将如何解决上述问题？请评论。

打包Java / Scala应用程序

首先，我需要能够打包和上传二进制文件。在这里，Docker非常完美。我编写了一个简单的Dockerfile ，其中：

基于受信任的ubuntu + java7映像–无需在服务器上安装Java！
将胖子从我的磁盘复制到映像
指定使用复制的jar运行Java的入口点

完整的Dockerfile可以在这里找到： https ://gist.github.com/adamw/166b82ec04c9c0f67453。

有了这样的映像，我可以将其推送到（公共或私有） Docker注册表中，群集中的节点可以将其下载。

如果需要，我还可以安装我的应用程序需要的任何其他操作系统级别的依赖项，而不必担心版本冲突并在实际服务器上进行设置。

如果看一下Dockerfile，您可能会注意到有两个jar。这样做是为了最小化每次代码更改后必须上传的Docker映像的大小。第一个jar仅包含依赖项（Scala库，日志记录库，框架等）。第二个jar包含已编译的应用程序代码。从Dockerfile构建Docker映像时，将创建一系列中间映像，每个步骤之后一个。对于涉及相同文件的相同命令，不会创建新映像，但会从Docker缓存中重新使用映像。

依赖关系很少更改，因此通常dep-jar保持不变，因此缓存的版本会被重用（并且中间映像会上传一次）。另一方面，应用程序代码始终会更改。重要的是，首先将依赖项jar添加到映像，以便中间映像包含deps，但不包含应用程序代码（更改后的代码）。最后，通常只需要上传2-3MB。

不过，这里要注意一件事。在确定是否可以在ADD命令（该命令将文件从本地磁盘复制到该映像）之后重新使用该映像时，Docker仅检查该文件的最后修改时间戳。这将导致依赖项fat-jar在每次重新构建时都被重新添加，即使它们是相同的。因此，我创建了一个简单的bash脚本，仅当其md5校验和发生更改时，该脚本才会复制dockerfile旁边的fat-jar（作为Docker上下文的一部分从该文件上传）： https : //gist.github.com/adamw/ ba5d8b79ff553fba83fd 。

如何用SBT创建这样两个单独的jar？非常简单。只需使用SBT Assembly插件并更改其设置即可：

assemblyOption in assembly ~= { _.copy(includeBin = true, includeScala = false, includeDependency = false) }

然后， assemblyPackageDependency目标将创建仅依赖项的jar，而assembly将创建仅应用程序的jar。

设置服务器

随着包含我们应用程序的Docker映像在云中（在Docker集线器上）等待，现在是时候设置服务器了，Docker守护程序将在其中运行容器。

为了配置服务器，我选择了Amazon OpsWorks的Chef，这有两个原因：可以使用Stacks和Layers清楚地分离和组织EC2实例，这些服务器与Chef具有现成的集成，并且使用自定义厨师食谱非常容易。完全不需要手动实例设置！

以下步骤部分是摘要，部分是ShopIgniter博客上描述的内容的扩展。

Chef安装程序（由OpsWorks运行）将是最少的，并且仅包含运行Docker所需的内容。

首先，我们需要创建一个具有更新内核的基于Ubuntu 12.04的AMI（14.04尚不能与OpsWorks配合使用）–有关详细信息，请参阅ShopIgniter的博客。

其次，我们将使用自定义的厨师食谱；为此，您需要创建一个专用的存储库（例如在GitHub上）。食谱非常基本和简单： https : //gist.github.com/adamw/792f8c22abb09699b6d5 。

总结一下：

docker::setup安装Docker
docker::kill_containers杀死并删除所有正在运行的容器
docker::myapp从Docker注册表中提取myapp映像并运行一个容器，该容器具有例如Chef-JSON配置文件的每个应用程序部分中指定的命令行参数和环境变量（此处我们的应用程序使用单个命令-line参数，并且需要环境中的AWS凭证）：

{"myapp": {"image": "adamw/myapp:latest","cmdline": [ "com.softwaremill.myapp.Main", "10" ],"env": {"AWS_ACCESS_KEY_ID": “...","AWS_SECRET_ACCESS_KEY": “..."}}
}

配置OpsWorks

要配置OpsWorks，我们需要使用自定义Chef食谱和自定义配置JSON创建一个Stack，例如上面的示例（对于要运行的每个应用程序/容器类型，我们需要在配置JSON中有一个部分）。其次，对于我们要部署的每个应用程序（容器），我们需要创建一个图层。由于这些层将仅运行Docker，因此我们不使用任何预先配置的层，而使用“自定义”层。

该层将包含我们的自定义配方：在Setup阶段，我们需要使用docker::setup配方，在Deploy阶段，我们需要使用docker::kill_containers和docker::kill_containers docker::myapp配方。

现在，每次在该层上运行Deploy阶段时，Docker都会提取映像并运行指定的容器！通过创建具有适当配方的图层，我们可以在任何节点上启动容器的任何组合。

opsworks1-300x233

运行部署阶段

要一次单击即可实际运行“ Deploy阶段，我们需要创建一个虚拟的OpsWorks应用程序：只需选择“类型：其他”和“存储库类型：其他”。现在，每次要在服务器上部署应用程序（运行更新的Docker容器）时，只需将此虚拟应用程序部署在所需的实例或层上即可。

这也可以通过API调用来完成（就像AWS上的一切一样）！因此，构建应用程序，创建Docker映像，推送该映像以及在OpsWorks上运行部署的整个过程可以非常容易地实现自动化-例如在成功构建之后。

一切就绪后，我们现在可以将新实例添加到图层，启动和停止它们，并让多节点集群运行我们的应用程序！要更新应用程序，只需将二进制文件推送到注册表即可。

在本地测试厨师

虽然Chef的食谱非常少，但仍然可以在本地对其进行测试仍然很有用。使用Vagrant可以轻松实现。使用Vagrant，我们可以轻松地创建安装了Chef的VM，该VM可以运行我们的配方，从而可以运行Docker容器。此特定情况的Vagrantfile在这里： https ://gist.github.com/adamw/bf6fa803b6b13fd7430b。

Vagrantfile包含对我们正在开发的Chef食谱的引用（通过chef.cookbooks_path ），并且具有与我们在OpsWorks中使用的相同的配置JSON。

发布vagrant up ，我们将运行虚拟机。更改食谱或上载新容器后，我们可以通过使用vagrant provision --provision-with chef_solo轻松地重新运行Chef食谱。