Re: Immutability of applications
John,toggle quoted messageShow quoted text
I'd like to understand more about what you are hoping to accomplish.
Are you trying to detect gaps where a new env var has been pushed, but the
app has not been restarted? Is this for monitoring/compliance or debugging
It seems like Apps these days get configuration from a pretty wide variety
of sources, env variables being only one. Apps also ship with defaults,
UNIX defaults (max filedes, semaphores, etc), and apps sometimes adjust
their settings based on values in SQL or Redis*, etc.
Each app cares about these settings differently, some are sensitive to RAM
available, but not number of open files, etc.
I only ask because it seems like asking for "effective environment" vs
"actual environment" is only a subset of configurations.
The infrastructure can only express what has been provided to the app, but
for any number of reasons, may not represent the current actual running
state of the app.
I understand that it means more work for the app dev, but I often implement
a quick "/config" endpoint in my apps. This allows me to verify what
configuration the App is actually using at a given moment.
It's a more comprehensive way of validating that all "intended
configuration," is in fact actual configuration.
Pivotal Cloud Foundry
* A quick example: the NOC can use an admin endpoint to toggle on/off an
experimental feature, which is detected via Redis, etc.
On Monday, November 9, 2015, Dieu Cao <dcao(a)pivotal.io> wrote:
Pivotal Software, Inc.