Support dashes in environment variables when creating containers

[ngcdev]

Is your feature request related to a problem? Please describe. I was creating a container deployment with az container create ... -e some-var=someValue and I got an error message that the variable name is invalid. To be precise, this error:

ERROR: (InvalidContainerEnvironmentVariable) The environment variable name in container 'mycontainer' of container group 'mycontainer' is invalid. A valid environment variable name must start with alphabetic character or '_', followed by a string of alphanumeric characters or '_' (e.g. 'my_name',  or 'MY_NAME',  or 'MyName').
Code: InvalidContainerEnvironmentVariable

Describe the solution you'd like Env vars are usually used to pass configuration settings to the container. If the software is using some third party package that expects config settings with a dash in the name, there's nothing we can do to change it. The dash in env vars is supported in docker-compose (for example) and property names with dashes are supported in appsettings.config in .net core apps. So, supporting env vars with dashes in the name will be good (in a Linux environment, using the shell export command it's not possible to have an dash in the name, but it is possible to have it when using the env command, so the shells can support it)

Describe alternatives you've considered The alternative will be outside of az CLI scope. Perhaps in .net core settings to interpret a triple underscore as a dash or some other way to escape it for env vars. For our own programs, we can change the settings not to use a dash, but for third party tools, there's nothing we can do.

Additional context Not sure what mechanism az will use to set the env vars in the Azure deployment, but the command env in Linux works for setting env vars with dashes in the name. I have tested with docker-compose setting env vars with dashes and then reading them from a .net core app in a container and they do work

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @macolso.

Issue Details

---

**Is your feature request related to a problem? Please describe.** I was creating a container deployment with `az container create ... -e some-var=someValue` and I got an error message that the variable name is invalid. To be precise, this error: ``` ERROR: (InvalidContainerEnvironmentVariable) The environment variable name in container 'mycontainer' of container group 'mycontainer' is invalid. A valid environment variable name must start with alphabetic character or '_', followed by a string of alphanumeric characters or '_' (e.g. 'my_name', or 'MY_NAME', or 'MyName'). Code: InvalidContainerEnvironmentVariable ``` **Describe the solution you'd like** Env vars are usually used to pass configuration settings to the container. If the software is using some third party package that expects config settings with a dash in the name, there's nothing we can do to change it. The dash in env vars is supported in docker-compose (for example) and property names with dashes are supported in appsettings.config in .net core apps. So, supporting env vars with dashes in the name will be good (in a Linux environment, using the shell `export` command it's not possible to have an dash in the name, but it is possible to have it when using the `env` command, so the shells can support it) **Describe alternatives you've considered** The alternative will be outside of `az` CLI scope. Perhaps in .net core settings to interpret a triple underscore as a dash or some other way to escape it for env vars. For our own programs, we can change the settings not to use a dash, but for third party tools, there's nothing we can do. **Additional context** Not sure what mechanism `az` will use to set the env vars in the Azure deployment, but the command `env` in Linux works for setting env vars with dashes in the name. I have tested with docker-compose setting env vars with dashes and then reading them from a .net core app in a container and they do work

Author:	ngcdev
Assignees:	-
Labels:	`Service Attention`, `Container Instances`
Milestone:	-

[yonzhan]

route to service team

[StevenTCramer]

While at it support . in env names also.

 - Group azure  Error                                                                                                                                                                                      127.4s
containerinstance.ContainerGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidContainerEnvironmentVariable" Message="The environment variable name in container 'elasticsearch' of container group 'azure' is invalid. A valid environment variable name must start with alphabetic character or '_', followed by a string of alphanumeric characters or '_' (e.g. 'my_name',  or 'MY_NAME',  or 'MyName')."

my docker-compose file contains

 environment:
      - discovery.type=single-node

[axorth]

This is ridiculous. I am trying to deploy a non-prod version of DotCMS and this is keeping me from deploying Elastic Search.

services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:7.9.1 environment:

• cluster.name=elastic-cluster
• discovery.type=single-node
• data
• bootstrap.memory_lock=true
• "ES_JAVA_OPTS=-Xmx1G "

[GlenColby]

+1 for this, this is a weird limitation

[RonaldSwaine]

+1

For those setting up ES, they do have the alternate long form settings, but properties with dashes in them still get caught.

Do work: ELASTIC_PASSWORD ES_SETTING_NODE_NAME ES_SETTING_DISCOVERY_TYPE

But to get CORS to work, for example:

Works: ES_SETTING_HTTP_CORS_ENABLED

Does not work: ES_SETTING_HTTP_CORS_ALLOW-ORIGIN