从IBM集成总线到App Connect企业容器

139 阅读12分钟

从IBM Integration Bus到App Connect Enterprise Containers

在这篇文章中,我们以ODBC为例,说明如何从IBM App Connect Enterprise Containers连接到数据库。

最常见的集成点之一是数据库,而App Connect很适合连接到大量的数据存储。用于连接数据库的最常见的协议之一是ODBC,所以这就是我们在这篇文章中要讨论的例子。

我们再次选择了一个非常基本的流程,因为这篇文章的重点不是要展示App Connect的数据库操作能力,而是要展示如何将现有的集成迁移到容器中。在ODBC的案例中,这主要是围绕着所涉及的各种配置文件。

和以前的文章一样,我们将从一个基本的迁移开始,然后在最后建立起一些更高级的话题。

消息流的描述

我们有一个非常简单的消息流,通过HTTP接收请求,并在数据库表中创建(插入)一条记录。

如果你想看一下工具包中的流程,你可以在下面的位置下载SimpleDatabaseApp.zip文件中的流程源。然而,请注意,在这个方案中,我们实际上不需要对该流程做任何改动。

我们使用数据库节点,通过ODBC协议进行数据库交互。

数据库节点有一个简单的INSERT语句,如下图所示。

CREATE COMPUTE MODULE DBInsertFlow_Compute      
    CREATE FUNCTION Main() RETURNS BOOLEAN             
        BEGIN                       
           INSERT INTO Database.EMP values('employee1', 1234);                      
           RETURN TRUE;            
        END;

为了简洁起见,我们将不提供创建DB2(或任何其他)数据库的说明。我们将假设你正在阅读这篇文章,因为你已经有一个DB2数据库,你现有的集成正在使用这个数据库,并且/或者你已经有技能创建一个数据库。

用于ODBC连接的配置文件

现在让我们看看在当前环境中如何定义与数据库的连接,比如在IBM Integration Bus v10中创建的环境。 然后我们将看看如何在部署在Kubernetes中的IBM App Connect v12上执行同样的配置。我们将主要记录如何为DB2进行配置,但我们会参考其他数据库的不同步骤。

从IBM App Connect v11.0.0.11开始,App Connect Enterprise的二进制文件中就包含了本地DB2驱动程序。这使你能够配置App Connect Enterprise以直接连接到DB2,而不需要自己获取和安装DB2客户端。IBM App Connect还可以使用包含的DataDirect ODBC驱动程序连接到许多其他常见的数据库,如(Oracle、Sybase和SQL Server)。

这意味着IBM App Connect Enterprise认证的容器已经包含了你需要的所有二进制文件,以连接到广泛的数据库。你所需要做的就是添加连接配置。

数据库连接配置有三个必须的部分:

  1. 固定属性(odbc.ini):从一个环境到另一个环境不会改变的值,如数据库驱动程序二进制文件的位置,以及与连接行为方式有关的属性(超时等)。
  2. 位置属性(odbc.ini 或 db2cli.ini):在哪里可以找到数据源,比如它的主机、端口和名称。根据你的设置,在你从开发到生产的环境中,这些可能会也可能不会改变。
  3. 凭证(mqsisetdbparms):用于连接到数据源的用户名和密码。显然,这些几乎总是从一个环境到另一个环境的变化。

让我们依次看一下这些东西,了解在现有环境中哪里可以找到它们,然后在Kubernetes中如何配置它们。

固定属性(odbc.ini文件)

使用ODBC标准连接到数据库所需的大多数参数都包含在一个名为odbc.ini的文件中。在真实的迁移场景中,例如从IBM Integration Bus v10迁移,你会在通过ODBCINI环境变量指向的目录中找到现有的odbc.ini。一个常用的位置是/var/mqsi,但它可以指向当前服务器上的任何目录。

下面是一个符合我们提供的集成流程的DB2 odbc.ini文件的例子。

[ODBC Data Sources]

