Copyright (c) 2006-2014 MindTouch Inc.
This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).
At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.
A complete copy of the MSA is available at http://www.mindtouch.com/msa
Table of Contents
Show a recommended developer workflow for developing ServerTemplates using Chef cookbooks and recipes.
There are two basic types of workflows for Chef development.
The rsync program is available on Linux machines and can be used to synchronize file trees across local disks, directories, or a local network. In this example, rsync will be used to synchronize the cookbook repositories on your local development box with the cookbook repositories on the running server instance.
Although you can use both workflows for Chef development purposes, some developers may find it more useful to use the rsync model. One of the key benefits of using the rsync workflow is that you can develop your code faster and more efficiently because you do not have to constantly push all of the changes to your repository and refresh them in the Dashboard before you can run and test the script on the server. By using the rsync model, you can author code on your local development machine and test the script immediately on the running server without having to perform the push and refetch steps every time. This way, you will only have to push the code changes after you have already tested them on a running server.
Note: If you are using the rsync model, you will never be able to refetch changes from your cookbook repositories. As a best practice, once you are satisfied with your changes after testing your scripts using rsync, you should commit the changes to your cookbook repositories and relaunch a fresh new server without the "development" tag (which is mentioned in more detail below).
Note: You must use this workflow if you are going to make any changes to the Chef metadata (e.g. Add a new recipe).
Note: You can only use this workflow if you are not going to make any changes to the Chef metadata (e.g. Add a new recipe).
rs_run_recipe -n "<cookbook_name>::<recipe>" && tailf /var/log/messages
When you launch a server that uses cookbooks for server configuration purposes, the required cookbooks are locally stored on the server instance itself. A unique identifier is assigned to each repository on a running server instance. You will need to know a repository's UID if you want to use the Chef Developer Workflow that uses rsync.
Important! A cookbook's UID is not static. A new UID will be associated to a cookbook each time you update a cookbook's version or "Refetch" the cookbook after updating its code in its source repository.
Launch a server that uses cookbooks for server configuration purposes.
Once the server is operational, SSH into the server instance and navigate to the directory where cookbooks are locally stored. If you are using a server that was launched with a RightImage the cookbooks will be stored in the following location: /var/cache/rightscale/cookbooks/default
Run the following command to navigate to the default location:
# cd /var/cache/rightscale/cookbooks/default/
Each cookbook that is used by the server will be assigned a unique identifier. Therefore, you will most likely see a list of several cookbook directories.
# cd /var/cache/rightscale/cookbooks/default/ # ls 05fe0e9401da911fdb518fe37b3a8c5393e3883d 12fdb518fe37b3a8c5393e3283d05fe0e9401da9 b518fe37b3a8c5193e3883d05fe0e9401da912fd
Inside each one you will find a 'cookbooks' directory with all of the repository's cookbooks and recipes.
# cd 05fe0e9401da911fdb518fe37b3a8c5393e3883d/cookbooks/
If you want to run the command locally on your development machine, see code example below.
# rsync from Local Development Machine to Cloud Instance # # Assumes public key has been added to /root/.ssh/authorized_keys # # rsync -avz --exclude=.git <src_path> root@<instance>:/var/cache/rightscale/cookbooks/default/<HASH> # where <scr_path> is the directory of where the cookbooks are locally stored on your development machine. # <dst_path> is the directory of where the cookbooks are locally stored on the cloud server instance. # <HASH> is the Cookbook UID. # EXAMPLE: rsync -avz --exclude=.git /src/cookbooks/ firstname.lastname@example.org:/var/cache/rightscale/cookbooks/default/05fe0e9401da911fdb518fe37b3a8c5393e3883d/cookbooks
Use the cbsync Ruby script on your local development machine to rsync your current development directory to the cloud server (virtual machine) that you're using for testing purposes. Use the script to rsync one or all cookbooks.
See the 'psschroeter / cbsync' project: https://gist.github.com/psschroeter/6630949
|Glossary | 用語 | 용어||Site Map | Site Help||Community||Corporate Site||Get Support||Dashboard Login|
|Doc Feedback||Product Feedback||Resources||MultiCloud Marketplace||Forums|
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.