openshift
嗨，大家好！ 在这篇博客文章中，我想举一个简单的示例，展示使用Openshift 3（Docker和Kubernetes）扩展我们的Drools Stateless服务有多么容易。 我将展示如何通过按需提供新实例来扩展我们的服务，以及如何使用循环策略通过Kubernetes平衡这些实例的负载。
我们的Drools无状态服务
首先，我们需要一个无状态的Kie Session进行游戏。 在这些简单的示例中，我创建了一个食品推荐服务，以演示您可以使用这种方法建立什么样的情景。 所有源代码都可以在github上托管的Drools Workshop存储库中找到： https : //github.com/Salaboy/drools-workshop/tree/master/drools-openshift-example
在这个项目中，您将找到4个模块：
- drools-food-model：我们的业务模型，包括领域类，例如成分，三明治，沙拉等
- drools-food-kjar：我们的业务知识，在这里，我们有一组规则来描述如何完成食品推荐。
- drools-food-services：使用Wildfly群，我将展示封装规则引擎的特定于域的服务。 这里提供了一组休息服务，以便我们的客户可以进行交互。
- drools-controller：通过使用Kubernetes Java API，我们可以根据需要向Openshift环境以编程方式提供我们的食品推荐服务的新实例。
我们的工作单位将是Drools-Food-Services项目，该项目公开REST端点与我们的无状态会话进行交互。
您可以看一下非常简单的服务端点： https : //github.com/Salaboy/drools-workshop/blob/master/drools-openshift-example/drools-food-services/src/main/java/ org / drools / workshop / food / endpoint / api / FoodRecommendationService.java
还要注意，还有另一个服务可以为我们提供有关服务运行位置的基本信息： https : //github.com/Salaboy/drools-workshop/blob/master/drools-openshift-example/drools-food-services/ src / main / java / org / drools / workshop / food / endpoint / api / NodeStatsService.java
稍后，我们将调用此服务以确切知道该服务的哪个实例正在答复我们的客户。
该示例的规则很简单，并且操作不多，如果您想学习Drools，我建议您创建更多有意义的完整规则并与我分享，以便我们改进示例;）您可以看一下这些规则此处： https : //github.com/Salaboy/drools-workshop/blob/master/drools-openshift-example/drools-food-kjar/src/main/resources/rules.drl
如您所料：男孩三明治和女孩沙拉:)
您需要了解的关于我们服务的最后一件重要的事情是服务端点如何挑选规则。 我正在使用Drools CDI扩展名@Inject一个KieContainer，该问题使用KIE-CI模块来解决，这在我以前的文章中已有解释。
我们将把这个项目捆绑到一个Docker Image中，该镜像可以根据需要/启动多次。 如果您已经安装在您的本地环境中的码头工人客户端，您可以通过观察它在举办的salaboy / Drools的食品服务形象开始这种食物推荐服务hub.docker.com/salaboy
通过启动Docker映像甚至不知道内部正在运行什么，我们立即注意到以下优点：
- 除了Docker外，我们不需要安装Java或任何其他工具
- 我们无需进行任何配置即可运行Rest Service
- 由于映像托管在hub.docker.com中，我们甚至不需要在本地构建任何内容
- 我们可以在任何操作系统上运行
同时，我们注意到以下缺点：
- 我们需要知道我们的服务在哪个IP和端口中被Docker公开
- 如果我们运行多个映像，则需要跟踪所有IP和端口，并通知所有客户有关这些IP和端口的信息。
- 同一docker映像实例的不同实例之间没有内置的负载平衡方式
为了解决Openshift的这些缺点，更具体地说，Kubernetes可以拯救我们！
在Openshift中配置我们的服务
如前所述，如果我们只是开始创建服务的新Docker Image实例，我们很快就会发现我们的客户将需要知道我们正在运行多少个实例以及如何联系每个实例。 这显然是不好的，因此，我们需要一个中间层来处理此问题。 Kubernetes为我们提供了这一抽象和供应层，这使我们能够创建POD的多个实例（在docker映像之上的抽象）并为其配置Replication Controllers和Services 。
Replication Controller的概念提供了一种方法，该方法可以定义在给定时间应运行多少个实例来运行我们的服务。 复制控制器负责确保如果我们至少需要运行3个实例，则这些实例将一直运行。 如果这些实例之一死亡，则复制控制器将自动为我们生成一个。
Kubernetes中的服务解决了了解所有Docker实例详细信息的问题。 服务使我们能够为客户提供一个立面，以便与我们的Pod实例进行交互。 服务层还允许我们定义策略（称为会话亲和力），以定义如何在服务后平衡Pod实例的负载。 有内置策略：ClientIP和Round Robin。
因此，我们现在需要做的事情，我们需要安装Openshift Origin（v3）和我们的项目Drools Controller，该项目将与Kubernetes REST端点进行交互以提供Pod，复制器控制器和服务。
对于Openshift安装，我建议您按照此处描述的步骤进行操作： https : //github.com/openshift/origin/blob/master/CONTRIBUTING.adoc
我在笔记本电脑上的上一个链接中介绍了Vagrant选项（第二个选项）。
最后，可以找到一个非常简单的示例，说明如何使用Kubernetes API在这种情况下将我们的drools-food-services供应到Openshift中。
请注意，我们在运行时定义了所有内容，这确实很棒，因为我们可以从头开始或修改现有的服务，复制控制器和Pod。
您可以看一下drools-controller项目。 其中显示了我们如何创建指向Docker映像并定义1个副本的复制控制器（默认情况下会创建一个副本）。
如果您登录Openshift Console，您将能够使用Replication Controller和我们Pod的一个副本看到新创建的服务。 通过使用UI（或API，更改Main类），我们可以根据需要提供更多副本。 Kubernetes服务将确保在不同的Pod实例之间实现负载平衡。
瞧！ 我们的服务副本已启动并正在运行！
现在，如果通过对映射的Kubernetes服务端口执行GET来访问NodeStat服务，您将获得正在响应该请求的Pod。 如果您多次执行请求，您应该能够看到循环策略正在实施。
wget http://localhost:9999/api/node {"node":"drools-controller-8tmby","version":"version 1"}
wget http://localhost:9999/api/node {"node":"drools-controller-k9gym","version":"version 1"}
wget http://localhost:9999/api/node {"node":"drools-controller-pzqlu","version":"version 1"}
wget http://localhost:9999/api/node {"node":"drools-controller-8tmby","version":"version 1"}以相同的方式，您可以与这3个Pod中的每一个Statless会话进行交互。 在这种情况下，您实际上不需要知道哪个Pod在回答您的请求，您只需要由他们中的任何一个来完成工作即可。
加起来
通过利用Openshift起源基础架构，我们通过不重新发明Kubernetes和Docker等工具中已经存在的机制来简化架构。 在接下来的文章中，我将介绍使用此基础结构的其他一些不错的优点，例如汇总来升级我们的服务版本，增加安全性和Api管理。
如果您对此方法有疑问，请分享您的想法。
openshift
1627
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