USERDB=IBM Data Server Driver included in ACE
;# IBM Data Server Driver included in ACE

[USERDB]
DRIVER=/opt/ibm/ace-12/server/ODBC/dsdriver/odbc_cli/clidriver/lib/libdb2o.so
Description=IBM Db2 ODBC Database accessed using IBM Data Server Driver included in ACE
Database=USERDB

[ODBC]
InstallDir=/opt/ibm/ace-12/server/ODBC/drivers
UseCursorLib=0 
IANAAppCodePage=4
UNICODE=UTF-8

Odbc.ini文件对每个数据库供应商都略有不同。

关于其他数据库的模板,请参考这里的IBM文档。

作为一个例子,这里有一个Oracle的odbc.ini样本。

[ODBC Data Sources]

注意上面的Oracle例子odbc.ini文件中用粗体字标记的行。它们包含主机、端口和服务名称,尽管这些可以说是下一个类别("位置属性")中的内容可能因环境而改变。

位置属性(db2cli.ini文件)

正如我们刚刚看到的,Oracle和其他数据库在odbc.ini文件中把 "位置属性 "与 "固定属性 "交织在一起。而DB2则将它们保存在一个单独的文件中,名为db2cli.ini。如果位置属性在不同的环境中发生变化,但你想保留一套一致的 "固定属性",这可能很有用。

例如,在从IBM Integration Bus v10迁移的情况下,你会在通过DB2CLIINI环境变量指向的目录中找到现有的db2cli.ini。一个常用的位置是/var/mqsi,但它可以指向当前服务器上的任何目录。

下面是一个DB2 db2cli.ini文件的例子,它与我们提供的集成流程的数据源相匹配。

[USERDB]
Hostname=9.145.146.224
Port=50000
Database=USERDB

当然,你需要改变主机名和端口字段以匹配你的数据库。

凭证(mqsisetdbparms)

历史上,数据库等资源的凭证(如用户名和密码)是使用mqsisetdbparms命令行工具在集成服务器上配置的。 这个命令在当前版本中仍然适用于传统的IBM App Connect。

然而,对于管理员来说,不得不对正在运行的容器运行命令并不是一个好的云本地实践。 容器应该用它所需要的所有信息来启动,然后在运行时不应该发生进一步的配置。

因此,App Connect认证容器及其相关的操作者已经被设计为从属性文件中接收凭证,并在启动时将其自动应用到集成服务器上。

创建一个名为**"setdbparms.txt**"的文件,内容如下,并相应更新细节。

odbc::<datasource name> <uid> <password>

...其中是odbc.ini文件中的stanza的名称。比如说。

odbc::USERDB my-user-id my-password

将数据库配置应用于Kubernetes

我们现在已经准备好了必要的文件(odbc.ini、db2cli.ini和setdbparms.txt)。现在让我们把它们应用到Kubernetes环境中,以便以后在部署我们的集成流程时可以引用它们。

我们通过创建包含相关文件的 "配置"(稍后会详细讨论)来实现这一目标,就像我们在之前的例子中所做的那样,例如在《将使用MQ的App Connect流程转移到容器上 》中定义了一个队列管理器

我们用命令行来演示这些配置的创建,以证明它们可以被包含在自动构建管道中。然而,在每种情况下,我们也会参考通过用户界面应用它们的说明。

使用odbc.ini配置类型创建固定数据源属性

可以通过 IBM App Connect 仪表板来创建 odbc.ini 配置类型,这已经有很好的记录。我们将通过命令行来创建它,就像你在自动管道中那样。

将 odbc.ini 文件插入 base64,以获得该文件的 base64 编码版本。比如说。

$ cat odbc.ini | base64

接下来我们需要创建一个'odbc.ini'配置定义。创建一个具有以下内容的文件('odbcini.yaml'),采取base64输出,在数据部分更新以下文件。

apiVersion: appconnect.ibm.com/v1beta1

