此内容没有您所选择的语言版本。
Chapter 2. Creating virtual databases
To add a virtual database, you must complete the following tasks:
- Install the Data Virtualization Operator.
- Design and develop the database.
- Create a custom resource (CR) file for deploying the database.
- Deploy the virtual database to OpenShift by running the Data Virtualization Operator with the CR.
You can use any of the following methods to design a virtual database.
- Create a virtual database from a DDL file
- Define the entire contents of a virtual database, including the DDL, in a YAML file. For more information, see Chapter 3, Creating a virtual database by embedding DDL statements in a custom resource (CR) .
- Create a virtual database as a Maven artifact
- Create a virtual database from one or more DDL files and generate a Maven artifact for deployment For more information, see Chapter 4, Creating a virtual database as a Maven artifact.
- Create a virtual Database as a fat JAR
- Use the Teiid Spring Boot plug-in to create a Maven-based Java project with a DDL file, and then generate a fat JAR for deployment. For more information, see Chapter 5, Creating a virtual database as a fat JAR.
In each of the methods, you use SQL data definition language (DDL) to specify the structure of the virtual database, and you then configure the data sources that you want the virtual database to read from and write to.
There are advantages and disadvantages to using each method, the runtime virtualizations that any of the methods create have equivalent features. Choose a method based on the complexity of your project and on whether you want to be able to test the virtualization as a standalone component or on OpenShift only.
After you define the virtual database, you use the Data Virtualization Operator to deploy the virtualization from a custom resource (CR). The custom resource that you use to deploy a virtual database varies with the method that you used to design the virtual database. For more information, see Chapter 6, Running the data virtualization operator to deploy a virtual database.
After you set up connections to a data source, you can optionally configure authentication to Red Hat SSO to secure the connections, and enable single sign-on.
You can also create virtual databases in Fuse Online (Technology Preview). Virtual databases that you create in Fuse Online provide a limited set of features.
Additional resources
2.1. Compatible data sources
You can configure create virtual databases from a range of different data sources.
For each data source, you must provide the name of the translator that can interpret the commands and data that pass between the virtual database and the data source.
The following table lists the data source types from which you can create virtual databases, and the names of the translators for each data source:
| Data source | Translator name | |
|---|---|---|
| Amazon S3/ Ceph | ||
| Google Sheets | ||
| Data Grid (Infinispan) | ||
| MongoDB | ||
| Relational databases | ||
| Amazon Athena | amazon-athena or jdbc-ansi | |
| Amazon Redshift | ||
| Db2 | ||
| Microsoft SQL Server (JDBC) | ||
| MySQL | ||
| Oracle | ||
| PostgreSQL | ||
| SAP HANA (JDBC) | ||
| OData | ||
| OData4 | ||
| OpenAPI | ||
| REST | ||
| Salesforce | ||
| sFTP | ||
| SOAP | ||
2.2. Creating custom resources to deploy virtualizations
Before you can use the Data Virtualization Operator to create a virtual database, you must specify properties for the data source in a custom resource (CR) file.
When you run the Data Virtualization Operator, it reads information from the CR that it needs to convert a data virtualization artifact into an image and deploy it to OpenShift.
Properties in the CR specify environment variables that store the credentials that the Operator requires to connect to a data source. You can specify the values directly in the CR, or provide references to an OpenShift secret that stores the values. For more information about creating secrets, see Section 7.4, “Using secrets to store data source credentials”.
Period characters (.) are not valid for use in environment variables. When you add variable names to the CR, use underscore characters (_) as separators.
The information that you add to the CR depends on the type of artifact that you created for the virtualization and the location of artifact. You can also supply configuration information in the CR.
If you want OpenShift to create an HTTP endpoint for the deployed virtualization, add the property spec/exposeVia3scale to the CR, and set its value to false. If the value is set to true it is assumed that 3scale manages the endpoint, and no HTTP endpoint is created.
Additional resources
2.2.1. Environment variables in custom resources
You set environment variables in the custom resource file to enable your virtual database to connect to data sources.
Because you typically deploy virtual databases to multiple OpenShift environments, such as to a staging and a production environment, you might want to define different data source properties for each environment. For example, the login credentials that you must provide to access a data source in the staging environment are probably different from the credentials that you use to access the data source in the production environment. To define unique values in each environment, you can use environment variables.
The environment variables that you define in a CR replace any static properties that you might set elswhere, for example, in the application.properties file for a fat JAR. If you define a property in the properties file and in the CR, the value in the CR file takes precedence.
You can combine the use of environment variables and secret objects to specify and protect the unique details for each environment. Instead of specifying static values for environment variables directly in the CR, you can store the values for each deployment environment in secret objects that are unique to each environment. The value of each environment variable in the CR contains only a key reference, which specifies the name of a secret object, and the name of a token in the secret. The token stores the actual value. At runtime, environment variables retrieve their values from the tokens.
By using secrets to store the values of your environment variables, you can use a single version of the CR across environments. The secret objects that you deploy in each environment must have the same name, but in each environment you assign token values that are specific to the environment.
Additional resources
- For more information about using secrets, see Section 7.4, “Using secrets to store data source credentials”.
- For information about adding a CR file, see Section 2.2, “Creating custom resources to deploy virtualizations”.
