The rhscl/mariadb-102-rhel7 image provides a MariaDB 10.2 SQL database server.

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

# docker pull registry.access.redhat.com/rhscl/mariadb-102-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 -e VAR=VALUE to the docker run command:

To disable remote root access, simply unset MYSQL_ROOT_PASSWORD and restart the container.

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

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

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

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.

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

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

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

# docker 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:

# docker 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 docker logs <image_name> command.

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

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

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

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:

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

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

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.

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

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

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

# docker 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:

# docker 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 docker stop postgresql_database command.

The the postgres daemon first writes its logs to the standard output. To examine the container image log, use the docker 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 docker 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 docker run command:

Unless you use the -u option with the docker 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
$ docker 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:

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

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

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.