将base64编码的输出粘贴到的位置。

使用部署配置。

$ oc apply -f odbcini.yaml

使用通用配置类型创建数据源位置属性

由于 db2cli.ini 是 DB2 独有的,它不适合任何标准的配置类型,所以我们把它作为一个"通用 "配置类型来加载。通用类型需要一个额外的步骤,因为它们总是以压缩文件的形式提供。

可以通过 IBM App Connect 仪表板来创建通用配置类型,这一点已经有很好的记录了。我们将通过命令行来创建它,就像你在自动化管道中那样。

将 "db2cli.ini "压缩到一个名为 "extensions.zip "的文件中。

$ zip db2cli.ini > extensions.zip

将该压缩文件导入base64,得到该文件的base64编码版本,即。

$ cat extensions.zip | base64

接下来我们需要创建一个**"通用**"配置定义。创建一个名为'generic.yaml'的文件,内容如下。

apiVersion: appconnect.ibm.com/v1beta1
kind: Configuration
metadata:
  name: extensions.zip
  namespace: mynamespace
spec:
  type: generic  
  description: Files for configuring Db2
  data: <InsertDataHere>

将base64编码的输出粘贴在的位置。

通过以下方式部署该配置。

$ oc apply -f generic.yaml

使用Setdbparms配置类型创建数据源凭证

凭证有一个特定的配置类型,叫做 "setdbparms"。它们与其他配置的处理方式不同,因为它们包含更敏感的数据(密码)。目前,它们被存储在Kubernetes的 "秘密 "中,但这都是由运营商为您隐蔽处理的。

可以通过 IBM App Connect 仪表板创建 setdbparms 配置类型,这一点已经有很好的记录了。我们将通过命令行来创建它,就像你在自动管道中那样。

将setdbparms.txt文件插入base64,得到该文件的base64编码版本,即。

$ cat setdbparms.txt | base64

接下来我们需要创建一个**'setdbparms**'配置定义。创建一个文件('setdbparms.yaml'),内容如下。

apiVersion: appconnect.ibm.com/v1beta1

将base64编码的输出粘贴在*的位置。*

用以下方法部署该配置。

$ oc apply -f setdbparms.yaml

部署集成

现在我们已经将所有的数据库配置存储在Kubernetes的配置中,我们可以继续部署我们的集成。

为了方便,我们预先创建了一个BAR文件,并在GitHub上提供。

创建一个集成服务器定义文件(IS-database-db2-app.yaml),其中包括对我们在 "配置 "部分创建的配置对象的引用,如下所示。

apiVersion: appconnect.ibm.com/v1beta1

注意**"env**"部分的DB2CLIINIPATH。这需要稍微解释一下。操作员会自动将任何作为**"通用**"配置提供的文件放到**/home/aceuser/generic** 目录中。因此这将包括我们的 db2cli.ini文件。但是,集成服务器不会寻找 db2cli.ini 文件,除非它看到 DB2CLIINIPATH 环境变量。在'env'部分的那一行是在创建这个环境变量。

使用部署集成服务器。

$ oc apply -f IS-database-db2-app.yaml

测试流程

我们在这个演示中使用的示例消息流在数据库中的EMP表中创建了一条记录(行),其中有雇员姓名和雇员ID。

该消息流暴露了名为"/createRecord "的HTTP端点服务。

要调用消息流,使用'oc get routes'获得公共URL,然后使用curl命令调用服务,将替换为你得到的服务名称。

$ curl -X POST http://<hostname>/createRecord

在成功创建记录后,你应该看到返回的响应信息,如下所示。

<Response>
        Successfully created an employee record into the database
</Response>

在数据库方面,你可以通过在数据库表中运行SELECT查询来验证。

HTML

SQL> select * from EMP;

NAME                    ID
--------------      -------
employee1             1234

