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.

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

Assign lambdas to environment variables #188

Merged
merged 2 commits into from
Jul 27, 2018

Conversation

h0tbird
Copy link
Contributor

@h0tbird h0tbird commented Jul 24, 2018

env_vars FOO: lambda { |hostname| "foo-#{hostname}" }

The lambda function will be invoked by Centurion with server_hostname as its only argument. This is useful to assign a sticky identity for each of the containers in the deploy.

Usage example: https://source.datanerd.us/site-engineering/centurion-configs/pull/4856/files

@wulczer
Copy link
Contributor

wulczer commented Jul 24, 2018

That's looking good to me (and has been tested locally).

@intjonathan @aughr thoughts?

@imakewebthings
Copy link

No objections here.

@aughr
Copy link
Contributor

aughr commented Jul 24, 2018

I'm definitely in favor of the goal here. Is there any way that we can pass in container identity other than a hostname, or at least allow that extension in the future?

@aughr
Copy link
Contributor

aughr commented Jul 24, 2018

(Thinking of running multiple containers on a single host.)

@wulczer
Copy link
Contributor

wulczer commented Jul 24, 2018 via email

@intjonathan
Copy link
Contributor

To meaningfully run multiple containers on the same host, you need a different set of host_port bindings, which typically means a different environment block.

Looks like the block is evaluated in the context of the Service, so you could pass just about anything. I suspect @port_bindings might be the right thing to pass as a second argument, as that'd be the second-level differentiator for additional containers on the same host.

That said, the PortBinding objects in there haven't previously been exposed to the DSL, and would take some documenting.

@wulczer
Copy link
Contributor

wulczer commented Jul 25, 2018

You're right, we have access to all of the Service stuff! Do you think @port_bindings would be useful for the author of a config file? To avoid exposing the Ruby object, we could pass in port_bindings_config which serialises it into a hash that gets used when starting the container. We could also just pass in the current environment...

I'm still don't see clearly how this would make writing configs easier. @aughr do you have an simple example of a Rakefile where it would be useful to have something else than hostname available when determining a value for an env var?

@h0tbird
Copy link
Contributor Author

h0tbird commented Jul 26, 2018

Since this is a blocker for some DRI we are working on, I would like to propose merging it and possibly extend it later. I hope it is not a very unpopular proposal.

@aughr
Copy link
Contributor

aughr commented Jul 26, 2018

Sounds good, thanks @h0tbird.

@intjonathan
Copy link
Contributor

I have team events all day today, but I can package this up tomorrow.

@intjonathan intjonathan merged commit 492d7ee into newrelic:master Jul 27, 2018
@intjonathan
Copy link
Contributor

Enjoy! https://github.com/newrelic/centurion/releases/tag/v1.9.2

@h0tbird
Copy link
Contributor Author

h0tbird commented Jul 30, 2018

Thanks @intjonathan !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants