Docker Java应用程序部署– 4个应用程序堆栈：Tomcat，GlassFish，Jetty和JBoss

在http://DCHQ.io上免费注册以访问现成的多层Java应用程序模板（包括Tomcat，JBoss，GlassFish和Jetty上的Movie Store应用程序）以及应用程序生命周期管理功能（如监视），容器更新，放大/缩小和连续交付。

背景

Java开发人员和DevOps专业人员长期以来一直在努力实现企业Java应用程序的自动化部署。

这些应用程序的复杂性通常意味着，每次在DEV / TEST环境中部署应用程序时，都必须重新配置应用程序依赖性和外部集成。

许多解决方案宣传“一次建模，随处部署”消息，以进行应用程序部署。但是，实际上，总会有一些复杂性，例如，很难在本地vSphere虚拟环境和AWS环境中重用应用程序模板。

但是，最近，Docker容器普及了将应用程序组件打包到Linux容器中的想法，只要安装了Docker Engine，它们就可以在所有Linux主机上完全相同地部署。

不幸的是，对企业Java应用程序进行容器化仍然是一个挑战，主要是因为现有的应用程序组合框架无法解决复杂的依赖关系，外部集成或置备后的自动扩展工作流。此外，容器的短暂设计意味着开发人员必须启动新的容器并在每次版本更新时重新创建复杂的依赖关系和外部集成。

DCHQ具有托管和内部部署版本，可解决所有这些挑战，并通过高级应用程序组合框架简化了企业Java应用程序的容器化，该框架通过跨映像环境变量绑定，可扩展的BASH脚本插件扩展了Docker Compose。可以在请求时间或后置资源时调用，并通过应用程序群集在多个主机或区域上实现高可用性，并支持自动扩展。

设置应用程序后，用户可以监视正在运行的容器的CPU，内存和I / O，获取通知和警报，并执行第二天的操作，例如预定备份，使用BASH脚本插件和Scale的容器更新。进出。此外，借助Jenkins促进连续交付的即用型工作流使开发人员可以刷新正在运行的应用程序的Java WAR文件，而不会破坏现有的依赖关系和集成。

在此博客中，我们将介绍名为Movie Store的Java应用程序的端到端自动化，该Java应用程序部署在四个不同的容器化应用程序堆栈上：

Nginx（用于负载平衡），群集的Tomcat和MongoDB（作为数据库）
Nginx（用于负载平衡），集群JBoss和MongoDB（作为数据库）
Nginx（用于负载平衡），集群Jetty和MongoDB（作为数据库）
Nginx（用于负载平衡），集群化的GlassFish和MongoDB（作为数据库）

相同的Java WAR文件将部署在四个不同的应用程序服务器上。 DCHQ不仅可以自动执行应用程序部署，而且还可以与12种不同的云集成，以使用软件定义的网络自动执行群集的配置和自动扩展。我们将介绍：

构建可在任何地方运行的任何Linux主机上重复使用的应用程序模板
在任何云上配置和自动扩展基础架构（本博客中以Rackspace为例）
在Rackspace集群上部署基于Java的多层Movie Store应用程序
监视正在运行的容器的CPU，内存和I / O
触发构建后，使用Jenkins启用持续交付工作流来更新正在运行的应用程序的WAR文件
扩展Application Server群集以进行可扩展性测试

在Tomcat，JBoss，Jetty和GlassFish上为基于Java的电影商店应用程序构建应用程序模板

登录到DCHQ（托管的DCHQ.io或内部部署版本）后，用户可以导航到<strong“ mso-bidi-font-weight：=”” normal” =””>管理> 模板，然后单击在+按钮上创建一个新的Docker Compose模板。

我们使用来自Docker Hub的官方映像为同一个Movie Store应用程序创建了四个应用程序模板，但为四个不同的应用程序服务器创建了四个。

3层MovieStore（Nginx – Tomcat – Mongo）
3层MovieStore（Nginx – JBoss- Mongo）
3层MovieStore（Nginx –码头– Mongo）
3层MovieStore（Nginx – GlassFish – Mongo）

在所有四个模板中，您会注意到Nginx正在调用BASH脚本插件来动态（或在请求时）将应用程序服务器的容器IP添加到default.conf文件中。

应用程序服务器（Tomcat，JBoss，Jetty和GlassFish）也正在调用BASH脚本插件，以从外部URL部署Movie Store Java WAR文件。Tomcat，JBoss和Jetty正在调用完全相同的插件-除了WAR。文件正在部署在不同的目录中：

Tomcat –目录= / usr / local / tomcat / webapps / ROOT.war
JBoss –目录= / opt / jboss / wildfly / standalone / deployments / ROOT.war
码头– dir = / var / lib / jetty / webapps / ROOT.war

GlassFish正在调用另一个插件，该插件使用asadmin命令在默认服务器上部署该应用程序。

您会注意到， cluster_size参数使您可以指定要启动的容器数（具有相同的应用程序依赖性）。

host参数允许您指定要用于容器部署的主机。这样，您可以确保跨不同主机（或区域）的应用程序服务器群集的高可用性，并且可以遵守关联性规则以确保数据库在例如单独的主机上运行。以下是host参数支持的值：

host1，host2，host3等–在数据中心（或集群）中随机选择一个主机进行容器部署
<IP地址1，IP地址2等> -允许用户指定用于容器部署的实际IP地址
<主机名1，主机名2等> -允许用户指定用于容器部署的实际主机名
通配符（例如“ db- *”或“ app-srv- *”）–指定要在主机名中使用的通配符

此外，用户可以通过引用另一个图像的环境变量来创建跨图像环境变量绑定。在这种情况下，我们进行了几个绑定-包括mongo.host = {{MongoDB | container_ip}}-在绑定中，数据库容器IP在请求时被动态解析，并用于确保应用程序服务器可以与数据库服务器建立连接。数据库。

以下是受支持的环境变量值的列表：

{{字母数字| 8}} –创建一个随机的8个字符的字母数字字符串。这对于创建随机密码最有用。
{{<图像名称> | ip}} –允许您输入容器的主机IP地址作为环境变量的值。这对于允许中间件层与数据库建立连接最有用。
{{<图像名称> | container_ip}} –允许您输入容器的内部IP作为环境变量的值。这对于允许中间件层与数据库建立安全连接（不暴露数据库端口）最有用。
{{<图像名称> | port _ <端口号>}} –允许您输入容器的端口号作为环境变量的值。这对于允许中间件层与数据库建立连接最有用。在这种情况下，指定的端口号必须是内部端口号，即不是分配给容器的外部端口。例如，{{PostgreSQL | port_5432}}将转换为实际的外部端口，该端口将允许中间件层与数据库建立连接。
{{<图像名称> | <环境变量名称>}} –允许您将一个图像的环境变量的值输入到另一个图像的环境变量中。这里的用例是无止境的-因为大多数多层应用程序将具有跨映像依赖关系。