ufo 5.0.7 → 6.0.0

data/lib/ufo/help/current.md

@@ -1,65 +0,0 @@
-Sets a current service to remember so you do not have to provide the service name all the time.  This shortens the commands
-
-    ufo ship demo-web # before
-    ufo current --service demo-web
-    ufo ship # after
-
-The state information is written to `.ufo/current`.
-
-## Examples
-
-### summary
-
-    ufo current --service demo-web --env-extra 1
-    ufo current --service demo-web --env-extra 1 --services demo-web demo-worker
-    ufo current --service demo-web --env-extra ''
-    ufo current --service demo-web
-    ufo current --env-extra '1'
-
-### service
-
-To set current service:
-
-    ufo current --service demo-web
-    ufo current --service demo-worker
-    ufo current --service demo-web
-
-To view current service, run `ufo current` without any arguments.
-
-    $ ufo current
-    Current service: demo-web
-
-To remove current service:
-
-    ufo current --service ''
-
-### env-extra
-
-To also set a current `UFO_ENV_EXTRA`.
-
-    ufo current --env-extra 1
-
-The extra env setting will be reflected:
-
-    $ ufo current
-    Current service: demo-web
-    Current env_extra: 1
-
-The `UFO_ENV_EXTRA` variable takes higher precedence than the current setting in the saved file.
-
-To unset:
-
-    ufo current --env-extra ''
-
-### services
-
-The ufo ships command builds one docker image and deploys it to multiple ECS services. You can also have ufo remember what services to use with the current command.
-
-    ufo current --services demo-web demo-worker
-    ufo ships # will depoy to both demo-web and demo-worker
-
-### rm all
-
-To remove all current settings use the `--rm` option.
-
-    ufo current --rm

data/lib/ufo/help/deploy.md

