Chef-server Cookbook

Chef Infra (archive)
1

Ohai Chefs,

Chef Server 12 is generally available, but CHEF’s chef-server cookbook is
not up to date to support it. I’d like to talk briefly about the future of
this cookbook.

Internally at CHEF, we’ve been working on two new cookbooks:
chef-server-ingredient0, which provides a resource for managing “Chef
Server packages” from packagecloud, and chef-server-cluster1, which is
a set of recipes used with chef-provisioning to stand up a multi-node Chef
Server cluster. The main use case is for our internal operations team to
use this as the basis for building Hosted Chef, but it can also be a
reference point for others to consume, or use for ideas to build their own.

While server clusters are great, that doesn’t fit everyone’s needs or use
case. A single standalone Chef Server may be sufficient for your
organization, or for testing purposes. The scope of the chef-server
cookbook is to fulfill the “standalone” topology of Chef Server. It’s
purpose will be:

  1. Install chef-server-core package.

  2. Write out /etc/opscode/chef-server.rb content.

  3. Run chef-server-ctl reconfigure.

This is what the default recipe does now. However, it doesn’t do so with
the Package Cloud repositories that we have in place - it reimplements the
install.sh script as an “omnitruck client API library.” While this works,
the package repositories are an easier-to-consume way to get Chef Server
installed on a standalone system, and the code is a lot more maintainable.

Here’s the plan for how we’ll address this in the chef-server cookbook:

  1. The default recipe will be refactored to use the
    chef_server_ingredient resource, and we will support Chef Server 12.

  2. We’ll create a chef11 branch, which will be for Chef Server 11.

  3. The cookbook will be updated for testing with test-kitchen.

  4. We’ll make a major version bump of the cookbook, and release it to
    Supermarket, too.

We won’t support a dual-configurable v11 vs v12 option. If you need Chef
Server 11, use the 2.1.x version of the cookbook.

Complex configuration scenarios such as tiered or ha topologies are not
supported with this cookbook. The configuration hash will remain supported,
but we recommend using chef-server-cluster cookbook for non-standalone
topologies. We’ll have more guidance about how to set up a “wrapper”
cookbook, the use of chef-server-cluster, or using the
chef-server-ingredient cookbook to achieve customized deployments in the
future.

Thank you for your patience and understanding. If you have questions or
concerns please reach out to me, joshua@chef.io.

Cheers,

Joshua

2

Ohai Chefs!

Version 3.0.0 of chef-server is released, incorporating the changes
discussed above. The changelog contains a summary, and the readme is
updated to be clear about the scope of the cookbook.

https://supermarket.chef.io/cookbooks/chef-server

Enjoy!
Joshua

On Fri, Feb 20, 2015 at 4:35 PM, Joshua Timberman joshua@chef.io wrote:

Ohai Chefs,

Chef Server 12 is generally available, but CHEF’s chef-server cookbook
is not up to date to support it. I’d like to talk briefly about the future
of this cookbook.

Internally at CHEF, we’ve been working on two new cookbooks:
chef-server-ingredient0, which provides a resource for managing “Chef
Server packages” from packagecloud, and chef-server-cluster1, which is
a set of recipes used with chef-provisioning to stand up a multi-node Chef
Server cluster. The main use case is for our internal operations team to
use this as the basis for building Hosted Chef, but it can also be a
reference point for others to consume, or use for ideas to build their own.

While server clusters are great, that doesn’t fit everyone’s needs or use
case. A single standalone Chef Server may be sufficient for your
organization, or for testing purposes. The scope of the chef-server
cookbook is to fulfill the “standalone” topology of Chef Server. It’s
purpose will be:

  1. Install chef-server-core package.

  2. Write out /etc/opscode/chef-server.rb content.

  3. Run chef-server-ctl reconfigure.

This is what the default recipe does now. However, it doesn’t do so with
the Package Cloud repositories that we have in place - it reimplements the
install.sh script as an “omnitruck client API library.” While this works,
the package repositories are an easier-to-consume way to get Chef Server
installed on a standalone system, and the code is a lot more maintainable.

Here’s the plan for how we’ll address this in the chef-server cookbook:

  1. The default recipe will be refactored to use the
    chef_server_ingredient resource, and we will support Chef Server 12.

  2. We’ll create a chef11 branch, which will be for Chef Server 11.

  3. The cookbook will be updated for testing with test-kitchen.

  4. We’ll make a major version bump of the cookbook, and release it to
    Supermarket, too.

We won't support a dual-configurable v11 vs v12 option. If you need Chef
Server 11, use the 2.1.x version of the cookbook.

Complex configuration scenarios such as tiered or ha topologies are not
supported with this cookbook. The configuration hash will remain supported,
but we recommend using chef-server-cluster cookbook for non-standalone
topologies. We’ll have more guidance about how to set up a “wrapper”
cookbook, the use of chef-server-cluster, or using the
chef-server-ingredient cookbook to achieve customized deployments in the
future.

Thank you for your patience and understanding. If you have questions or
concerns please reach out to me, joshua@chef.io.

Cheers,

Joshua