Chapter 14. Database Images

The rhscl/mariadb-105-rhel7 image provides a MariaDB 10.5 SQL database server.

To pull the rhscl/mariadb-105-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/mariadb-105-rhel7

The usage and configuration is the same as for the MySQL image. Note that the name of the daemon is mysqld and all environment variables have the same names as in MySQL.

The image recognizes the following environment variables that you can set during initialization by passing the -e VAR=VALUE option to the podman run command:

The following environment variables influence the MySQL configuration file and are all optional:

When the MariaDB image is run with the --memory parameter set, values of the following parameters will be automatically calculated based on the available memory unless the parameters are explicitly specified:

You can also set the following mount point by passing the -v /host:/container option to the podman run command:

See How to Extend the rhscl/mariadb-101-rhel7 Container Image, which is applicable also to rhscl/mariadb-105-rhel7.

The rhscl/mysql-80-rhel7 image provides a MySQL 8.0 SQL database server.

To pull the rhscl/mysql-80-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/mysql-80-rhel7

To set only the mandatory environment variables and not store the database in a host directory, execute the following command:

# podman run -d --name mysql_database -e MYSQL_USER=<user> -e MYSQL_PASSWORD=<pass> \
  -e MYSQL_DATABASE=<db> -p 3306:3306 rhscl/mysql-80-rhel7

This will create a container named mysql_database running MySQL with database db and user with credentials user:pass. Port 3306 will be exposed and mapped to the host. If you want your database to be persistent across container executions, also add a -v /host/db/path:/var/lib/mysql/data argument. The directory /host/db/path will be the MySQL data directory.

If the database directory is not initialized, the entrypoint script will first run mysql_install_db and set up necessary database users and passwords. After the database is initialized, or if it was already present, mysqld is executed and will run as PID 1. You can stop the detached container by running the podman stop mysql_database command.

The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the podman run command:

The following environment variables influence the MySQL configuration file and are all optional:

When the MySQL image is run with the --memory parameter set, values of the following parameters will be automatically calculated based on the available memory unless the parameters are explicitly specified:

You can also set the following mount point by passing the -v /host:/container option to the podman run command:

The rhscl/postgresql-13-rhel7 image provides a PostgreSQL 13 SQL database server; the rhscl/postgresql-12-rhel7 image provides a PostgreSQL 12 server, and the rhscl/postgresql-10-rhel7 image provides a PostgreSQL 10 server.

To pull the rhscl/postgresql-13-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/postgresql-13-rhel7

To pull the rhscl/postgresql-12-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/postgresql-12-rhel7

To pull the rhscl/postgresql-10-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/postgresql-10-rhel7

To set only the mandatory environment variables and not store the database in a host directory, execute the following command:

# podman run -d --name postgresql_database -e POSTGRESQL_USER=<user> \
  -e POSTGRESQL_PASSWORD=<pass> -e POSTGRESQL_DATABASE=<db> \
  -p 5432:5432 <image_name>

This will create a container named postgresql_database running PostgreSQL with database db and user with credentials user:pass. Port 5432 will be exposed and mapped to the host. If you want your database to be persistent across container executions, also add a -v /host/db/path:/var/lib/pgsql/data argument. This will be the PostgreSQL database cluster directory.

If the database cluster directory is not initialized, the entrypoint script will first run initdb and set up necessary database users and passwords. After the database is initialized, or if it was already present, postgres is executed and will run as PID 1. You can stop the detached container by running the podman stop postgresql_database command.

The the postgres daemon first writes its logs to the standard output. To examine the container image log, use the podman logs <image_name> command. Then the log output is redirected to the logging collector process and appears in the pg_log/ directory.

The image recognizes the following environment variables that you can set during initialization by passing -e VAR=VALUE to the podman run command:

The following options are related to migration:

The following environment variables influence the PostgreSQL configuration file and are all optional:

You can also set the following mount point by passing the -v /host:/container option to the podman run command:

Unless you use the -u option with the podman run command, processes in containers are usually run under UID 26. To change the data directory permissions, use the following command:

$ setfacl -m u:26:-wx /your/data/dir
$ podman run <...> -v /your/data/dir:/var/lib/pgsql/data:Z <...>

