I have a ASP.NET Core Worker Service which gets some information like thread count, batch size etc. from appsettings.json. These settings will only take affect on startup and cannot be change when the service is running.
The application will be running in a kubernetes cluster.
What is the best practice for changing these settings while deployed in production? What I need to have done is, changing the settings and restart the service.
I can come up with these solution:
1. Mapping appsetttings.json to a volume, to be able to change it, so that when container is restarted the appsettings is not reverted.
- Do I need to move the appsettings.json file to another folder then root? Is there something about not mapping the running application to a volume?
1. Update the containers environment variables to override settings.
- Will these settings be reverted back when the container is restarted?)
Any other ideas?
Depending on the content of your application json you may store it inside ConfigMap or Secret and then mount it into the pod.
Both ConfigMap and Secret are stored in Kubernetes API and are always mounted into the pod read-only. Please read provided links to understand how to create and mount them inside your pods.
If your application can be configured both with a configuration file and with environment variables, my experience has been that using environment variables is easier. There are several aspects of this:
You can directly include the environment variable in your deployment specification
env:
- name: SOME_CONFIG_SETTING
value: its valueFor a config file you need to create a separate ConfigMap object, add it to a per-pod volume, and mount the volume in a container. That's routine and well-documented, but harder than just setting an environment variable.
If you use Helm to deploy your application, it's very easy to substitute a configuration value at deploy time
- name: SOME_CONFIG_SETTING
value: {{ .Values.someConfigSetting | default "its value" }}If you change the value of the environment variable in the deployment spec, that's enough of a change to automatically delete and recreate the pods running the container; that is, you will get an automatic restart. If the configuration settings are in a ConfigMap, absent some Helm hackery, you will need to manually restart the deployment when the configuration changes.
You should not use kubectl exec here, and you should not need to try to manually restart the process running inside a container. If a pod is managed by a deployment, kubectl delete pod deployment-name-12345-abcde will cause it to immediately be recreated, effectively restarting that replica of the service.