@@ -1,38 +0,0 @@
-It is useful to sometimes deploy only the task definition without re-building it.  Say for example, you are debugging the task definition and just want to directly edit the `.ufo/output/demo-web.json` definition. You can accomplish this with the `ufo deploy` command.  The `ufo deploy` command will deploy the task definition in `.ufo/output` unmodified.  Example:
-
-    ufo deploy demo-web
-
-The above command does the following:
-
-1. register the `.ufo/output/demo-web.json` task definition to ECS untouched.
-2. deploys it to ECS by updating the service
-
-## ufo tasks build
-
-To regenerate a `.ufo/output/demo-web.json` definition:
-
-    ufo tasks build
-
-## ufo ship
-
-The `ufo deploy` command does less than the `ufo ship` command.  Normally, it is recommended to use `ufo ship` over the `ufo deploy` command to do everything in one step:
-
-1. build the Docker image
-2. register the ECS task definition
-3. update the ECS service
-
-The `ufo ships`, `ufo ship`, `ufo deploy` command support the same options. The options are presented here again for convenience:
-
-{% include ufo-ship-options.md %}
-
-## Creating mutiple environments in parallel
-
-If you would like to create multiple enviroments quickly in parallel, the `--no-wait` and `--build` option can help speed up the process.  Example:
-
-    ufo ship # at least once
-    for i in {1..3}; do
-      UFO_ENV_EXTRA=$i ufo deploy --no-wait --build
-    done
-
-A more detailed post is available here: [How to Create Unlimited Extra Environments
-](https://blog.boltops.com/2018/07/12/ufo-how-to-create-unlimited-extra-environments).

data/lib/ufo/help/destroy.md

@@ -1,9 +0,0 @@
-## Examples
-
-Ufo provides a quick way to destroy an ECS service. This is effectively the same thing as deleting the CloudFormation stack.
-
-    ufo destroy demo-web
-
-If you would like to bypass the prompt, you can use the `--sure` option.
-
-    ufo destroy demo-web --sure

data/lib/ufo/help/docker/base.md

@@ -1,49 +0,0 @@
-The docker cache task builds a docker image using the `Dockerfile.base` file and
-updates the FROM `Dockerfile` image with the generated image from `Dockerfile.base`.
-
-## Summarized Example
-
-  ufo docker base
-  ufo docker base --no-push # do not push the image to the registry
-
-Docker image `tongueroo/demo-ufo:base-2016-10-21T15-50-57-88071f5` built.
-
-## Concept
-
-Docker is fantastic and has given developers more power and control over the OS their application runs on.  Sometimes building Docker images can be slow though.  Docker layer caching technology helps immensely to speed up the process as Docker will only rebuild layers that require rebuilding. But sometimes one little dependency changes it results in having to rebuild many layers.
-
-The `ufo docker base` commands allows you to build an Docker image from `Dockerfile.base` to be used as a cache and in the FROM instruction in the main `Dockerfile`.  This base Docker cache image technique speeds up development substantially if you have dependencies like gems in your project.  Let's say you have 20 gems in your project and are actively developing your project. You are experimenting with 3 different gems, adding and removing them while you are investigating the best gem to use.  Without the Docker image cache that already has all of your other gems installed each time you adjust `Gemfile` it would have to wait until all the gems from scratch again installed again.
-
-There are pros and cons of using this approach.  Remember there are 2 hard problems in computer science: 1. Naming and 2. Caching.  The main con about this approach is if you forget to update the base Docker image you will have cached artifacts that will not disappear unless you rebuild the base Docker image.  While some folks are completely against introducing this cache layer, some have found it being a huge win in speeding up their Docker development workflow.  If you are using this technique it is recommended that you set up some automation that rebuilds the base Docker image at least nightly.
-
-## Demo
-
-To demonstrate this command, there's a `docker-cache` branch in the [tongueroo/demo-ufo](https://github.com/tongueroo/demo-ufo/tree/docker-cache) repo.
-
- Let's see the command in action:
-
-    ufo docker base
-    Building docker image with:
-      docker build -t tongueroo/demo-ufo:base-2017-06-12T14-36-44-2af505e -f Dockerfile.base .
-      ...
-    Pushed tongueroo/demo-ufo:base-2017-06-12T14-36-44-2af505e docker image. Took 28s.
-    The Dockerfile FROM statement has been updated with the latest base image:
-      tongueroo/demo-ufo:base-2017-06-12T14-36-44-2af505e
-
-Some of the output has been excluded so we can focus on the important parts to point out. First notice that the commmand simply shells out to the docker command and calls:
-
-    docker build -t tongueroo/demo-ufo:base-2017-06-12T14-36-44-2af505e -f Dockerfile.base .
-
-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"]
-```

data/lib/ufo/help/docker/name.md

@@ -1,16 +0,0 @@
-It is sometimes handy to grab the name of the Docker image that was just generated.  Let's say ou needed the image name so you can feed it into another script that you have. The command `ufo docker name` returns the image of the most recently built Docker image.
-
-## Examples
-
-    ufo docker build # stores the docker image name in the .ufo/data folder
-    ufo docker name  # fetches image name from .ufo/data folder
-
-An example image name would look something like this: `tongueroo/demo-ufo:ufo-2018-02-15T19-29-06-88071f5`
-
-Note, the `.ufo/data` folder is an internal data folder and it's structure can change in future releases.
-
-If you want to generate a brand new name for whatever purpose, you can use the `--generate` flag.  The generate does not write to the `.ufo/data` folder.  It only generates a fresh name to stdout.  If you run it multiple times, it will generate new names.  You can notice this by seeing that the timestamp will always update:
-
-    ufo docker name --generate  # example: tongueroo/demo-ufo:ufo-2018-02-15T10-00-00-88071f5
-    ufo docker name --generate  # example: tongueroo/demo-ufo:ufo-2018-02-15T10-00-08-88071f5
-    ufo docker name --generate  # example: tongueroo/demo-ufo:ufo-2018-02-15T10-00-16-88071f5

data/lib/ufo/help/docker.md

@@ -1,6 +0,0 @@
-## Examples
-
-  ufo docker base
-  ufo docker build
-  ufo docker name
-  ufo docker push

data/lib/ufo/help/init.md

@@ -1,91 +0,0 @@
-The `ufo init` command provides a way to quickly setup a project to be ufo ready. It creates a ufo folder with all the starter supporting files in order to use ufo.  This page demonstrates how to use `ufo init`.  The command requires the `--image` option.  If the `--app` option is not provided, then it is inferred and set as the parent folder name. Example:
-
-    cd demo
-    ufo init --image tongueroo/demo-ufo # same as --app demo
-
-## Examples
-
-For this example we will use [tongueroo/demo-ufo](https://github.com/tongueroo/demo-ufo) which is a small test sinatra app.  Let's run the command in our newly clone project.
-
-    $ git clone https://github.com/tongueroo/demo-ufo.git demo
-    $ cd demo
-    $ ufo init --image=tongueroo/demo-ufo
-    Setting up ufo project...
-          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.
-
-## More Short Examples
-
-    ufo init --image httpd
-    ufo init --image 123456789012.dkr.ecr.us-west-2.amazonaws.com/myimage
-    ufo init --image tongueroo/demo-ufo --launch-type fargate --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole
-    ufo init --image httpd --vpc-id vpc-123
-
-## Important options
-
-The `app` is that application name that you want to show up on the ECS dashboard.  It is encouraged to have the app name be a single word.  If the option is not provided, the app name is inferred and is the parent folder name.
-
-The `image` is the base portion of image name that will be pushed to the docker registry, ie: DockerHub or AWS ECR.  The image should **not** include the tag since the tag is generated upon a `ufo ship`.  For example:
-
-    tongueroo/demo-ufo => tongueroo/demo-ufo:ufo-2018-02-08T21-04-02-3c86158
-
-The generated `tongueroo/demo-ufo:ufo-2018-02-08T21-04-02-3c86158` image name gets pushed to the docker registry.
-
-The `--vpc-id`, `--ecs-subnets`, and `--elb-subnets` options are optional but very useful. If not specified then ufo will use the default vpc for the network settings like subnets and security groups, which might not be what you want.
-
-## Directory Structure
-
-The standard directory structure of the `.ufo` folder that was created looks like this:
-
-    ufo
-    ├── output
-    ├── settings.yml
-    ├── task_definitions.rb
-    ├── templates
-    │   └── main.json.erb
-    └── variables
-        ├── base.rb
-        ├── production.rb
-        └── development.rb
-
-For a explanation of the folders and files refer to [Structure]({% link _docs/structure.md %}).
-
-## Fargate Support
-
-For ECS Fargate, the ECS task definition structure is a bit different.  To initialize a project to support Fargate use the `--launch-type fargate` option.  You'll be prompted for a execution role arn.  This value gets added to the generated `.ufo/variables/base.rb` and used in the `.ufo/templates/main.json.erb`.
-
-    ufo init --image tongueroo/demo-ufo --app demo --launch-type fargate
-
-You can also generate the init ufo files and bypass the prompt by providing the `--execution-role-arn` option upfront.
-
-    ufo init --image tongueroo/demo-ufo --app demo --launch-type fargate --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole
-
-For more information and a demo of Fargate support, check out the [Quick Start: Fargate Docs]({% link quick-start.md %}).
-
-## Custom Templates
-
-If you would like the `ufo init` command to use your own custom templates, you can achieve this with the `--template` and `--template-mode` options.  Example:
-
-    ufo init --image=tongueroo/demo-ufo --template=tongueroo/ufo-custom-template
-
-This will clone the repo on GitHub into the `~/.ufo/templates/tongueroo/ufo-custom-template` and use that as an additional template source.  The default `--template-mode=additive` mode means that if there's a file in `tongueroo/ufo-custom-template` that exists it will use that in place of the default template files.
-
-If you do not want to use any of the original default template files within the ufo gem at all, you can use the `--template-mode=replace` mode. Replace mode will only use templates from the provided `--template` option.  Example:
-
-    ufo init --image=tongueroo/demo-ufo --template=tongueroo/ufo-custom-template --template-mode=replace
-
-You can also specific the full GitHub url. Example:
-
-    ufo init --image=tongueroo/demo-ufo --template=https://github.com/tongueroo/ufo-custom-template
-
-If you would like to use a local template that is not on GitHub, then created a top-level folder in `~/.ufo/templates` without a subfolder. Example:
-
-    ufo init --image=tongueroo/demo-ufo --template=my-custom # uses ~/.ufo/templates/my-custom

data/lib/ufo/help/network/init.md

@@ -1,13 +0,0 @@
-## Examples
-
-    ufo network init # will use default vpc and subnets
-    ufo network init --vpc-id vpc-123
-    ufo network init --vpc-id vpc-123 --subnets subnet-aaa subnet-bbb
-
-If the `--vpc-id` option is set and the `--subnets` is not, then ufo generates files with all the associated subnets from the specified vpc id.
-
-You can also specify name of the settings file to create with the `--filename` option.  Example.
-
-    ufo network init --vpc-id vpc-123 --filename dev
-
-The above command creates a `.ufo/settings/network/dev.yml` file.  You might want to then update your `.ufo/settings.yml` file and update the `network_profile` config to reference it.

data/lib/ufo/help/ps.md

@@ -1,27 +0,0 @@
-## Examples
-
-    $ ufo ps
-    => Service: demo-web
-       Service name: development-demo-web-Ecs-7GAUAXH5F56M
-       Status: ACTIVE
-       Running count: 2
-       Desired count: 2
-       Launch type: FARGATE
-       Task definition: demo-web:85
-       Elb: develop-Elb-1M74CLRS2G0Z4-686742146.us-east-1.elb.amazonaws.com
-    +----------+------+-------------+----------------+---------+-------+
-    |    Id    | Name |   Release   |    Started     | Status  | Notes |
-    +----------+------+-------------+----------------+---------+-------+
-    | f590ee5e | web  | demo-web:85 | 47 minutes ago | RUNNING |       |
-    | fb60ba9f | web  | demo-web:85 | 45 minutes ago | RUNNING |       |
-    +----------+------+-------------+----------------+---------+-------+
-
-Skip the summary info:
-
-    $ ufo ps --no-summary
-    +----------+------+-------------+----------------+---------+-------+
-    |    Id    | Name |   Release   |    Started     | Status  | Notes |
-    +----------+------+-------------+----------------+---------+-------+
-    | f590ee5e | web  | demo-web:85 | 48 minutes ago | RUNNING |       |
-    | fb60ba9f | web  | demo-web:85 | 45 minutes ago | RUNNING |       |
-    +----------+------+-------------+----------------+---------+-------+

data/lib/ufo/help/releases.md

@@ -1,16 +0,0 @@
-## Example
-
-    $ ufo releases
-    Recent task definitions for this service:
-      demo-web:86
-      demo-web:85
-      demo-web:84
-      demo-web:83
-      demo-web:82
-      demo-web:81
-      demo-web:80
-      demo-web:79
-      demo-web:78
-      demo-web:77
-      demo-web:76
-    $

data/lib/ufo/help/resources.md

@@ -1,20 +0,0 @@
-Displays information about the service.
-
-## Examples
-
-    $ ufo resources demo-web
-    Resources:
-    Ecs - AWS::ECS::Service:
-      arn:aws:ecs:us-east-1:111111111111:service/dev-demo-web-Ecs-KN8OVQ7L2N40
-    EcsSecurityGroupRule - AWS::EC2::SecurityGroupIngress:
-      EcsSecurityGroupRule
-    EcsSecurityGroup - AWS::EC2::SecurityGroup:
-      sg-63c17228
-    Elb - AWS::ElasticLoadBalancingV2::LoadBalancer:
-      arn:aws:elasticloadbalancing:us-east-1:111111111111:loadbalancer/app/dev-hi-Elb-1KEVRDILLSUC9/0b9434b7a9a66fb7
-    ElbSecurityGroup - AWS::EC2::SecurityGroup:
-      sg-11b1025a
-    Listener - AWS::ElasticLoadBalancingV2::Listener:
-      arn:aws:elasticloadbalancing:us-east-1:111111111111:listener/app/dev-hi-Elb-1KEVRDILLSUC9/0b9434b7a9a66fb7/1996f1f252d7ba2e
-    TargetGroup - AWS::ElasticLoadBalancingV2::TargetGroup:
-      arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/dev-h-Targe-1VUFA8577XWT7/7e67276c182fdc87

data/lib/ufo/help/rollback.md

@@ -1,35 +0,0 @@
-## Examples
-
-You only need to specific the task definition version number, though you can specify the name also
-
-    ufo rollback demo-web 1
-    ufo rollback demo-web demo-web:1
-
-To see recent task definitions:
-
-    ufo releases
-
-If you set a current service with `ufo current`, then the commands get shorten:
-
-    ufo rollback demo-web:1
-    ufo rollback 1
-
-Note, task definitions get created by many ways with more than just `ufo ship`. So it the previous version might not be the latest version number minus one.
-
-## Using image name
-
-Another way to specify the version for rollback is with the container definition's image value.  Here's the portion of the ecs task definition that you would look for:
-
-    ...
-    "container_definitions": [
-      {
-        "name": "web",
-        "image": "tongueroo/demo-ufo:ufo-2018-06-21T15-03-52-ac60240",
-        "cpu": 256,
-    ...
-
-You only need to specify enough for a match to be found.  Ufo searches the 30 most recent task definitions. So all of these would work:
-
-    ufo rollback tongueroo/demo-ufo:ufo-2018-06-21T15-03-52-ac60240
-    ufo rollback 2018-06-21T15-03-52
-    ufo rollback ac60240

data/lib/ufo/help/scale.md

@@ -1,26 +0,0 @@
-Ufo provides a command to scale up and down an ECS service quickly. It is a simple wrapper for `aws ecs update-service --service xxx ----desired-count xxx`.  Here's an example of how you use it:
-
-    $ ufo scale 3
-    Scale demo-web service in development cluster to 3
-
-It is useful to use `ufo ps` to check the status.
-
-    $ ufo ps
-    => Service: demo-web
-       Service name: development-demo-web-Ecs-7GAUAXH5F56M
-       Status: ACTIVE
-       Running count: 2
-       Desired count: 3
-       Launch type: FARGATE
-       Task definition: demo-web:85
-       Elb: develop-Elb-1M74CLRS2G0Z4-686742146.us-east-1.elb.amazonaws.com
-    +----------+------+-------------+----------------+--------------+-------+
-    |    Id    | Name |   Release   |    Started     |    Status    | Notes |
-    +----------+------+-------------+----------------+--------------+-------+
-    | 8f95ef9d | web  | demo-web:85 | PENDING        | PROVISIONING |       |
-    | f590ee5e | web  | demo-web:85 | 50 minutes ago | RUNNING      |       |
-    | fb60ba9f | web  | demo-web:85 | 48 minutes ago | RUNNING      |       |
-    +----------+------+-------------+----------------+--------------+-------+
-    $
-
-While scaling via this method is quick and convenient the [ECS Service AutoScaling](http://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) that is built into ECS is a much more powerful way to manage scaling your ECS service.

data/lib/ufo/help/ship.md

@@ -1,95 +0,0 @@
-The main command you use when using ufo is: `ufo ship`.  This command:
-
-1. builds the docker image
-2. registers the generated ECS task definition
-3. deploys the definition to AWS ECS
-
-Basic usage is:
-
-    ufo ship demo-web
-
-The ECS service gets created if the service does not yet exist on the cluster.
-
-### Conventions
-
-By convention, the task and service names match. If you need to override this convention, then you can use the task option.  For example, if you want to ship to the `demo-web-1` service and use the `demo-web` task, run:
-
-    ufo ship demo-web-1 --task demo-web
-
-## Options in Detail
-
-The command has a decent amount of options, you can see the options available with `ufo ship -h`.  The table below covers some of the options in detail:
-
-{% include ufo-ship-options.md %}
-
-As you can see there are plenty of options for `ufo ship`.  Let's demonstrate usage of them in a few examples.
-
-### Load Balancer
-
-ECS services can be associated with a Load Balancer upon creation. Ufo can automatically create a load balancer.  The options:
-
-1. Automatically create the ELB.
-2. Provide a target group from an existing ELB.
-3. No ELB is created.
-
-Here are examples for each of them:
-
-    ufo ship demo-web --elb=true
-
-    # Use existing target group from pre-created ELB:
-    ufo ship demo-web --elb=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/target-name/2378947392743
-
-    # Disable creating elb and prompt:
-    ufo ship demo-web --elb=false
-
-Note, if the docker container's name is web then the `--elb` flag defaults to true automatically.
-
-If you need to create a network load balancer with pre-allocated EIPs, you can use `--elb-eip-ids`, example:
-
-    ufo deploy demo-web --elb-eip-ids eipalloc-a8de9ca1 eipalloc-a8de9ca2
-
-More info available at the [load balancer docs](http://ufoships.com/docs/load-balancer/).
-
-### Deploying Task Definition without Docker Build
-
-Let's you want skip the docker build phase and only want use ufo to deploy a task definition. You can do this with the `ufo deploy` command.  Refer to [ufo deploy](http://ufoships.com/reference/ufo-deploy/) for more info.
-
-### Not Waiting for Deployments to Complete
-
-By default when ufo updates the ECS service with the new task definition, it does so synchronuously. It'll wait until the CloudFormation stack finishes.  You can make it asynchronuously with the `--no-wait` option:
-
-    ufo ship demo-web --no-wait
-
-The `--no-wait` option is useful for creating multiple environments:: [How to Create Unlimited Extra Environments
-](https://blog.boltops.com/2018/07/12/ufo-how-to-create-unlimited-extra-environments).
-
-### Route 53 DNS Support
-
-Ufo can automatically create a "pretty" route53 record an set it to the created ELB dns name. This is done in by configuring the `.ufo/settings/network/[profile].yml` file. Example:
-
-    dns:
-      name: "{stack_name}.mydomain.com."
-      hosted_zone_name: mydomain.com. # dont forget the trailing period
-
-Refer to [Route53 Support](http://ufoships.com/docs/route53-support/) for more info.
-
-### Cleaning up Docker Images Automatically
-
-Since ufo builds the Docker image every time there's a deployment, you eventually will end up with a long list of Docker images.  Ufo automatically cleans up older docker images at the end of the deploy process if you are using AWS ECR.  By default ufo keeps the most recent 30 Docker images. This can be adjusted with the `--ecr-keep` option.
-
-    docker ship demo-web --ecr-keep 2
-
-You should see something like this:
-
-    Cleaning up docker images...
-    Running: docker rmi tongueroo/demo-ufo:ufo-2017-06-12T06-46-12-a18aa30
-
-If you are using DockerHub or another registry, ufo does not automatically clean up images.
-
-### Scheduling Strategy
-
-You can set the ECS scheduling strategy dynamically.  Here's an example:
-
-    ufo ship --scheduling-strategy daemon
-
-You can change the scheduling strategy by explicitly specifying it.  Otherwise, the scheduling strategy state is maintained for future deployments, so you do not have to specify it repeatedly. The default scheduling strategy is replica.

data/lib/ufo/help/ships.md

@@ -1,35 +0,0 @@
-The `ufo ships` command allows you to deploy the *same* Docker image and task definition to multiple ECS services.  It is a common pattern to have the same code base running on different roles.  For example, say you have an application with 3 roles:
-
-1. web - serves web requests.
-2. worker - processes background jobs.
-3. clock - schedules background jobs.
-
-Instead of using the [ufo ship]({% link _reference/ufo-ship.md %}) and build and deploying the code 3 times you can instead use `ufo ships`.  This will result in the *same* Docker image and *same* task definition being deployed to all 3 services.  Example usage:
-
-    ufo ships demo-web demo-worker demo-clock
-
-## Shell expansion
-
-Since the ECS service names are provided as a list you can shorten the command by using bash shell expansion 😁
-
-    ufo ships hi-{web,worker,clock}
-
-If you're new to shell expansion, run this to understand why above works just as well:
-
-    $ echo hi-{web,worker,clock}
-    demo-web demo-worker demo-clock
-
-## Overriding convention
-
-As explained in detail in [Conventions]({% link _docs/conventions.md %}) the task definition and service name are the same by convention.  This convention also applies for each of the services being shipped in the list. The task definition and service names match for each of the services in the list.  If you would like to override the convention as part of the ships command then you use a special syntax. In the special syntax the service and task definition is separated by a colon.  Examples:
-
-    ufo ships demo-web-1:demo-web demo-clock-1 demo-worker-1
-    ufo ships demo-web-1:my-task demo-clock-1:another-task demo-worker-1:third-task
-
-## ufo ships Options
-
-The `ufo ships`, `ufo ship`, `ufo deploy` command support the same options. The options are presented here again for convenience:
-
-{% include ufo-ship-options.md %}
-
-Note: The `--task` option is not used with the `ufo ships` command.

data/lib/ufo/help/stop.md

@@ -1,7 +0,0 @@
-ECS deployments can sometimes take a while. One reason could be because the old ECS tasks can take some time to drain and removed. The recommended way to speed this draining process up is configuring the `deregistration_delay.timeout_seconds` to a low value.  You can configured this in `.ufo/settings/cfn/default.yml`. For more info refer to http://ufoships.com/docs/settings-cfn/  This setting works well for Application Load Balancers.
-
-However, for Network Load Balancers, it seems like the deregistration_delay is not currently being respected. In this case, it take an annoying load time and this command can help speed up the process.
-
-The command looks for any extra old ongoing deployments and stops the tasks associated with them.  This can cause errors for any inflight requests.
-
-    ufo stop demo-web

data/lib/ufo/help/task.md

@@ -1,27 +0,0 @@
-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.
-
-    ufo task hi-migrate # default command
-    ufo task demo-web --command bin/migrate
-    ufo task demo-web --command bin/with_env bundle exec rake db:migrate:redo VERSION=xxx
-    ufo task demo-web -c uptime
-    ufo task demo-web -c pwd
-
-## Skipping Docker and Task Registration
-
-The `--task-only` option is useful. By default, the `ufo task` command will build the docker image and then register a new task definition.  The docker build process usually is the part that takes the most time. You can skip the docker build process after building it at least once.  This is a faster way to run a bunch of commands with the same Docker image. Example:
-
-  ufo task demo-web -c uptime # build at least once
-  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/