AWS 上基于 Docker 的 3 层 Java 应用程序的端到端自动化

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

亚马逊网络服务的地理分布和不断增长的云服务数量促使许多初创企业和企业将他们的应用程序托管在分布在不同地区的亚马逊实例上。然而,随着开发团队开始成长或企业开始新的开发项目,为快速成长的团队复制一致的 DEV/TEST 环境成为任何云基础架构上的难题。

DCHQ 简化了企业应用程序的容器化,并使得通过一键部署按钮在多台主机上复制非常复杂的应用程序环境成为可能。 DCHQ 不仅自动执行应用程序部署,而且还与 AWS 集成以自动配置和自动扩展由分布式 Amazon 实例组成的支持 Weave 的集群。

在这篇博客中,我们将介绍 AWS 上的自动化基础设施配置,以及部署在集群 Tomcat 服务器上的 3 层 Java 应用程序的自动化部署和生命周期管理,并分别使用 Nginx 和 MySQL 作为负载均衡器和数据库。

在 AWS 上自动配置和自动扩展集群

首先,用户可以通过导航到 Manage > Repo & Cloud Provider 然后单击 + 按钮选择 AWS 来为 AWS 注册 Cloud Provider。需要提供 AWS 访问密钥和秘密密钥——可以从 AWS 控制台的安全凭证部分检索它们。

然后,用户可以使用自动扩展策略创建一个支持 Weave 的集群,以自动启动新的 Amazon 实例。 Weave 集群中服务器之间的通信受密码保护——确保没有其他 Weave 集群能够与任何正在运行的容器建立通信。这可以通过导航到“管理”>“数据中心和集群”页面然后单击 + 按钮来完成。您可以选择基于容量的放置策略,然后将 Weave 作为网络层,以促进集群内多个主机之间的跨容器通信。此示例中的自动扩展策略将 VM(或 Amazon 实例)的最大数量设置为 10。

用户现在可以通过导航到“管理”>“裸机服务器和虚拟机”,然后单击“+”按钮选择 AWS,在新创建的集群上配置多个 Amazon 实例。选择云提供商后,用户可以选择区域、实例类型和映像。 DCHQ 已通过 Red Hat Enterprise Linux、CentOS 和 Ubuntu 认证——但用户应避免选择处于 beta 或 alpha 模式的映像。最近测试过的Ubuntu镜像是us-west-1/ami-1fc03e5b(或者ubuntu/images/ubuntu-trusty-14.04-amd64-server-20150812)。用户需要提供安全组名称(例如默认值)。安全组需要开启如下入端口:Docker为32000-59000,Weave为6783,RabbitMQ为5672。然后选择数据中心(或集群)并指定 Amazon 实例的数量。

建模和部署基于 Docker 的多层 Java 应用程序(Nginx、集群 Tomcat 和 MySQL)

提供 Amazon 实例后,用户可以在新的 Amazon 实例上部署基于 Docker 的多层应用程序。这可以通过导航到自助服务库然后单击自定义来请求多层应用程序来完成。

在此示例中,我们有一个多层应用程序,由 Nginx(用于负载平衡)、Tomcat(集群应用程序服务器)和 MySQL(作为数据库)组成。您会注意到 Nginx 正在调用 BASH 脚本插件以动态(或在请求时)在 default.conf 文件中添加应用程序服务器的容器 IP。 Tomcat 还调用 BASH 脚本插件从指定的 URL 部署 Java WAR 文件。您会注意到 cluster_size 参数允许您指定要启动的容器数量(具有相同的应用程序依赖性)。主机参数允许您指定要用于容器部署的主机。以下是主机参数支持的值:


  • host1、host2、host3 等——在数据中心(或集群)中随机选择一个主机进行容器部署
  • <IP Address 1, IP Address 2, etc.> -- 允许用户指定用于容器部署的实际 IP 地址
  • <Hostname 1, Hostname 2, etc.> -- 允许用户指定用于容器部署的实际主机名
  • 通配符(例如“db-*”或“app-srv-*”)——指定在主机名中使用的通配符

此外,用户可以通过引用另一个图像的环境变量来创建跨图像环境变量绑定。在这种情况下,我们做了几个绑定——包括 database.url=jdbc:mysql://{{MySQL|container_ip}}:3306/{{MySQL|MYSQL_DATABASE}} 其中数据库容器 IP 和名称是动态解析的在请求时,用于在应用程序服务器中配置数据库 URL。

