Move away from depending on CONTAINER_NAME to determine linux environment

[liliankasem]

Today, the host depends on the environment variable CONTAINER_NAME to determine if we are running in a linux environment. This measn customers cannot use this app setting or the host will crash for them.

azure-functions-host/src/WebJobs.Script/Environment/EnvironmentExtensions.cs

Lines 323 to 341 in c62778b

	public static bool IsAnyLinuxConsumption(this IEnvironment environment)
	{
	return (environment.IsLinuxConsumptionOnAtlas() || environment.IsFlexConsumptionSku() || environment.IsLinuxConsumptionOnLegion()) && !environment.IsManagedAppEnvironment();
	}
	public static bool IsLinuxConsumptionOnAtlas(this IEnvironment environment)
	{
	return !environment.IsAppService() &&
	!string.IsNullOrEmpty(environment.GetEnvironmentVariable(ContainerName)) &&
	string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost));
	}
	public static bool IsConsumptionOnLegion(this IEnvironment environment)
	{
	return !environment.IsAppService() &&
	(!string.IsNullOrEmpty(environment.GetEnvironmentVariable(ContainerName)) ||
	!string.IsNullOrEmpty(environment.GetEnvironmentVariable(WebsitePodName))) &&
	!string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost));
	}

The above is just one example, but this is likely sprinkled all over the host. This issue will also require working with the platform team as there is now a contract established.

Goal

Remove dependency on CONTAINER_NAME environment variable for determining linux environments and Skus.

Workaround

The only workaround today is to not use CONTAINER_NAME, and for customers to consider this a protected app setting.

Related Issues

• Accidental use of config "CONTAINER_NAME" causes inexplicable crash #9454
• func host segfaults when specifying CONTAINER_NAME app setting #9867
• func start errors when there is a CONTAINER_NAME app setting azure-functions-core-tools#4227