ufo 5.0.6 → 6.0.1

data/docs/_docs/quick-start-ec2.md

@@ -1,86 +0,0 @@
----
-title: 'Quick Start: EC2'
-nav_order: 2
----
-
-## What is ECS EC2?
-
-ECS EC2 is a way to run Docker containers on your own EC2 instances.  This difference between ECS EC2 and ECS Fargate is who manages the servers.  With ECS Fargate, AWS manages the EC2 instances for you and provides an interesting "serverless" option. With ECS EC2, you manage the EC2 instances and are responsible for maintenance.  The pro with ECS EC2 is more control and cost savings, since you're not paying for the overhead for AWS Fargate maintenance. Refer to [Heroku vs ECS Fargate vs EC2 On-Demand vs EC2 Spot Pricing Comparison](https://blog.boltops.com/2018/04/22/heroku-vs-ecs-fargate-vs-ec2-on-demand-vs-ec2-spot-pricing-comparison) for a pricing comparison.
-
-## Let's Go
-
-In a hurry? No sweat! Here's a quick start to using ufo that takes only a few minutes. For this example, we will use a Sinatra app from [tongueroo/demo-ufo](https://github.com/tongueroo/demo-ufo).  The `ufo init` command sets up the ufo directory structure in your project. The `ufo ship` command deploys your code to an AWS ECS service.  The `ufo ps` and `ufo scale` command shows you how to verify and scale additional containers.
-
-    gem install ufo
-    git clone https://github.com/tongueroo/demo-ufo.git demo
-    cd demo
-    aws ecr create-repository --repository-name demo/sinatra
-    ECR_REPO=$(aws ecr describe-repositories --repository-name demo/sinatra | jq -r '.repositories[].repositoryUri')
-    ufo init --image $ECR_REPO
-    ufo current --service demo-web
-    ufo ship
-    ufo ps
-    ufo scale 2
-
-This quickstart assumes:
-
-* You have push access to the repo. Refer to the Notes "Repo Push Access" section below for more info.
-* You are using ECS EC2 and have an ECS cluster with EC2 Container instances running. Refer to the Notes "ECS EC2 vs ECS Fargate" section below for more info.
-* The ECS Cluster is in the default VPC. If it is not you need to use the `--vpc-id`, `--ecs-subnets`, and `--elb-subnets` options in the [ufo init]({% link _reference/ufo-init.md %}) command.
-
-## What Happened
-
-The `ufo ship demo-web` command does the following:
-
-1. Builds the Docker image and pushes it to a registry
-2. Builds the ECS task definitions and registry them to ECS
-3. Updates the ECS Service
-4. Creates an ELB and connects it to the ECS Service
-
-You should see something similar to this:
-
-```
-$ ufo init --app=demo --image=tongueroo/demo-ufo
-Setting up ufo project...
-      create  .env
-      create  .ufo/settings.yml
-      create  .ufo/task_definitions.rb
-      create  .ufo/templates/main.json.erb
-      create  .ufo/variables/base.rb
-      create  .ufo/variables/development.rb
-      create  .ufo/variables/production.rb
-      create  Dockerfile
-      create  bin/deploy
-      append  .gitignore
-Starter ufo files created.
-$ ufo ship demo-web
-Building docker image with:
-  docker build -t 112233445566.dkr.ecr.us-west-2.amazonaws.com/demo/sinatra:ufo-2017-09-10T15-00-19-c781aaf -f Dockerfile .
-....
-Software shipped!
-$ ufo ps
-+----------+------+-------------+---------------+---------+-------+
-|    Id    | Name |   Release   |    Started    | Status  | Notes |
-+----------+------+-------------+---------------+---------+-------+
-| f590ee5e | web  | demo-web:85 | 1 minutes ago | RUNNING |       |
-+----------+------+-------------+---------------+---------+-------+
-$ ufo scale 2
-Scale demo-web service in development cluster to 2
-$
-```
-
-Congratulations! You have successfully deployed code to AWS ECS with ufo. It was really that simple 😁
-
-{% include repo_push_access.md %}
-
-## ECS EC2 vs ECS Fargate
-
-Ufo does not create the EC2 servers themselves to run the ECS tasks. If you use `ufo ship` to deploy an application to ECS EC2 and have not set up the EC2 servers, then the CloudFormation update will not be able to provision the ECS tasks and eventually roll back. Essentially it cannot create the ECS tasks because there are no EC2 servers to run them.
-
-Refer to the AWS [Creating a Cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html) docs to create an ECS cluster. Also refer to [ECS Terms Tutorial](https://blog.boltops.com/2017/09/08/aws-ecs-terms-tutorial) for an explanation of ECS terms.
-
-If you would like not to manage the EC2 server fleet, you are looking for ECS Fargate instead of ECS EC2.  ECS Fargate allows you to run ECS Tasks and AWS will manage the EC2 server fleet for you. Refer to the [Quick Start: Fargate]({% link quick-start.md %}) docs and use those quick start like commands instead.  The pricing for Fargate is more because AWS manages the server fleet for you. Refer to [Heroku vs ECS Fargate vs EC2 On-Demand vs EC2 Spot Pricing Comparison](https://blog.boltops.com/2018/04/22/heroku-vs-ecs-fargate-vs-ec2-on-demand-vs-ec2-spot-pricing-comparison) for a pricing comparison.
-
-Learn more in the next sections.
-
-{% include prev_next.md %}

data/docs/_docs/secrets.md

@@ -1,135 +0,0 @@
----
-title: Secrets
-nav_order: 20
----
-
-## What are Secrets?
-
-[ECS supports injecting secrets or sensitive data](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html) into the the environment as variables.  ECS decrypts the secrets straight from AWS to the ECS task environment. It never passes through the machine calling `ufo ship` IE: your laptop, a deploy server, or CodeBuild, etc.
-
-ECS supports 2 storage backends for secrets:
-
-1. [Secrets Manager](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-secrets.html#secrets-envvar)
-2. [Systems Manager Parameter Store](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-parameters.html#secrets-envvar-parameters)
-
-Here are both of the formats:
-
-Secrets manager format:
-
-```json
-{
-  "containerDefinitions": [{
-    "secrets": [{
-      "name": "environment_variable_name",
-      "valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name-AbCdEf"
-    }]
-  }]
-}
-```
-
-Parameter store format:
-
-```json
-{
-  "containerDefinitions": [{
-    "secrets": [{
-      "name": "environment_variable_name",
-      "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name"
-    }]
-  }]
-}
-```
-
-## UFO Support
-
-Ufo supports both forms of secrets. You create a `.secrets` file and can reference it in the `.ufo/templates/main.json.erb`
-
-```json
-{
-  "family": "<%= @family %>",
-  # ...
-  <% if @secrets %>
-  "secrets": <%= helper.secrets_file(".secrets") %>,
-  <% end %>
-}
-```
-
-The `.secrets` file is like an env file that will understand a secrets-smart format.  Example:
-
-    NAME1=SSM:my/parameter_name
-    NAME2=SECRETSMANAGER:/my/secret_name-AbCdEf
-
-The `SSM:` and `SECRETSMANAGER:` prefix will be expanded to the full ARN. You can also just specify the full ARN.
-
-    NAME1=arn:aws:ssm:region:aws_account_id:parameter/my/parameter_name
-    NAME2=arn:aws:secretsmanager:region:aws_account_id:secret:my/secret_name-AbCdEf
-
-In turn, this generates:
-
-```json
-{
-  "containerDefinitions": [{
-    "secrets": [
-      {
-        "name": "NAME1",
-        "valueFrom": "arn:aws:ssm:us-west-2:111111111111:parameter/demo/development/foo"
-      },
-      {
-        "name": "NAME2",
-        "valueFrom": "arn:aws:secretsmanager:us-west-2:111111111111:secret:/demo/development/my-secret-test-qRoJel"
-      }
-    ]
-  }]
-}
-```
-
-## SSM Parameter Names with Leading Slash
-
-If your SSM parameter has a leading slash then do **not** include when using it in the .secrets file. Example:
-
-    aws ssm get-parameter --name /demo/development/foo
-
-So use:
-
-    FOO=SSM:demo/development/foo
-
-The extra slash seems to confuse ECS. For secretsmanager names, you do include the leading slash.
-
-## Substitution
-
-Ufo also does a simple substition on the value. For example, the `:UFO_ENV` is replaced with the actual value of `UFO_ENV=development`. Example:
-
-    NAME1=SSM:demo/:UFO_ENV/parameter_name
-    NAME2=SECRETSMANAGER:demo/:UFO_ENV/secret_name-AbCdEf
-
-Expands to:
-
-    NAME1=arn:aws:ssm:region:aws_account_id:parameter/demo/development/parameter_name
-    NAME2=arn:aws:secretsmanager:region:aws_account_id:secret:/demo/development/secret_name-AbCdEf
-
-## IAM Permission
-
-If you're using secrets, you'll need to provide an IAM execution role so the EC2 instance has permission to read the secrets. Here's a starter example:
-
-.ufo/iam_roles/execution_role.rb
-
-```ruby
-managed_iam_policy("AmazonEC2ContainerRegistryReadOnly")
-managed_iam_policy("AmazonSSMReadOnlyAccess")
-managed_iam_policy("CloudWatchLogsFullAccess")
-managed_iam_policy("SecretsManagerReadWrite")
-```
-
-More info [ECS IAM Roles]({% link _docs/iam-roles.md %})
-
-## Debugging Tip
-
-Be sure that the secrets exist. If they do not you will see an error like this in the ecs-agent.log:
-
-/var/log/ecs/ecs-agent.log
-
-    level=info time=2020-06-26T00:59:46Z msg="Managed task [arn:aws:ecs:us-west-2:111111111111:task/development/91828be6a02b48f982cd9122db5e39b2]: error transitioning resource [ssmsecret] to [CREATED]: fetching secret data from SSM Parameter Store in us-west-2: invalid parameters: /my-parameter-name" module=task_manager.go
-
-Sometimes there is even no error message in the ecs-agent.log. As a debugging step, try removing all secrets and seeing if that the container will start up.
-
-{% include prev_next.md %}

data/docs/_docs/settings/aws_profile.md

@@ -1,36 +0,0 @@
----
-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

@@ -1,12 +0,0 @@
----
-title: Settings Cfn
-short_title: Cfn
-categories: settings
-nav_order: 14
----
-
-## Customizing Resources
-
-{% include cfn-customize.md %}
-
-{% include prev_next.md %}

data/docs/_docs/settings/cluster.md

@@ -1,66 +0,0 @@
----
-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:
-
-    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.
-
-    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/manage-security-groups.md

@@ -1,24 +0,0 @@
----
-title: Managed Security Groups
-short_title: Security Groups
-categories: settings
-nav_order: 16
----
-
-Ufo creates and manages two security groups. One for the ELB and one for the ECS tasks. Details here: [UFO Security Groups]({% link _docs/extras/security-groups.md %}).
-
-You can disable the creation of managed security groups with: `managed_security_groups: false`. Example:
-
-```yaml
-base:
-  image: tongueroo/demo-ufo
-  managed_security_groups: false
-```
-
-## Why?
-
-Security Groups managed by UFO are transient. If you delete the UFO app and recreate it entirely. Any manual changes to the security groups will be lost.
-
-You can precreate security groups and add them generated UFO CloudFormation template, see [Settings Network]({% link _docs/settings/network.md %}). So then you won't lose any manual changes. If you're taking this approach, it's nice to have UFO not create any managed security groups at all. This removes security group clutter.
-
-{% include prev_next.md %}

data/docs/_docs/settings/network.md

@@ -1,45 +0,0 @@
----
-title: Settings Network
-short_title: Network
-categories: settings
-nav_order: 17
----
-
-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.
-
-```
----
-vpc: vpc-11111111
-ecs_subnets: # at least 2 subnets required
-  - subnet-11111111
-  - subnet-22222222
-elb_subnets: # defaults to same subnets as ecs_subnets when not set
-  - subnet-33333333
-  - subnet-44444444
-
-# Optional existing security group ids to add in addition to the ones created by ufo.
-# elb_security_groups:
-#   - sg-aaa
-# ecs_security_groups:
-#   - sg-bbb
-
-# Also supports extra security groups specific to each ECS service.
-# So you can target security groups on a per-role basis.
-# ecs_security_groups:
-#   demo-web:
-#   - sg-bbb
-#   - sg-ccc
-#   demo-worker:
-#   - sg-bbb
-#   - sg-ccc
-```
-
-Option | Description
---- | ---
-vpc | Used to create ecs and elb security groups, target group in the CloudFormation template.
-ecs_subnets | Used to assign a subnet mapping to the ECS service created in CloudFormation when the network mode is awsvpc. Also used to in .ufo/params.yml as part of the run_task api call that is made by `ufo task`.
-elb_subnets | Used to create elb load balancer.  Defaults to same subnets as ecs_subnets when not set.
-ecs_security_groups | Additional security groups to associate with the ECS tasks.
-elb_security_groups | Additional security groups to associate with the ELB.
-
-{% include prev_next.md %}

data/docs/_docs/settings.md

@@ -1,55 +0,0 @@
----
-title: Settings
-nav_order: 12
----
-
-The behavior of ufo can be configured with a `settings.yml` file.  A starter project `.ufo/settings.yml` file is generated as part of the `ufo init` command. There are can be multiple settings files. The options from the files get merged and respected in 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 `settings.yml`:
-
-```yaml
-base:
-  image: tongueroo/demo-ufo
-  # clean_keep: 30 # cleans up docker images on your docker server.
-  # ecr_keep: 30 # cleans up images on ECR and keeps this remaining amount. Defaults to keep all.
-  # network_profile: default # .ufo/settings/network/default.yml file
-  # cfn_profile: default # .ufo/settings/cfn/default.yml file
-
-development:
-  # cluster: dev # uncomment if you want the cluster name be other than the default
-                 # the default is to match UFO_ENV.  So UFO_ENV=development means the ECS
-                 # cluster will be name development
-  # The aws_profile tightly binds UFO_ENV to AWS_PROFILE and vice-versa.
-  # aws_profile: dev_profile
-
-production:
-  # cluster: prod
-  # aws_profile: prod_profile
-```
-
-The table below covers each setting:
-
-Setting  | Description
-------------- | -------------
-aws_profile  | If you have the `AWS_PROFILE` environment variable set, this will ensure that you are deploying the right `UFO_ENV` to the right AWS environment. It is explained below.
-cfn_profile | The name of the cfn profile settings file to use. Maps to .ufo/settings/cfn/NAME.yml file. Will match an `UFO_ENV` file if it exists. IE: .ufo/settings/cfn/development.yml. Otherwise it defaults to .ufo/settings/cfn/default.yml.
-clean_keep  | Docker images generated from ufo are cleaned up automatically for you at the end of `ufo ship`. This controls how many docker images to keep around. The default is 3.
-cluster  | By convention, the ECS cluster that ufo deploys to matches the `UFO_ENV`. If `UFO=development`, then `ufo ship` deploys to the `development` ECS cluster. This is option overrides this convention.
-ecr_keep  | If you are using AWS ECR, then the ECR images can also be automatically cleaned up at the end of `ufo ship`. By default this is set to `nil` and all AWS ECR are kept.
-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/demo-ufo` is correct and `tongueroo/demo-ufo:my-tag` is incorrect.
-managed\_security\_groups | Create managed security groups for application ELBs. Defaults to true. If you disable it with false then no managed security groups will be created by UFO.
-network_profile | The name of the network profile settings file to use. Maps to .ufo/settings/network/NAME.yml file. Will match an `UFO_ENV` file if it exists. IE: .ufo/settings/network/development.yml. Otherwise it defaults to .ufo/settings/network/default.yml.
-
-## AWS_PROFILE support
-
-An interesting option is `aws_profile`.  This allows you to tightly connect an AWS_PROFILE to a UFO_ENV. The details are in the [Settings AWS_PROFILE docs]({% link _docs/settings/aws_profile.md %}).
-
-## ECS Cluster Convention
-
-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. This is detailed in the [Settings Cluster docs]({% link _docs/settings/cluster.md %}).
-
-{% include prev_next.md %}

data/docs/_docs/ssl_errors.md

@@ -1,40 +0,0 @@
----
-Title: SSL Errors
----
-
-UFO uses the AWS Ruby SDK and the underlying default SSL certificate chain configured in your active Ruby and
-OpenSSL to communicate to your AWS environment. This means that you _must correctly configure_ your Ruby and OpenSSL to have all the needed ROOT certificates for UFO to be able to communicate to AWS - _especially_ if you are behind a proxy or a corporate SSL-Proxy.
-
-If you are behind a corporate SSL proxy and you have not updated system, OpenSSL and Ruby certificate chains to include the needed corporate root certificates, you will see errors, such as:
-
-```
-Seahorse::Client::NetworkingError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate in certificate chain)
-  ~/.rbenv/versions/2.6.0/lib/ruby/2.6.0/net/protocol.rb:44:in `connect_nonblock'
-  ~/.rbenv/versions/2.6.0/lib/ruby/2.6.0/net/protocol.rb:44:in `ssl_socket_connect'
-  ~/.rbenv/versions/2.6.0/lib/ruby/2.6.0/net/http.rb:996:in `connect'
-  ~/.rbenv/versions/2.6.0/lib/ruby/2.6.0/net/http.rb:930:in `do_start'
-  ~/.rbenv/versions/2.6.0/lib/ruby/2.6.0/net/http.rb:925:in `start'
-```
-
-## Helper Scripts
-
-The `docs/utils` directory has a few scripts that should be able to help you resolve these issues and track down which certs are giving you problems.
-
-- `ssl-doctor.rb` is from the very useful examples at <https://github.com/mislav/ssl-tools>, and it can help you find the missing ROOT cert in your certificate chain and give suggestion on getting OpenSSL working correctly.
-- `update-cert-chains.sh` will help you update your Ruby and OpenSSL chains by adding in the missing ROOT cert and also pulling in the OSX System Root to your rbenv environment.
-- `test-aws-api-access.rb` should now return a list of the S3 buckets for the current AWS profile that is active.
-
-## Trouble-shooting
-
-### Update Brew and OpenSSL
-
-- `brew update`
-- `brew upgrade openssl`
-
-### Use the Helper Scripts to find the trouble spot
-
-Once you have updated OpenSSL and your `brew` packages, use the helper scripts above to see if you can track down the missing certificate in your certificate chain.
-
-The `update-cert-chain.sh` file was created using the suggestions from <https://gemfury.com/help/could-not-verify-ssl-certificate/>. Please review the information at <https://gemfury.com/help/could-not-verify-ssl-certificate/> if the `Helper Scripts` above do not fully resolve your issue.
-
-The `test-aws-api-access.rb` uses examples from the <https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/quick-start-guide.html> for using and configuring the Ruby AWS SDK on your system.

data/docs/_docs/structure.md

@@ -1,41 +0,0 @@
----
-title: Structure
-nav_order: 11
----
-
-Ufo creates a `.ufo` folder within your project which contains the required files used by ufo to build and deploy docker images to ECS.  The standard directory structure of the `.ufo` folder looks like this:
-
-```sh
-.ufo
-├── output
-├── params.yml
-├── settings.yml
-├── settings/cfn/default.yml
-├── settings/network/default.yml
-├── task_definitions.rb
-├── templates
-|   └── main.json.erb
-└── variables
-    ├── base.rb
-    ├── production.rb
-    └── development.rb
-```
-
-The table below covers the purpose of each folder and file.
-
-File / Directory  | Description
-------------- | -------------
-iam_roles/  | Where ufo managed iam roles associated with the task definition can be defined. For more details see: [IAM Roles]({% link _docs/iam-roles.md %}).
-output/  | 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 %}).
-params  | 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 %}).
-settings.yml  | Ufo's general settings file, where you adjust the default [settings]({% link _docs/settings.md %}).
-settings/cfn/default.yml  | Ufo's cfn settings. You can customize the CloudFormation resource properties here.
-settings/network/default.yml  | Ufo's network settings. You can customize the vpc and subnets to used here.
-task_definitions.rb  | This is where you define the task definitions and specify the variables to be used by the ERB templates.
-templates/  | The ERB templates with the task definition json code.  The templates are covered in more detail in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
-templates/main.json.erb  | This is the main and starter template task definition json file that ufo initially generates.
-variables  | 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’s use ufo!
-
-{% include prev_next.md %}

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

