Populate the /ttconfig Directory
You can use different methods to ensure metadata files are placed in the /ttconfig directory of TimesTen containers. There is no requirement as to which method to use. Kubernetes provides such facilities as ConfigMaps, Secrets, and init containers for you to consider.
Using ConfigMaps and Secrets
You can use one or more ConfigMaps and one or more Secrets to incorporate metadata files into the TimesTen containers. This lets you specify different TimesTen metadata for different deployments. In addition, you can use Secrets for metadata that contains sensitive data, like passwords and certificates.
The use of a ConfigMap to populate the metadata into Pods is a standard Kubernetes technique. One benefit is that you can modify the ConfigMap after it is created, which results in the immediate update of the files that are in the Pod.
Note:
TimesTen may not immediately notice and act on the changed content of the files.
When you use ConfigMaps and Secrets to hold your metadata and then reference them in the TimesTenClassic object definition, the TimesTen Operator creates a Projected Volume called tt-config. This tt-config volume contains the contents of all the ConfigMaps and all the Secrets specified in the dbConfigMap and the dbSecret fields of your TimesTenClassic or your TimesTenScaleout object. This volume is mounted as /ttconfig in the TimesTen containers.
Note:
You can specify one or more ConfigMaps and/or Secrets in your TimesTenClassic or TimesTenScaleout object using thedbConfigMap and dbSecret datum. The result is that these ConfigMaps and/or Secrets are mounted read-only at /ttconfig. Since such a mount is read-only, you cannot write into it from an init container. Alternatively, you can use an emptydir volume and use an init container to write files into it. However, you cannot combine ConfigMaps and Secrets with an init container. For information about using an init container, see Using an init container.
To use ConfigMaps and Secrets, follow this process:
-
Decide what facilities will contain what metadata files. For example, you can use one ConfigMap for all the metadata files. Or, for example, you can use one ConfigMap for the
db.inimetadata file and one Secret for theadminUserand theschema.sqlmetadata files. There is no specific requirement. -
Create the directory (or directories) that will contain the metadata files.
-
Use the
kubectlcreatecommand to create the ConfigMap and the Secrets in the Kubernetes cluster. -
Include the ConfigMaps and Secrets in your TimesTenClassic or your TimesTenScaleout object definition.
The following examples illustrate how to use ConfigMaps and Secrets for a TimesTenClassic or a TimesTenScaleout object.
Example Using One ConfigMap
This example uses one ConfigMap (called sample) for the db.ini, the adminUser, and the schema.sql metadata files.
You can use this ConfigMap for a TimesTenClassic or a TimesTenScaleout object.
Example Using One ConfigMap and One Secret
This example uses one ConfigMap (called myconfig) for the db.ini metadata file and one Secret (called mysecret) for the adminUser and the schema.sql metadata files.
You can use this ConfigMap and Secret for a TimesTenClassic or a TimesTenScaleout object.
Example Using One ConfigMap for a TimesTenScaleout Object
This example shows you how to create a metadata file for a direct connectable and a metadata file for a client/server connectable. It then shows you how to include these connectables in a ConfigMap for a TimesTenScaleout object. The ConfigMap also includes the db.ini, adminUser, and schema.sql metadata files.
Using an init container
You can use an init container to place your metadata files into the /ttconfig directory of the TimesTen containers. An init container lets you to create your own scripts to populate the /ttconfig directory. You can use an init container for TimesTenClassic and for TimesTenScaleout objects. For more information about init containers, see:
https://kubernetes.io/docs/concepts/workloads/pods/init-containers
Note:
You can specify one or more ConfigMaps and/or Secrets in your TimesTenClassic or TimesTenScaleout object using thedbConfigMap and dbSecret datum. The result is that these ConfigMaps and/or Secrets are mounted read-only at /ttconfig. Since such a mount is read-only, you cannot write into it from an init container. Alternatively, you can use an emptydir volume and use an init container to write files into it. However, you cannot combine ConfigMaps and Secrets with an init container. For information about using ConfigMaps and Secrets, see Using ConfigMaps and Secrets.
Here is an example that illustrates how to use an init container for a TimesTenClassic object. The template element is required. This element is applied to Pods that contain the TimesTen Classic instances. The example shows you where to specify the script that populates the /ttconfig directory. It also uses the tt-config volume name in the volumes field of the TimesTenClassic object. If you specify a volume with the tt-config name, it is automatically mounted at /ttconfig in your TimesTen containers.
apiVersion: timesten.oracle.com/v4 kind: TimesTenClassic metadata: name: init1 spec: ttspec: storageClassName: oci-bv storageSize: 250Gi image: container-registry.oracle.com/timesten/timesten:22.1.1.34.0 imagePullSecret: sekret template: spec: imagePullSecrets: - name: sekret initContainers: - name: initclassic image: container-registry.oracle.com/timesten/timesten:22.1.1.34.0 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: {}
When using an init container for a TimesTenScaleout object, the metadata files must be placed in both the dataTemplate and the mgmtTemplate elements.