ufo 1.7.1 → 2.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: cc56aa67cb348333d5f4acb69d69aa4ff5111a9a
-  data.tar.gz: d94119d0b65d750dd50b22c23e36164c7a9ad58a
+  metadata.gz: 3a5d33336408ed8561e2ab17ffedba97b9e42010
+  data.tar.gz: 8698b1a455086430b60f59faeb222891432a8842
 SHA512:
-  metadata.gz: 66006a32629804ff02ea14d46396a795d228468a33e83372c75c1c8acf71a2b085b18a15de54bff7ebe9589ff7ff9b1018f84fb399d0556cb339fd4dea82fcd6
-  data.tar.gz: 54d374ee989fbfec7c54190c8c44911742396edb4a07aed1e34f7ea117c8f84e7bf7dd3efd2c5cc8d2ac254bfc92e842383c9a1208cf75949e6e034741238bfa
+  metadata.gz: c299d3bdc20d6eb2b4a7ea3a729061c001b260da2f2a4216cd7643efa82210d41821a67fd625a2cadbd8b1288122646c3499890b5765715927b73464a35fb946
+  data.tar.gz: 13359e5a3d4f33f4e6852951097f4c88974a23b3d3183d370487aac9a74d95eff503f91b0f3149aa5431d6e49183c59e3c9370803c14fa9e65cf7d408daf6991

data/CHANGELOG.md

