-
Notifications
You must be signed in to change notification settings - Fork 5
Example
Create an OpsWorks stack: myapp::dev::us-east
. Note that the naming convention here is important. To use this workflow, you need to adhere to the naming convention of app::env::region. If your app name will have multiple words, use underscores, e.g. my_app.
Edit the stack settings for myapp::dev::us-east
. Set Use Custom Chef Cookbooks
to Yes
. Set the repository URL to https://s3.amazonaws.com/<berks-s3-bucket>/myapp-dev-us-east/cookbooks.tgz
. Replace <berks-s3-bucket>
with the name of the S3 bucket you specified when we got started. Note that you'll need to create the bucket manually: aws s3 mb s3://<my_bucket>
. You'll want to create an IAM user as well, the credentials for which you can specify in the fields provided. The user only needs s3:Get
and s3:List
permissions.
To go along with this new stack, we need a github repo called opsworks-myapp
. Create a new branch in the repo called dev-us-east
. This corresponds directly to the env::region portion of the stack name, so if we add another stack in the future called myapp::prod::us-west
, we would create a new branch called prod-us-east
. Clone the repo locally to <berks-repository-path>/opsworks-myapp
. Create a new Berksfile in the repo with whatever contents you need to run your stack. I'm going to assume a working knowledge of Berkshelf.
Now we're ready to create a new cookbook repository for our stack. The default opzworks behavior for the berks
command is to build the berkshelf, bundle it as cookbooks.tgz, and upload it to <berks-s3-bucket>/project-env-region/cookbooks.tgz
. It will then execute update_custom_cookbooks
on the stack so that the stack instances retrieve our updated cookbooks.
opzworks berks myapp
will work in our case if the only stack we have created is myapp. If you have any other stacks that match myapp
, the code will exit with a message that it detected more than one matching stack, in which case you need to be more explicit: opzworks berks myapp::dev::us-east
, for example.
If you want to skip the execution of update_custom_cookbooks
on the remote stack, pass the --no-update
flag.
It should look something like this:
Managing stack json works more or less the same way. In our opsworks-myapp
repo, in the same dev-us-east
branch, create a file called stack.json
. If you go into the Opsworks stack settings for our stack, you can copy out anything that already might exist there.
It should look something like the following (any valid json blob will suffice for our example):
{
"opsworks": {
"ruby_version": "2.2"
},
"ruby": {
"patch_version": "3"
},
"sensu": {
"version": "0.21.0-1"
},
"mapzen": {
"environment": "prod"
},
"uchiwa": {
"version": "0.13.0-1",
"install_method": "http",
"settings": {
"users": [
{
"username" : "user",
"password": "redacted",
"role": {
"readonly": false
}
}
]
}
}
}
Now we want to push this to our stack, so we'll run opzworks json myapp::dev
. The output would look similar to this:
You can now manage all your stack custom json from a the opsworks-myapp
github repo.