@@ -1,61 +0,0 @@
----
-title: Build Docker
-nav_order: 6
----
-
-## Build the Docker Image
-
-Let's use the `ufo docker build` command to build the docker image. The command uses the `Dockerfile` in the current project to build the docker image.  You use your own Dockerfile so you have fully control over how you would like the image to be built.  For this tutorial we will continue to use the [tongueroo/demo-ufo](https://github.com/tongueroo/demo-ufo) app and it's Dockerfile. Let's run the command:
-
-```sh
-ufo docker build
-```
-
-You should see similar output (some of the output has been truncated for conciseness):
-
-```sh
-$ ufo docker build
-Building docker image with:
-  docker build -t tongueroo/demo-ufo:ufo-2018-06-28T16-33-57-7e0af94 -f Dockerfile .
-Sending build context to Docker daemon    128kB
-Step 1/10 : FROM ruby:2.5.1
- ---> 857bc7ff918f
-Step 2/10 : WORKDIR /app
- ---> Using cache
- ---> 4e93fbb496c9
-...
-Step 10/10 : CMD bin/web
- ---> Running in cd63ebaec8aa
- ---> 14852737c639
-Removing intermediate container cd63ebaec8aa
-Successfully built 14852737c639
-Successfully tagged tongueroo/demo-ufo:ufo-2018-06-28T16-33-57-7e0af94
-Docker image tongueroo/demo-ufo:ufo-2018-06-28T16-33-57-7e0af94 built.
-Docker build took 2s.
-```
-
-As you can see `ufo docker build` shells out and calls `docker build -t tongueroo/demo-ufo:ufo-2017-06-11T22-18-03-a18aa30 -f Dockerfile .`.  The docker image tag that is generated contains a useful timestamp and the current HEAD git sha of the project that you are on.
-
-By default when you are running `ufo docker build` directly it does not push the docker image to the registry.  If you would like it to push the built image to a registry at the end of the build use the `--push` flag.
-
-```sh
-ufo docker build --push
-```
-
-You can also use the `ufo docker push` command which will push the last built image from `ufo docker build`.
-
-```
-ufo docker push
-```
-
-You should see the image being pushed with a message that looks something like this:
-
-```sh
-Pushed tongueroo/demo-ufo:ufo-2018-06-28T16-33-57-7e0af94 docker image.
-Docker push took 12s.
-```
-
-
-Note in order to push the image to a registry you will need to login into the registry.  If you are using DockerHub use the `docker login` command.  If you are using AWS ECR then ufo automatically calls the `aws ecr get-login` command and authenticates for you.
-
-{% include prev_next.md %}