ufo 5.0.7 → 6.0.0

data/docs/_docs/extras/redirection-support.md

@@ -1,27 +0,0 @@
----
-title: Redirection Support
-nav_order: 33
----
-
-## Application Load Balancers
-
-If you are using an Application Load Balancer you can configure redirection by editing the default actions of the regular listener that is set up by ufo. This assumes you have set up [SSL Support]({% link _docs/extras/ssl-support.md %}).  Here's an example that redirects http to https with a 302 http status code:
-
-```
-Listener:
-  Port: 80
-  # ...
-  DefaultActions:
-   - Type: redirect
-     RedirectConfig:
-       Protocol: HTTPS
-       StatusCode: HTTP_302 # HTTP_301 and HTTP_302 are valid
-       Port: 443
-```
-
-
-## Network Load Balancers
-
-Network Load Balancers work at layer 4, so they do not support redirection.  Instead you need to handle redirection within your app.
-
-{% include prev_next.md %}

data/docs/_docs/extras/route53-support.md

@@ -1,27 +0,0 @@
----
-title: Route53 Support
-nav_order: 32
----
-
-Ufo can create a "pretty" route53 record and set it's value to the created ELB DNS name. This is done by configuring the `.ufo/settings/cfn/default.yml` file. Example:
-
-```yaml
-Dns:
-  Name: "{stack_name}.mydomain.com."
-  HostedZoneName: mydomain.com. # dont forget the trailing period
-```
-
-The `{stack_name}` variable gets substituted with the CloudFormation stack name launched by ufo. So for example:
-
-    ufo ship demo-web
-
-Results in:
-
-    "{stack_name}.mydomain.com." => "development-demo-web.mydomain.com."
-
-**IMPORTANT**: The route53 host zone must already exist. You can create route53 hosted zone with the cli like so:
-
-    aws route53 create-hosted-zone --name mydomain.com --caller-reference $(date +%s)
-    aws route53 list-hosted-zones
-
-{% include prev_next.md %}

data/docs/_docs/extras/security-groups.md

@@ -1,36 +0,0 @@
----
-title: Security Groups
-nav_order: 29
----
-
-Ufo creates and manages two security groups. One for the ELB and one for the ECS tasks.
-
-Some consideration for these security groups:
-
-* Network load balancers do not support security groups. So an ELB security group is only created if the load balancer is an Application load balancer.
-* The ECS security group for tasks currently always gets created, but is only used if network_mode is awsvpc. This is because in bridge network mode the EC2 container instance’s Ethernet card and its security group is used. The EC2 containers group security group is outside the control of ufo. You’ll need to configure the security group appropriately yourself. Ufo will only assign the ECS security group when awsvpc node mode is used and ufo has control of the security group.
-
-## EC2 Instance Security Group Help
-
-If you are seeing that the Targets in the ELB Target Group are reporting unhealthy, it is usually a security group issue.  You might see this output with `ufo ps`:
-
-    $ ufo ps --no-summary
-    +----------+------+--------------+----------------+---------+-------------------------+
-    |    Id    | Name |   Release    |    Started     | Status  |          Notes          |
-    +----------+------+--------------+----------------+---------+-------------------------+
-    | 070a9c0a | web  | demo-web:169 | 6 minutes ago  | STOPPED | Failed ELB health check |
-    | d02728ba | web  | demo-web:169 | 3 minutes ago  | STOPPED | Failed ELB health check |
-    | 8dcf81ae | web  | demo-web:169 | 13 seconds ago | RUNNING |                         |
-    +----------+------+--------------+----------------+---------+-------------------------+
-    There are targets in the target group reporting unhealthy.  This can cause containers to cycle. Here's the error:
-    (service development-demo-web-Ecs-13D2BFA4ULNC9) (instance i-0812a3bcd94babf12) (port 32779) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/devel-Targe-1MJR8V6VOWBGI/3f44f85710fe0297) due to (reason Request timed out)
-    Check out the ECS console events tab for more info.
-    $
-
-If you are using network mode bridge, then you'll need to need to configure the container instance's security group to allow traffic to the Docker ephemeral port range. For details on the Docker ephemeral port range on AWS, you search for "ephemeral" on the [ECS Port Mapping Docs](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_PortMapping.html).
-
-In general, ports below 32768 are outside of the ephemeral port range. So an easy way to configure the container instance's security group is to whitelist ports 32768 to 65535 to your VPC's CIDR block. An example of a CIDR block range could be `10.0.0.0/16`. The CIDR block is being suggested because the Application load balancer and security group created by ufo can change if you change the load balancer settings.
-
-If you are using a network load balancer and are running bridge network mode, then you need to whitelist ports 32768 to 65535 to `0.0.0.0/0`.  This is because network load balancers operate at layer 4 of the OSI model and cannot be assigned security groups, so they use the security group of the instance.  If you feel this is too loose of permissions, you can use awsvpc mode. There are some considerations for awsvpc mode though which is discussed next.
-
-{% include prev_next.md %}

