ufo 2.1.0 → 2.2.0

data/README.md

@@ -22,14 +22,6 @@ See [ufoships.com](http://ufoships.com) for full documentation.
 
 ## Installation
 
-If you want to quickly install ufo without having to worry about ufo’s dependencies you can simply install the Bolts Toolbelt which has ufo included.
-
-```sh
-brew cask install boltopslabs/software/bolts
-```
-
-Or if you prefer you can install ufo with RubyGems
-
 ```sh
 gem install ufo
 ```

data/docs/_docs/conventions.md

@@ -6,7 +6,7 @@ Ufo uses a set of naming conventions.  This helps enforce some best practices an
 
 ### UFO_ENV to ECS Cluster Convention
 
-By default, the ECS cluster value is the same as UFO_ENV's value.  So if `UFO_ENV=prod` then the ECS Cluster is prod and if `UFO_ENV=stag` then the ECS Cluster is stag.  You can easily override this convention by specifying the `--cluster` CLI option.  You can also override this behavior with [settings.yml]({% link _docs/settings.md %}) to spare you from having to type `--cluster` over and over.
+By default, the ECS cluster value is the same as UFO_ENV's value.  So if `UFO_ENV=production` then the ECS Cluster is production and if `UFO_ENV=staging` then the ECS Cluster is staging.  You can easily override this convention by specifying the `--cluster` CLI option.  You can also override this behavior with [settings.yml]({% link _docs/settings.md %}) to spare you from having to type `--cluster` over and over.
 
 ### Service and Task Names Convention
 

data/docs/_docs/helpers.md

@@ -12,6 +12,7 @@ full\_image\_name | The full docker image name that ufo builds. The "base" por
 dockerfile\_port | Exposed port extracted from the Dockerfile of the project. 
 env_vars(text) | This method takes a block of text that contains the env values in key=value format and converts that block of text to the proper task definition json format.
 env_file(path) | This method takes an `.env` file which contains a simple key value list of environment variables and converts the list to the proper task definition json format.
+task_definition_name | The name of the task_definition.  So if the code looks like this `task_definition "demo-web" do`, the task_definition_name is "demo-web".
 
 To call the helper in task_definitions.rb you must add `helper.` in front.  So full\_image\_name  is called via `helper.full_image_name`.
 

data/docs/_docs/settings.md

@@ -15,17 +15,18 @@ image: tongueroo/hi
 clean_keep: 30
 ecr_keep: 30
 aws_profile_ufo_env_map:
-  default: prod
-  # More examples:
-  # aws_profile1: prod
-  # aws_profile2: stag
-  # aws_profile3: dev
+  default: staging
+#   # More examples:
+#   aws_profile1: production
+#   aws_profile2: staging
+#   aws_profile3: development
+
 ufo_env_cluster_map:
-  default: prod
-  # More examples:
-  # aws_profile1: prod
-  # aws_profile2: stag
-  # aws_profile3: dev
+  default: production
+#   # More examples:
+#   production: production
+#   staging: staging
+#   development: development
 ```
 
 The table below covers what each setting does:
@@ -39,19 +40,19 @@ Setting  | Description
 
 ### UFO_ENV to ECS Cluster Mapping
 
-The `ufo_env_cluster_map` option allows you to override the [UFO_ENV to ECS Cluster Convention]({% link _docs/conventions.md %}).  Normally, the ECS cluster defaults to whatever UFO_ENV is set to.  For example, when `UFO_ENV=prod` the ECS Cluster is prod and when `UFO_ENV=stag` the ECS Cluster is stag.  This setting allows you to override this behavior so that you do not have to specify the `--cluster` CLI option repeatedly.  Let's go through an example:
+The `ufo_env_cluster_map` option allows you to override the [UFO_ENV to ECS Cluster Convention]({% link _docs/conventions.md %}).  Normally, the ECS cluster defaults to whatever UFO_ENV is set to.  For example, when `UFO_ENV=production` the ECS Cluster is production and when `UFO_ENV=staging` the ECS Cluster is staging.  This setting allows you to override this behavior so that you do not have to specify the `--cluster` CLI option repeatedly.  Let's go through an example:
 
 By default:
 
 ```sh
-UFO_ENV=prod ufo ship hi-web # cluster defaults to UFO_ENV which is prod
-UFO_ENV=prod ufo ship hi-web --cluster prod # same as above
+UFO_ENV=production ufo ship hi-web # cluster defaults to UFO_ENV which is prod
+UFO_ENV=production ufo ship hi-web --cluster prod # same as above
 ```
 
 Override the convention and explicitly specify the `--cluster` option in the CLI.
 
 ```sh
-UFO_ENV=prod ufo ship hi-web --cluster custom-cluster # override the default UFO_ENV TO cluster mapping
+UFO_ENV=production ufo ship hi-web --cluster custom-cluster # override the default UFO_ENV TO cluster mapping
 ```
 
 We can also override the convention with `settings.yml`:
@@ -64,7 +65,7 @@ ufo_env_cluster_map:
 Because of the `ufo_env_cluster_map` setting, the `--cluster` CLI option is not longer required:
 
 ```sh
-UFO_ENV=prod ufo ship hi-web # same as --cluster custom-cluster because of settings.yml
+UFO_ENV=production ufo ship hi-web # same as --cluster custom-cluster because of settings.yml
 ```
 
 ### AWS_PROFILE TO UFO_ENV Mapping
@@ -73,23 +74,23 @@ An interesting way to set `UFO_ENV` is with the `aws_profile_ufo_env_map` in `uf
 
 ```yaml
 aws_profile_ufo_env_map:
-  default: dev
-  my-prod-profile: prod
-  my-stag-profile: stag
+  default: development
+  my-prod-profile: production
+  my-stag-profile: staging
 ```
 
 In this case, when you set `AWS_PROFILE` to switch AWS profiles, ufo picks this up and maps the `AWS_PROFILE` value to the specified `UFO_ENV` using the `aws_profile_ufo_env_map` lookup.  Example:
 
 ```sh
-AWS_PROFILE=my-prod-profile => UFO_ENV=prod
-AWS_PROFILE=my-stag-profile => UFO_ENV=stag
-AWS_PROFILE=default => UFO_ENV=dev
-AWS_PROFILE=whatever => UFO_ENV=dev
+AWS_PROFILE=my-prod-profile => UFO_ENV=production
+AWS_PROFILE=my-stag-profile => UFO_ENV=staging
+AWS_PROFILE=default => UFO_ENV=development
+AWS_PROFILE=whatever => UFO_ENV=development
 ```
 
-Notice how `AWS_PROFILE=whatever` results in `UFO_ENV=dev`.  This is because the `default: dev` map is specially treated. If you set the `default` map, this becomes the default value when the profile map is not specified in the rest of `ufo/settings.yml`.
+Notice how `AWS_PROFILE=whatever` results in `UFO_ENV=development`.  This is because the `default: development` map is specially treated. If you set the `default` map, this becomes the default value when the profile map is not specified in the rest of `ufo/settings.yml`.
 
-This behavior prevents you from switching `AWS_PROFILE`s and then accidentally deploying a production based docker image to staging and vice versas because you forgot to also switch `LONO_ENV` to its respective environment.
+This behavior prevents you from switching `AWS_PROFILE`s and then accidentally deploying a production based docker image to staging and vice versas because you forgot to also switch `UFO_ENV` to its respective environment.
 
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/ufo-help.md %}">Back</a>

