cancel
Showing results for 
Search instead for 
Did you mean: 
mbencek
Cadet
Cadet
  • 11.1K Views

Automatically restarting pods when the secret or config map gets updated

Jump to solution

Hello,
Once the configmap or secret gets updated, pods using these don't see the change. After the update, pods need to get restarted/redeployed manually.

What is the best practice to automate this process on OpenShift 4.10?
Marko

Labels (1)
1 Solution

Accepted Solutions
mighty_quinn
Mission Specialist
Mission Specialist
  • 11.1K Views

You can achieve this by adding a trigger section to the DeploymentConfig object, which defines the actions to take when a configmap or secret changes.

Here's an example of how to configure the DeploymentConfig to trigger a rolling deployment when a configmap changes:

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: example
spec:
template:
spec:
containers:
- name: example
image: example:latest
env:
- name: CONFIGMAP_RELOAD_INTERVAL
value: "5s"
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:

 


name: example-config
triggers:
- type: ConfigChange
type: ImageChange
imageChangeParams:
automatic: true
containerNames:
- example

The trigger section defines two types of triggers: ConfigChange and ImageChange. The ConfigChange trigger is responsible for detecting changes in the configmap referenced by the volume, and the ImageChange trigger is responsible for detecting changes in the Docker image.

The CONFIGMAP_RELOAD_INTERVAL environment variable is used to tell the application how often to check for changes in the configmap. In this example, it is set to 5 seconds.

When a change is detected in the configmap or the Docker image, OpenShift will automatically initiate a rolling deployment, which updates the pods one at a time, ensuring that the application remains available during the update.

 

Some guidance on DeploymentConfig objects is here:

https://docs.openshift.com/container-platform/4.12/applications/deployments/what-deployments-are.htm...

View solution in original post

4 Replies
mighty_quinn
Mission Specialist
Mission Specialist
  • 11.1K Views

You can achieve this by adding a trigger section to the DeploymentConfig object, which defines the actions to take when a configmap or secret changes.

Here's an example of how to configure the DeploymentConfig to trigger a rolling deployment when a configmap changes:

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: example
spec:
template:
spec:
containers:
- name: example
image: example:latest
env:
- name: CONFIGMAP_RELOAD_INTERVAL
value: "5s"
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:

 


name: example-config
triggers:
- type: ConfigChange
type: ImageChange
imageChangeParams:
automatic: true
containerNames:
- example

The trigger section defines two types of triggers: ConfigChange and ImageChange. The ConfigChange trigger is responsible for detecting changes in the configmap referenced by the volume, and the ImageChange trigger is responsible for detecting changes in the Docker image.

The CONFIGMAP_RELOAD_INTERVAL environment variable is used to tell the application how often to check for changes in the configmap. In this example, it is set to 5 seconds.

When a change is detected in the configmap or the Docker image, OpenShift will automatically initiate a rolling deployment, which updates the pods one at a time, ensuring that the application remains available during the update.

 

Some guidance on DeploymentConfig objects is here:

https://docs.openshift.com/container-platform/4.12/applications/deployments/what-deployments-are.htm...

  • 7,557 Views

Can this also be acheived with deployment and not deployment config?

alexcorcoles
Flight Engineer
Flight Engineer
  • 7,547 Views

This is a fairly common desire, and there are many discussions on this topic. DO280 incidentally touches this topic in chapter 8, section 4; that's a guided exercise about granting applications access to the Kubernetes API; and the example application is https://github.com/stakater/Reloader , which seems to be a common way to have workloads apply configmap/secret updates.

Note that although this is covered by the course, it's presented as an example and is not meant to be an endorsement, nor imply it's best or supported.

Wasim_Raja
Moderator
Moderator
  • 7,481 Views

Thank you for the important information @alexcorcoles 

0 Kudos
Join the discussion
You must log in to join this conversation.