data/docs/_docs/extras/ssl-support.md

@@ -1,20 +0,0 @@
----
-title: SSL Support
-nav_order: 31
----
-
-You can configure SSL support by uncomment the `listener_ssl` option in `.ufo/settings/cfn/default.yml`.  Here's an example:
-
-```
-ListenerSsl:
-  Port: 443
-  Certificates:
-  - CertificateArn: arn:aws:acm:us-east-1:111111111111:certificate/11111111-2222-3333-4444-555555555555
-```
-
-For the certificate arn, you will need to create a certificate with AWS ACM. To do so, you can follow these instructions: [Request a Public Certificate
-](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)
-
-The protocol will be either HTTP or HTTPS for Application Load Balancers and TCP or TLS for Network Load Balancers. Ufo will infer the right value, so you usually don't have to configure the protocol manually.  You can configure it if required though.
-
-{% include prev_next.md %}

data/docs/_docs/faq.md

@@ -1,100 +0,0 @@
----
-title: FAQ
-nav_order: 50
----
-
-**Q: Is AWS ECS Fargate supported?**
-
-Yes, Fargate is supported.  To use ufo with Fargate, you will need to adjust the template in `.ufo/templates` to a structure supported by Fargate.  There are 2 key items to adjust:
-
-1. The task definition JSON. Notably, the JSON structure has the `requiresCompatibilities`, `networkMode`, and `executionRoleArn` attributes. The `cpu` and `memory` attributes also move outside of the `containerDefinitions` level to the top-level attributes. For details on how to adjust the task definition refer to [Task Definitions]({% link _docs/tutorial-ufo-tasks-build.md %}).
-2. The params that get sent to the `run_task` API methods. For details on how to adjust the params refer to [Params]({% link _docs/ufo-task-params.md %})
-
-If it's a brand new project, you can use `ufo init` with the `--launch-type fargate` option and it will generate a starter task definition JSON file that has the right Fargate structure. More info is available at [ufo init reference](/reference/ufo-init/#fargate-support).
-
-A quick and easy way to test fargate is to follow the [Quick Start: Fargate Docs]({% link quick-start.md %}) which provides a demo example.
-
-**Q: Can I tell ufo to use specific docker build options?**
-
-Yes, you can do this with the environment variable `UFO_DOCKER_BUILD_OPTIONS`.  Example:
-
-```
-$ UFO_DOCKER_BUILD_OPTIONS="--build-arg RAILS_ENV=production" ufo docker build
-Building docker image with:
-  docker build --build-arg RAILS_ENV=production -t tongueroo/demo-ufo:ufo-2018-05-19T11-52-16-6714713 -f Dockerfile .
-...
-Docker image tongueroo/demo-ufo:ufo-2018-05-19T11-52-16-6714713 built.  Took 2s.
-```
-
----
-
-**Q: Can you tell ufo to use a custom user-defined Docker tag name?**
-
-In short, no. There's some image cleanup logic that relies on the specific naming convention.  However, you can re-tag the build docker image with another tag after ufo is done building the image.  The key is using the `ufo docker name` command to get the last docker image name that was built by ufo. Example:
-
-```
-$ ufo docker build
-$ ufo docker name
-tongueroo/demo-ufo:ufo-2018-05-19T11-41-06-6714713
-$ docker tag $(ufo docker name) hi:mytag
-$ docker images | grep hi
-hi                                                     mytag                              5b01e38bd060        3 minutes ago       955MB
-tongueroo/demo-ufo                                           ufo-2018-05-19T11-41-06-6714713    5b01e38bd060        3 minutes ago       955MB
-$ docker push hi:mytag
-```
-
----
-
-**Q: What's the difference between ufo vs ecs-deploy?**
-
-Some differences:
-
-* ecs-deploy is implemented in bash
-* ufo is implemented in ruby
-* ecs-deploy is a simpler, which could work better for you. It’s nice that it’s one bash script.
-
-ufo does 3 things:
-
-1. Builds and pushes the Docker image
-2. Builds and registers the task definition with ECS
-3. Deploys by either creating or updating the ECS service
-
-Ecs-deploy does step 2 and 3 but not step 1. For step 3, doesn’t look like ecs-deploy creates a service if it doesn’t exist. It’s more designed to update existing an ECS service.
-
-The main difference is that ecs-deploy downloads current ECS task definition and replaces the image attribute. ufo regenerates the task definition from code each deploy. If you’re making adjustments to the task definition with the ECS console as your flow, the ecs-deploy makes more sense. If you want to keep your task definition codified than ufo makes more sense.
-
-Some more differences:
-
-* ufo creates the CloudWatch log group if doesn’t exist. Small thing but it’s easy to forget.
-* ufo has a concept of variables that get layered. This is how it handles multi environments with very similar task definitions with just a few differences.
-
-Generally, ufo does more in scope so we’re sort of comparing apples to oranges here.  Hope that helps.
-
----
-
-**Q: Is it somehow possible to change the templates for the files, that the ufo init-command generates? Most of my services follow the same overall structure, which means I'll have to perform the same changes every time I initialize a new UFO setup.**
-
-Yes, this is achieved with the `--template` and `--template-mode` options when calling the `ufo init` command. The documentation for it is in the [ufo init reference docs](http://ufoships.com/reference/ufo-init/).
-
----
-
-**Q: How can I use syslog instead of awslogs for logging?**
-
-Open up `.ufo/templates/main.json.erb` - this gets created as part of the [ufo init](http://ufoships.com/reference/ufo-init/) command.  Then you can adjust the ecs template definition to something like this:
-
-```json
-            "logConfiguration": {
-                "logDriver": "syslog"
-            },
-```
-
-Here's the specific aws docs section [Specifying a Log Configuration in your Task Definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#specify-log-config)
-
-Also, you might have to enable the log driver by adding the ECS_AVAILABLE_LOGGING_DRIVERS variable to your `/etc/ecs/ecs.config`. Relevant docs:
-
-* [Using AWS Logs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#enable_awslogs)
-* [ECS Agent Install](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html)
-
-Hope that helps.
-
-{% include prev_next.md %}

data/docs/_docs/fargate.md

@@ -1,5 +0,0 @@
----
-title: Fargate
----
-
-This doc has been moved to [Quick Start: Fargate]({% link quick-start.md %}).

data/docs/_docs/helpers.md

@@ -1,24 +0,0 @@
----
-title: Helpers
-nav_order: 19
----
-
-The `task_definitions.rb` file has access to helper methods. These helper methods provide useful contextual information about the project.
-
-For example, one of the helper methods provides the exposed port in the Dockerfile of the project. This is useful if someone changes the exported port in the Dockerfile, he will likely forget also to update the ufo variable.  You can reference the port via the helper to prevent this from happening. Here is a list of the helpers:
-
-Helper  | Description
-------------- | -------------
-full\_image\_name | The full docker image name that ufo builds. The "base" portion of the docker image name is defined in `settings.yml`. For example, the base portion is `tongueroo/demo-ufo` and the full image name is `tongueroo/demo-ufo:ufo-[timestamp]-[sha]`. The base name does not include the generated Docker tag, which contains a timestamp and git sha of the project.
-dockerfile\_port | Exposed port extracted from the Dockerfile of the project.
-env_vars(text) | This method takes a block of text that contains the env values in `key=value` format and converts that block of text to the proper task definition JSON format.
-env_file(path) | This method takes a `.env` file which contains a simple key-value list of environment variables and converts the list to the proper task definition JSON format.
-secrets_vars(text) | This method takes a block of text that contains the secrets values in `key=value` format and converts that block of text to the proper task definition JSON format.
-secrets_file(path) | This method takes a `.secrets` file which contains a simple key-value list of environment variables and converts the list to the proper task definition JSON format.
-task_definition_name | The name of the task_definition.  So if the code looks like this `task_definition "demo-web" do`, the task_definition_name is "demo-web".
-
-To call the helper in task_definitions.rb you must add `helper.` in front.  So `full_image_name` is called via `helper.full_image_name`.
-
-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 helper methods.
-
-{% include prev_next.md %}

data/docs/_docs/iam-roles.md

@@ -1,112 +0,0 @@
----
-title: Task Definition IAM Roles
-nav_order: 21
----
-
-## What are ECS IAM Roles?
-
-For ECS Task Definitions, you can assign it 2 IAM roles: 1) taskRoleArn and 2) executionRoleArn. It's usually defined in the JSON structure like so:
-
-```json
-{
-  "family": "..",
-  "taskRoleArn": "...",
-  "executionRoleArn": "...",
-  "containerDefinitions": [
-    ...
-  ]
-}
-```
-
-Here's a table that explains the difference between the 2 IAM roles.
-
-Name | Purpose
---- | ---
-taskRoleArn | This is the role that the ECS task itself uses. So this is what IAM permissions your application has access to. Think about it as the "container role".
-executionRoleArn | This is the role that the EC2 instance host uses. This allows the EC2 instance to pull from the ECR registry. Think about it as the "host role".
-
-## How to Assign IAM Roles with UFO
-
-You can assign an IAM role to the ECS Task definition in ways:
-
-1. IAM Role with Code (UFO Managed)
-2. Precreated IAM Role
-
-## IAM Role with Code (UFO Managed)
-
-UFO can automatically create the IAM and assign it to the task definition. You create these files so UFO will know to create and manage the IAM roles.
-
-    .ufo/iam_roles/execution_role.rb
-    .ufo/iam_roles/task_role.rb
-
-### Example 1
-
-You then use a DSL to create the IAM roles. Here are examples:
-
-.ufo/iam_roles/execution_role.rb
-
-```ruby
-managed_iam_policy("AmazonSSMReadOnlyAccess")
-managed_iam_policy("SecretsManagerReadWrite")
-managed_iam_policy("service-role/AmazonECSTaskExecutionRolePolicy")
-```
-
-.ufo/iam_roles/task_role.rb
-
-```ruby
-iam_policy("AmazonS3ReadOnlyAccess",
-  Action: [
-    "s3:Get*",
-    "s3:List*"
-  ],
-  Effect: "Allow",
-  Resource: "*"
-)
-iam_policy("CloudwatchWrite",
-  Action: [
-    "cloudwatch:PutMetricData",
-  ],
-  Effect: "Allow",
-  Resource: "*"
-)
-```
-
-### Example 2
-
-You can use the `managed_iam_policy` and `iam_policy` together. You can also group multiple statements in the `iam_policy` declaration.
-
-.ufo/iam_roles/task_role.rb
-
-```ruby
-managed_iam_policy("AmazonSSMManagedInstanceCore")
-
-iam_policy("custom-policy", [
-  {
-    Action: "ecs:UpdateContainerInstancesState",
-    Resource: "*",
-    Effect: "Allow"
-  },
-  {
-    Action: "sns:Publish",
-    Resource: "*",
-    Effect: "Allow"
-  }
-])
-```
-
-## Pre-Created IAM Role
-
-You can also assign the task definition `executionRoleArn` with pre-created IAM roles. It looks something like this in the `.ufo/templates/main.json.erb` file:
-
-```json
-{
-  "family": "<%= @family %>",
-  "taskRoleArn": "arn:aws:iam::112233445566:role/pre-created-iam-role",
-  "executionRoleArn": "arn:aws:iam::112233445566:role/pre-created-iam-role",
-  "containerDefinitions": [
-    ...
-  ]
-}
-```
-
-{% include prev_next.md %}

data/docs/_docs/install.md

@@ -1,25 +0,0 @@
----
-title: Installation
-nav_order: 3
----
-
-## Install with RubyGems
-
-You can install ufo with RubyGems:
-
-```sh
-gem install ufo
-```
-
-Or you can add ufo to your Gemfile in your project if you are working with a ruby project.  It is not required for your project to be a ruby project to use ufo.
-
-{% highlight ruby %}
-gem "ufo"
-{% endhighlight %}
-
-## 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.
-* AWS: Set up your AWS credentials at `~/.aws/credentials` and `~/.aws/config`.  This is the [AWS standard way of setting up credentials](https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/).
-
-{% include prev_next.md %}

data/docs/_docs/more/auto-completion.md

@@ -1,24 +0,0 @@
----
-title: Auto Completion
-nav_order: 49
----
-
-Ufo supports bash auto-completion.  To set it up add the following to your `~/.profile` or `.bashrc`:
-
-    eval $(ufo completion_script)
-
-Remember to restart your shell or source your profile file.
-
-Auto Completion examples:
-
-    ufo [TAB]
-    ufo ship [TAB]
-    ufo ship demo-web [TAB]
-    ufo ship demo-web --[TAB]
-    ufo ship --[TAB]
-    ufo docker [TAB]
-    ufo docker build [TAB]
-    ufo tasks [TAB]
-    ufo tasks build [TAB]
-
-{% include prev_next.md %}

data/docs/_docs/more/automated-cleanup.md

@@ -1,14 +0,0 @@
----
-title: Automated Clean Up
-nav_order: 48
----
-
-Ufo can be configured to automatically clean old images from the ECR registry after the deploy completes by configuring your [settings.yml]({% link _docs/settings.md %}) file like so:
-
-```yaml
-ecr_keep: 30
-```
-
-Automated Docker images clean up only works if you are using ECR registry.
-
-{% include prev_next.md %}

data/docs/_docs/more/customize-cloudformation.md

@@ -1,35 +0,0 @@
----
-title: Customize CloudFormation
-nav_order: 43
----
-
-Under the hood, ufo creates most of the required resources with a CloudFormation stack.  This includes the ELB, Target Group, Listener, Security Groups, ECS Service, and Route 53 records.  You might need to customize these resources.  Here are the ways to customize the resources that ufo creates.
-
-1. Settings - This is done with the `.ufo/settings/cfn/default.yml` file. This is the main and recommended way to customize.
-2. Override cfn template - You can specify your own template to use.  You save this template at `.ufo/settings/cfn/stack.yml`. Use this approach as a last resort only when necessary.
-
-## Settings
-
-The recommended approach to customize the CloudFormation resources is by adding properties to `.ufo/settings/cfn/default.yml`.
-
-{% include cfn-customize.md %}
-
-## Override Cfn Template
-
-You can override the source template that ufo uses by creating your own and saving it at `.ufo/settings/cfn/stack.yml` in your project. It is recommended that you copy the source code and work from there [cfn/stack.yml](https://github.com/tongueroo/ufo/blob/master/lib/cfn/stack.yml).  Use this approach as a last resort only when absolutely necessary as it'll likely break with a future version of ufo.
-
-## CloudFormation Stack Name
-
-The CloudFormation stack name is based on the service name, UFO_ENV and UFO_ENV_EXTRA.  A few examples help demonstrate:
-
-Command | Stack Name
---- | ---
-ufo ship demo-web | demo-web-development
-ufo ship demo-web -\-cluster dev | demo-web-development
-UFO_ENV_EXTRA=2 ufo ship demo-web -\-cluster dev | demo-web-development-2
-
-## CloudFormation Stack Source Code
-
-The CloudFormation stack is currently generated from a template. The source code for this template is located at [cfn/stack.yml](https://github.com/tongueroo/ufo/blob/master/lib/cfn/stack.yml).  This implementation might change in the future.
-
-{% include prev_next.md %}

data/docs/_docs/more/migrations.md

@@ -1,25 +0,0 @@
----
-title: Database Migrations
-nav_order: 47
----
-
-A common task is to run database migrations with newer code before deploying the code. This is easily achieved with the `ufo task` command. Here's an example:
-
-    ufo task demo-web -c bundle exec rake db:migrate
-
-It is nice to wrap the commands in a wrapper script in case you have to do things like to load the environment.
-
-    ufo task demo-web -c bin/migrate
-
-The `bin/migrate` script can look like this:
-
-    #!/bin/bash
-    bundle exec rake db:migrate
-
-The `ufo task` command is generalized so you can run any one-off task. It is not just limited to running migrations. The `ufo task` command performs the following:
-
-1. Builds the docker image and pushes it to a registry
-2. Registers the ECS Task definition
-3. Runs a one-off ECS Task
-
-{% include prev_next.md %}

data/docs/_docs/more/run-in-pieces.md

@@ -1,30 +0,0 @@
----
-title: Run in Pieces
-nav_order: 45
----
-
-The `ufo ship` command goes through a few stages:
-
-1. building the docker image
-2. registering the task defiintions
-2. updating the ECS service.
-
-The CLI exposes many of these steps as separate commands.  Here is now you would be able to run each of the steps in pieces.
-
-Build the docker image first.
-
-    ufo docker build
-    ufo docker push # pushes last built image to a registry
-
-Build the task definitions.
-
-    ufo tasks build    # generates task definition json files to .ufo/output
-    ufo tasks register # registers all genreated task definitions .ufo/output to ECS
-
-Update the service with the task definitions in `.ufo/output` untouched.
-
-    ufo deploy demo-web
-
-Note if you use the `ufo deploy` you should ensure that you have already pushed the docker image to your docker registry.  Or else the task will not be able to spin up because the docker image does not exist.  This is one of the reasons it is recommended that you use `ufo ship`.
-
-{% include prev_next.md %}

data/docs/_docs/more/single-task.md

@@ -1,25 +0,0 @@
----
-title: Run Single Task
-nav_order: 46
----
-
-Sometimes you do not want to run a long running `service` but a one time task. Running Rails migrations are an example of a one off task.  Here is an example of how you would run a one time task.
-
-    ufo task demo-web -c bundle exec rake db:migrate
-
-At the end of the output you should see you the task ARN:
-
-
-    $ ufo task demo-web -c bundle exec rake db:migrate
-    ...
-    Running task_definition: demo-web
-    Task ARN: arn:aws:ecs:us-west-2:994926937775:task/a0e4229d-3d39-4b26-9151-6ab6869b84d4
-    $
-
-You can describe that task for more details:
-
-    aws ecs describe-tasks --tasks arn:aws:ecs:us-west-2:994926937775:task/a0e4229d-3d39-4b26-9151-6ab6869b84d4
-
-You can check out the [ufo task](http://ufoships.com/reference/ufo-task/) reference for more details.
-
-{% include prev_next.md %}

data/docs/_docs/more/stuck-cloudformation.md

@@ -1,29 +0,0 @@
----
-title: Stuck CloudFormation
-nav_order: 44
----
-
-The CloudFormation stack update or creation can get stuck in a `*_IN_PROGRESS` state for a very long time, like more than an hour.  This happens when you deploy an ECS service that fails to stabilize. Usually, this is an error with the Docker container failing to start up successfully.
-There can be many reasons for this, here are some examples:
-
-* Bug in the startup script in the Dockerfile.
-* There are no container instances available to place the docker ECS task.
-* You have a rails app and it is failing to connect to the database upon startup, maybe due to a security group setting.
-
-To resolve this, you can:
-
-1. cancel the current deploy
-2. fix the underlying issue
-3. deploy again
-
-## Canceling Deployment
-
-If an ECS deployment does not finish within 10 minutes because the ECS service is not stabilizing, it is usually due one of the reasons above. In these cases, it is safe to cancel and try again.
-
-To cancel a current deploy, run:
-
-    ufo cancel
-
-This is the same thing as canceling the stack update in the CloudFormation console.
-
-{% include prev_next.md %}

data/docs/_docs/more/why-cloudformation.md

@@ -1,21 +0,0 @@
----
-title: Why CloudFormation
-nav_order: 42
----
-
-Version 3 of ufo was a simpler implementation and did not make use of CloudFormation to create the ECS service. In version 4, ufo uses CloudFormation to create the ECS Service.  This is because ufo became more powerful. Notably, support for Load Balancers was added. With this power, also came added complexity. So the complexity was push onto CloudFormation.  Hence, ECS service is implemented as CloudFormation resource in version 4.
-
-My gut was already telling me that with Load Balancer support, the "orchestration" or sequencing logic in ufo would become annoyingly complex and shifting it to CloudFormation would be worth it. Nevertheless, I took the time with quick experimental branch and added Load Balancer support using the aws-sdk directly without CloudFormation.
-
-The pull request for that code is here [ufo/pull/42](https://github.com/tongueroo/ufo/pull/42). An additional tool was created for the non-CloudFormation approach called [balancer](https://github.com/tongueroo/balancer). Balancer is a standalone tool used to create load balancers consistently with "profile" files.
-
-* [ufo/pull/42](https://github.com/tongueroo/ufo/pull/42) - PR for non-CloudFormation. Closed and not used.
-* [ufo/pull/43](https://github.com/tongueroo/ufo/pull/43) - PR for CloudFormation. Merged and used.
-
-The results of the exercise confirm my gut.  Though the CloudFormation implementation requires more upfront investment, it ultimately pays off.  For example, route53 DNS support was added to ufo easily and quickly.  Sometimes the learning curve of CloudFormation can be a deterrent, so I hope that these thoughts help.
-
-You can check the resources created with CloudFormation by clicking on the stack name of in the CloudFormation console.
-
-<img src="/img/docs/cloudformation-resources.png" class="doc-photo" />
-
-{% include prev_next.md %}

data/docs/_docs/next-steps.md

@@ -1,16 +0,0 @@
----
-title: Next Steps
-nav_order: 52
----
-
-This concludes the tutorial guide for ufo. Hopefully you are now more comfortable with ufo's basic usage, concepts, and have a feel for the workflow.
-
-From here, there are a few resources that can help you continue along:
-
-* Check out the [ufo](https://github.com/tongueroo/ufo) repo on GitHub
-* Submit an issue
-* Write a blog post describing how you are using ufo, or an interesting problem ufo has allowed you to solve
-
-Everyone can contribute to make ufo better, including the documentation. These docs are of the same ufo repo in the [docs folder](https://github.com/tongueroo/ufo/tree/master/docs). Please fork the project and open a pull request!  We love your pull requests. Contributions are encouraged and welcomed!
-
-{% include prev_next.md %}