data/docs/_docs/tutorial-ufo-ship.md

@@ -14,7 +14,7 @@ By convention, ufo will ship the docker container to an ECS cluster with the sam
 
 ```sh
 ufo ship hi-web --cluster prod
-UFO_ENV=prod ufo ship hi-web --cluster prod
+UFO_ENV=production ufo ship hi-web --cluster prod
 ```
 
 When you run `ufo ship hi-web`:

data/docs/_docs/ufo-env.md

@@ -15,13 +15,13 @@ The `UFO_ENV` can be set easily in several ways:
 ### At the CLI Command
 
 ```sh
-UFO_ENV=prod ufo ship hi-web --cluster prod
+UFO_ENV=production ufo ship hi-web --cluster prod
 ```
 
 ### As an environment variable
 
 ```sh
-export UFO_ENV=prod
+export UFO_ENV=production
 ufo ship hi-web --cluster prod
 ```
 
@@ -33,21 +33,21 @@ The most interesting way to set `UFO_ENV` is with the `aws_profile_ufo_env_map`
 
 ```yaml
 aws_profile_ufo_env_map:
-  default: dev
-  my-prod-profile: prod
-  my-stag-profile: stag
+  default: development
+  my-prod-profile: production
+  my-stag-profile: staging
 ```
 
 In this case, when you set `AWS_PROFILE` to switch AWS profiles, ufo picks this up and maps the `AWS_PROFILE` value to the specified `UFO_ENV` using the `aws_profile_ufo_env_map` lookup.  Example:
 
 ```sh
-AWS_PROFILE=my-prod-profile => UFO_ENV=prod
-AWS_PROFILE=my-stag-profile => UFO_ENV=stag
-AWS_PROFILE=default => UFO_ENV=dev
-AWS_PROFILE=whatever => UFO_ENV=dev
+AWS_PROFILE=my-prod-profile => UFO_ENV=production
+AWS_PROFILE=my-stag-profile => UFO_ENV=staging
+AWS_PROFILE=default => UFO_ENV=development
+AWS_PROFILE=whatever => UFO_ENV=development
 ```
 
