ufo 5.0.7 → 6.0.0

data/docs/_reference/ufo-releases.md

@@ -1,40 +0,0 @@
----
-title: ufo releases
-reference: true
----
-
-## Usage
-
-    ufo releases SERVICE
-
-## Description
-
-Show possible 'releases' or task definitions for the service.
-
-## 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
-    $
-
-
-## Options
-
-```
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-resources.md

@@ -1,44 +0,0 @@
----
-title: ufo resources
-reference: true
----
-
-## Usage
-
-    ufo resources SERVICE
-
-## Description
-
-The ECS service resources.
-
-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
-
-
-## Options
-
-```
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-rollback.md

@@ -1,61 +0,0 @@
----
-title: ufo rollback
-reference: true
----
-
-## Usage
-
-    ufo rollback SERVICE VERSION
-
-## Description
-
-Rolls back to older task definition.
-
-## 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
-
-
-## Options
-
-```
-[--wait], [--no-wait]        # Wait for deployment to complete
-                             # Default: true
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-scale.md

@@ -1,50 +0,0 @@
----
-title: ufo scale
-reference: true
----
-
-## Usage
-
-    ufo scale SERVICE COUNT
-
-## Description
-
-Scale the ECS service.
-
-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.
-
-
-## Options
-
-```
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-ship.md

@@ -1,129 +0,0 @@
----
-title: ufo ship
-reference: true
----
-
-## Usage
-
-    ufo ship SERVICE
-
-## Description
-
-Builds and ships container image to the ECS service.
-
-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.
-
-
-## Options
-
-```
-[--ecr-keep=N]                               # ECR specific cleanup of old images.  Specifies how many images to keep.  Only runs if the images are ECR images. Defaults keeps all images.
-[--elb=ELB]                                  # Decides to create elb, not create elb or use existing target group.
-[--elb-eip-ids=one two three]                # EIP Allocation ids to use for network load balancer.
-[--elb-type=ELB_TYPE]                        # ELB type: application or network. Keep current deployed elb type when not specified.
-[--scheduling-strategy=SCHEDULING_STRATEGY]  # Scheduling strategy to use for the service. IE: replica, daemon
-[--stop-old-tasks], [--no-stop-old-tasks]    # Stop old tasks as part of deployment to speed it up
-[--task=TASK]                                # ECS task name, to override the task name convention.
-[--wait], [--no-wait]                        # Wait for deployment to complete
-                                             # Default: true
-[--image-override=IMAGE_OVERRIDE]            # Override image in task definition for quick testing
-[--verbose], [--no-verbose]                  
-[--mute], [--no-mute]                        
-[--noop], [--no-noop]                        
-[--cluster=CLUSTER]                          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-ships.md

@@ -1,68 +0,0 @@
----
-title: ufo ships
-reference: true
----
-
-## Usage
-
-    ufo ships [LIST_OF_SERVICES]
-
-## Description
-
-Builds and ships same container image to multiple ECS services.
-
-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.
-
-
-## Options
-
-```
-[--ecr-keep=N]                               # ECR specific cleanup of old images.  Specifies how many images to keep.  Only runs if the images are ECR images. Defaults keeps all images.
-[--elb=ELB]                                  # Decides to create elb, not create elb or use existing target group.
-[--elb-eip-ids=one two three]                # EIP Allocation ids to use for network load balancer.
-[--elb-type=ELB_TYPE]                        # ELB type: application or network. Keep current deployed elb type when not specified.
-[--scheduling-strategy=SCHEDULING_STRATEGY]  # Scheduling strategy to use for the service. IE: replica, daemon
-[--stop-old-tasks], [--no-stop-old-tasks]    # Stop old tasks as part of deployment to speed it up
-[--task=TASK]                                # ECS task name, to override the task name convention.
-[--wait], [--no-wait]                        # Wait for deployment to complete
-[--image-override=IMAGE_OVERRIDE]            # Override image in task definition for quick testing
-[--verbose], [--no-verbose]                  
-[--mute], [--no-mute]                        
-[--noop], [--no-noop]                        
-[--cluster=CLUSTER]                          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-status.md

@@ -1,23 +0,0 @@
----
-title: ufo status
-reference: true
----
-
-## Usage
-
-    ufo status SERVICE
-
-## Description
-
-Status of ECS service.  Essentially, status of CloudFormation stack
-
-
-## Options
-
-```
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-stop.md

@@ -1,31 +0,0 @@
----
-title: ufo stop
-reference: true
----
-
-## Usage
-
-    ufo stop SERVICE
-
-## Description
-
-Stop tasks from old deployments.  Can speed up deployments with network load balancer.
-
-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
-
-
-## Options
-
-```
-[--verbose], [--no-verbose]  
-[--mute], [--no-mute]        
-[--noop], [--no-noop]        
-[--cluster=CLUSTER]          # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-task.md

