Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Custom Environment Variables #1382

Closed
platinummonkey opened this issue Sep 19, 2014 · 4 comments
Closed

Custom Environment Variables #1382

platinummonkey opened this issue Sep 19, 2014 · 4 comments

Comments

@platinummonkey
Copy link

Docker allows environment variables to be set at runtime that certain applications would depend on (or use default values).

Perhaps this example might be more clear and demonstrates environment variables specific to the application and utilizing kubernetes aware environment variable substitution:

Say I have an application that depends on some external application not running within the kubernetes domain.

{
    "id": "myAppController",
    "kind": "ReplicationController",
    "apiversion": "v1beta1",
    "desiredState": {
        "replicas": 1,
        "replicaSelector": {
            "name": "myapp",
            "tier": "app",
        },
        "podTemplate": {
            "desiredState": {
                "manifest": {
                    "version": "v1beta1",
                    "id": "myAppController",
                    "containers": [{
                        "name": "myapp",
                        "image": "mycompany/myapp"
                    }],
                   "env": {
                         "EXTERNAL_SERVICE_HOST": "example.com",
                         "EXTERNAL_SERVICE_PORT": 1234,
                         "EXTERNAL_SERVICE_SPECIAL_SETTING": "abcd",
                         "EXTERNAL_SERVICE_FORWARD_TO": "$MYOTHERAPP_SERVICE_HOST:$MYOTHERAPP_SERVICE_PORT"
                   }
                }
            },
            "labels": {
                "name": "myapp",
                "tier": "app",
            }
        }
    },
    "labels": {
        "name": "myapp",
        "tier": "app",
    }
}

Variable expansion (as in that last case) could happen at the docker container context on the shell.
@platinummonkey platinummonkey mentioned this issue Sep 19, 2014
Closed
@brendandburns
Copy link
Contributor

This is a super slippery slope towards config. I'm somewhat ok with doing this in the kubecfg binary, I'm fairly resistant to doing this in the API itself.

@thockin
Copy link
Member

thockin commented Sep 19, 2014

I apologize, I asked you to file an issue from an issue which already covered the topic :) My head is not screwed on today. I think #1331 covers this. I'm going to close this, scream if you disagree.

@thockin thockin closed this as completed Sep 19, 2014
@thockin
Copy link
Member

thockin commented Sep 19, 2014

FTR @brendanburns the workaround (make your command be sh -c) is enough to limp along, but even with config I can buy the argument that @smarterclayton has made a few times - giving users the power to customize the env to the app is better than customizing the app to the env.

I'd like to leave #1331 open, though it is pretty clearly not p0 because there is a workaround.

@brendandburns
Copy link
Contributor

I agree with the sentiment, I think its the right thing to do, I'm just not
sure that the concrete pod api is the place to do it, it's going to require
introducing a set of $magic $variables that I'm not super happy about, but
I'm ammenable to the "makes user's life easier" argument.

--brendan

On Fri, Sep 19, 2014 at 9:23 AM, Tim Hockin notifications@github.com
wrote:

FTR @brendanburns https://github.com/brendanburns the workaround (make
your command be sh -c) is enough to limp along, but even with config I can
buy the argument that @smarterclayton https://github.com/smarterclayton
has made a few times - giving users the power to customize the env to the
app is better than customizing the app to the env.

I'd like to leave #1331
#1331 open,
though it is pretty clearly not p0 because there is a workaround.

—
Reply to this email directly or view it on GitHub
#1382 (comment)
.

mfojtik pushed a commit to mfojtik/kubernetes that referenced this issue Oct 21, 2022
@openshift-merge-robot
Merge pull request kubernetes#1382 from soltysh/bump-1.23.12
6b34f32 
Bug 2101326: bump to k8s 1.23.12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@platinummonkey @thockin @brendandburns