Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Pre/Post Install Script functionality #1766
I've been using this locally for a while, and figure I'd make a PR to see if you guys would want to bring it in. It adds the ability to run a script before and/or after nodeup.
The pre/post scripts are set via environment variables, exactly like
You can also set
It's a bit of a hack; I don't like the environment-variable-as-arguments pattern, but I don't have much experience with Go, and I needed something to get something working.
There is one caveat. The post-install step does not actually execute after nodeup has completed. It executes after nodeup has been started. This is because nodeup is launched in the background. I've tried to wait for it to finish, but there seems to be a weird race condition with docker and needing User Data to finish first (something like that).
In my opinion, I think if we were to continue down the pre/post install script path, a good end result would be to move these into the instance group spec. Something like
Hi @austinmoore-. Thanks for your PR.
I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with
So this is awesome. A few thoughts:
So for the pre-install script, we're doing some dynamic Chef provisioning. One of the things provisioned is the CloudWatch Logs Agent. The reason I have this run in the pre-install is so that I can get logs like cloud-init's into AWS as the instance is coming up.
I'd like for us to use systemd for these types of dynamic startups, so our AMI is good to go without needing to run Chef on top of it. But until we get there, I need to run Chef with this pre-install script.
I currently only use the post-install for one thing: enabling RBAC. I have a simple script that adds the necessary RBAC flags in
As you can see, I've refactored the bash script that runs in User Data. I refactored it so that I could download the pre-/post-install scripts using the same code that's used to download nodeup. I understand that it's a critical piece of code though, so if you want, we can figure out a way to get this into nodeup without risk breaking the bash.
I agree that we should just stick with the bare minimum. As I've seen mentioned before, this type of thing is an anti-pattern. But it is a nice escape hatch to have when you really need it.
@austinmoore- how would you feel about "actions" which run at a certain time. I'm very wary of binding things into the bootstrap script - I figure that script is very much an implementation detail, and it looks like it will vary between providers.
I'm thinking we have a few "triggers":
And the actions I'm thinking about:
And for how we express it, I'm inspired by the liveness checks in kubernetes itself, which have exec actions and http actions.
Obviously we don't want to do all of this right away, but I'm thinking this is a sustainable mechanism that doesn't lock us into that script, and it becomes an official part of the cluster specification.
I can code up at least the framework unless you're keen on doing it :-)
One thing to consider is to attempt to make this as os independent as possible. Focus primarily around driving this via systemd. Here is a good article around this systemd capability. http://www.richardbucker.com/2015/11/systemd-run-once.html
Possibly abstracting the creation of systemd units.