eb_deployer 0.2.2 → 0.2.3

data/.gitignore

@@ -16,3 +16,6 @@ test/tmp
 test/version_tmp
 tmp
 /.rvmrc
+_site
+/samples/jruby_rails4/jruby_rails4.war
+/samples/jruby_rails4/public/assets/*

data/.ruby-gemset

@@ -0,0 +1 @@
+eb_deployer

data/.ruby-version

@@ -0,0 +1 @@
+ruby-1.9.3-p429

data/README.md

@@ -1,8 +1,8 @@
 # EbDeployer
 
-Low friction deployments should be a breeze. Elastic Beanstalk provides a great foundation for performing Blue-Green deployments, and EbDeployer add a missing top to automate the whole flow out of box.
+Low friction deployments should be a breeze. Elastic Beanstalk provides a great foundation for performing Blue-Green deployments, and EbDeployer add a missing link to automate the whole flow out of box.
 
-ElasticBeanstalk Deployer thus allows you to do continuous delivery on AWS.
+EbDeployer thus allows you to do continuous delivery on AWS.
 
 ## Installation
 
@@ -12,18 +12,22 @@ ElasticBeanstalk Deployer thus allows you to do continuous delivery on AWS.
 
 ### Step One: AWS Account Setup
 
-Create an AWS IAM user for deploy and give it privilege to operate Elastic Beanstalk. Download the access keys for executing the deployment tasks later.
+Create an AWS IAM user for deploy and give it privilege to operate Elastic Beanstalk. Download the access keys for executing the deployment tasks later. Ensure your command line is primed with appropriate access_keys using one of techniques mentioned on [aws blog](http://ruby.awsblog.com/blog/tag/config). For example using environment variable:
+
+    $ export AWS_ACCESS_KEY_ID=xxx
+    $ export AWS_SECRET_ACCESS_KEY=xxx
+
 
 ### Step Two: Packaging
 
-You need package your application for Elastic Beanstalk stack first. For Java app an warball is appropriate. For Ruby on Rails app a tar.gz file is good. You can also package a Rails/Sinatra app as war ball using warbler and deploy to Java stack. (Please remember do rake assets:precompile first for rails app)
+You need to package your application for Elastic Beanstalk stack first. For Java app a warball is appropriate. For Ruby on Rails app a tar.gz file is good. You can also package a Rails/Sinatra app as a war ball using warbler and deploy to Java stack. (Please remember to run rake assets:precompile first for a rails app.)
 
 
 ### Step Three: Generate configuration and Configure deployment process
 
     $ eb_deploy
 
-This will generate a default configuration at location 'config/eb_deployer.yml'. It is almost empty but working one. And it will generate settings for two environment 'dev' and 'production'. If you had time please try to read through it to see the options you can tweak.
+This will generate a default configuration at location 'config/eb_deployer.yml'. It is almost empty but working one. And it will generate settings for two environments 'development' and 'production'. Some options can be tweaked. The yml files includes documentation on how you can best suit it to your purpose.
 
 
 ### Step Four: Fasten your seat belt
@@ -31,26 +35,27 @@ run deploy
 
     $ eb_deploy -p <package built> -e <environment>
 
-Then open aws console for Elastic Beanstalk to see what happened.
+Then open aws console for Elastic Beanstalk to see the result of this deployment.
 
 
-### Smoke Testing your stack
+### Conifgure Smoke Testing your stack
 
 EB_Deployer allows you to automate your deployment and then some. You can also add smoke tests to your deployment - thus ensuring that the app you deployed is also working correctly.
-Adding a smoke test suite is also simple. Check "smoke_test" section in your eb_deployer.yml. The simplest thing you can do is using curl make sure landing page get loaded, e.g.:
+Adding a smoke test suite is also simple. Check "smoke_test" section in your eb_deployer.yml. We show a simple curl based smoke test that helps you test if your app is up and responding to http.
 
-    smoke_test: >
+    smoke_test: |
       curl_http_code = "curl -s -o /dev/null -w \"%{http_code}\" http://#{host_name}"
       Timeout.timeout(600) do
-        while `#{curl_http_code}`.strip != '200'
+        until ['200', '302'].include?(`#{curl_http_code}`.strip)
           sleep 5
         end
       end
 
 
+Any rakeable test suite can be run as part of the smoke test(selenium, cucumber, capybara, and so on.)
 You can add more smoke tests by calling arbitrary rake tasks (Please make sure check return status):
-   
-    smoke_test: >
+
+    smoke_test: |
       `rake test:smoke HOST_NAME=#{host_name}`
       raise("Smoke failed!") unless $?.success?
 
@@ -67,7 +72,7 @@ Once this new stack is stable or has run for a while you can choose to delete th
 
 ### Destroying a stack
 So you are done with this application or environment, you can destroy it easily as well.
-   
+
     $ eb_deployer -d -e <environment>
 
 and you are done!

data/lib/eb_deployer.rb

@@ -205,7 +205,7 @@ module EbDeployer
     action = options.delete(:action)
 
     unless File.exists?(options[:config_file])
-      puts "Generat default configuration one at location #{options[:config_file]}."
+      puts "Generated default configuration at #{options[:config_file]}."
       DefaultConfig.new(File.basename(Dir.pwd)).write_to(options[:config_file])
       exit(2)
     end

data/lib/eb_deployer/default_config.yml

@@ -9,32 +9,32 @@ common:
   # AWS region to deploy. Default to us-east-1
   # region: us-west-1
 
-  # There are two deployment strategies: blue-green or inplace-update.
-  # Blue green keep two elastic beanstalk environments and always deploy to
-  # inactive one, to achive zero downtime. inplace-update strategy
-  # will only keep one environment, and update the version inplace on
-  # deploy. inplace-update will save resources but will have downtime. Default
-  # strategy is blue-green. PS. All old environments need be destroyed when you
-  # switching between strategies.
+  # There are two deployment strategies: 'blue-green' or 'inplace-update'.
+  # Blue green deployments keep two elastic beanstalk environments and always deploy to
+  # inactive one, to achieve zero downtime.
+  # Inplace-update strategy will only keep one environment, and update the version inplace on
+  # deploy. Inplace-update will save resources but will suffer from downtime.
+  # (All old environments need be destroyed when you switching between strategies.)
+  # Default strategy is 'blue-green'.
   # strategy: blue-green
 
-  # If phoenix mode is turn on, it will terminate the old elastic
-  # beanstalk environment and recreate on deploy. For blue-green
-  # deployment it terminate the inactive environment first then
-  # recreate it. This is useful to avoiding configuration drift and
-  # accumulating state on the ec2 instances. Also it has the benifit of
+  # If phoenix mode is turned 'on', it will terminate the old elastic
+  # beanstalk environment and recreate a new one on deploy. For blue-green
+  # deployment it will terminate the inactive environment first then
+  # recreate it. This is useful to avoid configuration drift and
+  # accumulating state on the ec2 instances. Also it has the benefit of
   # keeping your ec2 instance system package upto date, because everytime ec2
-  # instance boot up from AMI it does a system update. Default is off but we suggest
-  # overriden it to on for production environment.
+  # instance boots up from AMI it does a system update. Default is 'off' but we suggest
+  # you override it to 'on' for production environment.
   # phoenix_mode: false
 
-  # Generating version label for package be deployed. A readable version label will
+  # Generating version label for package to be deployed. A readable version label will
   # provide better traceablity of your deployment process.
   # By default setting is:
   # version_label: <%%= package_digest %>
   # which means using MD5 digest of the package file. If you deploy using build
   # pipeline tool such as GO, switching to pipline counter is highly suggested to
-  # increase the readability. Following example read pipeline counter from environment
+  # increase the readability. Following example will read pipeline counter from environment
   # variable with a fall back to digest for local deployment:
   # version_label: <%%= ENV['GO_PIPELINE_COUNTER'] || package_digest %>
 
@@ -42,26 +42,27 @@ common:
   # Smoke test value should be a piece of ruby code with access to single variable
   # "host_name" -- environment DNS name. Smoke test snippet will be evaluated at
   # the end of the deployment for inplace-update deployment. For blue-green
-  # deployment it will run after inactive environment update finish and before
-  # switching.
-  # Defining a smoke test is high recommended for serious usage. The
-  # simplest one could just be checking server landing page using curl, e.g.
-  # smoke_test: >
-  #   curl_http_code = "curl -s -o /dev/null -w \"%{http_code}\" http://#{host_name}"
-  #   Timeout.timeout(600) do
-  #     while `#{curl_http_code}`.strip != '200'
-  #       sleep 5
-  #     end
-  #   end
+  # deployment it will run after inactive environment update is completed and before
+  # switching over.
+  # Defining a smoke test is highly recommended for serious usage. By default we use
+  # The simplest one that just be checking server landing page using curl, e.g.
+  smoke_test: |
+    curl_http_code = "curl -s -o /dev/null -w \"%{http_code}\" http://#{host_name}"
+    Timeout.timeout(600) do
+      until ['200', '302'].include?(`#{curl_http_code}`.strip)
+        sleep 5
+      end
+    end
 
 
-  # Elastic Beanstalk settings that will apply to the environments you
+
+  # Elastic Beanstalk settings that will apply to the environments you are
   # deploying.
   # For all available options take a look at
   # http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html
   option_settings:
     # Following is an option_settings example which changes EC2 instance type
-    # from t1.micro (default) to m1.small. Intances with t1.micro type sometime
+    # from t1.micro (default) to m1.small. Instances with t1.micro type sometime
     # are not very responsible, so m1.small is suggested for saving time.
     # But if you care about the marginal cost difference you can comment this out to
     # go back to t1.micro.
@@ -82,10 +83,12 @@ common:
   #    :capabilities => An array. You need set it to ['CAPABILITY_IAM'] if the
   # template include IAM Instance Profile.
   resources:
-    # For example creating a RDS instance for blue green deployment:
+
+    # For example creating a RDS instance for blue green deployment(check jruby-rails4
+    # sample project which has a working example):
     # template: config/my_rds.json
     # inputs:
-    #   DBPassword: <%%= random_hash %>
+    #   DBPassword: <%%= ENV.fetch("MYDBPASSWORD") %>
     # outputs:
     #   RDSPassSecurityGroup:
     #     namespace: aws:autoscaling:launchconfiguration
@@ -102,7 +105,7 @@ environments:
     # strategy: inplace-update
   production:
     option_settings:
-      # example for overriding common option_settings: providing least redanduncy
+      # example for overriding common option_settings: providing least redundancy
       # in production environment.
       # - namespace: aws:autoscaling:asg
       #   option_name: MinSize

data/lib/eb_deployer/version.rb

@@ -1,3 +1,3 @@
 module EbDeployer
-  VERSION = "0.2.2"
+  VERSION = "0.2.3"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: eb_deployer
 version: !ruby/object:Gem::Version
-  version: 0.2.2
+  version: 0.2.3
   prerelease: 
 platform: ruby
 authors:
@@ -10,7 +10,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-09-28 00:00:00.000000000 Z
+date: 2013-09-29 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: aws-sdk
@@ -54,6 +54,8 @@ extensions: []
 extra_rdoc_files: []
 files:
 - .gitignore
+- .ruby-gemset
+- .ruby-version
 - Gemfile
 - LICENSE
 - README.md