很好!所以你已经在一个容器中部署并测试了一个简单的流程,它通过ODBC与数据库对话。现在,让我们快速浏览一下几个更高级的主题。

将额外的配置应用于数据库连接

除了那些在ODBC层中定义的参数外,还有许多进一步的调整参数可用于数据库连接。例子包括如何管理和缓存连接,一些常见的例子是:maxConnectionAge、maxConnectionUseCount、maxStatementAge和statementCacheSize。

在传统的部署中,这些都是用mqsichangeproperties命令设置的,你可以用mqsireportproperties从当前环境中提取这些值。下面是一个命令的例子。

mqsireportproperties integration_node -e integration_server -o ComIbmDatabaseConnectionManager -r

在容器中,甚至在任何使用App Connect v11或以上版本的部署中,这些参数应该使用一个名为server.conf.yaml的属性文件来设置。

现在是介绍这个至关重要的文件的好时机。这是用于配置集成服务器的主要属性文件。App Connect企业认证容器带有一个默认的server.conf.yaml文件(/home/aceuser/ace-server/server.conf.yaml)。到目前为止,我们还不需要了解这个文件,因为默认的已经符合我们的需求。

如果我们需要添加或改变server.conf.yaml的属性,我们可以通过 "配置 "提供一个进一步的server.conf.yaml文件,就像我们在本文中对其他属性文件所做的那样。关于如何做到这一点的细节在这里:server.conf.yaml类型

最终,我们额外的 server.conf.yaml文件将在启动时从配置中提取,并放置在**/home/aceuser/ace-server/overrides/**目录中。其中指定的任何属性将覆盖默认文件中的属性。

数据库连接属性存在于文件的一个特定节中。以我们先前的属性为例,我们可以在server.conf.yaml文件中添加以下内容。

ResourceManagers: 
DatabaseConnectionManager:
  maxConnectionAge='60'
  maxConnectionUseCount='100'
  maxStatementAge='600'
  statementCacheSize='40'

完整的数据库相关属性,以及关于数据库连接的更多细节,可以在这里找到。数据库连接

捕获ODBC跟踪

我们将在某些时候需要对我们的数据库连接进行更深入的诊断,也许是通过启用跟踪。这可以通过另一个文件(odbcinst.ini)来实现,该文件作为一个 "通用 "配置被添加,就像我们之前对db2cli.ini文件所做的那样。

关于如何做到这一点的更多细节记录在这里。为在CP4I中运行的集成服务器启用ODBC跟踪

什么是配置,在运行时它们会发生什么?

这篇文章,比本系列中的任何文章都更广泛地使用了配置。配置为App Connect Enterprise提供了一种通用机制,用于存储集成服务器在运行时需要的属性文件。

根据配置的类型,配置以ConfigMap或Secret的形式原生存储在Kubernetes中。不同类型的配置对象的完整列表可在这里的文档中找到。集成服务器的配置类型

你会注意到,我们在集成服务器定义文件(上面的IS-database-db2-app.yaml)中引用了所有我们已经创建的配置。在启动时,App Connect Enterprise认证容器会浏览配置参考列表,并将它们加载到目录树中的正确位置,如下图所示。

因此,一旦运行,App Connect在容器中的运行方式与直接安装在操作系统中的方式相同,只是从文件系统的属性文件中读取信息。

理论上,当在容器中运行时,你不应该需要知道这些文件在容器的文件系统中的位置,上面的内容只是作为参考/兴趣提供。你不应该试图直接对运行中的容器中的文件进行修改。 相反,你应该总是与 "配置 "对象进行交互。如果你需要对配置中的某个文件的属性进行修改,你应该通过与我们在这篇文章中相同的过程--将修改后的文件放入配置YAML文件中,然后将其重新应用于Kubernetes。运营商会意识到配置已被更改,并代表您重新启动服务器,使新值被接收。

这种云原生的配置管理方法确保运行中的容器和配置之间没有漂移的危险,确保环境配置的一致性和可重复性。