Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Configuring Containerized Services

July 10, 2017
Tomas Tomecek
Related topics:
Containers
Related products:
Red Hat OpenShift

Share:

    I’m assuming you’ve already tried to run some example of a multi-container application. Let’s say we have an application composed of the following:

    • Web service
    • Database
    • Key-value store
    • Worker

    Let’s focus on the database now. Container images for databases usually come with an easy way to configure them via environment variables. The great thing about this approach is how easy to use it is, e.g. let’s take our RHSCL PostgreSQL 9.5 container image. If you try to run it just like that, it refuses to run and instead guides you how you should run the container:

    $ docker run registry.access.redhat.com/rhscl/postgresql-95-rhel7:latest
    You must either specify the following environment variables:
      POSTGRESQL_USER (regex: '^[a-zA-Z_][a-zA-Z0-9_]*$')
      POSTGRESQL_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:]+$')
      POSTGRESQL_DATABASE (regex: '^[a-zA-Z_][a-zA-Z0-9_]*$')
    Or the following environment variable:
      POSTGRESQL_ADMIN_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:]+$')
    Or both.
    Optional settings:
      POSTGRESQL_MAX_CONNECTIONS (default: 100)
      POSTGRESQL_MAX_PREPARED_TRANSACTIONS (default: 0)
      POSTGRESQL_SHARED_BUFFERS (default: 32MB)
    
    For more information see /usr/share/container-scripts/postgresql/README.md
    within the container or visit https://github.com/openshift/postgresql.

    Neat! So let’s pass the environment variables:

    $ docker run --rm \
        -e POSTGRESQL_USER=test_user \
        -e POSTGRESQL_PASSWORD=secret \
        -e POSTGRESQL_DATABASE=test_database \
        --name=pg \
        registry.access.redhat.com/rhscl/postgresql-95-rhel7:latest
    The files belonging to this database system will be owned by user "postgres".
    This user must also own the server process.
    
    The database cluster will be initialized with locale "en_US.utf8".
    The default database encoding has accordingly been set to "UTF8".
    The default text search configuration will be set to "english".
    
    Data page checksums are disabled.
    
    fixing permissions on existing directory /var/lib/pgsql/data/userdata ... ok
    creating subdirectories ... ok
    selecting default max_connections ... 100
    selecting default shared_buffers ... 128MB
    selecting dynamic shared memory implementation ... posix
    creating configuration files ... ok
    creating template1 database in /var/lib/pgsql/data/userdata/base/1 ... ok
    initializing pg_authid ... ok
    initializing dependencies ... ok
    creating system views ... ok
    loading system objects' descriptions ... ok
    creating collations ... ok
    creating conversions ... ok
    creating dictionaries ... ok
    setting privileges on built-in objects ... ok
    creating information schema ... ok
    loading PL/pgSQL server-side language ... ok
    vacuuming database template1 ... ok
    copying template1 to template0 ... ok
    copying template1 to postgres ... ok
    syncing data to disk ... ok
    
    output shortened
    
    LOG: redirecting log output to logging collector process
    HINT: Future log output will appear in directory "pg_log".

    And it’s running!

    If we want to start configuring the service, we may do so using a bunch of environment variables, such as POSTGRESQL_SHARED_BUFFERS. And this is where we may hit the wall: how we configure other parameters?

    The first thing to note is that it would be awesome if images clearly documented how you can change the configuration of the containerized service running inside.

    In the meantime, let’s have a look at what are the best ways to configure a containerized service.

    Overlaying configuration

    In this method, you should create a new container image by applying your configuration changes on top of an existing container image. Let’s try this with the PostgreSQL container image mentioned before.

    The first thing to do is to copy the existing configuration file template,openshift-custom-postgresql.conf.template from the running container:

    $ docker cp pg:/usr/share/container-scripts/postgresql/openshift-custom-postgresql.conf.template ./openshift-custom-postgresql.conf.template

    We should edit the template file now and produce our custom postgresql container image.

    #
    # Custom OpenShift configuration.
    #
    # NOTE: This file is rewritten every time the container is started!
    # Changes to this file will be overwritten.
    #
    
    # Listen on all interfaces.
    listen_addresses = '*'
    
    # Determines the maximum number of concurrent connections to the database server. Default: 100
    max_connections = ${POSTGRESQL_MAX_CONNECTIONS}
    
    # Allow each connection to use a prepared transaction.
    max_prepared_transactions = ${POSTGRESQL_MAX_PREPARED_TRANSACTIONS}
    
    # Sets the amount of memory the database server uses for shared memory buffers. Default: 32MB
    shared_buffers = ${POSTGRESQL_SHARED_BUFFERS}
    
    # Sets the planner's assumption about the effective size of the disk cache that is available to a single query.
    effective_cache_size = ${POSTGRESQL_EFFECTIVE_CACHE_SIZE}
    
    # Let’s increase work_mem so most operations are performed in memory
    work_mem = 64MB
    

    We added last two lines to the template.

    Now is the time to build the image, we will use this dockerfile: (we update labels so it’s clear that the newly built image is not the official RHSCL image, rather a variant based on it)

    FROM registry.access.redhat.com/rhscl/postgresql-95-rhel7:latest
    LABEL name="tomastomecek/postgresql" \
          vendor="Tomas Tomecek"
    COPY ./openshift-custom-postgresql.conf.template /usr/share/container-scripts/postgresql/
    

    Let’s build...

    $ docker build --tag=tomastomecek/postgresql .

    and run...

    $ docker run --rm \
        -e POSTGRESQL_USER=pg_test \
        -e POSTGRESQL_PASSWORD=secret \
        -e POSTGRESQL_DATABASE=test_db \
        --name pg tomastomecek/postgresql

    And check if the work_mem attribute was changed:

    $ docker exec pg bash -c 'psql --command "show work_mem;"'
    work_mem
    ----------
    64MB
    (1 row)

    It’s updated!

    We can even go one step further and change the value dynamically. Let’s update our template from

    work_mem = 64MB
    

    to

    work_mem = ${POSTGRESQL_WORK_MEM}
    

    We need to rebuild our image first

    $ docker build --tag=tomastomecek/postgresql .

    and then let’s set the work_mem attribute to 128MB via the environment variable:

    $ docker run --rm \
        -e POSTGRESQL_USER=pg_test \
        -e POSTGRESQL_PASSWORD=secret \
        -e POSTGRESQL_DATABASE=test_db \
        -e POSTGRESQL_WORK_MEM=128MB \
        --name pg tomastomecek/postgresql

    We were able to define a new environment variable because the container’s startup script is using the envsubst command. Obviously, this is just an implementation detail and it should be clearly documented how one can define new variables (if possible).

    Let’s verify now that work_mem is set to 128MB.

    $ docker exec pg bash -c 'psql --command "show work_mem;"'
    work_mem
    ----------
    128MB
    (1 row)

    Pros

    • Portable — the container will work the same way in any environment.
    • Easy to test and audit.

    Cons

    • Building and distributing a large amount of new images can be complicated.
    • Requires image to be built - which needs additional automation (git repository for dockerfile, build a pipeline, image naming conventions, registry).
    • It’s tricky to figure out without documentation — which may lead to undefined behavior.

    Injecting configuration

    In OpenShift, we can take advantage of ConfigMaps and inject configuration inside pods using them. Christoph Görn wrote a blog post on best practices for configuration inside OpenShift.

    Let’s do the example from “Overlaying configuration” section above without building a new image.

    Instead of building a new image, we will bind mount the template inside RHSCL postgresql container.

    $ docker run --rm \
        -e POSTGRESQL_USER=pg_test \
        -e POSTGRESQL_PASSWORD=secret \
        -e POSTGRESQL_DATABASE=test_db \
        -v openshift-custom-postgresql.conf.template:/usr/share/container-scripts/postgresql/ \
        -e POSTGRESQL_WORK_MEM=128MB \
        --name pg \
        registry.access.redhat.com/rhscl/postgresql-95-rhel7:latest

    This was a lot easier. All we had to do was to:

    1. Get the template file.
    2. Update it.
    3. Mount the template file inside the container.

    Let’s verify the work_mem attribute is set correctly.

    $ docker exec pg bash -c 'psql --command "show work_mem;"'
    work_mem
    ----------
    128MB
    (1 row)

    Pros

    • Decoupling configuration from the immutable image — you can configure the containerized service independently.
    • No need to create new images.

    Cons

    • The container is no longer portable and requires configuration.

    Conclusion

    As you can see, there is no silver bullet when it comes to the configuration of containerized services. There are multiple options and it’s up to you to pick the one, which suits you best.


    Click here to learn about Red Hat Openshift Container Platform, allowing you to provision, manage, and scale container-based applications.

    Last updated: March 23, 2023

    Recent Posts

    • Storage considerations for OpenShift Virtualization

    • Upgrade from OpenShift Service Mesh 2.6 to 3.0 with Kiali

    • EE Builder with Ansible Automation Platform on OpenShift

    • How to debug confidential containers securely

    • Announcing self-service access to Red Hat Enterprise Linux for Business Developers

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue