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. 14.1.2. Access To pull the rhscl/mariadb-105-rhel7 image, run the following command as root : 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 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) MYSQL_CHARSET Default character set (optional) MYSQL_COLLATION Default collation (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 name Description Default 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 name Default 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 Point Description /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. 14.1.4. Extending the Image See How to Extend the rhscl/mariadb-101-rhel7 Container Image , which is applicable also to rhscl/mariadb-105-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 : To set only the mandatory environment variables and not store the database in a host directory, execute the following command: 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 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 name Description Default 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 name Default 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 Point Description /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. 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 : To pull the rhscl/postgresql-12-rhel7 image, run the following command as root : To pull the rhscl/postgresql-10-rhel7 image, run the following command as root : To set only the mandatory environment variables and not store the database in a host directory, execute the following command: 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 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 Name Description Default 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 Name Description Default 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 Point Description /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: 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: 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 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. 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. 14.3.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 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 USDPOSTGRESQL_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 USDPOSTGRESQL_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. 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: 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. 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 : 14.4.3. Configuration and Usage To set only the mandatory environment variables and not store the database in a host directory, run: 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 REDIS_PASSWORD Password for the server access To set a password, run: 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 Point Description /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.

Commands:
podman pull registry.redhat.io/rhscl/mariadb-105-rhel7
podman pull registry.redhat.io/rhscl/mysql-80-rhel7
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
podman pull registry.redhat.io/rhscl/postgresql-13-rhel7
podman pull registry.redhat.io/rhscl/postgresql-12-rhel7
podman pull registry.redhat.io/rhscl/postgresql-10-rhel7
podman run -d --name postgresql_database -e POSTGRESQL_USER= <user> -e POSTGRESQL_PASSWORD= <pass> -e POSTGRESQL_DATABASE= <db> -p 5432:5432 <image_name>
setfacl -m u:26:-wx /your/data/dir podman run <...> -v /your/data/dir:/var/lib/pgsql/data:Z <...>
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
s2i build ~/image-configuration/ postgresql new-postgresql
podman pull registry.redhat.io/rhscl/redis-6-rhel7
podman run -d --name redis_database -p 6379:6379 rhscl/redis-6-rhel7
podman run -d --name redis_database -e REDIS_PASSWORD=strongpassword rhscl/redis-6-rhel7