Hi,
In our company we use chef with local mode, without chef server, but using berkshelf and environment cookbook pattern.
We have a single repo per cookbook approach and our "top level" cookbook, as Torben calls it, is the environment cookbook. We have an environment cookbook per each product we use to provide services with (we are an in-house IT service provider for public administration). Within each environment cookbook we version everything, environments, databags, nodes and so on. We use tags on nodes and search based on tags to provide auto-riconfiguration if we *manually* (because no chef server exists) add a node, for example for jboss nodes balanced by apache. Finally we developed some custom script to build each environment cookbook as payload of a sibgle stell script that can then be pushed/run on any node of that product infrastructure, we call this custom pattern we invented "chef zero package pattern" :) because that package is built by our CI server.
It would not be suitable for large infrastructures, I wouldn't recommend for real web-scale IT, but it is not our use case, we have many little product and having to manually manage nodes within environment cookbook is not a big problem.
We never wrote o published anything about that because it does not seem to me the right chef approach, but chef is an awesome framework and allows you to do such an horrible thing also :D
Sorry for this very quick answer if you think it is useful and want some other info, feel free to ask.
Cheers!
Marco
My team has been developing recipes with Chef for several months now and we've made significant progress in automating our infrastructure, but we're now getting to a point where we need to scale this up and make it a first class part of our CI pipeline where many teams are maintaining their own cookbooks sitting side by side the software code that's running on this infrastructure. Up until now we've been focused entirely on recipe development using chef-client and Vagrant for spinning up nodes and running the cookbooks via Vagrant's built in provisioners. As you'd expect, things are starting to become unwieldy with managing attributes and common shared cookbooks, etc. We've started looking at Berkshelf for managing dependencies and environments and roles for putting some structure to our attributes.Here's where it gets interesting... to put it bluntly, there are several within my team that aren't bought into the idea of Chef Server. Our entire enterprise orbits around our version control system. And we already have a large investment in Artifactory which is a home for all of the technical artifacts for all of our products across several platforms and it works quite well as a general purpose distribution hub. As we've started playing with the chef concepts of environments and roles while running chef-client in local mode, I think I see the value in these abstractions, however.... I'm starting to get the sense that using these outside the context of a Chef Server is going to be a very bumpy road.Right now I'm able to get our cookbook using environments and roles and have chef-client find them by pointed to a directory on disk where these json files list under version control. This works, but the next use case we're looking to support is running these outside the context of Vagrant and the current thought is using --recipe-url to point to a tarball that we published to artifactory from our CI builds in Jenkins (by way of Berks package). This use case would be for running these cookbooks are production machines that do not have connectivity to our version control system and will not be running in the context of Vagrant. As best I can tell, this will not work as I do not believe there is any way to include environments and roles json files in this tarbar and have chef-client recognize it via --recipe-url. Can someone confirm my suspicion?Questions1) are roles and environments even recommended at all? I'm finding folks out there that really feel strongly they are an anti-pattern [1][2], though I'm not sure I agree with them.2) I keep hearing about how there are loads of people out there using chef without chef-server and doing so happily. are there folks using environments and roles?3) similar to environments and roles, how are nodes managed in a chef-server-less world? I see that you can define these in json and even knife these into a chef server, but when I do a chef-client run in local mode, the nodes/ directory is written to with data from that run. In other words files in nodes/ doesn't seem to be something that's considered a "source" of anything, but rather a runtime output dir.4) I'm torn with chef-server because it feels like something like this shouldn't be necessary, but the deeper I get into these concepts more it feels like we're going against the grain not fully embracing chef-server. Can anyone point me to some detailed information on what the full development production lifecycle would look liek with a chef-server oriented world? What about the same in a chef-server-less world?Sorry for the long rambling email, but was hoping some kind soul could give me some guidance on how to proceed - every direction we look right now feel less than ideal.
Archive powered by MHonArc 2.6.16.