About Using Direct Mode Applications

You can run direct mode applications inside of the Pods in your TimesTenClassic and TimesTenScaleout deployments.

When configured in your TimesTenClassic deployment, each Pod in your active standby pair runs two or more containers. When configured in your TimesTenScaleout deployment, each Pod containing a data instance runs two or more containers. One container in each Pod runs TimesTen and the TimesTen agent and the other container(s) run whatever applications you choose. The applications that are running in your containers can use TimesTen in direct mode. For information on direct mode applications, see Managing TimesTen Databases in the Oracle TimesTen In-Memory Database Operations Guide.

TimesTen Pods are created with the Kubernetes shareProcessNamespace option. This option allows direct mode applications running in other containers within the same Pod to function properly.

Note:

The standard security issues that surround direct mode apply in this environment as in a non-Kubernetes environment. Segregating your applications into separate containers from TimesTen is intended for ease of management and ease of upgrade. It is not intended as a security barrier and provides no additional security.

Use the .spec.template.spec.containers attribute of your TimesTenClassic object or the .spec.dataTemplate.spec.containers of your TimesTenScaleout object to cause one or more containers to be created within each of the TimesTen Pods that runs the tt container. Such containers are created in addition to the tt container that runs TimesTen.

This example illustrates how to include the .spec.template.spec.containers attribute in your TimesTenClassic object definition. For a TimesTenScaleout object, replace template with one or more dataTemplates.

apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
  name: directmode
spec:
  ttspec:
    storageClassName: oci-bv
    storageSize: 250Gi
    image: container-registry.oracle.com/timesten/timesten:22.1.1.19.0
    imagePullSecret: sekret
    dbConfigMap:
    - directmode
  template:
    spec:
      containers:
      - name: yourapp
        image: phx.ocir.io/youraccount/yourapplication:2
        command: ["/bin/yourapp"]
      - name: anotherapp
        image: phx.ocir.io/youraccount/anotherapplication:2
        command: ["/bin/anotherapp"]

You can specify any other Kubernetes configuration for these containers.

The Operator automatically adds appropriate mounts to the containers. This gives your containers the ability to access TimesTen.

To use TimesTen in direct mode, your application containers must know how TimesTen is configured in the tt container. You must configure your application containers similarly.

In particular:

  • You must know the name of the TimesTen users group. If you are using a container image located at container-registry.oracle.com/timesten, the name of the TimesTen users group is timesten. If you built the TimesTen container image, and changed the timesten default, ensure you use the name you used when you built the container image. See Option 2b: Build with Customizations and Dockerfile ARGs.

  • You must know the name of the Linux operating system user that runs TimesTen. The default is timesten. As was mentioned in the previous bullet, if you changed this default, ensure you use the name you used when you built the container image.

  • You must configure your application containers to run your applications as a member of the TimesTen users group. Only members of this group can run TimesTen in direct mode.

  • You can run your direct mode applications as a user with the same UID as that of the TimesTen user that runs TimesTen (3429 is the default) . However, this grants the application instance administrator permissions on the TimesTen instance. Alternatively, you can create a group with the same GID as that of the TimesTen users group of and then create a user whose primary or secondary group is that group, but with a UID that is not the UID of the TimesTen user that is running TimesTen. In this case, you can run your application as this user and also use TimesTen in direct mode. You can then grant this user privileges up to and including the ADMIN privilege. For more information on primary and secondary groups, see Creating an Installation on Linux/UNIX in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide. For information on TimesTen privileges, see System Privileges and Object Privileges in the Oracle TimesTen In-Memory Database SQL Reference.

  • The direct mode application must use the TimesTen instance that is configured at /tt/home/timesten/instances/instance1. The scripts to configure the TimesTen environment variables are located at /tt/home/timesten/instances/instance1/bin/ttenv.*.

  • Do not modify any file that is located in the TimesTen instance. In addition, ensure you do not create any new files in the $TIMESTEN_HOME directory tree of the instance.

  • Do not add entries to the /tt/home/timesten/instances/instance1/conf/sys.odbc.ini file. These files can be overwritten by the Operator. However, you can store your own DSN entries in the $HOME/.odbc.ini file located in your application container.

  • Do not create additional TimesTen databases.

Kubernetes, not the Operator, is responsible for monitoring and managing the life cycle of the direct mode containers. In particular:

  • Applications are started by Kubernetes regardless of the state of TimesTen (located in its own container). Kubernetes manages the life cycle of containers individually. It does not sequence. Your application must know how to wait for TimesTen to become available.

  • For a TimesTenClassic object, a direct mode application runs in the Pod containing the active TimesTen database and in the Pod containing the standby TimesTen database. The application may need to use the ttRepStateGet built-in procedure to determine whether it is running on the active or on the standby and perhaps quiesce itself on the standby. For more information on the ttRepStateGet built-in procedure, see ttRepStateGet in the Oracle TimesTen In-Memory Database Reference.

  • Kubernetes may start the application before the TimesTen database exists or before it is loaded into memory and ready for use. It is the responsibility of the direct mode application to verify the state of the TimesTen database in its Pod and to use it appropriately.

  • If your application exits, the container terminates, and Kubernetes spawns another container. This does not impact TimesTen that is running in the tt container.