Development repository for Opscode Cookbook application
hungryblank 30b30643fd fix COOK-2812 allow block for restart_command | hace 11 años | |
---|---|---|
libraries | hace 12 años | |
providers | hace 11 años | |
recipes | hace 12 años | |
resources | hace 11 años | |
templates | hace 12 años | |
test | hace 12 años | |
.gitignore | hace 12 años | |
CHANGELOG.md | hace 12 años | |
CONTRIBUTING.md | hace 12 años | |
Gemfile | hace 11 años | |
LICENSE | hace 12 años | |
README.md | hace 11 años | |
metadata.rb | hace 12 años |
This cookbook is designed to be able to describe and deploy web applications. It provides the basic infrastructure; other cookbooks are required to support specific combinations of frameworks and application servers. The following cookbooks are available at this time:
As of version 2.0.0 of this cookbook, the recipes using configuration
stored in the apps
data bag are fully deprecated and removed.
Version 1.0.4 of this cookbook is the last release where these recipes
were available.
See COOK-1820.
Chef 0.10.0 or higher required (for Chef environment use).
The previous dependencies have been moved out to the application-stack-specific cookbooks, and this cookbook has no external dependencies.
The application
LWRP configures the basic properties of most
applications, regardless of the framework or application server they
use. These include:
This LWRP uses the deploy_revision
LWRP to perform the bulk of its
tasks, and many concepts and parameters map directly to it. Check the
documentation for deploy_revision
for more information.
Configuration of framework-specific aspects of the application are performed by invoking a sub-resource; see the appropriate cookbook for more documentation.
:deploy
: deploy an application, including any necessary
configuration, restarting the associated service if necessary:force_deploy
: same as :deploy
, but it will send a :force_deploy
action to the deploy resource, directing it to deploy the
application even if the same revision is already deployedname
: name attribute. The name of the application you are setting
up. This will be used to derive the default value for other
attributepackages
: an Array or Hash of packages to be installed before
starting the deploymentpath
: target path of the deployment; it will be created if it does
not existowner
: the user that shall own the target pathgroup
: the group that shall own the target pathstrategy
: the underlying LWRP that will be used to perform the
deployment. The default is :deploy_revision
, and it should never
be necessary to change itscm_provider
: the provider class to use for the deployment. It
defaults to Chef::Provider::Git
, you can set it to
Chef::Provider::Subversion
to deploy from an SVN repositoryrepository
: the URL of the repository the application should be
checked out fromrevision
: an identifier pointing to the revision that should be
checked outdeploy_key
: the private key to use to access the repository via SSHrollback_on_error
: if true, exceptions during a deployment will be
caught and a clean rollback to the previous version will be
attempted; the exception will then be re-raised. Defaults to true;
change it only if you know what you are doingenvironment
: a Hash of environment variables to set while running
migrationspurge_before_symlink
: an Array of paths (relative to the checkout)
to remove before creating symlinkscreate_dirs_before_symlink
: an Array of paths (relative to the
checkout) pointing to directories to create before creating symlinkssymlinks
: a Hash of shared/dir/path => release/dir/path. It
determines which files and dirs in the shared directory get
symlinked to the current release directorysymlink_before_migrate
: similar to symlinks, except that they will
be linked before any migration is runmigrate
: if true
then migrations will be run; defaults to falsemigration_command
: a command to run to migrate the application from
the previous to the current staterestart_command
: a command to run when restarting the applicationenvironment_name
: the name of a framework-specific "environment"
(for example the Rails environment). By default it is the same as
the Chef environment, unless it is _default
, in which case it is
set to production
enable_submodules
: whether to enable git submodules in the deploy,
passed into the deploy resource.You can also set a few attributes on this LWRP that are interpreted as callback to be called at specific points during a deployment. If you pass a block, it will be evaluated within a new context. If you pass a string, it will be interpreted as a path (relative to the release directory) to a file; if it exists, it will be loaded and evaluated as though it were a Chef recipe.
The following callback attributes are available:
before_deploy
: invoked immediately after initial setup and before
the deployment proper is started. This callback will be invoked on
every Chef runbefore_migrate
before_symlink
before_restart
after_restart
Anything that is not a known attribute will be interpreted as the name of a sub-resource; the resource will be looked up, and any nested attribute will be passed to it. More than one sub-resource can be added to an application; the order is significant, with the latter sub-resources overriding any sub-resource that comes before.
Sub-resources can set their own values for some attributes; if they do, they will be merged together with the attribute set on the main resource. The attributes that support this behavior are the following:
environment
: environment variables from the application and from
sub-resources will be merged together, with later resources
overriding values set in the application or previous resourcesmigration_command
: commands from the application and from
sub-resources will be concatenated together joined with '&&' and run
as a single shell command. The migration will only succeed if all
the commands succeedrestart_command
: commands from the application and from
sub-resources will be evaluated in ordersymlink_before_migrate
: will be concatenated as a single arraycallbacks
: sub-resources callbacks will be invoked first, followed
by the application callbacksTo use the application cookbook we recommend creating a cookbook named
after the application, e.g. my_app
. In metadata.rb
you should
declare a dependency on this cookbook and any framework cookbook the
application may need. For example a Rails application may include:
depends "application"
depends "application_ruby"
The default recipe should describe your application using the
application
LWRP; you may also include additional recipes, for
example to set up a database, queues, search engines and other
components of your application.
A recipe using this LWRP may look like this:
application "my_app" do
path "/deploy/to/dir"
owner "app-user"
group "app-group"
repository "http://git.example.com/my-app.git"
revision "production"
# Apply the rails LWRP from application_ruby
rails do
# Rails-specific configuration. See the README in the
# application_ruby cookbook for more information.
end
# Apply the passenger_apache2 LWRP, also from application_ruby
passenger_apache2 do
# Passenger-specific configuration.
end
end
You can of course use any code necessary to determine the value of attributes:
application "my_app" do
repository "http://git.example.com/my-app.git"
revision node.chef_environment == "production" ? "production" : "develop"
end
Attributes from the application and from sub-resources are merged together:
application "my_app" do
restart_command "kill -1 `cat /var/run/one.pid`"
environment "LC_ALL" => "en", "FOO" => "bar"
rails do
restart_command "touch /tmp/something"
environment "LC_ALL" => "en_US"
end
passenger_apache2 do
environment "FOO" => "baz"
end
end
# at the end, you will have:
#
# restart_command #=> kill -1 `cat /var/run/one.pid` && touch /tmp/something
# environment #=> LC_ALL=en_US FOO=baz
Most databases have the concept of migrations (or you can just use your own):
application "my_app" do
path "/deploy/to/dir"
owner "app-user"
group "app-group"
repository "http://git.example.com/my-app.git"
revision "production"
php do
migrate true
migration_command "your-applications-migrate-command"
end
end
This will run your-applications-migrate-command
, with the current
directory set to the directory of the current checkout.
To use the application cookbook, we recommend creating a role named
after the application, e.g. my_app
. Create a Ruby DSL role in your
chef-repo, or create the role directly with knife.
% knife role show my_app -Fj
{
"name": "my_app",
"chef_type": "role",
"json_class": "Chef::Role",
"default_attributes": {
},
"description": "",
"run_list": [
"recipe[my_app]"
],
"override_attributes": {
}
}
Author: Seth Chisamore (schisamo@opscode.com)
Copyright 2009-2012, Opscode, 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.