@@ -3,6 +3,11 @@
 All notable changes to this project will be documented in this file.
 This project *tries* to adhere to [Semantic Versioning](http://semver.org/), even before v1.0.
 
+## [2.0.0]
+* shared variable support
+* UFO_ENV introduced
+* settings: AWS_PROFILE and UFO_ENV mapping to ecs cluster
+
 ## [1.7.1]
 * only create log group if it doesnt already exist
 

data/docs/_docs/conventions.md

@@ -4,6 +4,10 @@ title: Conventions
 
 Ufo uses a set of naming conventions.  This helps enforce some best practices and also allows the ufo commands to be concise.  Ufo allows you to easily override or bypass the conventions if you need it.
 
+### 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.
+
 ### Service and Task Names Convention
 
 Ufo assumes a convention that service\_name and the task\_name are the same. If you would like to override this convention then you can specify the task name.

data/docs/_docs/helpers.md

@@ -17,6 +17,6 @@ To call the helper in task_definitions.rb you must add `helper.` in front.  So f
 
 The 2 classes which provide these special helper methods are in [ufo/dsl.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl.rb) and [ufo/dsl/helper.rb](https://github.com/tongueroo/ufo/blob/master/lib/ufo/dsl/helper.rb). Refer to these classes for the full list of the special variables and methods.
 
-<a id="prev" class="btn btn-basic" href="{% link _docs/settings.md %}">Back</a>
+<a id="prev" class="btn btn-basic" href="{% link _docs/variables.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/conventions.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>

data/docs/_docs/install.md

@@ -2,19 +2,9 @@
 title: Installation
 ---
 
-### Install with Bolts Toolbelt
-
-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
-```
-
-For more information about the Bolts Toolbelt or to get an installer for another operating system visit: [https://boltops.com/toolbelt](https://boltops.com/toolbelt)
-
 ### Install with RubyGems
 
-If you prefer to install ufo via RubyGems follow the instructions:
+You can install ufo with RubyGems:
 
 ```sh
 gem install ufo
@@ -26,6 +16,16 @@ Or you can add ufo to your Gemfile in your project if you are working with a rub
 gem "ufo"
 {% endhighlight %}
 
+### Install with Bolts Toolbelt
+
+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
+```
+
+For more information about the Bolts Toolbelt or to get an installer for another operating system visit: [https://boltops.com/toolbelt](https://boltops.com/toolbelt)
+
 ### Dependencies
 
 * Docker: You will need a working version of [Docker](https://docs.docker.com/engine/installation/) installed as ufo shells out and calls the `docker` command.

data/docs/_docs/settings.md

@@ -2,56 +2,97 @@
 title: Settings
 ---
 
-The behavior of ufo can be configured via the `ufo/settings.yml` file.  A starter `settings.yml` file is generated as part of the `ufo init` command. A lot of these settings are default options so you do not have to type out these options repeatedly for some of the ufo commands. Let's cover the available settings in an example `settings.yml` that we've modified:
+The behavior of ufo can be configured via the `ufo/settings.yml` file.  A starter project `ufo/settings.yml` file is generated as part of the `ufo init` command. You can have multiple settings files. The options from the files get merged and respect the following precedence:
+
+1. current folder - The current folder's `ufo/settings.yml` values take the highest precedence.
+2. user - The user's `~/.ufo/settings.yml` values take the second highest precedence.
+3. default - The [default settings](https://github.com/tongueroo/ufo/blob/master/lib/ufo/default/settings.yml) bundled with the tool takes the lowest precedence.
+
+Let's take a look at an example `ufo/settings.yml`:
 
 ```yaml
 image: tongueroo/hi
 clean_keep: 30
 ecr_keep: 30
-service_cluster:
-  default: stag # default cluster
-  hi-web-stag: stag
-  hi-clock-stag: blue
-  hi-worker-stag: anothercluster
+aws_profile_ufo_env_map:
+  default: prod
+  # More examples:
+  # aws_profile1: prod
+  # aws_profile2: stag
+  # aws_profile3: dev
+ufo_env_cluster_map:
+  default: prod
+  # More examples:
+  # aws_profile1: prod
+  # aws_profile2: stag
+  # aws_profile3: dev
 ```
 
-### Docker image name
+The table below covers what each setting does:
+
+Setting  | Description
+------------- | -------------
+`image`  | The `image` value is the name that ufo will use for the Docker image name to be built.  Only provide the basename part of the image name without the tag because ufo automatically generates the tag for you. For example, `tongueroo/hi` is correct and `tongueroo/hi:my-tag` is incorrect.
+`aws_profile_ufo_env_map`  | Maps the `AWS_PROFILE` to the `UFO_ENV` value.
+`ufo_env_cluster_map`  | Maps the `UFO_ENV` to an ECS cluster value.  This allows you to override the convention where the default cluster equals to `UFO_ENV`. value.  This is covered in detailed at [Conventions]({% link _docs/conventions.md %}).
 
-The `image` value is the name that ufo will use for the Docker image name to be built.  Only provide the basename part of the image name without the tag. For example, `tongueroo/hi` is correct and `tongueroo/hi:my-tag` is incorrect.
 
-### ECS Cluster for Service
+### UFO_ENV to ECS Cluster Mapping
 
-The `service_cluster` mapping provides a way to set default "service-to-cluster" mappings so that you do not have to specify the `--cluster` repeatedly.  This is very helpful. For 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=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:
+
+By default:
 
 ```sh
-ufo ship hi-web-stag --cluster stag
-ufo ship hi-web-stag # same as above because it is configured in ufo/settings.yml
-ufo ship hi-web-stag --cluster special-cluster # overrides the default setting in `ufo/settings.yml`
+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
 ```
 
-Also, with this `settings.yml`:
+Override the convention and explicitly specify the `--cluster` option in the CLI.
 
 ```sh
-ufo ship hi-clock-stag # deploys to the ECS cluster named blue
+UFO_ENV=prod ufo ship hi-web --cluster custom-cluster # override the default UFO_ENV TO cluster mapping
 ```
 
-### ECR Cleanup
-
-Ufo can be configured to automatically clean old images from the ECR registry after the deploy completes.
+We can also override the convention with `settings.yml`:
 
 ```yaml
-ecr_keep: 30
+ufo_env_cluster_map:
+  prod: custom-cluster
 ```
 
-### Docker Cleanup
+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 can be configured to automatically clean old Docker images.
+### AWS_PROFILE TO UFO_ENV Mapping
+
+An interesting way to set `UFO_ENV` is with the `aws_profile_ufo_env_map` in `ufo/settings.yml`.  Given:
 
 ```yaml
-docker_keep: 30
+aws_profile_ufo_env_map:
+  default: dev
+  my-prod-profile: prod
+  my-stag-profile: stag
+```
+
+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
 ```
 
+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`.
+
+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.
+
+
 <a id="prev" class="btn btn-basic" href="{% link _docs/ufo-help.md %}">Back</a>
-<a id="next" class="btn btn-primary" href="{% link _docs/helpers.md %}">Next Step</a>
+<a id="next" class="btn btn-primary" href="{% link _docs/ufo-env.md %}">Next Step</a>
 <p class="keyboard-tip">Pro tip: Use the <- and -> arrow keys to move back and forward.</p>
 

data/docs/_docs/structure.md

@@ -9,8 +9,12 @@ ufo
 ├── output
 ├── settings.yml
 ├── task_definitions.rb
-└── templates
-    └── main.json.erb
+├── templates
+|   └── main.json.erb
+└── variables
+    ├── base.rb
+    ├── prod.rb
+    └── stag.rb
 ```
 
 The table below covers the purpose of each folder and file.
@@ -22,6 +26,7 @@ File / Directory  | Description
 <code>task_definitions.rb</code>  | This where you define the task definitions and specify the variables to be used by the ERB templates.
 <code>templates/</code>  | The ERB templates with the task definition json code.  The template are covered in more detail in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
 <code>templates/main.json.erb</code>  | This is the main and starter template task definition json file that ufo initially generates.
+<code>variables</code>  | This is where you can define shared variables that are made available to the template_definitions.rb and your templates. More info at [Variables]({% link _docs/variables.md %}).
 
 Now that you know where the ufo configurations are located and what they look like.  Let use ufo!
 

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

@@ -8,12 +8,31 @@ Let's run the command in our newly clone project.
 ```sh
 git clone https://github.com/tongueroo/hi.git
 cd hi
-ufo init --app=hi --env stag --cluster=stag --image=tongueroo/hi
+ufo init --app=hi --env prod --cluster=prod --image=tongueroo/hi
 ```
 
 You should see output similiar to this:
 
-<img src="/img/tutorials/ufo-init.png" class="doc-photo" />
+```
+$ ufo init --app=hi --env prod --cluster=prod --image=tongueroo/hi
+Setting up ufo project...
+created: ./bin/deploy
+created: ./Dockerfile
+created: ./ufo/settings.yml
+created: ./ufo/task_definitions.rb
+created: ./ufo/templates/main.json.erb
+created: ./ufo/variables/base.rb
+created: ./ufo/variables/prod.rb
+created: ./ufo/variables/stag.rb
+created: ./.env
+Starter ufo files created.
+$ ufo ship hi-web
+Building docker image with:
+  docker build -t tongueroo/hi:ufo-2017-09-10T15-00-19-c781aaf -f Dockerfile .
+....
+Software shipped!
+$
+```
 
 The `ufo init` command generated a few starter ufo files for you. The standard directory structure of the ufo folder looks like this:
 
@@ -34,24 +53,11 @@ Take a look at the `ufo/settings.yml` file and notice that it contains some defa
 
 ```yaml
 image: tongueroo/hi
-service_cluster:
-  default: stag # default cluster
-  # can override the default cluster for each service.  CLI overrides all of these settings.
-  hi-web-stag:
-  hi-clock-stag:
-  hi-worker-stag:
 ```
 
 The `image` value is the name that ufo will use as a base to generate a Docker image name.
 
-The `service_cluster` mapping provides a way to set default service-to-cluster mappings so that you do not have to specify the `--cluster` repeatedly.  This is very helpful. For example:
-
-```
-ufo ship hi-web-stag --cluster hi-cluster
-ufo ship hi-web-stag # same as above because it is configured in ufo/settings.yml
-ufo ship hi-web-stag --cluster special-cluster # overrides the default setting in `ufo/settings.yml`.
-```
-
+The other settings are optional.  You can learn more about them at [Settings]({% link _docs/settings.md %}).
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/tutorial.md %}">Back</a>
 <a id="next" class="btn btn-primary" href="{% link _docs/tutorial-ufo-docker-build.md %}">Next Step</a>

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

@@ -7,53 +7,54 @@ title: Deploy One App
 In this guide we have walked through what ufo does step by step.  First ufo builds the Docker image with `ufo docker build`.  Then it will build and register the ECS task definitions with the `ufo tasks` commands. Now we'll deploy the code to ECS.
 
 ```sh
-ufo ship hi-web-stag --cluster stag
+ufo ship hi-web
 ```
 
-Note, when we ran `ufo init` earlier, it configured `ufo/settings.yml` to map hi-web-stag to the `stag` cluster with the service_cluster option.  This nicely simplifies the command to
+By convention, ufo will ship the docker container to an ECS cluster with the same value as UFO_ENV, which defaults to prod.  So the command above is the same as:
 
-```bash
-ufo ship hi-web-stag
+```sh
+ufo ship hi-web --cluster prod
+UFO_ENV=prod ufo ship hi-web --cluster prod
 ```
 
-When you run `ufo ship hi-web-stag`:
+When you run `ufo ship hi-web`:
 
 1. It builds the docker image.
 2. Generates a task definition and registers it.
 3. Updates the ECS service to use it.
 
-If the ECS service hi-web-stag does not yet exist, ufo will create the service for you. Ufo will also automatically create the ECS cluster. If you are relying on this tool to create the cluster, you still need to associate ECS Container Instances to the cluster yourself.
+If the ECS service hi-web does not yet exist, ufo will create the service for you. Ufo will also automatically create the ECS cluster. If you are relying on this tool to create the cluster, you still need to associate ECS Container Instances to the cluster yourself.
 
 By convention, if the service has a container name web, you'll get prompted to create an ELB and specify a target group arn.  The ELB and target group must already exist. You can bypass the prompt and specify the target group ARN as part of the ship command or with the `--no-target-group-prompt` option.  The elb target group only gets associated with the ECS service if the service is being created for the first time.  If the service already exists then the `--target-group` parameter just gets ignored and the ECS task simply gets updated.  Example:
 
 
 ```bash
-ufo ship hi-web-stag --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web-stag/12345
+ufo ship hi-web --target-group=arn:aws:elasticloadbalancing:us-east-1:12345689:targetgroup/hi-web/12345
 ```
 
 Let's go back to the original command and take a look at the output:
 
 ```sh
-ufo ship hi-web-stag
+ufo ship hi-web
 ```
 
 The output should look something like this (some of the output has been removed for conciseness):
 
 ```sh
-$ ufo ship hi-web-stag
+$ ufo ship hi-web
 Building docker image with:
   docker build -t tongueroo/hi:ufo-2017-06-12T06-46-12-a18aa30 -f Dockerfile .
 ...
 Pushed tongueroo/hi:ufo-2017-06-12T06-46-12-a18aa30 docker image. Took 9s.
 Building Task Definitions...
 Generating Task Definitions:
-  ufo/output/hi-web-stag.json
-  ufo/output/hi-worker-stag.json
-  ufo/output/hi-clock-stag.json
+  ufo/output/hi-web.json
+  ufo/output/hi-worker.json
+  ufo/output/hi-clock.json
 Task Definitions built in ufo/output.
-hi-web-stag task definition registered.
-Shipping hi-web-stag...
-hi-web-stag service updated on stag cluster with task hi-web-stag
+hi-web task definition registered.
+Shipping hi-web...
+hi-web service updated on stag cluster with task hi-web
 Software shipped!
 Cleaning up docker images...
 Running: docker rmi tongueroo/hi:ufo-2017-06-11T20-32-16-a18aa30 tongueroo/hi:ufo-2017-06-11T20-27-44-bc80e84 tongueroo/hi:ufo-2017-06-11T20-02-18-bc80e84
@@ -72,14 +73,14 @@ The `ufo ship` command will automatically calls the steps we called manually in
 If you would like to skip the first 2 steps you can use the `--no-docker` and `--no-tasks` flags:
 
 ```sh
-ufo ship hi-web-stag --no-docker --no-tasks
+ufo ship hi-web --no-docker --no-tasks
 ```
 
 The output should look something like this:
 
 ```sh
-Shipping hi-web-stag...
-hi-web-stag service updated on stag cluster with task hi-web-stag
+Shipping hi-web...
+hi-web service updated on stag cluster with task hi-web
 Software shipped!
 ```
 

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

@@ -9,9 +9,9 @@ These processes use the same codebase and same docker image, but have slightly d
 While we can use the `ufo ship` command to deploy to all 3 service roles individually like so:
 
 ```sh
-ufo ship hi-web-stag
-ufo ship hi-worker-stag
-ufo ship hi-clock-stag
+ufo ship hi-web
+ufo ship hi-worker
+ufo ship hi-clock
 ```
 
 This would build a new Docker image for each process.  We actually want have the same docker image running on all of these roles.  In this case where we want to use the *same* Docker image for all 3 roles, ufo provides a `ufo ships` command.
@@ -19,7 +19,7 @@ This would build a new Docker image for each process.  We actually want have the
 ### ufo ships
 
 ```sh
-ufo ships hi-web-stag hi-worker-stag hi-clock-stag
+ufo ships hi-web hi-worker hi-clock
 ```
 
 You can check on the ECS console and should see something similar to this:
@@ -29,7 +29,7 @@ You can check on the ECS console and should see something similar to this:
 You can shorten the command by taking advantage of shell expansion:
 
 ```sh
-ufo ships hi-{web,worker,clock}-stag
+ufo ships hi-{web,worker,clock}
 ```
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/tutorial-ufo-ship.md %}">Back</a>

