Buildout recipes for postdeploy.
Project description
Post-deploy
This recipe is for people who want to automate checking (or actual application) of post-buildout deployment steps and havent adopted a configuration management system like Yaybu, Puppet or Chef.
It takes a template Yaybu configuration and allows you to inject settings from your buildout - so the configuration is configured for that one particualar deployment. It creates a bin/postdeploy that you can run with sudo after running buildout.
When you graduate to server-wide configuration management you can opt to keep your post-deployment configuration with your buildout and just call postdeploy from your main configuration management tool.
Basic use
Consider a simple yaybu configuration:
resources.append: - Execute: name: some-script command: ${buildout.buildout.directory}/bin/somescript user: root creates: ${buildout.buildout.directory}/stuff.cfg
You could wire this into buildout like so:
[buildout] parts = postdeploy [postdeploy] recipe = isotoma.recipe.postdeploy config = config.yay
To look at the ‘expanded’ form of your configuration - with all the variables filled in - you can now (after running buildout) do:
$ ./bin/postdeploy show resources: - Execute: name: /var/somedir/bin/somescript user: root creates: /var/somedir/stuff.cfg
This command optionally takes -v which shows a more verbose dump of your configuration.
You can simulate what would happen if the config was applied without harming the system using the simulate command:
$ ./bin/postdeploy simulate /---------------------------- Execute[some-script] ----------------------------- | # /var/somedir/bin/somescript \-------------------------------------------------------------------------------
This command will have an exit code of 254 if it thinks no changes are required, 0 if it successfully simulated applying some changes and anything else indicates a problem with your configuration. It makes an ideal monitoring tool as it can warn of manual hacks or incomplete deployments.
Finally you can apply the configuration with apply:
$ ./bin/postdeploy simulate /---------------------------- Execute[some-script] ----------------------------- | # /var/somedir/bin/somescript | Here is the stdout from your command | .... | .... | Success! \-------------------------------------------------------------------------------
Mandatory Parameters
- config
A Yay file to apply to this computer. It will have access to metadata in your buildout.
Optional Parameters
- searchpath
A set of directories or URLs to search for assets needed to full configure this site.
- history.track
A list of values to monitor. This is useful when you have a list of parts that are buildout managed but need symlinking in postdeploy. Using history tracking you can make sure they are removed from the system if they are removed from buildout.
For example:
[buildout] parts = ${parts:apache} postdeploy [vhost1] <snip> [parts] apache = vhost1 vhost2 [postdeploy] recipe = isotoma.recipe.postdeploy history.track = parts:apache
And in your Yaybu configuration:
resources.append: .foreach vhost in history.parts.apache: - Link: name: /etc/apache2/sites-enabled/${buildout.sitename}-${vhost} policy: remove
The first time you run buildout a datafile with the current state is created, Now if you remove vhost2 from your buildout and run postdeploy Yaybu will ensure your symlink is removed. This data persists across multiple buildouts so is safe even if you forget to run postdeploy.
- history.db
You don’t normally need to change this setting.
Because this recipe has to support Python 2.4 it can’t use Yay as its main datastore. This is the path to a Python shelf.
The default is ${buildout:directory}/var/${partname}-history.db
- history.yay
You don’t normally need to change this setting.
The data from history.db is persisted as yay, it is loaded from here when you run bin/postdeploy.
The default is ${buildout:directory}/var/${partname}-history.yay
- executable
A python executable to use. Defaults to the same one used to invoke buildout. This is to support Python 2.4 buildouts as Yaybu requires 2.6 or 2.7.
Repository
This software is available from our recipe repository on github.
License
Copyright 2012 Isotoma Limited
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
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.
Changelog
0.0.0 (2012-03-16)
Nothing changed yet.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Hashes for isotoma.recipe.postdeploy-0.0.0.tar.gz
Algorithm | Hash digest | |
---|---|---|
SHA256 | 733e7d7e6bf410186364e88c03c5238ba5d84424df5138f4865cc1c5cd4f3c5a |
|
MD5 | 0e7958d26bca61f8eb5e0029d630a34c |
|
BLAKE2b-256 | f55d8b14a9c0e0b9568ff3b19c3bec1db620e84586502a786fce90f594ebb90f |