以下是支持的环境变量列表:


  • {{alphanumeric | 8}} – 创建一个随机的 8 字符字母数字字符串。这对于创建随机密码最有用。
  • {{<Image Name> | ip}} – 允许您输入容器的主机 IP 地址作为环境变量的值。这对于允许中间件层与数据库建立连接最有用。
  • {{<Image Name> | container_ip}} – 允许您输入容器的内部 IP 作为环境变量的值。这对于允许中间件层与数据库建立安全连接(不暴露数据库端口)最为有用。
  • {{<Image Name> | port _<Port Number>}} – 允许您输入容器的端口号作为环境变量的值。这对于允许中间件层与数据库建立连接最有用。在这种情况下,指定的端口号需要是内部端口号——即不是分配给容器的外部端口。例如, {{PostgreSQL | port_5432}} 将被转换为允许中间件层与数据库建立连接的实际外部端口。
  • {{<Image Name> | <Environment Variable Name>}} – 允许您将图像环境变量的值输入到另一个图像的环境变量中。这里的用例是无穷无尽的——因为大多数多层应用程序都具有跨图像依赖性。

在单击运行之前,用户可以选择环境标签(如 DEV 或 QE)和为 AWS 创建的数据中心。

监控正在运行的容器的 CPU、内存和 I/O

一旦应用程序启动并运行,用户就可以监控正在运行的容器的 CPU、内存和 I/O 利用率,并执行第 2 天的操作,例如备份、使用 BASH 插件的容器更新、扩展/扩展和持续交付.

用户可以执行历史监控分析并将问题关联到容器更新或构建部署。这可以通过单击正在运行的应用程序的“操作”菜单,然后单击“监视”来完成。可以选择自定义日期范围来查看历史 CPU、内存和 I/O 利用率。

横向扩展 Tomcat 应用程序服务器集群

如果正在运行的应用程序变得资源受限,用户可以扩展应用程序以满足不断增加的负载。此外,用户可以安排在工作时间扩展,例如在周末安排扩展。

要将 Tomcat 服务器集群从 2 个扩展到 4 个,用户可以单击正在运行的应用程序的 Actions 菜单,然后选择 Scale Out。然后用户可以指定集群的新大小,然后单击立即运行。

然后我们使用 BASH 脚本插件更新 Nginx 的 default.conf 文件,以便它知道添加的新应用程序服务器。还可以安排 BASH 脚本插件以适应用例,例如以定义的频率清理日志或更新配置。应用程序时间线可用于跟踪对应用程序所做的每个更改以进行审核和诊断。

横向扩展完成后,用户可以执行 BASH 插件来更新 Nginx 的 default.conf 文件,以便它知道添加的新应用程序服务器。还可以安排 BASH 脚本插件以适应用例,例如以定义的频率清理日志或更新配置。

要在正在运行的容器上执行插件,用户可以单击正在运行的应用程序的操作菜单,然后选择插件。然后用户可以选择负载均衡器 (Nginx) 容器,搜索需要执行的插件,使用切换按钮启用容器重启。此插件的默认参数将动态解析所有正在运行的 Tomcat 服务器的容器 IP,并将它们添加为 default.conf 文件的一部分。


应用程序时间线可用于跟踪对应用程序所做的每个更改以进行审核和诊断。这可以从正在运行的应用程序页面底部的可扩展菜单中访问。

当容器或主机关闭或主机或容器的 CPU 和内存利用率超过定义的阈值时,警报和通知可用。


使用 Jenkins 启用持续交付工作流,以在触发构建时更新正在运行的应用程序的 WAR 文件

对于希望通过重建包含应用程序代码的 Docker 映像并在每次应用程序更新时启动新容器来遵循“不可变”容器模型的开发人员,DCHQ 提供了一个 自动构建 功能,允许开发人员从 Dockerfiles 或包含 Dockerfiles 的 GitHub 项目自动创建 Docker 映像.

但是,许多开发人员可能希望使用最新的 Java WAR 文件来更新正在运行的应用程序服务器容器。为此,DCHQ 允许开发人员使用 Jenkins 实现 持续交付 工作流。这可以通过单击正在运行的应用程序的 Actions 菜单然后选择 Continuous Delivery 来完成。用户可以选择一个已经在 DCHQ 注册的 Jenkins 实例,Jenkins 上将生成最新 WAR 文件的实际作业,然后选择一个 BASH 脚本插件来获取此构建并将其部署到正在运行的应用程序服务器上。保存此策略后,每当触发构建时,DCHQ 都会从 Jenkins 获取最新的 WAR 文件,并将其部署到正在运行的应用程序服务器上。

结论

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

DCHQ 提供托管和本地版本,解决了所有这些挑战,并通过先进的应用程序组合框架简化了企业 Java 应用程序的容器化,该框架促进了跨图像环境变量绑定,可扩展的 BASH 脚本插件可以在请求时间或后置备,以及应用程序集群,以实现跨多个主机或区域的高可用性,并支持自动缩放。

http://DCHQ.io 免费注册 以访问开箱即用的多层 Java 应用程序模板以及应用程序生命周期管理功能,如监控、容器更新、扩展/扩展和持续交付。