if you want to interact with chef via command line, knife is your best bet,
knife has nothing to do with orchestration, its a chef aware , mixlib-cli
based component (which means its primary goal is to build command line
tools), which also provides following additional features:
- re-usability with other knife components. For example you can build a
knife server provision -C cloud , and use knife-linode, knife-google or
knife-ec2 based on the -C parameter
- it has a ui component which can do colored output, and provides a
presenter. For example inside knife if you do ui.outpur(object) it will
automatically print readable colored output by default, but can also print
json if you supply -Fj
- Chef awareness… it has a baked in rest method (with and without auth),
helpers for doing crud operations on chef’s domain objects (like apiclient,
node, role etc).
that said, knife has some pain (primarily propagating from mixlib-cli), but
their workarounds are pretty well documented.
As per your first argument on orchestration, first of all each organization
has their own requirement of orchestration, with varying level of
complexity, and if they can be offloaded to command line mechanisms, i dont
see any pain in building knife plugins and using them for orchestration.
For example, if you decide to remove a node from a load balancer, do a
deployment and add it back again, and you want to trigger it from jenkins,
you can pretty much do this with knife plugins, and trigger them from
jenkins.
What we should be concerned about, is not to build thick plugins, or
putting way to much logic in them. If you can refactor them into separate
classes you get the ability to reuse them across knife and other
components. But this is true with any library from re-usability standpoint.
For example most of the knife-cloud plugins uses fog underneath and are
pretty thin.
on the contrary i’ll not try to go ployglot unless i have to. Re-usability
will be restricted to individual components once you go ployglot. Also you
have to maintain the language/framework specific idioms & toolchain. This
is fine if you have people who are good at multiple languages, but often
times its not the case. If i can use Boto then why not take the
func/fabric/salt route (which has a 0mq based orchestration built, and you
can fall back to ssh also because you have func/fabric ). They are pretty
decent, and also i get to reuse my code across these components. I would
only recommend going polyglot if the underlying tool or framework forces me
to do so. Like we built our jenkins - chef integration in java, because
jenkins java binding are first class.
At the end of the day I want to come of with a solution that comprises of
smallest , readable, testable code, that can be extended intuitively
comments ?
.