data/docs/_docs/tutorial-ufo-tasks-build.md

@@ -13,7 +13,7 @@ Let's take a look at the 2 files that are used by ufo to build the the ECS task
 
 Ufo task definitions are written as an ERB template that makes it every easily accessible and configurable to your requirements.  Here is is an example of an ERB template `ufo/templates/main.json.erb` that shows how easy it is to modfied the task definition you want to be uploaded by ufo:
 
-**main.json.erb**:
+**ufo/templates/main.json.erb**:
 
 ```json
 {
@@ -27,30 +27,7 @@ Ufo task definitions are written as an ERB template that makes it every easily a
             "memory": <%= @memory %>,
             <% end %>
             <% if @memory_reservation %>
-            "memoryReservation": <%= @memory_reservation %>,
-            <% end %>
-            <% if @container_port %>
-            "portMappings": [
-                {
-                    "containerPort": "<%= @container_port %>",
-                    "protocol": "tcp"
-                }
-            ],
-            <% end %>
-            "command": <%= @command.to_json %>,
-            <% if @environment %>
-            "environment": <%= @environment.to_json %>,
-            <% end %>
-            <% if @awslogs_group %>
-            "logConfiguration": {
-                "logDriver": "awslogs",
-                "options": {
-                    "awslogs-group": "<%= @awslogs_group %>",
-                    "awslogs-region": "<%= @awslogs_region || 'us-east-1' %>",
-                    "awslogs-stream-prefix": "<%= @awslogs_stream_prefix %>"
-                }
-            },
-            <% end %>
+...
             "essential": true
         }
     ]
@@ -59,52 +36,50 @@ Ufo task definitions are written as an ERB template that makes it every easily a
 
 The instance variable values are specified in `ufo/task_definitions.rb` via a DSL.  Here's the file:
 
-**task_definitions.rb**:
+**ufo/task_definitions.rb**:
 
 ```
