Deploys and configures the Chef server in a relatively stateless model. The included policyfiles provide examples of deployment options and the required attributes.
Install or restore the Chef Server in a new deployment, wrapping the Chef-Server cookbook. It looks for the existence of a knife-ec-backup tarball to restore from, configured with the node['mcs']['restore']['file'] attribute. You will need to use the managed_organization recipe or provide your own organizations recipe to use the other recipes.
This creates a managed Chef organization and an org-managing admin user through the appropriate attributes.
Runs knife ec backup via cron and puts the backups in the node['mcs']['backup']['dir']. The default is 2:30am daily, but you may change the cron schedule via the following attributes.
node['mcs']['backup']['cron']['minute'] = '30'
node['mcs']['backup']['cron']['hour'] = '2'
node['mcs']['backup']['cron']['day'] = '*'
node['mcs']['backup']['cron']['month'] = '*'
node['mcs']['backup']['cron']['weekday'] = '*'
Schedules the Chef client to run on the Chef server via cron against a provided policyfile archive. This may be set to use --local-mode, for when the Chef client has no other Chef server to contact. See the example policyfiles/cron.rb and kitchen.yml for reference.
The node['mcs']['data_bags']['dir'] is compared against the existing data bags on the server and creates and/or updates them as necessary. If the node['mcs']['data_bags']['prune'] attribute is true then the data bags and their items are deleted if they exist on the server but do not have the requisite JSON files.
Takes the node['mcs']['cookbooks']['dir'], node['mcs']['environments']['dir'] and node['mcs']['roles']['dir'] directories and loads whatever content is found into the Chef server organization. If you want to use the same directory for the roles and environments the recipe can distinguish between JSON files. The cookbooks are expected to be tarballs in a directory, they will all be attempted to load via their Berksfile or with knife. For legacy cookbooks with multiple dependencies it may take multiple runs to load everything.
Takes the node['mcs']['policyfile']['dir'] and parses any .lock.json files to determine which policyfile archives to load into the local Chef server. Policies will be assigned to the group designated by the node['mcs']['policyfile']['group'] attribute for the Chef server (_default is the default). If the policy itself sets the node['mcs']['policyfile']['group'] attribute, the policy will be assigned to that group.
The default.rb attributes file documents available settings and tunings.
Custom resources are used to reduce the complexity of the included recipes.
The :create action will instantiate a Chef server organization with an internal administrator user. The name properties is the organization. The organization's full_name, email, and password are all optional properties.
This resource schedules backups of the Chef server via cron-style properties (minute, hour, day, month, weekday). The backups are written to the directory and their filenames start with the prefix.
This resource requires an archive property specifying the policyfile archive to deploy and use for running via cron.
This resource requires a tarball property specifying the knife ec backup tarball to restore from.
This resource runs berks or knife against the directory property specifying the source for the cookbook tarballs to keep in sync with the server.
This resource works off of the directory property specifying the source for the data bags to keep in sync with the server.
This has :create, :prune, :item_create, and :item_prune for managing the data bags available on the server. This custom resource is called from the data_bag_loader resource.
All of the Ruby or JSON environment files in the directory will be loaded onto the Chef Server and updated if they change.
This resource looks for policyfile locks and archives in the directory specifying the source, only uploading them if they have been updated.
All of the Ruby or JSON role files in the directory will be loaded onto the Chef Server and updated if they change.
There is a kitchen.yml that may be used for testing with Vagrant. The kitchen.vagrant.yml may be symlinked as kitchen.local.yml and used with local caches to speed up testing. If you want to use Docker, kitchen.dokken.yml may be used but it does not persist changes between runs and is thus not significantly faster (it's slower than Vagrant with caching). The following Suites map to example policyfiles that may be repurposed as necessary, with variants for testing Chef 14 and 15 of each:
Tests simple installation and creation of the managed Chef user and organization.
Restores the Chef server from a backup with policyfiles. kitchen verify restore ensures the policyfiles were restored properly.
Checks the chef-client is in the crontab
Checks the backup script is in the crontab and backup directories are available.
Adds loading data bags from the included test directory. It restores from a previous data bag backup to ensure pruning and updating work.
Adds loading policyfiles from the included test directory.
Adds loading cookbooks, environments and roles from the included test directory.
Installs the Chef server, restores from a backup, attempts to load policyfiles (which are included in the restored backup) and adds backup via cron.
- Author: Matt Ray matt@chef.io
- Copyright 2018-2019, Chef Software, Inc
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.