engineyard / ey-docs

Engine Yard Docs
http://docs.engineyard.com
28 stars 11 forks source link

Explaining instance roles #274

Closed daniel-nelson closed 12 years ago

daniel-nelson commented 12 years ago

It would be helpful if http://docs.engineyard.com/custom-chef-recipes.html explained instance roles. It is not obvious that 'app' means app slaves, so that if one wants a recipe to run on all application instances, one needs to include both 'app' and 'app_master'.

janeday commented 12 years ago

Thanks very much for this suggestion. I added a section about instance roles to the page: http://docs.engineyard.com/custom-chef-recipes.html#topic10 Sincerely, Jane

ches commented 12 years ago

Is there any further specific documentation on EY's Chef usage, a roadmap, etc.? It would be great to use real Chef role definitions, which Chef Solo has supported for a long time, but EY is still using a now-ancient version of Chef.

drnic commented 12 years ago

Hey @ches,

Documentation on EY Chef usage - what docco/tutorials would you like? something on gentoo as well?

Roadmap - we do have some excitement around modern chef coming soon. Just between you and me.

/cc @calavera

ches commented 12 years ago

That's great news, thanks.

I guess what I'm looking for, which may be somewhat moot if modern Chef is coming soon-ish, is key differences that someone with experience might expect versus what you'd find in current Chef docs and commonly cited "best practices." A lot of existing EY docs are oriented toward and organized for people without much experience administering environments and deploying apps, which is certainly good, but perhaps an "expert" track to summarize "what's different" would help -- having an ops-y background, the learning curve seems like it may actually be worse for translating not-quite-directly-applicable skills: old Chef, engineyard/serverside vs. cap & the like, Gentoo vs. other distros, etc. For instance, clearly stating "this is Chef Solo" immediately tells me a lot, and could be helpful for newcomers as well to express that you can forego spending time learning about this Knife thing you've heard of. And don't get me wrong -- I'm happy that a lot of your code like serverside is out there for the viewing.

There's plenty of info on Gentoo out there, so no need to reinvent the wheel -- people should be discouraged from doing much ad-hoc administration anyhow! -- but I suppose some help on a few cases specific to EY, deploying and config-managing apps would be nice: special filesystem organization like what lives in /engineyard, what ey_resin is and why deploy hooks aren't running with your app's bundled gems available, advice given that Gentoo isn't as well-supported as Debian- and Red Hat-based distros in many commonly available cookbooks, etc.

Relatedly, I've mentioned it a few times elsewhere with some positive response -- from you and @tmornini IIRC -- but publishing an EY Cloud Vagrant box with your portage tree would be really helpful for getting to know some of this stuff better, and for developing Chef recipes without the clock running on paid instances, on flights without wifi, and so on. Stacks up nicely against Micro Cloud Foundry too. I had tons of fun a week ago sorting out why the C extension-based memcached gem wouldn't build on a design/CSS guy's Mac.

Not sure whether or not this is a very good forum for you guys to discuss and track this, so thanks for asking at any rate! You're bridging a gap between pushbutton PaaS with very limited flexibility and a transparent and malleable environment that happens to have tuned stacks and professional services available, and I appreciate that it's a challenge to give customers across the spectrum what they want :-)