2

I am currently installing a Chef server according to http://wiki.opscode.com/display/chef/Installing+Chef+Server+using+Chef+Solo for CentOS 6.2. I want to package everything up into my own custom RPM but I'm wondering what the best way of packaging it is. (I know there are rpms already available, but I want to use my own build).

I'm considering storing everything including the binaries and configuration files into an RPM and storing that in my YUM repo and making it a default package in my kickstart server.

I'm wondering if there is a better way of automating this via git, or should I stick with files/rpm?

DevNull0000001
  • 21
  • 2
  • Are you very specific in packaging your own RPM ? If not, the packages from RBEL Repo ( http://rbel.frameos.org/ ) are very good. It is even endorsed by OpsCode folks. – Shyam Sundar C S May 23 '12 at 18:29

2 Answers2

2

First, about building your own "full stack" of Chef Server.

Opscode is going to release a full stack package of everything required for the Open Source Chef Server soon. This was demonstrated at ChefConf last week, and is under active development for a near term release.

The demo was in a keynote talk by Chris Brown and Adam Jacob. The demo starts here, but the entire thing is interesting, giving a look at the upcoming features for Chef in 2012.

The new omnibus build system for Chef consists of a couple repositories. First is the build system itself. Then, the repository for building open source software commonly used. Finally, the repository containing the build instructions for Chef itself, including both client and server. You're welcome to check these out and give it a go. If you need further help with them, the Chef developers mailing list or #chef-hacking channel on irc.freenode.net are the best resources.

Next, about managing configuration.

Since you're using Chef, you should manage the configuration with Chef itself. The demonstration (and the built packages from the omnibus projects above) uses Chef Solo for configuring the server, though it can be a chef-client to itself too. How you approach that is up to you, but store your Chef configuration in a source code repository, whether that is git or another system.

jtimberman
  • 7,511
  • 2
  • 33
  • 42
  • Hey jtimberman, Thanks for your reply. The omnibus build system seems to overstep other package managers like yum, deb though. Is everything supposed to be self contained? Thanks for your reply. – DevNull0000001 May 31 '12 at 18:45
  • Yes, everything is supposed to be self contained. It does look like there's overlap, but the point is giving you a single, stable package that has software that we *know* work with Chef that we can support. We can't necessarily trust that the underlying operating systems we support to not make sweeping changes to their packages, or languish on old versions not supported by upstream (like Ruby). Also, its the only sane way to release software for Windows :). – jtimberman Jun 23 '12 at 16:15
0

Git isn't built for setting up and deploying applications, you're better off with using an RPM through with kickstart.

The RPM build process shouldn't be too hard, it'll just take time to make it copy the files to the right locations unless you customize an existing SRPM.

Kyle
  • 1,589
  • 9
  • 14
  • A nice answer that stuck to what the question was asking and to the here-and-now. –  Dec 07 '12 at 23:19