ufo 4.4.3 → 4.5.0

data/docs/_docs/settings/aws_profile.md

@@ -0,0 +1,36 @@
+---
+title: Settings AWS_PROFILE
+short_title: AWS Profile
+categories: settings
+nav_order: 13
+---
+
+## AWS_PROFILE support
+
+An interesting option is `aws_profile`.  Here's an example:
+
+```yaml
+development:
+  aws_profile: dev_profile
+
+production:
+  aws_profile: prod_profile
+```
+
+This provides a way to tightly bind `UFO_ENV` to `AWS_PROFILE`.  This prevents you from forgetting to switch your `UFO_ENV` when switching your `AWS_PROFILE` thereby accidentally launching a stack in the wrong environment.
+
+
+AWS_PROFILE | UFO_ENV | Notes
+--- | --- | ---
+dev_profile | development
+prod_profile | production
+whatever | development | default since whatever is not found in settings.yml
+
+The binding is two-way. So:
+
+    UFO_ENV=production ufo ship # will deploy to the AWS_PROFILE=prod_profile
+    AWS_PROFILE=prod_profile ufo ship # will deploy to the UFO_ENV=production
+
+This behavior prevents you from switching `AWS_PROFILE`s, forgetting to switch `UFO_ENV` and then accidentally deploying a production based docker image to development and vice versa because you forgot to also switch `UFO_ENV` to its respective environment.
+
+{% include prev_next.md %}

data/docs/_docs/{settings-cfn.md → settings/cfn.md}

@@ -1,5 +1,7 @@
 ---
 title: Settings Cfn
+short_title: Cfn
+categories: settings
 nav_order: 14
 ---
 

data/docs/_docs/settings/cluster.md

@@ -0,0 +1,72 @@
+---
+title: Settings Cluster
+short_title: Cluster
+categories: settings
+nav_order: 15
+---
+
+Normally, the ECS cluster defaults to whatever UFO_ENV is set to by [convention]({% link _docs/conventions.md %}).  For example, when `UFO_ENV=production` the ECS Cluster is `production` and when `UFO_ENV=development` the ECS Cluster is `development`.  There are several ways to override this behavior. Let's go through some examples.
+
+## CLI Override
+
+By default, these are all the same:
+
+```sh
+ufo ship demo-web
+UFO_ENV=development ufo ship demo-web # same
+UFO_ENV=development ufo ship demo-web --cluster development # same
+```
+
+If you use a specific `UFO_ENV=production`, these are the same
+
+```
+UFO_ENV=production ufo ship demo-web
+UFO_ENV=production ufo ship demo-web --cluster production # same
+```
+
+Override the convention by explicitly specifying the `--cluster` option in the CLI.
+
+```sh
+ufo ship demo-web --cluster custom-cluster # override the cluster
+UFO_ENV=production ufo ship demo-web --cluster production-cluster # override the cluster
+```
+
+The cavaet is that you must remember to specify `--cluster`.  A wrapper `bin/deploy` script could be useful here.
+
+## Environment Cluster Setting
+
+If you don't want to specify the `--cluster` option in the command repeatedly, you can configure the cluster based on the the UFO_ENV.  Setting the `cluster` option in the `settings.yml` file:
+
+```yaml
+development:
+  cluster: dev
+
+production:
+  cluster: prod
+```
+
+## Service Cluster Setting
+
+Another interesting way of specifying the cluster to use is with the `service_cluster` option.  The `service_cluster` option takes a Hash value. Here's an example:
+
+```yaml
+base:
+  service_cluster:
+    demo-web: web-fleet
+    demo-worker: worker-fleet
+```
+
+In this example, ufo will deploy the demo-web service to the web-fleet ECS cluster and the demo-worker service to the worker-fleet ECS cluster.
+
+Also since the service_cluster is configured in the base section, it is used for all `UFO_ENV=development`, `UFO_ENV=production`, etc.
+
+## Precendence
+
+The precedence of the settings from highest to lowest is:
+
+* cli option
+* service_cluster service specific setting
+* cluster environment setting
+* UFO_ENV default convention
+
+{% include prev_next.md %}

data/docs/_docs/{settings-network.md → settings/network.md}

@@ -1,6 +1,8 @@
 ---
 title: Settings Network
-nav_order: 13
+short_title: Network
+categories: settings
+nav_order: 16
 ---
 
 The settings.yml file references a network settings file with the `network_profile` option. This file has configurations that are related to the network.  The source code for the starter template file is at [network/default.yml.tt](https://github.com/tongueroo/ufo/blob/master/lib/template/.ufo/settings/network/default.yml.tt)  Here's an example network settings file.

data/docs/_docs/structure.md

@@ -26,7 +26,7 @@ The table below covers the purpose of each folder and file.
 File / Directory  | Description
 ------------- | -------------
 <code>output/</code>  | The folder where the generated task definitions are written to.  The way the task definitions are generated is covered in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
-<code>params</code>  | This is where you can adjust the params that get send to the aws-sdk api calls. More info at [Params]({% link _docs/params.md %}).
+<code>params</code>  | This is where you can adjust the params that get send to the aws-sdk api calls for the [ufo task](https://ufoships.com/reference/ufo-task/) command. More info at [Params]({% link _docs/ufo-task-params.md %}).
 <code>settings.yml</code>  | Ufo's general settings file, where you adjust the default [settings]({% link _docs/settings.md %}).
 <code>settings/cfn/default.yml</code>  | Ufo's cfn settings. You can customize the CloudFormation resource properties here.
 <code>settings/network/default.yml</code>  | Ufo's network settings. You can customize the vpc and subnets to used here.

data/docs/_docs/ufo-current.md

@@ -1,6 +1,6 @@
 ---
 title: Ufo Current
-nav_order: 21
+nav_order: 22
 ---
 
 ## service

data/docs/_docs/ufo-env-extra.md

@@ -1,6 +1,6 @@
 ---
 title: UFO_ENV_EXTRA
-nav_order: 20
+nav_order: 21
 ---
 
 Ufo has an concept of extra environments. This is controlled by the `UFO_ENV_EXTRA` variable.  By setting `UFO_ENV_EXTRA` you can create additional identical ECS services or environments.

data/docs/_docs/ufo-env.md

@@ -1,6 +1,6 @@
 ---
 title: UFO_ENV
-nav_order: 19
+nav_order: 20
 ---
 
 Ufo's behavior is controlled by the `UFO_ENV` environment variable.  For example, the `UFO_ENV` variable is used to layer different ufo variable files together to make it easy to specify settings for different environments like production and development.  This is covered thoroughly in the [Variables]({% link _docs/variables.md %}) section.  `UFO_ENV` defaults to `development` when not set.

data/docs/_docs/{params.md → ufo-task-params.md}

@@ -1,9 +1,18 @@
 ---
-title: Params
-nav_order: 15
+title: Ufo Task Params
+nav_order: 23
 ---
 
-Additionally, the params that ufo sends to the [ruby aws-sdk](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/ECS/Client.html#run_task-instance_method) methods to create resources can be customized with a `params.yml` file.  This allows you to customize the tool using the full power of the aws-sdk.
+You can run one off task with the [ufo task](https://ufoships.com/reference/ufo-task/) command.
+
+The `ufo task` commands:
+
+1. Builds the docker image
+2. Registers the ECS task definition
+3. Runs the command
+
+
+The params that ufo sends to the [ruby aws-sdk](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/ECS/Client.html#run_task-instance_method) methods to for the one off task can be customized with a `params.yml` file.  This allows you use the full power of the aws-sdk.
 
 A starter project `.ufo/params.yml` file is generated as part of the `ufo init` command. Let's take a look at an example `params.yml`:
 
@@ -27,10 +36,8 @@ run_task:
 
 Ufo provides 1st class citizen access to adjust the params sent to the aws-sdk calls:
 
-The parameters from this `params.yml` file get merged with params ufo generates internally.  Here's an example of where the merging happens in the source code for the run task command [task.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/task.rb).  Also, here's the starter [params.yml source code](https://github.com/tongueroo/ufo/blob/master/lib/template/.ufo/params.yml.tt) for reference.
-
 ERB and [shared variables]({% link _docs/variables.md %}) are available in the params file.  You can also define the subnets in your config/variables and use them in them in the params.yml file.
 
-NOTE: The params.yml file does not have access to the `task_definition_name` helper method. That is only available in the `task_definitions.rb` template_definition code blocks.
+Note, the params.yml file does not have access to the `task_definition_name` helper method. That is only available in the `task_definitions.rb` template_definition code blocks.
 
 {% include prev_next.md %}

data/docs/_docs/upgrading.md

@@ -1,6 +1,6 @@
 ---
 title: Upgrading
-nav_order: 30
+nav_order: 33
 ---
 
 <ul>

data/docs/_docs/upgrading/upgrade4.5.md

@@ -0,0 +1,54 @@
+---
+title: Upgrading to Version 4.5
+short_title: Version 4.5
+order: 1
+categories: upgrading
+nav_order: 34
+---
+
+In ufo version 4.4 and 4.5, the default cloudformation stack names used by ufo were changed.
+
+* In versions 4.3 and below, the cluster name is prepended to the service name.
+* In version 4.4, the cluster name is appended to the service name.
+* In version 4.5, the Ufo.env name is appended to the service name.
+
+By convention, the cluster name defaults to UFO_ENV. So, by default there is not difference between cluster name and UFO_ENV.  However, if you were using the cluster option then there will be a difference.  Here's a table to help explain:
+
+Version | UFO_ENV | Cluster Name | Stack Name
+--- | --- | --- | ---
+4.3 and below | development | mycluster | mycluster-demo-web
+4.4 | development | mycluster | demo-web-mycluster
+4.5 | development | mycluster | demo-web-development
+
+You must upgrade to using the new stack and delete the old stack manually.  You can delete the old stack with the CloudFormation console by selecting the old stack, clicking Actions, and *Delete Stack*.
+
+## Upgrading Instructions
+
+To upgrade from version 4.3 to 4.5 you can run:
+
+    ufo upgrade v43to45
+
+This updates your `.ufo/settings.yml` file to include `stack_naming: append_ufo_env` which removes a warning message and 20 second delay when you deploy. Example:
+
+.ufo/settings.yml:
+
+```yaml
+base:
+  stack_naming: append_ufo_env
+```
+
+If you would still like to keep the old behavior, you can use:
+
+Version | Setting
+--- | ---
+4.3 and below | stack_naming: prepend_cluster
+4.4 | stack_naming: append_cluster
+4.5 | stack_naming: append_ufo_env
+
+Support for `prepend_cluster` may be **removed** in future versions.
+
+## Reasoning
+
+CloudFormation names the resources it creates with the beginning portion of the stack name. When the stack name prepends the environment then resources like ELBs a little bit harder to identify since they might be named something like this `product-Elb-K0LFFQ9LK50W`. It makes it harder to distinguish ELBs from different apps created by ufo.
+
+{% include prev_next.md %}

data/docs/_docs/upgrading/upgrade4.md

@@ -3,7 +3,7 @@ title: Upgrading to Version 4.0
 short_title: Version 4.0
 order: 2
 categories: upgrading
-nav_order: 32
+nav_order: 35
 ---
 
 A major change in ufo from version 3 to 4 is that the ECS service is now created by CloudFormation. If you have an existing ECS service deployed by ufo version 3, when you deploy your app again with ufo version 4, there will be a new additional ECS service created. Here is the recommended upgrade path.

data/docs/_docs/variables.md

@@ -1,6 +1,6 @@
 ---
 title: Shared Variables
-nav_order: 16
+nav_order: 17
 ---
 
 Often, you end up using the set of common variables across your task definitions for a project.  Ufo supports a shared variables concept to support this.  You specify variables files in the `.ufo/variables` folder and they are made available to your `.ufo/task_definitions.rb` as well as your `.ufo/templates` files.

data/docs/_includes/subnav.html

@@ -15,16 +15,23 @@
         <li><a href="{% link docs.md %}">Docs</a>
             <ul>
                 <li><a href="{% link _docs/structure.md %}">Structure</a></li>
-                <li><a href="{% link _docs/settings.md %}">Settings</a></li>
-                <li><a href="{% link _docs/settings-network.md %}">Settings Network</a></li>
-                <li><a href="{% link _docs/settings-cfn.md %}">Settings Cfn</a></li>
-                <li><a href="{% link _docs/params.md %}">Params</a></li>
+                <li><a href="{% link _docs/settings.md %}">Settings</a>
+                    <ul>
+                        {% assign docs = site.docs | where: "categories","settings" | sort: "order" %}
+                        {% for doc in docs -%}
+                          <li><a href='{{doc.url}}'>{{doc.short_title}}</a></li>
+                        {% endfor %}
+                    </ul>
+                </li>
                 <li><a href="{% link _docs/variables.md %}">Shared Variables</a></li>
                 <li><a href="{% link _docs/helpers.md %}">Helpers</a></li>
                 <li><a href="{% link _docs/conventions.md %}">Conventions</a></li>
                 <li><a href="{% link _docs/ufo-env.md %}">Ufo Env</a></li>
                 <li><a href="{% link _docs/ufo-env-extra.md %}">Ufo Env Extra</a></li>
                 <li><a href="{% link _docs/ufo-current.md %}">Ufo Current</a></li>
+                <li><a href="{% link _docs/ufo-task-params.md %}">Ufo Task Params</a></li>
+            </ul>
+        </li>
         <li>Extras
             <ul>
                 <li><a href="{% link _docs/extras/load-balancer.md %}">Load Balancer</a></li>
@@ -35,7 +42,9 @@
                 <li><a href="{% link _docs/extras/redirection-support.md %}">Redirection Support</a></li>
                 <li><a href="{% link _docs/extras/minimal-deploy-iam.md %}">Minimal Deploy IAM</a></li>
                 <li><a href="{% link _docs/extras/codebuild-iam-role.md %}">CodeBuild IAM Role</a></li>
+                <li><a href="{% link _docs/extras/dockerfile-erb.md %}">Dockerfile.erb</a></li>
             </ul>
+        </li>
         <li><a href="{% link _docs/upgrading.md %}">Upgrading</a>
             <ul>
                 {% assign docs = site.docs | where: "categories","upgrading" | sort: "order" %}

data/docs/_reference/ufo-apps.md

@@ -28,6 +28,7 @@ This command lists ECS services for an ECS cluster. It includes ECS services tha
 ## Options
 
 ```
+[--clusters=one two three]   # List of clusters
 [--verbose], [--no-verbose]  
 [--mute], [--no-mute]        
 [--noop], [--no-noop]        

data/docs/_reference/ufo-docker-base.md

@@ -49,8 +49,18 @@ Some of the output has been excluded so we can focus on the important parts to p
 
 It is using the docker `-f Dockerfile.base` option to build the base image.  It names the image with `tongueroo/demo-ufo:base-2017-06-12T14-36-44-2af505e`.  The image tag contains useful information: the timestamp when the image was built and the exact git sha of the code.  The image gets push to a registry immediately.
 
+## Dockerfile FROM updated
+
 Notice at the very end, the *current* `Dockerfile`'s FROM statement has been updated with the newly built base Docker image automatically.  This saves you from forgetting to copying and pasting it the `Dockerfile` yourself.
 
+If you're using a [Dockerfile.erb](https://ufoships.com/docs/extras/dockerfile-erb/), then ufo will update the `.ufo/settings/dockerfile_variables.yml` file instead.  It assumes you're using a Dockerfile.erb that looks something like this:
+
+```Dockerfile
+FROM <%= @base_image %>
+# ...
+CMD ["bin/web"]
+```
+
 
 ## Options
 

data/docs/_reference/ufo-network-init.md

@@ -29,10 +29,11 @@ The above command creates a `.ufo/settings/network/dev.yml` file.  You might wan
 ## Options
 
 ```
-[--force]                  # Bypass overwrite are you sure prompt for existing files.
-[--subnets=one two three]  # Subnets
-[--vpc-id=VPC_ID]          # Vpc id
-[--filename=FILENAME]      # Name of the settings file to create w/o extension.
-                           # Default: default
+[--force]                      # Bypass overwrite are you sure prompt for existing files.
+[--ecs-subnets=one two three]  # ECS Subnets
+[--elb-subnets=one two three]  # ELB Subnets
+[--vpc-id=VPC_ID]              # Vpc id
+[--filename=FILENAME]          # Name of the settings file to create w/o extension.
+                               # Default: default
 ```
 

data/docs/_reference/ufo-task.md

@@ -11,6 +11,12 @@ reference: true
 
 Run a one-time task.
 
+The `ufo task` commands:
+
+1. Builds the docker image
+2. Registers the ECS task definition
+3. Runs the command
+
 ## Examples
 
 You can use the `--command` or `-c` option to override the Docker container command.
@@ -29,6 +35,10 @@ The `--task-only` option is useful. By default, the `ufo task` command will buil
     ufo task demo-web --task-only -c ls # skip docker for speed
     ufo task demo-web --task-only -c pwd # skip docker for speed
 
+## Params
+
+You can control and customize the params that get sent to the ECS run_task call with a `config/params.yml` file. More info here: https://ufoships.com/docs/ufo-task-params/
+
 
 ## Options
 

data/docs/_reference/ufo-upgrade-v43to45.md

@@ -0,0 +1,15 @@
+---
+title: ufo upgrade v43to45
+reference: true
+---
+
+## Usage
+
+    ufo upgrade v43to45
+
+## Description
+
+Upgrade from version 4.3 and 4.4 to 4.5
+
+
+

data/docs/_reference/ufo-upgrade.md

@@ -16,7 +16,7 @@ upgrade subcommands
 * [ufo upgrade v2to3]({% link _reference/ufo-upgrade-v2to3.md %}) - Upgrade from version 2 to 3.
 * [ufo upgrade v33to34]({% link _reference/ufo-upgrade-v33to34.md %}) - Upgrade from version 3.3 to 3.4
 * [ufo upgrade v3to4]({% link _reference/ufo-upgrade-v3to4.md %}) - Upgrade from version 3 to 4.
-* [ufo upgrade v43to44]({% link _reference/ufo-upgrade-v43to44.md %}) - Upgrade from version 4.3 to 4.4
+* [ufo upgrade v43to45]({% link _reference/ufo-upgrade-v43to45.md %}) - Upgrade from version 4.3 and 4.4 to 4.5
 
 ## Options
 

data/docs/articles.md

@@ -1,6 +1,6 @@
 ---
 title: Articles
-nav_order: 42
+nav_order: 45
 ---
 
 * [How to Create Unlimited Extra Environments

data/lib/ufo.rb

@@ -8,44 +8,10 @@ require 'rainbow/ext/string'
 require 'render_me_pretty'
 require 'ufo/version'
 
-module Ufo
-  autoload :Apps, 'ufo/apps'
-  autoload :AwsService, 'ufo/aws_service'
-  autoload :Base, 'ufo/base'
-  autoload :Cancel, 'ufo/cancel'
-  autoload :CLI, 'ufo/cli'
-  autoload :Command, 'ufo/command'
-  autoload :Completer, "ufo/completer"
-  autoload :Completion, "ufo/completion"
-  autoload :Core, 'ufo/core'
-  autoload :Current, 'ufo/current'
-  autoload :Destroy, 'ufo/destroy'
-  autoload :Docker, 'ufo/docker'
-  autoload :DSL, 'ufo/dsl'
-  autoload :Ecr, 'ufo/ecr'
-  autoload :ECS, 'ufo/ecs'
-  autoload :Help, 'ufo/help'
-  autoload :Info, 'ufo/info'
-  autoload :Init, 'ufo/init'
-  autoload :LogGroup, 'ufo/log_group'
-  autoload :Network, 'ufo/network'
-  autoload :Param, 'ufo/param'
-  autoload :Ps, 'ufo/ps'
-  autoload :Releases, 'ufo/releases'
-  autoload :Rollback, 'ufo/rollback'
-  autoload :Scale, 'ufo/scale'
-  autoload :Sequence, 'ufo/sequence'
-  autoload :Setting, 'ufo/setting'
-  autoload :Ship, 'ufo/ship'
-  autoload :Stack, 'ufo/stack'
-  autoload :Status, 'ufo/status'
-  autoload :Stop, 'ufo/stop'
-  autoload :Task, 'ufo/task'
-  autoload :Tasks, 'ufo/tasks'
-  autoload :TemplateScope, 'ufo/template_scope'
-  autoload :Upgrade, "ufo/upgrade"
-  autoload :Util, 'ufo/util'
+require "ufo/autoloader"
+Ufo::Autoloader.setup
 
+module Ufo
   extend Core
 end