この章では、TimesTenデータベースの属性を定義するために指定する構成メタデータについて説明します。この構成メタデータは、KubernetesクラスタでTimesTenが実行されるときにTimesTenおよびオペレータによって使用されます。この章では、TimesTenコンテナに構成メタデータを取得するために使用できるKubernetesの機能についても説明します。この章には、構成メタデータの定義方法およびKubernetes機能の使用方法を示す様々な例も含まれています。その後、その他の構成オプションについて説明します。
メタデータ・ファイルの形式の構成メタデータを使用すると、TimesTenデータベースの属性、およびそのデータベースが他のアプリケーションやコンポーネントと相互作用する方法を指定できます。各メタデータ・ファイルには、特定の名前があります。このファイルを作成し、特定のメタデータを追加します。たとえば、TimesTenオペレータは、TimesTen接続属性についてdb.ini
という名前のファイルをサポートしています。このファイルを作成し、データベースの特定の接続属性を含めます。詳細は、サポートされているメタデータ・ファイルを参照してください。
Kubernetesは、TimesTenコンテナにメタデータ・ファイルを取得できる様々な機能をサポートしています。具体的には、オペレータが各ポッドを作成すると、そのポッドにはTimesTenを実行するコンテナが含まれています。このコンテナは、/ttconfig
ディレクトリでメタデータ・ファイルの存在を探すことによって、メタデータ・ファイルにアクセスします。Kubernetes機能を使用することで、メタデータ・ファイルはTimesTenコンテナの/ttconfig
ディレクトリに配置されます。これらの機能の詳細は、/ttconfigディレクトリの移入を参照してください。
これらはサポートされているメタデータ・ファイルです。これらのファイルを使用して、データベースの属性およびメタデータを指定します。これらのファイルを作成した後、それらのファイルをTimesTenコンテナに配置するために機能を選択すると、TimesTenは該当するファイルにアクセスして、目的のデータベースに固有の属性とメタデータを判断できるようになります。
次のメタデータ・ファイルは、すべてのデータベースに適用されます。
次のメタデータ・ファイルは、TimesTen Cacheに固有です。
次のメタデータ・ファイルは、TLSサポートに固有です。
epilog.sqlメタデータ・ファイルは、レプリケーション・スキームの作成後に発生する操作に使用されます。
オペレータは、作成時にADMIN
権限を持つ名前付きユーザーをデータベースに自動的に作成できます。この目的でadminUser
ファイルを作成します。このファイルには、次の形式の1行が含まれている必要があります。
user/password
TimesTen Cacheを使用する場合は、cachegroups.sql
ファイルを指定する必要があります。このファイルには、キャッシュ・グループの作成とキャッシュ・グループのロードの定義が含まれます。具体的には、このファイルではCREATE
CACHE
GROUP
文を指定します。さらに、Oracle Databaseからキャッシュ・グループにデータをロードする場合は、1つ以上のLOAD
CACHE
GROUP
文を指定できます。TimesTen組込みプロシージャのttOptUpdateStats
またはttOptEstimateStats
を指定することで、LOAD
CACHE
GROUP
操作の完了後にキャッシュ表の統計を更新することもできます。これらの組込みプロシージャは、cachegroups.sql
ファイル内でLOAD
CACHE
GROUP
文の後に続けるようにします。
このファイルは、キャッシュ・グループを作成してからレプリケーションを構成する必要があるため必須です。
詳細は、次を参照してください。
『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUPに関する項およびLOAD CACHE GROUPに関する項
『Oracle TimesTen In-Memory Databaseリファレンス』のttOptUpdateStatsに関する項およびttOptEstimateStatsに関する項
『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・グループのタイプに関する項
次に、cachegroups.sql
ファイルの例を示します。このファイルでは、2つのキャッシュ・グループを定義して、データを1つのキャッシュ・グループにロードします。
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP writecache FROM oratt.writetab ( pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40) ); CREATE READONLY CACHE GROUP readcache AUTOREFRESH INTERVAL 5 SECONDS FROM oratt.readtab ( keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32) ); LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
TimesTen Cacheを使用する場合は、cacheUser
メタデータ・ファイルを指定する必要があります。このファイルには、次の形式の1行が含まれている必要があります。
cacheUser/ttPassword/oraPassword
cacheUser
は、TimesTenキャッシュ・マネージャ・ユーザーとして指定するユーザーです。このユーザーは、Oracle Databaseのキャッシュ管理ユーザーとして指定したユーザーと同じ名前にする必要があります。このユーザーは、Oracleデータベースにすでに存在している必要があります。TimesTen cacheUser
ユーザー(TimesTenキャッシュ・マネージャ)のTimesTenパスワードとしてttPassword
を指定します。oraPassword
は、Oracle DatabaseでcacheUser
ユーザーを作成したときに指定したOracle Databaseパスワードです。
たとえば、Oracle Databaseでパスワードがoraclepwd
のcacheuser2
キャッシュ管理ユーザーを作成していたとします。さらに、このcacheuser2
ユーザーをTimesTenキャッシュ・マネージャ・ユーザーとして指定することにして、そのTimesTenパスワードをttpwd
にするとします。この例の場合、cacheUser
メタデータ・ファイルには次の行を含めます。
cacheuser2/ttpwd/oraclepwd
この例では、オペレータがTimesTenデータベースにttpwd
を使用してcacheuser2
ユーザーを作成します。このcacheuser2
ユーザーは、TimesTenデータベースのキャッシュ・マネージャ・ユーザーとしての役割を果たすことになります。(このTimesTenユーザーは作成する必要がありません。その操作は、オペレータが実行します)。TimesTenユーザーの詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenユーザーの作成に関する項を参照してください。このマニュアルの「概要」および「メタデータ・ファイルとKubernetes機能の作成」も参照してください。
オペレータは、TimesTenのcacheUser
ユーザー(この例ではcacheuser2
)に、このユーザーのキャッシュ・マネージャとしてのロールに適した権限を付与します。これに該当する権限を次に示します。
CREATE
SESSION
CACHE
MANAGER
CREATE
ANY
TABLE
LOAD
ANY
CACHE
GROUP
REFRESH
ANY
CACHE
GROUP
FLUSH
ANY
CACHE
GROUP
DROP
ANY
CACHE
GROUP
ALTER
ANY
CACHE
GROUP
UNLOAD
ANY
CACHE
GROUP
SELECT
ANY
TABLE
INSERT
ANY
TABLE
UPDATE
ANY
TABLE
DELETE
ANY
TABLE
デフォルトでは、TimesTen Client/Server環境では、クライアント・アプリケーションとTimesTenデータベースの間で暗号化されていないデータが転送されます。ただし、Client/Server用のTLSを構成すると、TimesTenのクライアントとサーバーの間でセキュアなネットワーク通信を確保できます。Client/Serverのトラフィックを暗号化するには、/ttconfig/csWallet
ファイルを指定します。このファイルには、サーバー用のOracleウォレットが含まれています。このウォレットに、TimesTenデータベースとClient/Serverアプリケーションの間のTLS暗号化の構成に使用される資格証明を含めます。このファイルは、TimesTenデータベースのコンテナのディレクトリ/tt/home/oracle/csWallet
で使用できるようになります。このディレクトリは、db.ini
ファイルで参照できます(wallet
接続属性を指定します)。詳細は、「レプリケーションおよびClient/Server用のTLS証明書の作成」と「Client/Server用のTLSの構成」を参照してください。
クライアント・ウォレットは、クライアント・アプリケーションでも使用できるようにする必要があります。詳細は、「レプリケーションおよびClient/Server用のTLS証明書の作成」と「Client/Server用のTLSの構成」を参照してください。
db.ini
ファイルには、TimesTenデータベースのTimesTen接続属性が含まれています。db.ini
ファイルで指定する接続属性は、TimesTenのsys.odbc.ini
ファイルに含まれます。db.ini
ファイルでは、DataStore
またはLogDir
接続属性を指定しないかぎり、データ・ストア属性、最初の接続属性および一般的な接続属性を指定できます。これら2つの属性はオペレータによって設定されます。DSNの名前は、TimesTenClassicオブジェクトの名前です。(たとえば、TimesTenClassicオブジェクトの名前がsample
の場合、DSNの名前はsample
になります。)
TimesTen Cacheを使用する場合は、このdb.ini
ファイルを指定する必要があります。そこでは、接続属性のOracleNetServiceName
とDatabaseCharacterSet
を指定する必要があります。DatabaseCharacterSet
値は、Oracle Databaseのデータベース文字セットの値と一致している必要があります。
TimesTen接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの属性のリストを参照してください。
ノート: /ttconfig/db.ini ファイルがTimesTenコンテナ内に存在しない場合、TimesTenはデフォルトのsys.odbc.ini ファイルを作成します。このデフォルトsys.odbc.ini の場合、接続属性はPermsize =200 DatabaseCharacterSet =AL32UTF8 です。
TimesTen Cacheを使用する場合は、 |
次の例は、TimesTenデータベースの接続属性を含むサンプルのdb.ini
ファイルを示しています。
PermSize=500 LogFileSize=1024 LogBufMB=1024 DatabaseCharacterSet=AL32UTF8 OracleNetServiceName=OraCache
このファイルは、レプリケーション・スキームを作成して、レプリケーション・エージェントを起動した後に発生する操作に使用します。たとえば、レプリケートされたXLAのブックマークを作成する場合は、このファイルでttXlaBookmarkCreate
組込みプロシージャをコールできます。
次に、epilog.sql
ファイルの例を示します。この例では、ttXlaBookmarkCreate
組込みプロシージャをコールしてXLAブックマークを作成します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttXlaBookmarkCreateに関する項を参照してください。
call ttXlaBookmarkCreate('mybookmark',0x01);
デフォルトでは、TimesTenレプリケーションは、TimesTenデータベース間で暗号化されていないデータを転送します。ただし、レプリケーション用のTLSを構成すると、レプリケートされたTimesTenデータベース間でセキュアなネットワーク通信を確保できます。そのためには、/ttconfig/replicationWallet
ファイルを指定する必要があります。このファイルにはOracleウォレットが含まれています。このウォレットには、TimesTenデータベースのアクティブ・スタンバイ・ペア間でTLS暗号化を構成するためにTimesTenレプリケーションで使用される資格証明が含まれています。詳細は、「レプリケーションおよびClient/Server用のTLS証明書の作成」と「レプリケーション用のTLSの構成」を参照してください。
また、TimesTenClassicオブジェクト定義には、replicationCipherSuite
フィールドを含める必要があり、オプションでreplicationSSLMandatory
フィールドを含めます。詳細は、表11-3「TimesTenClassicSpecSpec」のreplicationCipherSuite
エントリとreplicationSSLMandatory
エントリおよび「レプリケーション用のTLSの構成」を参照してください。
オペレータは、ユーザー、表、順序などのスキーマ・オブジェクトを使用してデータベースを自動的に初期化できます。オペレータでこれを行うには、schema.sql
ファイルを作成します。
このインスタンス管理者は、このファイルをデータベース作成の直後に実行します(ttIsql
ユーティリティを使用)。このファイルは、オペレータがTimesTenデータベースでレプリケーションまたはキャッシュを構成する前に実行します。
TimesTen Cacheでは、1人または複数のキャッシュ表ユーザーがキャッシュ表を所有します。このキャッシュ表ユーザーがキャッシュ・マネージャ・ユーザーでない場合は、schema.sql
ファイルを指定する必要があります。さらに、このファイルにスキーマ・ユーザーを含めて、そのスキーマ・ユーザーに適切な権限を割り当てることも必要です。たとえば、Oracle Databaseでoratt
スキーマ・ユーザーが作成されていたときに、このユーザーがTimesTenキャッシュ・マネージャ・ユーザーでない場合は、このファイルにTimesTen oratt
ユーザーを作成する必要があります。Oracle Databaseのスキーマ・ユーザーの詳細は、「Oracle Databaseユーザーの作成」を参照してください。また、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenユーザーの作成に関する項も参照してください。
このファイルには、キャッシュ定義を含めません。そのかわりに、cachegroups.sql
メタデータ・ファイルを使用します。詳細は、「cachegroups.sql」を参照してください。
Oracle Database sqlnet.ora
ファイルでは、クライアント・アプリケーションがOracle Databaseと通信する方法のオプションを定義します。TimesTen Cacheを使用する場合やttLoadFromOracle
などのツールを使用する場合は、sqlnet.ora
ファイルを定義します。このファイルには、TimesTenなどのアプリケーションがOracleデータベースに接続する方法が記述されています。ノート: sqlnet.ora
ファイルを定義する場合は、tnsnames.ora
ファイルを定義する必要があります。tnsnames.ora
ファイルの詳細は、tnsnames.oraファイルを参照してください。
次に、sqlnet.ora
ファイルの例を示します。
NAME.DIRECTORY_PATH= {TNSNAMES, EZCONNECT, HOSTNAME} SQLNET.EXPIRE_TIME = 10 SSL_VERSION = 1.2
Oracle Databaseのtnsnames.ora
ファイルでは、アプリケーションが接続するOracle Net Servicesを定義します。次を使用する場合は、tnsnames.ora
(および場合によってはsqlnet.oraファイルで説明されているsqlnet.ora
ファイル)を使用する必要があります。
TimesTen Cache
Pro*C、OCI、ODPI-CなどのSQL API
ttLoadFromOracle
機能(詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLoadFromOracleに関する項を参照してください)。
次に、tnsnames.ora
ファイルの例を示します。
OraTest = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = database.myhost.svc.cluster.local) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = OraTest.my.domain.com))) OraCache = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = database.myhost.svc.cluster.local) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = OraCache.my.domain.com)))
サポートされているメタデータ・ファイルを使用してTimesTenを構成するには、ファイルがTimesTenコンテナの/ttconfig
ディレクトリに配置されている必要があります。(サポートされているメタデータ・ファイルの詳細は、サポートされているメタデータ・ファイルを参照してください。)
/ttconfig
ディレクトリにファイルを取得する方法に関する要件はありません。ただし、Kubernetesでは次の機能を使用できます。
1つ以上のConfigMapおよび(または) 1つ以上のシークレットを使用して、メタデータ・ファイルをTimesTenコンテナに組み込むことができます。これにより、デプロイメントごとに異なるオブジェクトを使用して、TimesTenの異なるデプロイメントに異なるメタデータを提供できます。また、パスワードや証明書などの機密データを含むメタデータにシークレットを使用できます。
ConfigMapを使用してメタデータをポッドに移入する方法は、標準的なKubernetesの手法です。メリットの1つは、作成後にConfigMapを変更できることです。この結果、ポッド内のファイルが即時に更新されます。
ノート: TimesTenは、すぐには認識せずに、ファイルの変更されたコンテンツを処理する場合があります。 |
ConfigMapおよびシークレットを使用するには、次のプロセスに従います。
どの機能にどのメタデータ・ファイルを含めるかを決定します。たとえば、すべてのメタデータ・ファイルに対して1つのConfigMapを使用できます。または、別の例として、db.ini
メタデータ・ファイルに1つのConfigMapを使用し、adminUser
およびschema.sql
メタデータ・ファイルに1つのシークレットを使用できます。特定の要件はありません。
メタデータ・ファイルを格納するディレクトリを作成します。
kubectl
create
コマンドを使用して、KubernetesクラスタにConfigMapおよびシークレットを作成します。
TimesTenClassicオブジェクト定義にConfigMapおよびシークレットを含めます。TimesTenClassicオブジェクトの作成方法の詳細は、デプロイメント・プロセスの理解を参照してください。次の各項では、TimesTenClassicオブジェクト定義(YAMLファイル内)でConfigMapおよびシークレットを参照する方法と場所を示す例を示します。ただし、TimesTenClassicオブジェクトの作成方法の詳細は、デプロイメント・プロセスの理解を参照してください。
ConfigMapおよびシークレットを使用してメタデータを保持し、TimesTenClassicオブジェクト定義内でそれらを参照する場合、オペレータはtt-config
というProjectedV列を作成します。このtt-config
ボリュームには、TimesTenClassicオブジェクトのdbConfigMap
フィールドとdbSecret
フィールドで指定されたすべてのConfigMapのコンテンツとすべてのシークレットが含まれています。このボリュームはTimesTenコンテナに/ttconfig
としてマウントされます。
次の2つの例は、ConfigMapおよびシークレットの使用方法を示しています。
この例では、db.ini
、adminUser
およびschema.sql
メタデータ・ファイルに1つのConfigMap (sample
という名前)を使用します。
Linux開発ホストで、次のことを実行します。
選択したディレクトリから、メタデータ・ファイル用に空のサブディレクトリを作成します。この例では、cm_sample
サブディレクトリを作成します。(この例ではこれ以降、このディレクトリを示すためにcm_sample
ディレクトリを使用します。)
% mkdir -p cm_sample
ConfigMapディレクトリに移動します。
% cd cm_sample
このConfigMapディレクトリ(この例ではcm_sample
)にdb.ini
ファイルを作成します。このdb.ini
ファイルで、PermSize
接続属性とDatabaseCharacterSet
接続属性を定義します。
vi db.ini
PermSize=200 DatabaseCharacterSet=AL32UTF8
このConfigMapディレクトリ(この例ではcm_sample
)にadminUser
ファイルを作成します。このadminUser
ファイルで、tiger
パスワードを使用してscott
ユーザーを作成します。
vi adminUser
scott/tiger
このConfigMapディレクトリ(この例ではcm_sample
)にschema.sql
ファイルを作成します。このschema.sql
ファイルで、scott
ユーザーのs
順序とemp
表を定義します。オペレータはこれらのオブジェクト定義でデータベースを自動的に初期化します。
vi schema.sql
create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) );
ConfigMapを作成します。cm_sample
ディレクトリ内のファイルはConfigMapに組み込まれ、後でTimesTenコンテナで使用できます。
この例では次のとおりです。
ConfigMapの名前はsample
です。sample
を選択した名前に置き換えます(この例では、sample
は太字で表示されています)。
この例では、ConfigMapにコピーされるファイルが存在するディレクトリとしてcm_sample
を使用しています。別のディレクトリを使用する場合は、cm_sample
を使用するディレクトリの名前に置き換えます。(この例では、cm_sample
は太字で表示されています。)
kubectl
create
コマンドを使用して、ConfigMapを作成します。
% kubectl create configmap sample --from-file=cm_sample configmap/sample created
kubectl
describe
コマンドを使用して、ConfigMapのコンテンツを確認します。(この例ではsample
。)
% kubectl describe configmap sample Name: sample Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== adminUser: ---- scott/tiger db.ini: ---- PermSize=200 DatabaseCharacterSet=AL32UTF8 schema.sql: ---- create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) ); Events: <none>
sample
ConfigMapを正常に作成し、デプロイしました。
TimesTenClassicのオブジェクト定義にConfigMapを含めます。dbConfigMap
フィールドで、ConfigMapの名前を指定します(この例では、太字で表示されているsample
)。
この例では、250G
のstorageSize
を使用します(本番環境に適しています)。デモ用の場合は、50G
のstorageSize
で対応できます。詳細は、表11-3「TimesTenClassicSpecSpec」のstorageSize
エントリとlogStorageSize
エントリを参照してください。
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
name: sample
spec:
ttspec:
storageClassName: oci
storageSize: 250G
image: phx.ocir.io/youracount/tt1814110:3
imagePullSecret: sekret
dbConfigMap:
- sample
sample
ConfigMapはメタデータ・ファイルを保持します。tt-config
ボリュームには、sample
ConfigMapのコンテンツが含まれています。
dbConfigMap
属性の詳細は、TimesTenClassicSpecSpecを参照してください。TimesTenClassicオブジェクトの作成の詳細は、TimesTenClassicオブジェクトの定義および作成を参照してください。
この例では、db.ini
メタデータ・ファイルに1つのConfigMap (myconfig
という名前)を、adminUser
およびschema.sql
メタデータ・ファイルに1つのシークレット(mysecret
という名前)を使用します。
Linux開発ホストで、次のことを実行します。
選択したディレクトリから次のことを実行します。
ConfigMap用に空のサブディレクトリを1つ作成します。この例では、cm_myconfig
サブディレクトリを作成します。(この例ではこれ以降、このディレクトリを示すためにcm_myconfig
ディレクトリを使用します。)このディレクトリにはdb.ini
メタデータ・ファイルが格納されます。
シークレット用に2つ目の空のサブディレクトリを作成します。この例では、secret_mysecret
サブディレクトリを作成します。(この例ではこれ以降、このディレクトリを示すためにsecret_mysecret
ディレクトリを使用します。)このディレクトリには、adminUser
およびschema.sql
メタデータ・ファイルが格納されます。
% mkdir -p cm_myconfig % mkdir -p secret_mysecret
ConfigMapディレクトリに移動します。
% cd cm_myconfig
このConfigMapディレクトリ(この例ではcm_myconf
)にdb.ini
ファイルを作成します。このdb.ini
ファイルで、PermSize
接続属性とDatabaseCharacterSet
接続属性を定義します。
vi db.ini
PermSize=200 DatabaseCharacterSet=AL32UTF8
Secretディレクトリに移動します。
% cd secret_mysecret
このSecretディレクトリ(この例ではsecret_mysecret
)にadminUser
ファイルを作成します。このadminUser
ファイルで、tiger
パスワードを使用してscott
ユーザーを作成します。
vi adminUser
scott/tiger
このSecretディレクトリ(この例ではsecret_mysecret
)にschema.sql
ファイルを作成します。このschema.sql
ファイルで、scott
ユーザーのs
順序とemp
表を定義します。オペレータはこれらのオブジェクト定義でデータベースを自動的に初期化します。
vi schema.sql
create sequence scott.s; create table scott.emp ( id number not null primary key, name char(32) );
ConfigMapを作成します。cm_myconfig
ディレクトリ内のファイルはConfigMapに組み込まれ、後でTimesTenコンテナで使用できます。
この例では次のとおりです。
ConfigMapの名前はmyconfig
です。myconfig
を選択した名前に置き換えます(この例では、myconfig
は太字で表示されています)。
この例では、ConfigMapにコピーされるファイルが存在するディレクトリとしてcm_myconfig
を使用します。別のディレクトリを使用する場合は、cm_myconfig
を使用するディレクトリの名前に置き換えます。(この例では、cm_myconfig
は太字で表示されています。)
kubectl
create
コマンドを使用して、ConfigMapを作成します。
% kubectl create configmap myconfig --from-file=cm_myconfig configmap/myconfig created
myconfig
ConfigMapを正常に作成し、デプロイしました。
kubectl
describe
コマンドを使用して、ConfigMapのコンテンツを確認します。(この例ではmyconfig
。)
% kubectl describe configmap myconf Name: myconfig Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== db.ini: ---- PermSize=200 DatabaseCharacterSet=AL32UTF8 Events: <none>
シークレットを作成します。secret_mysecret
ディレクトリ内のファイルはシークレットに組み込まれ、後でTimesTenコンテナで使用できます。
この例では次のとおりです。
シークレットの名前はmysecret
です。mysecret
を選択した名前に置き換えます(この例では、mysecret
は太字で表示されています)。
この例では、シークレットにコピーされるファイルが置かれるディレクトリとしてsecret_mysecret
を使用します。別のディレクトリを使用する場合は、secret_mysecret
を使用するディレクトリの名前に置き換えます。(この例では、secret_mysecret
は太字で表示されています。)
kubectl
create
コマンドを使用してシークレットを作成します。
% kubectl create secret generic mysecret --from-file=secret_mysecret secret/mysecret created
mysecret
シークレットを正常に作成し、デプロイしました。
kubectl
describe
コマンドを使用してシークレット(この例ではmysecret
)を表示します。adminUser
およびschema.sql
ファイルの内容は表示されないことに注意してください。
% kubectl describe secret mysecret Name: mysecret Namespace: mynamespace Labels: <none> Annotations: <none> Type: Opaque Data ==== adminUser: 12 bytes schema.sql: 98 bytes
TimesTenClassicオブジェクト定義にConfigMapおよびシークレットを含めます。
dbConfigMap
フィールドで、ConfigMapの名前を指定します(この例では、太字で表示されているmyconfig
)。
dbSecret
フィールドで、シークレットの名前を指定します(この例では、太字で表示されているmysecret
)。
apiVersion: timesten.oracle.com/v1 kind: TimesTenClassic metadata: name: sample spec: ttspec: storageClassName: oci storageSize: 250G image: phx.ocir.io/youracount/tt1814110:3 imagePullSecret: sekret dbConfigMap: - myconfig dbSecret: - mysecret
myconfig
ConfigMapおよびmysecret
シークレットは、メタデータ・ファイルを保持します。tt-config
ボリュームには、myconfig
ConfigMapおよびmysecret
シークレットのコンテンツが含まれます。
dbConfigMap
属性とdbSecret
属性の詳細は、TimesTenClassicSpecSpecを参照してください。TimesTenClassicオブジェクトの作成の詳細は、TimesTenClassicオブジェクトの定義および作成を参照してください。
初期化コンテナを使用して、メタデータ・ファイルをTimesTenコンテナの/ttconfig
ディレクトリに取得できます。初期化コンテナでは、独自のスクリプトを作成して、/ttconfig
ディレクトリにメタデータ・ファイルを移入できます。初期化コンテナの詳細は、次を参照してください。
https://kubernetes.io/docs/concepts/workloads/pods/init-containers
この例は、初期化コンテナの使用方法を示しています。/ttconfig
ディレクトリ(太字で表示)に移入するスクリプトを指定する場所を示します。また、TimesTenClassicオブジェクトのvolumes
フィールドでtt-config
ボリューム名を使用します。tt-config
名でボリュームを指定すると、TimesTenコンテナの/ttconfig
に自動的にマウントされます。volumes
(太字で表示)を参照してください。
TimesTenClassicオブジェクトの作成の詳細は、TimesTenClassicオブジェクト・タイプおよびデプロイメント・プロセスの理解を参照してください。
apiVersion: timesten.oracle.com/v1 kind: TimesTenClassic metadata: name: init1 spec: ttspec: storageClassName: oci storageSize: 250G image: phx.ocir.io/youraccount/tt1814110:3 imagePullSecret: sekret template: spec: imagePullSecrets: - name: sekret initContainers: - name: init1a image: phx.ocir.io/youraccount/tt1814110:3 command: - sh - "-c" - | /bin/bash <<'EOF' Your script to populate /ttconfig goes here EOF volumeMounts: - name: tt-config mountPath: /ttconfig volumes: - name: tt-config emptyDir: {}
この項では、詳細構成オプションについて説明します。これらは環境のオプションの構成です。
オペレータは、TimesTenClassicオブジェクトと同じ名前のKubernetes StatefulSetオブジェクトを作成します。StatefulSetは、1つ以上のPersistentVolumeClaimsを、作成するポッドごとに関連付けます。これにより、関連ボリュームが各ポッドにマウントされます。これらのボリュームは、ポッドのインスタンス化後も保持されます。ポッドに障害が発生した場合、Kubernetesが新しいポッドを作成し、障害の発生したポッドと置き換えても、ポッドがこれらのボリュームに作成したファイルは残ります。
TimesTenClassicオブジェクトの作成時には、storageClassName
を指定する必要があり、storageSize
を指定できます。これらの属性によって、PersistentVolumesの特性が決まります。
storageClassName
は、使用しているKubernetes環境によって提供されるものである必要があります。たとえば、Oracle Kubernetes環境(OKE)では、oci
を使用できます。
OKEでは、デフォルトで50G
の記憶域が要求されます。別のサイズを要求するには、storageSize
属性を使用します。この項の例では、50G
より大きいstorageSize
とlogStorageSize
を使用します。50G
の記憶域はデモ目的に対応できますが、本番環境では、より大きな記憶域を検討してください。詳細は、表11-3「TimesTenClassicSpecSpec」のstorageSize
エントリとlogStorageSize
エントリを参照してください。
TimesTenによって、TimesTenインストール、インスタンスおよびデータベースがこの記憶域に配置されます。それは、各ポッドの各コンテナに/tt
としてマウントされます。TimesTenインスタンスは/tt/home/oracle/instances/instance1
にあります。
TimesTenのベスト・プラクティスでは、TimesTenデータベースに関連付けられたトランザクション・ログ・ファイルを、データベースのチェックポイント・ファイルとは異なる記憶域ボリュームに配置することをお薦めします。これにより、チェックポイントとトランザクション・ログ操作に記憶域への個別のパスが提供されます。たとえば、トランザクション・ログ・ファイルをパフォーマンスの高い記憶域に格納し、チェックポイント・ファイルを低速の記憶域に格納できます。詳細は、Oracle TimesTen In-Memory Databaseオペレーション・ガイドの個別の物理デバイスへのチェックポイントおよびトランザクション・ログ・ファイルの配置を参照してください。
チェックポイント・ファイルとトランザクション・ログ・ファイルを別の記憶域パスに配置するには、トランザクション・ログ・ファイルのみに使用される、2番目の永続記憶域の値を指定します。このためにはlogStorageSize
属性を使用し、logStorageClassName
属性を使用してその配置を制御します。これにより、各ポッドに対して2番目のPersistentVolumeClaimが作成され、/ttlog
の各コンテナで使用可能になります。(この2番目の記憶域ボリュームには/ttlog
マウント・ポイントがあります。)
詳細は、TimesTenClassicオブジェクト・タイプおよびデプロイメント・プロセスの理解を参照してください。
次に例を示します。
apiVersion: timesten.oracle.com/v1 kind: TimesTenClassic metadata: name: sample spec: ttspec: storageClassName: slower storageSize: 750G logStorageClassName: faster logStorageSize: 200G
tt
コンテナとdaemonlog
コンテナの特定のリソース要件を指定できます。たとえば、tt
コンテナには、4つのCPUと20GBのRAMが必要になることをKubernetesに通知できます。
そうするには、TimesTenClassicオブジェクトのcontainers
要素にtt
とdaemonlog
の両方のコンテナまたはどちらかのコンテナを指定します。そうすることで、これらのコンテナのリソース・データ項目は、オペレータが作成したStatefulSet内のコンテナの定義にオペレータによって逐語的にコピーされます。リソース以外のデータ項目は無視されます。tt
コンテナにリソースを指定しないと、リソース項目は空になります。デフォルト値はありません。
TimesTenのメモリーおよびディスク要件は、その他の環境のKubernetesと同じです。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenの記憶域のプロビジョニングに関する項を参照してください。
daemonlog
コンテナにリソースを指定しない場合は、デフォルト設定があります。(値の大/小文字は区別されます。たとえば、"20Mi"
は有効ですが、"20mi"
は無効です)。
デフォルトは次のとおりです。
memory:"
20Mi
"
cpu:"
100m
"
この例では、tt
コンテナとdaemonlog
コンテナのリソース要件(太字で表示)を指定する方法を示します。
apiVersion:timesten.oracle.com/v1 kind:TimesTenClassic metadata: name:sample spec: ttspec: storageClassName:oci storageSize:250G image:... imagePullSecret:... template: spec: containers: - name:tt resources: requests: memory:"512Mi" cpu: "1000m" limits: memory:"768Mi" cpu: "2000m" - name:daemonlog resources: requests: memory:"40Mi" cpu: "200m"
オペレータは、高可用性を提供するために使用できるTimesTenデータベースのレプリケート・ペアを構成します。ただし、適切なレベルの高可用性を提供するために、Kubernetesクラスタ内でのTimesTenポッドの配置を制御できます。たとえば、TimesTenポッドを異なる可用性ゾーンで使用できるようにしたり、異なるKubernetesノード上に存在するようにできます。
各環境の要件が異なる場合、オペレータはポッド配置を制御しようとしません。ただし、TimesTenClassicオブジェクトの仕様のテンプレートでaffinity
オプションを指定することで、これを行うことができます。オペレータは作成したStatefulSetにテンプレートを渡します。
詳細は、TimesTenClassicオブジェクト・タイプおよびデプロイメント・プロセスの理解を参照してください。
次に例を示します。
apiVersion: timesten.oracle.com/v1 kind: TimesTenClassic metadata: name: sample spec: … template: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 podAffinityTerm: labelSelector: matchExpressions: - key: "app" operator: In values: - ds1 topologyKey: "kubernetes.io/hostname"