如果您想在 openshift 上使用多模块 Maven 项目,那么您必须告诉 openshift 如何构建它们。您可以通过定义构建环境变量或编写可由 Openshift 解释的自定义构建脚本来完成此任务。
对于这两种方法,您都可以遵循this https://blog.openshift.com/maven-multi-module-projects-and-openshift/教程:
如果您想使用第一种方法,您可以通过为构建配置定义“MAVEN_ARGS_APPEND”变量来告诉 openshift 在构建过程时使用其他 Maven 命令。
因此,当构建操作在 openshift 上开始时,它会告诉 Maven 使用这些附加参数构建应用程序。
定义下面列出的其他构建环境变量以独立部署 war 模块:
MAVEN_ARGS_APPEND:-pl 模块名称 --also-make
ARTIFACT_DIR:模块名称/目标/
MODULE_DIR:模块名称
在这里,“-pl”命令提供了构建“xyz-data-services”及其所有依赖项的功能。因此,如果您的“xyz-data-services”模块依赖于“xyz-common”,那么maven将构建“xyz-common”,为“xyz-data-services”创建相关工件,将它们打包在一起并部署“xyz-数据服务”作为 Pod 上的战争。
在您的情况下,假设您想要将“xyz-data-services”模块和“xyz-front-end”模块打包为 war 并部署它们。
Case 1:
如果您想让这些模块可自行部署,那么您必须创建两个将在不同 Pod 上运行的应用程序。
第一个应用程序将具有以下构建环境变量:
MAVEN_ARGS_APPEND: -pl xyz-data-services --also-make
ARTIFACT_DIR: xyz-data-services/target/
MODULE_DIR: xyz-data-services
第二个将有这些人:
MAVEN_ARGS_APPEND: -pl xyz-front-end --also-make
ARTIFACT_DIR: xyz-front-end/target/
MODULE_DIR: xyz-front-end
Case 2:
如果您想将这些模块部署到同一个 pod 中,那么您可以向项目中添加一个附加模块,将两个 war 打包到单个 Ear 中并定义该 Ear 的变量。
所以让这个耳朵是“webapp”,你的父pom看起来像这样;
...
<modules>
<module>xyz-common</module>
<module>xyz-data-services</module>
<module>xyz-batch-importer</module>
<module>xyz-frontend</module>
<module>xyz-webapp</module>
</modules>
...
xyz-webapp pom 看起来像;
....
<artifactId>xyz-webapp-</artifactId>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-common</artifactId>
<version>${project.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-data-services</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>xyz-frontend</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
....
所以你的构建环境变量将是;
MAVEN_ARGS_APPEND: -pl xyz-webapp --also-make
ARTIFACT_DIR: xyz-webapp/target/
MODULE_DIR: xyz-webapp
如果您只想使用单个战争和单个 Pod,那么;
Case 3:
您可以将前端应用程序打包为 war 并声明对其他模块的依赖关系,这些模块都打包为“.jars”
您可以继续选择您想要的案例。这里重要的是,它取决于您的“微服务”实现。由于“微服务”术语和实现没有明确定义,并且可能会因架构或某些业务需求而异,因此您可以决定将前端、API、后端打包在一起还是独立管理它们。