You can clone with
# file: /usr/bin/ruby
# the normal 'rbenv global 1.9.3-p0' will affect this script but, unlike having *only* rbenv, this ruby will be available at low run levels (aka, for init scripts)
exec ruby "$@"
Interesting. You are able to rbenv install.... and rbenv global ... etc in a EC2 user-data script with this placed exactly where?
rbenv global ...
our boxes all have /usr/local on ebs. a snapshot of the this ebs drive (base packages, etc) is attached when a new box is brought up. therefore, there is nothing to install via user-data. does that make sense?
Okay I think I see. That EBS was hand crafted?
By production you seem to mean 'single use(r)'? That is no other users accessing. So I think the pull request tries to accommodate a wider set of use cases e.g. ensure that out the box a any new account bundles into its ~/vendor, All install and updates are logged automagically, etc.
yes, ebs which is cloned. our apps boot with a particular environment, so it's all that's needed to allow any app to have it's own ruby and work around dash ruby issus at boot time - food for thought
Interesting, unfortunately, or fortunately - depending on pov [worker or mgt :)], our policy is a "only do it once by hand". Pretty much once we have some thing or work-flow working, it has to be converted to a script. So we do "roll by hand", but that thing or work-flow has to survive the removal of the person ;)
Essentially, in our case production means that person-less version. E.g Out the box logging is then quite important so that we can easily grep/parse for any issues. But in your circumstances it looks like a total waste, and it is in those circumstances.
Of course, like your EBS, we only build one AMI's perregion, once, then they automatically get cloned to a new AMI if they build successfully - all fully automated of course ;)
Appreciate any further thoughts you have that might improve things.