@@ -1,56 +0,0 @@
----
-title: ufo task
-reference: true
----
-
-## Usage
-
-    ufo task TASK_DEFINITION
-
-## Description
-
-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.
-
-    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/
-
-
-## Options
-
-```
-    [--task-only], [--no-task-only]  # Skip docker and task register steps. Only run the task.
-w, [--wait], [--no-wait]             # Wait for task to finish.
-t, [--timeout=N]                     # How long to wait for task to finish.
-                                     # Default: 600
-c, [--command=one two three]         # Override the command used for the container
-    [--verbose], [--no-verbose]      
-    [--mute], [--no-mute]            
-    [--noop], [--no-noop]            
-    [--cluster=CLUSTER]              # Cluster.  Overrides .ufo/settings.yml.
-```
-

data/docs/_reference/ufo-tasks-build.md

@@ -1,178 +0,0 @@
----
-title: ufo tasks build
-reference: true
----
-
-## Usage
-
-    ufo tasks build
-
-## Description
-
-Build task definitions.
-
-## Summarized Example
-
-    ufo tasks build
-
-Builds all the task defintiions. Note all the existing ufo/output generated task defintions are wiped out.
-
-## Explanation
-
-The command `ufo tasks build` generates the task definitions locally and writes them to the `output/` folder.  There are 2 files that it uses in order to produce the raw AWS task definitions files.
-
-1. ufo/templates/main.json.erb
-2. ufo/task_definitions.rb
-
-Here's an example of each of them:
-
-**main.json.erb**:
-
-    {
-        "family": "<%= @family %>",
-        "containerDefinitions": [
-            {
-                "name": "<%= @name %>",
-                "image": "<%= @image %>",
-                "cpu": <%= @cpu %>,
-                <% if @memory %>
-                "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
-            }
-        ]
-    }
-
-**task_definitions.rb**:
-
-```ruby
-task_definition "demo-web" do
-    source "main" # will use ufo/templates/main.json.erb
-    variables(
-    family: task_definition_name,
-    name: "web",
-    container_port: helper.dockerfile_port,
-    command: ["bin/web"]
-  )
-end
-
-task_definition "demo-worker" do
-    source "main" # will use ufo/templates/main.json.erb
-    variables(
-    family: task_definition_name,
-    name: "worker",
-    command: ["bin/worker"]
-  )
-end
-
-task_definition "demo-clock" do
-    source "main" # will use ufo/templates/main.json.erb
-    variables(
-    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/demo-ufo:ufo-[sha].
-@cpu = 128
-@memory_reservation = 256
-@environment = helper.env_file(".env")
-```
-
-**ufo/variables/production.rb**:
-
-```ruby
-@environment = helper.env_vars(%Q{
-    RAILS_ENV=production
-    SECRET_KEY_BASE=secret
-})
-```
-
-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.
-
-To build the task definitions:
-
-    ufo tasks build
-
-You should see output similar to below:
-
-    $ ufo tasks build
-    Building Task Definitions...
-    Generating Task Definitions:
-      ufo/output/demo-web.json
-      ufo/output/demo-worker.json
-      ufo/output/demo-clock.json
-    Task Definitions built in ufo/output.
-    $
-
-Let's take a look at one of the generated files: `.ufo/output/demo-web.json`.
-
-    {
-      "family": "demo-web",
-      "containerDefinitions": [
-        {
-          "name": "web",
-          "image": "tongueroo/demo-ufo:ufo-2017-06-11T22-22-32-a18aa30",
-          "cpu": 128,
-          "memoryReservation": 256,
-          "portMappings": [
-            {
-              "containerPort": "3000",
-              "protocol": "tcp"
-            }
-          ],
-          "command": [
-            "bin/web"
-          ],
-          "environment": [
-            {
-              "name": "RAILS_ENV",
-              "value": "staging"
-            }
-          ],
-          "essential": true
-        }
-      ]
-    }
-
-If you need to modify the task definition template to suite your own needs it is super simple, just edit `main.json.erb`.  No need to dive deep into internal code that builds up the task definition with some internal structure.  It is all there for you to fully control.
-
-
-## Options
-
-```
-[--image-override=IMAGE_OVERRIDE]  # Override image in task definition for quick testing
-```
-