Container Images

The dxd container image contains a complete, standalone DirX Directory installation with all the server and client binaries. As in a standard Linux installation, the servers are automatically started by the dirxdsas process, which serves as the container entry point. The container image uses the UID 5000 and GUID 5000 to run the server.

The dxd container image is based on scratch, meaning no operating system is included. It contains all server and client binaries, including DSA, LDAP server, HTTP server, and associated tools.

In addition to the full image, DirX Directory delivers per-server container images. Each per-server image contains only the respective server binary and its dependencies. The following per-server images are available:

These images are intended to be used in the scalable example Kubernetes project or other custom deployments where separate per-server images are required. Like the full image, the per-server images use the UID 5000 and GUID 5000 to run the server.

The dirxcontroller container image is responsible for managing DSA replication in the scalable example project. It runs as a Kubernetes CronJob and performs reconciliation tasks such as creating and removing shadowing agreements and scaling the stateful set replicas.

The DirX Directory container images are delivered with a single container image tag that contains the full version number; for example, dxd:9.7.317. By default, no other tag is provided. Additional tags can be created in the target system’s image registry as necessary.

The dxd and dirxdsa container images only support using a file-based DBAM database. Database files can be automatically created by implementing the logic in an initialization script, or they can be initialized by running a DirX Directory container image in which the database files can be created.

In addition to the database and translog files, the following files must also be persisted:

As these files are read and modified by the servers and tools, they must be persisted using a volume with read and write permissions like the database files. By default, these files are stored in the $DIRX_INST_PATH/server/conf folder. However, in a containerized environment, configuration files and folders are usually mounted with read-only permissions. To solve this problem, you can use the DIRX_SYNC_FILE_PATH and DIRX_DBAM_PROFILE_PATH environment variables to configure the paths for these files so that they are stored in read-write locations, either with the DBAM database and translog files or on a separate read-write volume. See the environment configuration in the example Kubernetes projects for details.

In a containerized environment, secrets are typically mounted as read-only volumes. The DirX Directory servers automatically encrypt .pwd files. If a password file is mounted as read-only and is not already encrypted, the encryption will fail.

To solve this issue, password files must be encrypted before they are added to the container configuration. The example Kubernetes projects deliver an executable called dirxencryptpwd that can be used to encrypt password files beforehand. All .pwd files used in secrets must contain the already-encrypted password.