-Notice how `AWS_PROFILE=whatever` results in `UFO_ENV=dev`.  This is because the `default: dev` map is specially treated. If you set the `default` map, this becomes the default value when the profile map is not specified in the rest of `ufo/settings.yml`.  More info on settings is available at [settings]({% link _docs/settings.md %}).
+Notice how `AWS_PROFILE=whatever` results in `UFO_ENV=development`.  This is because the `default: development` map is specially treated. If you set the `default` map, this becomes the default value when the profile map is not specified in the rest of `ufo/settings.yml`.  More info on settings is available at [settings]({% link _docs/settings.md %}).
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/settings.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/variables.md %}">Next Step</a>

data/docs/_docs/variables.md

@@ -28,27 +28,27 @@ Shared variables also support a concept called layering.  The `config/variables/
 @environment = helper.env_file(".env")
 ```
 
-When `ufo ship` is ran with `UFO_ENV=prod` he `config/variables/prod.rb` will be evaluated and layered on top of the variables defined in `base.rb:
+When `ufo ship` is ran with `UFO_ENV=production` he `config/variables/production.rb` will be evaluated and layered on top of the variables defined in `base.rb:
 
-`ufo/variables/prod.rb`:
+`ufo/variables/production.rb`:
 
 ```ruby
-@environment = helper.env_vars(%Q{
+@environment = helper.env_vars(%Q[
   RAILS_ENV=production
   SECRET_KEY_BASE=secret
-})
+])
 ```
 
-When `ufo ship` is ran with `UFO_ENV=stag` he `config/variables/stag.rb` will be evaluated and layered on top of the variables defined in `base.rb:
+When `ufo ship` is ran with `UFO_ENV=staging` he `config/variables/staging.rb` will be evaluated and layered on top of the variables defined in `base.rb:
 
 
-`ufo/variables/prod.rb`:
+`ufo/variables/production.rb`:
 
 ```ruby
-@environment = helper.env_vars(%Q{
+@environment = helper.env_vars(%Q[
   RAILS_ENV=staging
   SECRET_KEY_BASE=secret
-})
+])
 ```
 
 

data/lib/starter_project/Dockerfile

@@ -1,4 +1,4 @@
-FROM ruby:2.3.3
+FROM ruby:2.5.0
 MAINTAINER Tung Nguyen <tongueroo@gmail.com>
 
 # This is just a sample Dockerfile. This is meant to be overriden.

data/lib/starter_project/ufo/settings.yml

@@ -4,15 +4,15 @@ image: <%= @image %>
 # ecr_keep: 30
 
 # aws_profile_ufo_env_map:
-#   default: prod
+#   default: staging
 #   # More examples:
-#   aws_profile1: prod
-#   aws_profile2: stag
-#   aws_profile3: dev
+#   aws_profile1: production
+#   aws_profile2: staging
+#   aws_profile3: development
 
 # ufo_env_cluster_map:
 #   default: prod
 #   # More examples:
-#   aws_profile1: prod
-#   aws_profile2: stag
-#   aws_profile3: dev
+#   production: prod
+#   staging: stag
+#   development: dev

data/lib/starter_project/ufo/task_definitions.rb

@@ -1,11 +1,12 @@
-# There will be some special variables that are automatically available in this file.
+# There some built-in helpers that are automatically available in this file.
 #
-# Some of variables are from the Dockerfile and some are from other places.
+# Some of helpers get data from the Dockerfile and some are from other places.
+# Here's a summary of the some helpers:
 #
-# * helper.full_image_name - Docker image name with the tag when docker image is built by ufo. This is defined in ufo/settings.yml.  The helper.full_image_name includes the git sha tongueroo/hi:ufo-[sha].
-# * helper.dockerfile_port - Expose port in the Dockerfile.  Only supports one exposed port, the first one that is encountered.
-#
-# helper.env_vars - is a helper method that generates the proper environment Array of Hashes
+#   full_image_name 
+#   dockerfile_port
+#   env_vars(text)
+#   env_file(path)
 #
 # More info: http://ufoships.com/docs/helpers/
 #
@@ -18,7 +19,8 @@ task_definition "<%= @app %>-web" do
     # uncomment out to set the log group
     # awslogs_group: "<%= @app %>-web",
     # awslogs_stream_prefix: "<%= @app %>",
-    command: ["bin/web"]
+    # awslogs_region: "us-east-1",
+    # command: ["bin/web"] # IMPORTANT: change or create a bin/web file
   )
 end
 
@@ -30,7 +32,8 @@ task_definition "<%= @app %>-worker" do
     # uncomment out to set the log group
     # awslogs_group: "<%= @app %>-worker",
     # awslogs_stream_prefix: "<%= @app %>",
-    command: ["bin/worker"]
+    # awslogs_region: "us-east-1",
+    # command: ["bin/worker"] # IMPORTANT: change or create a bin/worker file
   )
 end
 
@@ -42,6 +45,7 @@ task_definition "<%= @app %>-clock" do
     # uncomment out to set the log group
     # awslogs_group: "<%= @app %>-clock",
     # awslogs_stream_prefix: "<%= @app %>",
-    command: ["bin/clock"]
+    # awslogs_region: "us-east-1",
+    # command: ["bin/clock"] # IMPORTANT: change or create a bin/clock file
   )
 end

data/lib/starter_project/ufo/variables/{stag.rb → development.rb}

@@ -1,7 +1,7 @@
-# Example ufo/variables/prod.rb
+# Example ufo/variables/development.rb
 # More info on how variables work: http://ufoships.com/docs/variables/
 @cpu = 192
-@environment = helper.env_vars(%Q{
-  RAILS_ENV=staging
+@environment = helper.env_vars(%Q[
+  RAILS_ENV=development
   SECRET_KEY_BASE=secret
-})
+])

data/lib/starter_project/ufo/variables/{prod.rb → production.rb}

@@ -1,7 +1,7 @@
-# Example ufo/variables/prod.rb
+# Example ufo/variables/production.rb
 # More info on how variables work: http://ufoships.com/docs/variables/
 @cpu = 256
-@environment = helper.env_vars(%Q{
+@environment = helper.env_vars(%Q[
   RAILS_ENV=production
   SECRET_KEY_BASE=secret
-})
+])

data/lib/ufo.rb

@@ -13,6 +13,7 @@ module Ufo
   autoload :Util, 'ufo/util'
   autoload :Init, 'ufo/init'
   autoload :CLI, 'ufo/cli'
+  autoload :Help, 'ufo/help'
   autoload :Ship, 'ufo/ship'
   autoload :Task, 'ufo/task'
   autoload :Destroy, 'ufo/destroy'

