containerized runtimes require a portable mechanism in order for them to determine they are containerized

[larry-cable]

language runtimes, (libraries and environments) "traditionally" make assumptions about the filesystem and execution environment in which they are installed and execute, typically assuming an environment which is not a container (i.e a physical or virtual O.S environment that is both mutable and persistent across and beyond invocation lifecycles).

Such runtimes (e.g Java JVM) may require the ability to modify some aspect of their behaviors (particularly their serviceability capabilities) based upon their installation/execution environment, and in particular when such environments are "within" a container (image) context.

There appears to be no portable, nor reliable mechanism for runtimes to compute such determinations of their containerized "state".

Some implementations have employed various heuristics based upon the existence of some (specific) container (implementation) "artifact" such as either an environment variable, or the presence of a "dot" file, others introspect some
some aspects of /proc/self/... and /proc/1/... including determining the filesystem type of '/' (e.g "overlay" or "kataShared")
and comparing '/proc/self/cmdline' with "/proc/1/cmdline".

None of these mechanisms are portable or reliable, ideally an "open" container should encompass a mechanism for any such runtime (or other containerized service/application) to introspect its context (i.e: answer the question, "am I installed/executing in the context of a container image and resource mgr?")

[lpgc]

I would like to suggest a simple solution to this problem and also one that would aid user code to associate themselves with their container image in logging etc.

Perhaps we could require that the r/t inject an environment variable into the container which contains the container image identity.

The presence of this would indicate that processes were running from a container image and it would enable logging to contain the image id in order to uniquely associate logs etc with their originating container image

[lpgc]

I think that this specification should add environment variables, exposed to container instances, containing both the image and container (instance) id.

If for no other reason that to enable user code within a container instance to use this information for logging and tracing.

[TheJonesFoundation]

language runtimes, (libraries and environments) "traditionally" make assumptions about the filesystem and execution environment in which they are installed and execute, typically assuming an environment which is not a container (i.e a physical or virtual O.S environment that is both mutable and persistent across and beyond invocation lifecycles).

Such runtimes (e.g Java JVM) may require the ability to modify some aspect of their behaviors (particularly their serviceability capabilities) based upon their installation/execution environment, and in particular when such environments are "within" a container (image) context.

There appears to be no portable, nor reliable mechanism for runtimes to compute such determinations of their containerized "state".

Some implementations have employed various heuristics based upon the existence of some (specific) container (implementation) "artifact" such as either an environment variable, or the presence of a "dot" file, others introspect some some aspects of /proc/self/... and /proc/1/... including determining the filesystem type of '/' (e.g "overlay" or "kataShared") and comparing '/proc/self/cmdline' with "/proc/1/cmdline".

None of these mechanisms are portable or reliable, ideally an "open" container should encompass a mechanism for any such runtime (or other containerized service/application) to introspect its context (i.e: answer the question, "am I installed/executing in the context of a container image and resource mgr?")

vbatts:vbatts_toc