1 of 3

Enabling the option to write output data to container artifacts

For PostgreSQL and MySQL workspaces, you can configure Tonic Structural to write destination data to a container artifact instead of to a database server. For more information, go to Writing output to a container repository.

If Structural is deployed on Kubernetes, then the option is supported automatically.

If Structural is deployed on Docker, then to enable the option, you can set up a separate Kubernetes cluster to use specifically for that purpose.

Setting up a Kubernetes cluster to use to write output data to container artifacts

A Docker instance of Tonic Structural does not automatically support the option to write destination data to a container artifact.

To enable this option, you can set up a separate Kubernetes cluster. You then configure Structural environment settings to enable Structural to use that Kubernetes cluster as the destination location.

Installing the Kubernetes cluster

You can install the Kubernetes cluster on the same server where Docker is installed, or on a remote host that has network access to the Docker server.

You can use any compatible Kubernetes distribution. Here are links to the installation instructions for a few different options that will work:

The Structural service account must have the permissions listed in Required access to write destination data to container artifacts.

Setting the host location in the mounted kubeconfig

In the kubeconfig file, you must change the server property value from localhost to either:

If the cluster is remote, the Kubernetes host IP address or hostname
If the cluster is on the same host, to host.docker.internal

clusters:
- cluster:
certificate-authority-data: ...
server: <IP address or hostname, or host.docker.internal>
name: ..

Configuring Structural environment settings

To allow Structural to connect to the Kubernetes cluster and to write destination data to it, you must configure the following environment settings.

You can add these settings manually to the list on the Environment Settings tab of Structural Settings.

Setting

Description

CONTAINERIZATION_USE_REMOTE_KUBERNETES

Whether Structural can write destination data to a remote Kubernetes cluster.

Set this to true.

CONTAINERIZATION_PULL_SECRET

A base64 encoded Docker secret used to pull datapacker images.

This should be the same pull secret that you use to pull other images from Tonic.

CONTAINERIZATION_IMAGE_REPOSITORY

The repository where the base images are located.

If you use the images provided by Structural, then you do not need to set this.

CONTAINERIZATION_REMOTE_KUBERNETES_HOST

IP address or hostname of the host for the Kubernetes cluster. If you installed Kubernetes on the same host as Docker, then you do not need to set this.

CONTAINERIZATION_MANAGE_NAMESPACE

Whether to allow Structural to manage the remote namespace.

If you set this to true, then you can include {workspaceId} and {jobId} as placeholders in the value of CONTAINERIZATION_NAMESPACE.

CONTAINERIZATION_NAMESPACE

The namespace where Structural writes the destination data.

If CONTAINERIZATION_MANAGE_NAMESPACE is true, then the namespace can include the placeholders {workspaceId} and {jobId} to represent the specific workspace identifier and data generation job identifier.

Specifying the kubeconfig path

To allow Structural to write output data to the Kubernetes cluster, Structural also needs the path where kubeconfig is mounted to the Structural worker.

In the Docker Compose file, to specify the kubeconfig path, add the KUBECONFIG environment variable to the tonic_worker environment section.

tonic_worker:
  environment:
    KUBECONFIG: <fully qualified kubeconfig path>

Required access to write destination data to container artifacts

To enable Tonic Structural to write destination data to container artifacts, the Structural service account requires specific levels of access to Kubernetes.

The required access applies both on a Kubernetes cluster where Structural is deployed and, for Docker instances, on the .

Rolebinding with required access

On the Kubernetes cluster, the Structural service account must be granted a rolebinding that grants the following access to the Structural Kubernetes cluster:

On a Kubernetes instance of Structural, you can allow Structural to create the rolebinding automatically. In the Structural Helm chart, the following setting determines whether to have Structural automatically create and grant the rolebinding. By default, the setting is true.

If your access management method does not allow you to use this default configuration, then:

Change the setting to false.
Create and grant the rolebinding.

Additional rbac grant for a separate Kubernetes cluster

For a separate Kubernetes cluster, the environment setting CONTAINERIZATION_MANAGE_NAMESPACE indicates whether to allow Structural to manage the remote namespace.

If the setting is true, then you must add the following rbac grant to enable the Structural service account to manage namespaces.