data/lib/ufo/aws_services.rb

@@ -1,4 +1,7 @@
-require 'aws-sdk'
+require "aws-sdk-ecs"
+require "aws-sdk-ec2"
+require "aws-sdk-elasticloadbalancingv2"
+require "aws-sdk-cloudwatchlogs"
 
 module Ufo
   module AwsServices

data/lib/ufo/cli.rb

@@ -1,6 +1,5 @@
 require 'thor'
 require 'ufo/command'
-require 'ufo/cli/help'
 
 module Ufo
   class CLI < Command
@@ -11,17 +10,17 @@ module Ufo
     class_option :cluster, desc: "Cluster.  Overrides ufo/settings.yml."
 
     desc "docker [ACTION]", "docker related tasks"
-    long_desc Help.docker
+    long_desc Help.text(:docker)
     subcommand "docker", Docker
 
     desc "tasks [ACTION]", "task definition related tasks"
-    long_desc Help.tasks
+    long_desc Help.text(:tasks)
     subcommand "tasks", Tasks
 
     desc "init", "setup initial ufo files"
     option :image, type: :string, required: true, desc: "Docker image name without the tag. Example: tongueroo/hi. Configures ufo/settings.yml"
     option :app, type: :string, required: true, desc: "App name. Preferably one word. Used in the generated ufo/task_definitions.rb."
-    long_desc Help.init
+    long_desc Help.text(:init)
     def init
       Init.new(options).setup
     end
@@ -40,7 +39,7 @@ module Ufo
     end
 
     desc "ship [SERVICE]", "builds and ships container image to the ECS service"
-    long_desc Help.ship
+    long_desc Help.text(:ship)
     ship_options.call
     def ship(service)
       builder = build_docker
@@ -55,7 +54,7 @@ module Ufo
     end
 
     desc "ships [LIST-OF-SERVICES]", "builds and ships same container image to multiple ECS services"
-    long_desc Help.ships
+    long_desc Help.text(:ships)
     ship_options.call
     def ships(*services)
       builder = build_docker
@@ -73,7 +72,7 @@ module Ufo
     end
 
     desc "task [TASK_DEFINITION]", "runs a one time task"
-    long_desc Help.task
+    long_desc Help.text(:task)
     option :docker, type: :boolean, desc: "Enable docker build and push", default: true
     option :command, type: :array, desc: "Override the command used for the container"
     def task(task_definition)
@@ -83,7 +82,7 @@ module Ufo
     end
 
     desc "destroy [SERVICE]", "destroys the ECS service"
-    long_desc Help.destroy
+    long_desc Help.text(:destroy)
     option :sure, type: :boolean, desc: "By pass are you sure prompt."
     def destroy(service)
       task_definition = options[:task] || service # convention
@@ -91,14 +90,14 @@ module Ufo
     end
 
     desc "scale [SERVICE] [COUNT]", "scale the ECS service"
-    long_desc Help.scale
+    long_desc Help.text(:scale)
     def scale(service, count)
       Scale.new(service, count, options).update
     end
 
     desc "version", "Prints version number of installed ufo"
     def version
-      puts Ufo::VERSION
+      puts VERSION
     end
 
     no_tasks do

data/lib/ufo/command.rb

@@ -1,3 +1,18 @@
+require "thor"
+
+# Override thor's long_desc identation behavior
+# https://github.com/erikhuda/thor/issues/398
+class Thor
+  module Shell
+    class Basic
+      def print_wrapped(message, options = {})
+        message = "\n#{message}" unless message[0] == "\n"
+        stdout.puts message
+      end
+    end
+  end
+end
+
 module Ufo
   class Command < Thor
     class << self
@@ -16,6 +31,14 @@ module Ufo
           args -= help_flags
           args.insert(-2, "help")
         end
+
+        #   ufo --version
+        #   ufo -v
+        version_flags = ["-v", "--version"]
+        if args.length == 1 && !(args & version_flags).empty?
+          args = ["version"]
+        end
+
         super
       end
     end