PostgreSQL container images support migration of data from a remote PostgreSQL server. Use the following command and change the image name and add optional configuration variables when necessary:

$ podman run -d --name postgresql_database \
    -e POSTGRESQL_MIGRATION_REMOTE_HOST=172.17.0.2 \
    -e POSTGRESQL_MIGRATION_ADMIN_PASSWORD=remoteAdminP@ssword \
    [ OPTIONAL_CONFIGURATION_VARIABLES ]
    rhscl/postgresql-12-rhel7

The migration is done the dump and restore way (running pg_dumpall against a remote cluster and importing the dump locally by psql). Because the process is streamed (unix pipeline), there are no intermediate dump files created during this process to not waste additional storage space.

If some SQL commands fail during applying, the default behavior of the migration script is to fail as well to ensure the "all or nothing" result of a scripted, unattended migration. In most common cases, successful migration is expected (but not guaranteed), given you migrate from a previous version of PostgreSQL server container, which is created using the same principles - for example, migration from rhscl/postgresql-10-rhel7 to rhscl/postgresql-12-rhel7. Migration from a different kind of PostgreSQL container image will likely fail.

If this "all or nothing" principle is inadequate for you, there is an optional POSTGRESQL_MIGRATION_IGNORE_ERRORS option which peforms "best effort" migration. However, some data might be lost and it is up to the user to review the standard error output and fix issues manually in the post-migration time.

You might not use variables such as POSTGRESQL_USER in the migration scenario. All data (including information about databases, roles, or passwords) are copied from the old cluster. Ensure that you use the same optional configuration variables as you used for initialization of the old PostgreSQL container image. If some non-default configuration is done on a remote cluster, you might need to copy the configuration files manually, too.

The PostreSQL image supports automatic upgrade of a data directory created by the PostgreSQL server version provided by the previous rhscl image, for example, the rhscl/postgresql-13-rhel7 image supports upgrading from rhscl/postgresql-12-rhel7. The upgrade process is designed so that you should be able to just switch from image A to image B, and set the $POSTGRESQL_UPGRADE variable appropriately to explicitly request the database data transformation.

The upgrade process is internally implemented using the pg_upgrade binary, and for that purpose the container needs to contain two versions of PostgreSQL server (see the pg_upgrade man page for more information).

For the pg_upgrade process and the new server version, it is necessary to initialize a new data directory. This data directory is created automatically by the container tooling in the /var/lib/pgsql/data/ directory, which is usually an external bind-mountpoint. The pg_upgrade execution is then similar to the dump and restore approach. It starts both the old and the new PostgreSQL servers (within the container) and "dumps" the old data directory and, at the same time, it "restores" it into new data directory. This operation requires a lot of data files copying. Set the $POSTGRESQL_UPGRADE variable accordingly based on what type of upgrade you choose:

The PostgreSQL image can be extended using using source-to-image.

For example, to build a customized new-postgresql image with configuration in the ~/image-configuration/ directory, use the following command:

$ s2i build ~/image-configuration/ postgresql new-postgresql

The directory passed to the S2I build should contain one or more of the following directories:

During the S2I build, all provided files are copied into the /opt/app-root/src/ directory in the new image. Only one file with the same name can be used for customization, and user-provided files are preferred over default files in the /usr/share/container-scripts/ directory, so it is possible to overwrite them.

The rhscl/redis-6-rhel7 image provides Redis 6, an advanced key-value store.

To pull the rhscl/redis-6-rhel7 image, run the following command as root:

# podman pull registry.redhat.io/rhscl/redis-6-rhel7

To set only the mandatory environment variables and not store the database in a host directory, run:

# podman run -d --name redis_database -p 6379:6379 rhscl/redis-6-rhel7

This command creates a container named redis_database. Port 6379 is exposed and mapped to the host.

The following environment variable influences the Redis configuration file and is optional:

To set a password, run:

# podman run -d --name redis_database -e REDIS_PASSWORD=strongpassword rhscl/redis-6-rhel7

To make your database persistent across container executions, add the -v /host/db/path:/var/lib/redis/data:Z option to the podman run command.

To examine the container image log, use the podman logs <image_name> command.