Cloud-Native Microservices With Kubernetes - 2nd Edition

ConfigMap: Storing Configuration Data in a Decoupled Manner

In general, a good practice when deploying applications to Kubernetes is to separate configuration data from the application code. The configuration data is often environment-specific and may change frequently; this is why it's better to store it in the environment. In this way, we can avoid rebuilding and redeploying the application every time the configuration changes.

An application is deployed to environment-A; it reads its configuration from this environment. The same application is then deployed to environment-B; it reads its configuration from this new environment. No changes are required to the application code, as the configuration is decoupled from the application. In our case, Kubernetes is the environment and the ConfigMap resource is the resource that allows us to store configuration data.

What is a ConfigMap?

A ConfigMap is a resource that stores non-confidential configuration data as key-value pairs. It allows configuration data to be decoupled from containerized applications.

ConfigMaps can store configuration data, configuration files, and any other non-confidential data that your applications might need. When a Pod starts, it consumes the ConfigMap data and makes it available to the application running inside the container.

This resource is particularly useful in several scenarios, including when multiple applications share the same configuration, when the configuration data needs to be changed frequently without redeploying Pods, or when you want to organize your Deployments by decoupling operations from data.

ConfigMaps can be created using the kubectl command-line tool or by declaring a ConfigMap object in a manifest file.

How to Create a ConfigMap

Usually, before creating the ConfigMap, we need to identify the configuration data that our application needs. In our case, since we are going to use the postgres:18 image, we need to provide the following environment variables to configure PostgreSQL:

• POSTGRES_PASSWORD: This environment variable is required to use the PostgreSQL image. It must not be empty or undefined. This environment variable sets the superuser password for PostgreSQL. The default superuser is defined by the POSTGRES_USER environment variable.

• POSTGRES_USER: This optional environment variable is used in conjunction with POSTGRES_PASSWORD to set a user and their password. This variable will create the specified user with superuser power and a database with the same name.

• POSTGRES_DB: This optional environment variable can be used to define a different name for the default database that is created when the image is first started. If it is not specified, then the value of POSTGRES_USER will be used.

These variables are documented in the official PostgreSQL Docker image documentation.

If we were using another image, the variables could be different. In this case, we would need to check the documentation for the image to find out which variables are required.

Here is how to create the ConfigMap with the required environment variables:

cat < kubernetes/postgres-config.yaml
apiVersion: v1
kind: ConfigMap
metadata: