Chapter 10. Database Images

10.1. MariaDB

10.1.1. Description

The rhscl/mariadb-103-rhel7 image provides a MariaDB 10.3 SQL database server, the rhscl/mariadb-102-rhel7 image provides the MariaDB server version 10.2.

10.1.2. Access

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

# podman pull registry.access.redhat.com/rhscl/mariadb-103-rhel7

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

# podman pull registry.access.redhat.com/rhscl/mariadb-102-rhel7

10.1.3. Configuration and Usage

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:

Variable NameDescription

MYSQL_USER

User name for MySQL account to be created

MYSQL_PASSWORD

Password for the user account

MYSQL_DATABASE

Database name

MYSQL_ROOT_PASSWORD

Password for the root user (optional)

Note

The root user has no password set by default, only allowing local connections. You can set it by setting the MYSQL_ROOT_PASSWORD environment variable when initializing your container. This will allow you to login to the root account remotely. Local connections will still not require a password. To disable remote root access, simply unset MYSQL_ROOT_PASSWORD and restart the container.

Important

Because passwords are part of the image configuration, the only supported method to change passwords for an unpriviledged user (MYSQL_USER) and the root user is by changing the environment variables MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD, respectively. Changing database passwords through SQL statements or any other way will cause a mismatch between the values stored in the variables and the actual passwords. Whenever a database container starts, it will reset the passwords to the values stored in the environment variables.

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

Variable nameDescriptionDefault

MYSQL_LOWER_CASE_TABLE_NAMES

Sets how the table names are stored and compared

0

MYSQL_MAX_CONNECTIONS

The maximum permitted number of simultaneous client connections

151

MYSQL_MAX_ALLOWED_PACKET

The maximum size of one packet or any generated/intermediate string

200M

MYSQL_FT_MIN_WORD_LEN

The minimum length of the word to be included in a FULLTEXT index

4

MYSQL_FT_MAX_WORD_LEN

The maximum length of the word to be included in a FULLTEXT index

20

MYSQL_AIO

Controls the innodb_use_native_aio setting value in case the native AIO is broken. See http://help.directadmin.com/item.php?id=529

1

MYSQL_TABLE_OPEN_CACHE

The number of open tables for all threads

400

MYSQL_KEY_BUFFER_SIZE

The size of the buffer used for index blocks

32M (or 10% of available memory)

MYSQL_SORT_BUFFER_SIZE

The size of the buffer used for sorting

256K

MYSQL_READ_BUFFER_SIZE

The size of the buffer used for a sequential scan

8M (or 5% of available memory)

MYSQL_INNODB_BUFFER_POOL_SIZE

The size of the buffer pool where InnoDB caches table and index data

32M (or 50% of available memory)

MYSQL_INNODB_LOG_FILE_SIZE

The size of each log file in a log group

8M (or 15% of available memory)

MYSQL_INNODB_LOG_BUFFER_SIZE

The size of the buffer that InnoDB uses to write to the log files on disk

8M (or 15% of available memory)

MYSQL_DEFAULTS_FILE

Point to an alternative configuration file

/etc/my.cnf

MYSQL_BINLOG_FORMAT

Set sets the binlog format; supported values are row and statement

statement

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:

Variable nameDefault memory percentage

MYSQL_KEY_BUFFER_SIZE

10%

MYSQL_READ_BUFFER_SIZE

5%

MYSQL_INNODB_BUFFER_POOL_SIZE

50%

MYSQL_INNODB_LOG_FILE_SIZE

15%

MYSQL_INNODB_LOG_BUFFER_SIZE

15%

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

Volume Mount PointDescription

/var/lib/mysql/data

MySQL data directory

Note

When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.

10.1.4. Extending the Image

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

10.2. MySQL

10.2.1. Description

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

10.2.2. Access and Usage

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

# podman pull registry.access.redhat.com/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.

10.2.3. Configuration

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

Variable NameDescription

MYSQL_USER

User name for MySQL account to be created

MYSQL_PASSWORD

Password for the user account

MYSQL_DATABASE

Database name

MYSQL_ROOT_PASSWORD

Password for the root user (optional)

Note

The root user has no password set by default, only allowing local connections. You can set it by setting the MYSQL_ROOT_PASSWORD environment variable when initializing your container. This will allow you to login to the root account remotely. Local connections will still not require a password. To disable remote root access, simply unset MYSQL_ROOT_PASSWORD and restart the container.

Important

Because passwords are part of the image configuration, the only supported method to change passwords for an unpriviledged user (MYSQL_USER) and the root user is by changing the environment variables MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD, respectively. Changing database passwords through SQL statements or any other way will cause a mismatch between the values stored in the variables and the actual passwords. Whenever a database container starts, it will reset the passwords to the values stored in the environment variables.

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

Variable nameDescriptionDefault

MYSQL_LOWER_CASE_TABLE_NAMES

Sets how the table names are stored and compared

0

MYSQL_MAX_CONNECTIONS

The maximum permitted number of simultaneous client connections

151

MYSQL_MAX_ALLOWED_PACKET

The maximum size of one packet or any generated/intermediate string

200M

MYSQL_FT_MIN_WORD_LEN

The minimum length of the word to be included in a FULLTEXT index

4

MYSQL_FT_MAX_WORD_LEN

The maximum length of the word to be included in a FULLTEXT index

20

MYSQL_AIO

Controls the innodb_use_native_aio setting value in case the native AIO is broken. See http://help.directadmin.com/item.php?id=529

1

MYSQL_TABLE_OPEN_CACHE

The number of open tables for all threads

400

MYSQL_KEY_BUFFER_SIZE

The size of the buffer used for index blocks

32M (or 10% of available memory)

MYSQL_SORT_BUFFER_SIZE

The size of the buffer used for sorting

256K

MYSQL_READ_BUFFER_SIZE

The size of the buffer used for a sequential scan

8M (or 5% of available memory)

MYSQL_INNODB_BUFFER_POOL_SIZE

The size of the buffer pool where InnoDB caches table and index data

32M (or 50% of available memory)

MYSQL_INNODB_LOG_FILE_SIZE

The size of each log file in a log group

8M (or 15% of available memory)

MYSQL_INNODB_LOG_BUFFER_SIZE

The size of the buffer that InnoDB uses to write to the log files on disk

8M (or 15% of available memory)

MYSQL_DEFAULTS_FILE

Point to an alternative configuration file

/etc/my.cnf

MYSQL_BINLOG_FORMAT

Set sets the binlog format, supported values are row and statement

statement

MYSQL_LOG_QUERIES_ENABLED

To enable query logging, set this variable to 1

0

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:

Variable nameDefault memory percentage

MYSQL_KEY_BUFFER_SIZE

10%

MYSQL_READ_BUFFER_SIZE

5%

MYSQL_INNODB_BUFFER_POOL_SIZE

50%

MYSQL_INNODB_LOG_FILE_SIZE

15%

MYSQL_INNODB_LOG_BUFFER_SIZE

15%

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

Volume Mount PointDescription

/var/lib/mysql/data

MySQL data directory

Note

When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.

10.3. MongoDB

10.3.1. Description

The rhscl/mongodb-36-rhel7 image provides a MongoDB 3.6 NoSQL database server; the rhscl/mongodb-34-rhel7 image provides a MongoDB 3.4 NoSQL database server.

10.3.2. Access and Usage

To pull the rhscl/mongodb-36-rhel7 image, run the following command as root:

# podman pull registry.access.redhat.com/rhscl/mongodb-36-rhel7

To pull the rhscl/mongodb-34-rhel7 image, run the following command as root:

# podman pull registry.access.redhat.com/rhscl/mongodb-34-rhel7

To set only the mandatory environment variables and store the database in the /home/user/database directory on the host file system, execute the following command:

# podman run -d -e MONGODB_USER=<user> -e MONGODB_PASSWORD=<password> \
  -e MONGODB_DATABASE=<database> -e MONGODB_ADMIN_PASSWORD=<admin_password> \
  -v /home/user/database:/var/lib/mongodb/data <image_name>

If you are initializing the database and it is the first time you are using the specified shared volume, two databases will be created with two users: the admin database with the admin user, and the MONGODB_DATABASE with the MONGODB_USER. After that, the MongoDB daemon will be started. If you are re-attaching the volume to another container, the creation of the database user and admin user will be skipped and only the MongoDB daemon will be started.

The mongod deamon writes its logs to the standard output. To examine the container image log, use the podman logs <image_name> command.

10.3.3. Configuration

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

Variable NameDescription

MONGODB_ADMIN_PASSWORD

Password for the admin user

MONGODB_USER

User name for the MONGODB account to be created

MONGODB_PASSWORD

Password for the user account

MONGODB_DATABASE

Database name

Note

