Closed h0tbird closed 6 years ago
That's looking good to me (and has been tested locally).
@intjonathan @aughr thoughts?
No objections here.
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?
(Thinking of running multiple containers on a single host.)
On 24 July 2018 20:02:59 CEST, Andrew Bloomgarden notifications@github.com wrote:
(Thinking of running multiple containers on a single host.)
Yeah, we'd have to see what info is available to Centurion at that point...
Because we're just building up the payload that we'll post to the docker daemon, I'm not sure what more info do we have.
The author of the rakefile knows what service they're deploying (they wrote the rakefile and they defined the image to deploy) so I'm wondering if there's more we can pass in.
Of course, this being Ruby, we can probably start calling the lambda with a second argument and it'll be backwards compatible...
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.
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?
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.
Sounds good, thanks @h0tbird.
I have team events all day today, but I can package this up tomorrow.
Thanks @intjonathan !
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