-# common variables
-common = {
-  image: helper.full_image_name, # includes the git sha tongueroo/hi:ufo-[sha].
-  cpu: 128,
-  memory_reservation: 256,
-  environment: helper.env_file(".env")
-  # another example
-  # environment: helper.env_vars(%Q{
-  #   RAILS_ENV=production
-  #   SECRET_KEY_BASE=secret
-  # })
-}
-
-task_definition "hi-web-stag" do
+task_definition "hi-web" do
   source "main" # will use ufo/templates/main.json.erb
-  variables(common.dup.deep_merge(
+  variables(
     family: task_definition_name,
     name: "web",
     container_port: helper.dockerfile_port,
     command: ["bin/web"]
-  ))
+  )
 end
 
-task_definition "hi-worker-stag" do
+task_definition "hi-worker" do
   source "main" # will use ufo/templates/main.json.erb
-  variables(common.dup.deep_merge(
+  variables(
     family: task_definition_name,
     name: "worker",
     command: ["bin/worker"]
-  ))
+  )
 end
+```
 
-task_definition "hi-clock-stag" do
-  source "main" # will use ufo/templates/main.json.erb
-  variables(common.dup.deep_merge(
-    family: task_definition_name,
-    name: "clock",
-    command: ["bin/clock"]
-  ))
-end
+The shared variables are set in the variables folder:
+
+**ufo/variables/base.rb**:
+
+```ruby
+@image = helper.full_image_name # includes the git sha tongueroo/hi:ufo-[sha].
+@cpu = 128
+@memory_reservation = 256
+@environment = helper.env_file(".env")
+```
+
+**ufo/variables/prod.rb**:
+
+```ruby
+@environment = helper.env_vars(%Q{
+  RAILS_ENV=production
+  SECRET_KEY_BASE=secret
+})
 ```
 
-Ufo uses the ERB template in `main.json.erb` and combines it with the variables defined in the task definition declarations in `task_definitions.rb` and generates the raw AWS formatted task definition in the `output` folder.  In this case there are 3 task_definitions so there will be 3 generated output files.
+Ufo combines the `main.json.erb` template, `task_definitions.rb` definitions, and variables in the `ufo/variables` folder.  It then generates the raw AWS formatted task definition in the `output` folder.
 
 If you need to modify the task definition template to suite your own needs it is super simple, just edit `main.json.erb`.  You do not have to dive deep into internal code somewhere.  It is all there for you to fully control.
 
@@ -118,17 +93,26 @@ ufo tasks build
 
 You should see output similar to below:
 
-<img src="/img/tutorials/ufo-tasks-build.png" class="doc-photo" />
+```sh
+$ ufo tasks build
+Building Task Definitions...
+Generating Task Definitions:
+  ufo/output/hi-web.json
+  ufo/output/hi-worker.json
+  ufo/output/hi-clock.json
+Task Definitions built in ufo/output.
+$
+```
 
-Let's take a look at one of the generated files: `ufo/output/hi-web-stag.json`.
+Let's take a look at one of the generated files: `ufo/output/hi-web.json`.
 
 ```json
 {
-  "family": "hi-web-stag",
+  "family": "hi-web",
   "containerDefinitions": [
     {
       "name": "web",
-      "image": "tongueroo/hi:ufo-2017-06-11T22-22-32-a18aa30",
+      "image": "tongueroo/hi:ufo-2017-09-10T15-13-14-1105f71",
       "cpu": 128,
       "memoryReservation": 256,
       "portMappings": [
@@ -143,13 +127,16 @@ Let's take a look at one of the generated files: `ufo/output/hi-web-stag.json`.
       "environment": [
         {
           "name": "RAILS_ENV",
-          "value": "staging"
+          "value": "production"
+        },
+        {
+          "name": "SECRET_KEY_BASE",
+          "value": "secret"
         }
       ],
       "essential": true
     }
   ]
-}
 ```
 
 ### Register the ECS Task Definitions
@@ -163,9 +150,9 @@ ufo tasks register
 You should see something similiar to this:
 
 ```sh
-hi-clock-stag task definition registered.
-hi-web-stag task definition registered.
-hi-worker-stag task definition registered.
+hi-clock task definition registered.
+hi-web task definition registered.
+hi-worker task definition registered.
 ```
 
 <a id="prev" class="btn btn-basic" href="{% link _docs/tutorial-ufo-docker-build.md %}">Back</a>