The administrator user name is set to admin and you have to to specify the password by setting the MONGODB_ADMIN_PASSWORD environment variable. This process is done upon database initialization. The admin user has the dbAdminAnyDatabase, userAdminAnyDatabase, readWriteAnyDatabase, and clusterAdmin roles (see MongoDB reference for details). An unpriviledged user has only the readWrite role and needs to have a MONGODB_USER and MONGODB_PASSWORD environment variables set.

Important

Because passwords are part of the image configuration, the only supported method to change passwords for an unpriviledged user and the admin user is by changing the environment variables MONGODB_PASSWORD and MONGODB_ADMIN_PASSWORD, respectively. Changing database passwords directly in MongoDB will cause a mismatch between the values stored in the variables and the actual passwords. Whenever a database container image starts, it will reset the passwords to the values stored in the environment variables.

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

Variable NameDescriptionDefault

MONGODB_QUIET

Runs MongoDB in a quiet mode that attempts to limit the amount of output

true

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

Volume Mount PointDescription

/var/lib/mongodb/data

MongoDB data directory

Note

When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.

10.3.4. Extending the Image

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

For example, to build a customized MongoDB database image my-mongodb-rhel7 with configuration in the ~/image-configuration/ directory, run:

$ s2i build ~/image-configuration/ rhscl/mongodb-36-rhel7 my-mongodb-rhel7

Change the image name to rhscl/mongodb-34-rhel7 when using this image.

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

mongodb-cfg/

When running the run-mongod or run-mongod-replication commands, the contained mongod.conf file is used for mongod configuration. The envsubst command is run on the mongod.conf file to still allow customization of the image using environment variables. A custom configuration file does not affect the name of a replica set; it has to be set in the MONGODB_REPLICA_NAME environment variable. It is impossible to configure SSL using a custom configuration file.

mongodb-pre-init/

The contained shell scripts (*.sh) are sourced before the mongod server is started.

mongodb-init/

The contained shell scripts (*.sh) are sourced when the mongod server is started for the first time, that is, when the data directory is empty. The run-mongod command does not have an enabled authentication in this phase. The run-mongod-replication command does have an enabled authentication in this phase.

mongodb-start/

Similar to mongodb-init/, except these scripts are always sourced (after the mongodb-init/ scripts, if they exist). These scripts are skipped if run-mongod-replication is run with an already initialized data directory.

The following variables can be used in the scripts provided to S2I:

mongo_common_args

Contains arguments for the mongod server. Note that changing this can break existing customization scripts, that is, the default scripts.

MEMBER_ID

Contains an ID of the container. It is defined only in scripts for replication (the run-mongod-replication command) and has a different value for each container image in a replica set cluster. Customization scripts are run by all container images in a replica set; MEMBER_ID can be used to write scripts which are run only by some containers.

During the S2I build, all provided files are copied into the /opt/app-root/src/ directory in the new image. If some configuration files are present in the destination directory, files with the same name are overwritten. Also, only one file with the same name can be used for customization. User-provided files are preferred over the default files in the /usr/share/container-scripts/mongodb/ directory, so it is possible to overwrite them.

The same configuration directory structure can be used to customize the image every time the image is started using the podman run command. The directory has to be mounted into /opt/app-root/src/ in the image by using the -v ./image-configuration/:/opt/app-root/src/ option. This overwrites the customization built into the image.

10.4. PostgreSQL

10.4.1. Description

The rhscl/postgresql-10-rhel7 image provides a PostgreSQL 10 SQL database server.

The rhscl/postgresql-96-rhel7 image provides a PostgreSQL 9.6 SQL database server.

10.4.2. Access and Usage

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

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

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

# podman pull registry.access.redhat.com/rhscl/postgresql-96-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.

10.4.3. Configuration

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

Variable NameDescription

POSTGRESQL_USER

User name for PostgreSQL account to be created

POSTGRESQL_PASSWORD

Password for the user account

POSTGRESQL_DATABASE

Database name

POSTGRESQL_ADMIN_PASSWORD

Password for the postgres admin account (optional)

Note

The postgres administrator account has no password set by default, only allowing local connections. You can set it by setting the POSTGRESQL_ADMIN_PASSWORD environment variable when initializing your container. This will allow you to login to the postgres account remotely. Local connections will still not require a password.

Important

