Consider stopping use of environment variables to communicate with containers

[rfay]

What happened (or feature request):

We use both straight structured yaml in our docker-compose.yml and also free-form environment variables (in the environment: section of each container). It's (probably) hard to understand for the end user that may want to edit. For example, we have VIRTUAL_PORT and TCP_PORT as environment variables and the a yaml "-ports" section.

What you expected to happen:

• All config information delivered to containers to be handled explicitly in the yaml (or perhaps via labels)
• environment: specification should still be there for custom configuration of custom containers.

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues:

[beeradb]

Can you expand on specifically what is meant by "Environment specification still there for custom configuration of custom containers."?

As I read that you are just advocating for reducing the number of env vars we use, and not completely removing them?

[rfay]

I'm suggesting that end users could use environment variables to deliver info/config to their custom containers, providing them a simple hack for configuration, but we would not populate any config via env in our standard config.

[beeradb]

So, the heart of this seems to be whether or not to support user customization of our standard (i.e. web/DB) config?

[rfay]

No, I don't agree with that @beeradb - I was thinking we would support user customization of everything. But the standard things that we know about in advance (for our containers) would be done with yaml. Environment variables would just be an escape hatch for user customization of special containers.

[beeradb]

I see. No opposition to that proposal in theory. I think what would help color this conversation is if we could identify the specific environment variables that we feel are useful as an "Escape hatch" vs the ones which we feel should be removed. From there, our next steps could be:

1. Template the env vars we feel we can remove
2. Document the ones we keep, so users have some understanding of expectations

I agree we most likely have more than we need, but I haven't looked at it with a critical eye recently. And even if we find we do need 100% of what's there, documenting them would still be a very positive step.

[beeradb]

I took the liberty of updating the title, I hope the proposed next steps work for you. Feel free to change back if they don't.

[rfay]

I was saying that users could create any environment variable they wanted and use them in the environment section, and that we would use none for our purposes. So we would then not use:

      - PMA_USER=root
      - PMA_PASSWORD=root
      - VIRTUAL_HOST=$DDEV_HOSTNAME
      - VIRTUAL_PORT=8036
      - DEPLOY_NAME=local
      - TCP_PORT=$DDEV_HOSTNAME:3306

[rfay]

New title isn't accurate given what I think I'm after ;) Because I'm saying get rid of all of them (but support that mechanism for users)

[rfay]

I edited the OP and title just a bit, hoping to narrow this more. It's only about the environment: section and not about preprocessing of the docker-compose.yml. Sorry for all the misdirection today.

[rickmanelius]

Updating labels because I'm not fully sure I understand the implications and the priority.

[rfay]

This isn't happening right now, and is even more entrenched, so closing at this point.