Chapter 14. Database Images
14.1. MariaDB
14.1.1. Description
The rhscl/mariadb-105-rhel7 image provides a MariaDB 10.5 SQL database server; the rhscl/mariadb-103-rhel7 image provides a MariaDB 10.3 SQL database server.
14.1.2. Access
To pull the rhscl/mariadb-105-rhel7 image, run the following command as root:
# podman pull registry.redhat.io/rhscl/mariadb-105-rhel7
To pull the rhscl/mariadb-103-rhel7 image, run the following command as root:
# podman pull registry.redhat.io/rhscl/mariadb-103-rhel7
14.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 Name | Description |
---|---|
| User name for MySQL account to be created |
| Password for the user account |
| Database name |
| Password for the root user (optional) |
| Default character set (optional) |
| Default collation (optional) |
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.
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 name | Description | Default |
---|---|---|
| Sets how the table names are stored and compared |
|
| The maximum permitted number of simultaneous client connections | 151 |
| The maximum size of one packet or any generated/intermediate string | 200M |
| The minimum length of the word to be included in a FULLTEXT index | 4 |
| The maximum length of the word to be included in a FULLTEXT index | 20 |
|
Controls the | 1 |
| The number of open tables for all threads | 400 |
| The size of the buffer used for index blocks | 32M (or 10% of available memory) |
| The size of the buffer used for sorting | 256K |
| The size of the buffer used for a sequential scan | 8M (or 5% of available memory) |
| The size of the buffer pool where InnoDB caches table and index data | 32M (or 50% of available memory) |
| The size of each log file in a log group | 8M (or 15% of available memory) |
| The size of the buffer that InnoDB uses to write to the log files on disk | 8M (or 15% of available memory) |
| Point to an alternative configuration file |
|
|
Set sets the binlog format; supported values are |
|
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 name | Default memory percentage |
---|---|
| 10% |
| 5% |
| 50% |
| 15% |
| 15% |
You can also set the following mount point by passing the -v /host:/container
option to the podman run
command:
Volume Mount Point | Description |
---|---|
| MySQL data directory |
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.
14.1.4. Extending the Image
See How to Extend the rhscl/mariadb-101-rhel7 Container Image, which is applicable also to rhscl/mariadb-103-rhel7
.
14.2. MySQL
14.2.1. Description
The rhscl/mysql-80-rhel7 image provides a MySQL 8.0 SQL database server.
14.2.2. Access and Usage
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.
14.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 Name | Description |
---|---|
| User name for MySQL account to be created |
| Password for the user account |
| Database name |
| Password for the root user (optional) |
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.
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 name | Description | Default |
---|---|---|
| Sets how the table names are stored and compared |
|
| The maximum permitted number of simultaneous client connections | 151 |
| The maximum size of one packet or any generated/intermediate string | 200M |
| The minimum length of the word to be included in a FULLTEXT index | 4 |
| The maximum length of the word to be included in a FULLTEXT index | 20 |
|
Controls the | 1 |
| The number of open tables for all threads | 400 |
| The size of the buffer used for index blocks | 32M (or 10% of available memory) |
| The size of the buffer used for sorting | 256K |
| The size of the buffer used for a sequential scan | 8M (or 5% of available memory) |
| The size of the buffer pool where InnoDB caches table and index data | 32M (or 50% of available memory) |
| The size of each log file in a log group | 8M (or 15% of available memory) |
| The size of the buffer that InnoDB uses to write to the log files on disk | 8M (or 15% of available memory) |
| Point to an alternative configuration file |
|
|
Set sets the binlog format, supported values are |
|
|
To enable query logging, set this variable to |
|
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 name | Default memory percentage |
---|---|
| 10% |
| 5% |
| 50% |
| 15% |
| 15% |
You can also set the following mount point by passing the -v /host:/container
option to the podman run
command:
Volume Mount Point | Description |
---|---|
| MySQL data directory |
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.
14.3. PostgreSQL
14.3.1. Description
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.
14.3.2. Access and Usage
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.
14.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 Name | Description |
---|---|
| User name for PostgreSQL account to be created |
| Password for the user account |
| Database name |
| Password for the postgres admin account (optional) |
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.
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 Name | Description | Default |
---|---|---|
| Hostname/IP to migrate from | |
|
Password for the remote | |
| Optional: Ignore sql import errors | no |
The following environment variables influence the PostgreSQL configuration file and are all optional:
Variable Name | Description | Default |
---|---|---|
| The maximum number of client connections allowed. This also sets the maximum number of prepared transactions. | 100 |
| 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 |
| Sets how much memory is dedicated to PostgreSQL to use for caching data | 32M |
| Set to an estimate of how much memory is available for disk caching by the operating system and within the database itself | 128M |
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 Point | Description |
---|---|
| PostgreSQL database cluster directory |
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 <...>
14.3.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-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.
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.
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.
14.3.5. Upgrading the Database
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-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 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. |
| 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. |
Make sure you have enough space for the copied data. Upgrade failure because of insufficient space might lead to a data loss.
14.3.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:
|
Source all |
|
Contained configuration files ( |
|
Contained shell scripts ( |
|
Similar to |
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.
14.4. Redis
14.4.1. Description
The rhscl/redis-6-rhel7 image provides Redis 6, an advanced key-value store.
14.4.2. Access
To pull the rhscl/redis-6-rhel7 image, run the following command as root:
# podman pull registry.redhat.io/rhscl/redis-6-rhel7
14.4.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-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:
Variable Name | Description |
---|---|
| Password for the server access |
To set a password, run:
# podman run -d --name redis_database -e REDIS_PASSWORD=strongpassword rhscl/redis-6-rhel7
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 Point | Description |
---|---|
| Redis data directory |
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.