Since passwords are part of the image configuration, the only supported method to change passwords for the database user and postgres admin user is by changing the environment variables POSTGRESQL_PASSWORD and POSTGRESQL_ADMIN_PASSWORD, respectively. Changing database passwords through SQL statements or any way other than through the environment variables aforementioned will cause a mismatch between the values stored in the variables and the actual passwords. Whenever a database container image starts, it will reset the passwords to the values stored in the environment variables.

The following options are related to migration:

Variable NameDescriptionDefault

POSTGRESQL_MIGRATION_REMOTE_HOST

Hostname/IP to migrate from

 

POSTGRESQL_MIGRATION_ADMIN_PASSWORD

Password for the remote postgres admin user

 

POSTGRESQL_MIGRATION_IGNORE_ERRORS

Optional: Ignore sql import errors

no

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

Variable NameDescriptionDefault

POSTGRESQL_MAX_CONNECTIONS

The maximum number of client connections allowed. This also sets the maximum number of prepared transactions.

100

POSTGRESQL_MAX_PREPARED_TRANSACTIONS

Sets the maximum number of transactions that can be in the "prepared" state. If you are using prepared transactions, you will probably want this to be at least as large as max_connections

0

POSTGRESQL_SHARED_BUFFERS

Sets how much memory is dedicated to PostgreSQL to use for caching data

32M

POSTGRESQL_EFFECTIVE_CACHE_SIZE

Set to an estimate of how much memory is available for disk caching by the operating system and within the database itself

128M

Note

When the PostgreSQL image is run with the --memory parameter set and if there are no values provided for POSTGRESQL_SHARED_BUFFERS and POSTGRESQL_EFFECTIVE_CACHE_SIZE, these values are automatically calculated based on the value provided in the --memory parameter. The values are calculated based on the upstream formulas and are set to 1/4 and 1/2 of the given memory, respectively.

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

Volume Mount PointDescription

/var/lib/pgsql/data

PostgreSQL database cluster directory

Note

When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name which is running inside the container.

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 <...>

10.4.4. Data Migration

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-96-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-96-rhel7 to rhscl/postgresql-10-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.

Note

The container image provides migration help for users' convenience, but fully automatic migration is not guaranteed. Thus, before you start proceeding with the database migration, you will need to perform manual steps to get all your data migrated.

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.

Warning

The IP communication between the old and the new PostgreSQL clusters is not encrypted by default, it is up to the user to configure SSL on a remote cluster or ensure security using different means.

10.4.5. Upgrading the Database

Warning

Before you decide to perform the data directory upgrade, make sure you have backed up all your data. Note that you may need to manually roll back if the upgrade fails.

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-10-rhel7 image supports upgrading from rhscl/postgresql-96-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:

copy

The data files are copied from the old data directory to the new directory. This option has a low risk of data loss in case of an upgrade failure.

hardlink

Data files are hard-linked from the old to the new data directory, which brings performance optimization. However, the old directory becomes unusable, even in case of a failure.

Note

Make sure you have enough space for the copied data. Upgrade failure because of insufficient space might lead to a data loss.

10.4.6. Extending the Image

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:

postgresql-pre-start/

Source all *.sh files from this directory during an early start of the container. There is no PostgreSQL daemon running in the background.

postgresql-cfg/

Contained configuration files (*.conf) will be included at the end of the image’s postgresql.conf file.

postgresql-init/

Contained shell scripts (*.sh) are sourced when the database is freshly initialized (after successful initdb run, which made the data directory non-empty). At the time of sourcing these scripts, the local PostgreSQL server is running. For re-deployments scenarios with persistent data directory, the scripts are not sourced (no-op).

postgresql-start/

Similar to postgresql-init/, except these scripts are always sourced (after the postgresql-init/ scripts, if they exist).

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.

10.5. Redis

10.5.1. Description

The rhscl/redis-5-rhel7 image provides Redis 5, an advanced key-value store. The image is based on the rh-redis5 Software Collection.

10.5.2. Access

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

# podman pull registry.access.redhat.com/rhscl/redis-5-rhel7

10.5.3. Configuration and Usage

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-5-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:

Variable NameDescription

REDIS_PASSWORD

Password for the server access

To set a password, run:

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

Use a very strong password because Redis is fast and thus can become a target of a brute-force attack.

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.

Volume Mount PointDescription

/var/lib/redis/data

Redis data directory

Note

When mounting a directory from the host into the container, ensure that the mounted directory has the appropriate permissions and that the owner and group of the directory matches the user UID or name that is running inside the container.

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