ufo 5.0.0 → 5.0.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ce5c8180b261636a61805a4abc5cbd3d556784f77dbf20ca0f2384d8ab50ae32
-  data.tar.gz: 9d6e1955bd7ca4b35b347c61986af5c92c916410a1d9b43b0d11a76e1dbd4fc3
+  metadata.gz: 653b01be727b4764ac9c022606359059e6102fe30b202461ffb1ee1665c3d4b6
+  data.tar.gz: 97a8fd6af8b07ea9c213e339dd70c23f98a74186c7ba6cd906ea38e7aba39f10
 SHA512:
-  metadata.gz: 60ec0e82534f94e8daffbb9587f22753e4df92a77545ba4f220e0f9f3f1568a7dc0722f32e278f1853160ab477e80b0cfef8dbde6330c0b0af46a3e4695c8bc6
-  data.tar.gz: 4bb7540d47f271ea211b3ade315b6a69fe9d1ce23b2cf0cef82cf2ddb1905d849a6064a08aab07279e623073f985542f8396533aedde86fc0b78a39e99ca8bb0
+  metadata.gz: d040994ee8a6b73c151d91a90847dc91ef8c3233b4b9ff65aaf731f9c585ee8093dfb0c2448ce0eddd1b5e823bbafeab5e69495319c3959ac4281b804b404ecf
+  data.tar.gz: 2e64ef5b51b100708154b160a089e118e5e06346dbf68a5a69bdc1c0894ce1762d58f4ceb073c0ec6d1c38947662edb9901cbce16ef15df1255faca06e7c7eeb

data/CHANGELOG.md

@@ -3,6 +3,10 @@
 All notable changes to this project will be documented in this file.
 This project *tries* to adhere to [Semantic Versioning](http://semver.org/), even before v1.0.
 
+## [5.0.1]
+- #109 fix fargate
+- #110 adjust and document `managed_security_groups` setting
+
 ## [5.0.0]
 - #104 adjust logs default format to detailed
 - #105 major rework: build cfn template with Ruby instead of ERB for new features

data/docs/_docs/conventions.md

@@ -1,6 +1,6 @@
 ---
 title: Conventions
-nav_order: 19
+nav_order: 22
 ---
 
 Ufo uses a set of naming conventions.  This helps enforce some best practices and also allows the ufo commands to be concise.  You can override or bypass the conventions easily.

data/docs/_docs/extras/codebuild-iam-role.md

@@ -1,6 +1,6 @@
 ---
 title: CodeBuild IAM Role
-nav_order: 32
+nav_order: 35
 ---
 
 Note, the `/tmp/ecs-deploy-policy.json` policy is available at [Minimal Deploy IAM]({% link _docs/extras/minimal-deploy-iam.md %}).

data/docs/_docs/extras/dockerfile-erb.md

@@ -1,6 +1,6 @@
 ---
 title: Dynamic Dockerfile.erb
-nav_order: 33
+nav_order: 36
 ---
 
 Sometimes you may need a little more dynamic control of your Dockerfile. For these cases, ufo supports dynamically creating a Dockerfile from a Dockerfile.erb.  If Dockerfile.erb exists, ufo uses it to generate a Dockerfile as a part of the build process.  These means that you should update the source Dockerfile.erb instead, as the Dockerfile will be overwritten.  If Dockerfile.erb does not exist, then ufo will use the Dockerfile instead.

data/docs/_docs/extras/ecs-network-mode.md

@@ -1,6 +1,6 @@
 ---
 title: ECS Network Mode
-nav_order: 27
+nav_order: 30
 ---
 
 ## Pros and Cons: bridge network mode

data/docs/_docs/extras/load-balancer.md

@@ -1,6 +1,6 @@
 ---
 title: Load Balancer Support
-nav_order: 25
+nav_order: 28
 ---
 
 Ufo can automatically create a load balancer and associate it with an ECS service.  The options:

data/docs/_docs/extras/minimal-deploy-iam.md

@@ -1,6 +1,6 @@
 ---
 title: Minimal Deploy IAM Policy
-nav_order: 31
+nav_order: 34
 ---
 
 The IAM user you use to run the `ufo ship` command needs a minimal set of IAM policies in order to deploy to ECS. Here is a table of the baseline services needed:

data/docs/_docs/extras/notification-arns.md

@@ -1,7 +1,7 @@
 ---
 title: Notification ARNs
 categories: extras
-nav_order: 99
+nav_order: 37
 ---
 
 You can specific notification arns for CloudFormation stack related events with [configs/settings.yml]({% link _docs/settings.md %}). This may be useful for compliance purposes.

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

@@ -1,6 +1,6 @@
 ---
 title: Redirection Support
-nav_order: 30
+nav_order: 33
 ---
 
 ## Application Load Balancers
@@ -8,15 +8,15 @@ nav_order: 30
 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
+Listener:
+  Port: 80
   # ...
-  default_actions:
-   - type: redirect
-     redirect_config:
-       protocol: HTTPS
-       status_code: HTTP_302 # HTTP_301 and HTTP_302 are valid
-       port: 443
+  DefaultActions:
+   - Type: redirect
+     RedirectConfig:
+       Protocol: HTTPS
+       StatusCode: HTTP_302 # HTTP_301 and HTTP_302 are valid
+       Port: 443
 ```
 
 

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

@@ -1,14 +1,14 @@
 ---
 title: Route53 Support
-nav_order: 29
+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."
-  hosted_zone_name: mydomain.com. # dont forget the trailing period
+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:

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

@@ -1,6 +1,6 @@
 ---
 title: Security Groups
-nav_order: 26
+nav_order: 29
 ---
 
 Ufo creates and manages two security groups. One for the ELB and one for the ECS tasks.

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

@@ -1,15 +1,15 @@
 ---
 title: SSL Support
-nav_order: 28
+nav_order: 31
 ---
 
 You can configure SSL support by uncomment the `listener_ssl` option in `.ufo/settings/cfn/default.yml`.  Here's an example:
 
 ```
-listener_ssl:
-  port: 443
-  certificates:
-  - certificate_arn: arn:aws:acm:us-east-1:111111111111:certificate/11111111-2222-3333-4444-555555555555
+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

data/docs/_docs/faq.md

@@ -1,6 +1,6 @@
 ---
 title: FAQ
-nav_order: 45
+nav_order: 50
 ---
 
 **Q: Is AWS ECS Fargate supported?**

data/docs/_docs/helpers.md

@@ -1,6 +1,6 @@
 ---
 title: Helpers
-nav_order: 18
+nav_order: 19
 ---
 
 The `task_definitions.rb` file has access to helper methods. These helper methods provide useful contextual information about the project.

data/docs/_docs/iam-roles.md

@@ -1,5 +1,6 @@
 ---
 title: Task Definition IAM Roles
+nav_order: 21
 ---
 
 ## What are ECS IAM Roles?
@@ -45,9 +46,7 @@ You then use a DSL to create the IAM roles. Here are examples:
 .ufo/iam_roles/execution_role.rb
 
 ```ruby
-managed_iam_policy("AmazonEC2ContainerRegistryReadOnly")
 managed_iam_policy("AmazonSSMReadOnlyAccess")
-managed_iam_policy("CloudWatchLogsFullAccess")
 managed_iam_policy("SecretsManagerReadWrite")
 managed_iam_policy("service-role/AmazonECSTaskExecutionRolePolicy")
 ```
@@ -109,3 +108,5 @@ You can also assign the task definition `executionRoleArn` with pre-created IAM
   ]
 }
 ```
+
+{% include prev_next.md %}

data/docs/_docs/install.md

@@ -17,16 +17,6 @@ Or you can add ufo to your Gemfile in your project if you are working with a rub
 gem "ufo"
 {% endhighlight %}
 
-## Install with Bolts Toolbelt
-
-If you want to quickly install ufo without having to worry about ufo's dependencies you can install the Bolts Toolbelt which has ufo included.
-
-```sh
-brew cask install boltopslabs/software/bolts
-```
-
-For more information about the Bolts Toolbelt or to get an installer for another operating system visit: [https://boltops.com/toolbelt](https://boltops.com/toolbelt)
-
 ## Dependencies
 
 * Docker: You will need a working version of [Docker](https://docs.docker.com/engine/installation/) installed as ufo shells out and calls the `docker` command.

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

@@ -1,6 +1,6 @@
 ---
 title: Auto Completion
-nav_order: 44
+nav_order: 49
 ---
 
 Ufo supports bash auto-completion.  To set it up add the following to your `~/.profile` or `.bashrc`:

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

@@ -1,6 +1,6 @@
 ---
 title: Automated Clean Up
-nav_order: 43
+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:

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

@@ -1,6 +1,6 @@
 ---
 title: Customize CloudFormation
-nav_order: 38
+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.

data/docs/_docs/more/migrations.md

@@ -1,6 +1,6 @@
 ---
 title: Database Migrations
-nav_order: 42
+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:

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

@@ -1,6 +1,6 @@
 ---
 title: Run in Pieces
-nav_order: 40
+nav_order: 45
 ---
 
 The `ufo ship` command goes through a few stages:

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

@@ -1,6 +1,6 @@
 ---
 title: Run Single Task
-nav_order: 41
+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.

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

@@ -1,6 +1,6 @@
 ---
 title: Stuck CloudFormation
-nav_order: 39
+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.

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

@@ -1,6 +1,6 @@
 ---
 title: Why CloudFormation
-nav_order: 37
+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.

data/docs/_docs/next-steps.md

@@ -1,6 +1,6 @@
 ---
 title: Next Steps
-nav_order: 47
+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.

data/docs/_docs/secrets.md

@@ -1,10 +1,11 @@
 ---
 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 handles the decryption the secrets go 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 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:
 
@@ -55,7 +56,7 @@ Ufo supports both forms of secrets. You create a `.secrets` file and can referen
 
 The `.secrets` file is like an env file that will understand a secrets-smart format.  Example:
 
-    NAME1=SSM:/my/parameter_name
+    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.
@@ -71,17 +72,29 @@ In turn, this generates:
     "secrets": [
       {
         "name": "NAME1",
-        "valueFrom": "arn:aws:ssm:us-west-2:536766270177:parameter/demo/development/foo"
+        "valueFrom": "arn:aws:ssm:us-west-2:111111111111:parameter/demo/development/foo"
       },
       {
         "name": "NAME2",
-        "valueFrom": "arn:aws:secretsmanager:us-west-2:536766270177:secret:/demo/development/my-secret-test-qRoJel"
+        "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:
@@ -109,4 +122,14 @@ 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.md

@@ -16,8 +16,8 @@ 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
+  # 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
@@ -35,13 +35,14 @@ 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
-`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.
-`network_profile` | The name of the network profile settings file to use. Maps to .ufo/settings/network/NAME.yml file
+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
 

data/docs/_docs/settings/manage-security-groups.md

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

@@ -2,7 +2,7 @@
 title: Settings Network
 short_title: Network
 categories: settings
-nav_order: 16
+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.
@@ -22,6 +22,16 @@ elb_subnets: # defaults to same subnets as ecs_subnets when not set
 #   - 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

data/docs/_docs/structure.md

@@ -25,15 +25,16 @@ The table below covers the purpose of each folder and file.
 
 File / Directory  | Description
 ------------- | -------------
-<code>output/</code>  | 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 %}).
-<code>params</code>  | 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 %}).
-<code>settings.yml</code>  | Ufo's general settings file, where you adjust the default [settings]({% link _docs/settings.md %}).
-<code>settings/cfn/default.yml</code>  | Ufo's cfn settings. You can customize the CloudFormation resource properties here.
-<code>settings/network/default.yml</code>  | Ufo's network settings. You can customize the vpc and subnets to used here.
-<code>task_definitions.rb</code>  | This is where you define the task definitions and specify the variables to be used by the ERB templates.
-<code>templates/</code>  | The ERB templates with the task definition json code.  The templates are covered in more detail in [ufo tasks build]({% link _docs/tutorial-ufo-tasks-build.md %}).
-<code>templates/main.json.erb</code>  | This is the main and starter template task definition json file that ufo initially generates.
-<code>variables</code>  | This is where you can define shared variables that are made available to the `template_definitions.rb` and your templates. More info at [Variables]({% link _docs/variables.md %}).
+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!
 

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

@@ -65,8 +65,6 @@ base:
   # 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.
   # defaults when an new ECS service is created by ufo ship
-  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
@@ -75,14 +73,10 @@ development:
   # When you have AWS_PROFILE set to one of these values, ufo will switch to the desired
   # environment. This prevents you from switching AWS_PROFILE, forgetting to
   # also switch UFO_ENV, and accidentally deploying to production vs development.
-  # aws_profiles:
-  #   - dev_profile1
-  #   - dev_profile2
+  # aws_profile: dev_profile1
 
 production:
   # cluster: prod
-  # aws_profiles:
-  #   - prod_profile
 ```
 
 The `image` value is the name that ufo will use as a base portion of the name to generate a Docker image name, it should not include the tag portion.

data/docs/_docs/ufo-current.md

@@ -1,6 +1,6 @@
 ---
 title: Ufo Current
-nav_order: 23
+nav_order: 26
 ---
 
 ## service

data/docs/_docs/ufo-env-extra.md

@@ -1,6 +1,6 @@
 ---
 title: UFO_ENV_EXTRA
-nav_order: 22
+nav_order: 25
 ---
 
 <div class="video-box"><div class="video-container"><iframe src="https://www.youtube.com/embed/UVQuwQGToYE" frameborder="0" allowfullscreen=""></iframe></div></div>

data/docs/_docs/ufo-env.md

@@ -1,6 +1,6 @@
 ---
 title: UFO_ENV
-nav_order: 21
+nav_order: 24
 ---
 
 Ufo's behavior is controlled by the `UFO_ENV` environment variable.  For example, the `UFO_ENV` variable is used to layer different ufo variable files together to make it easy to specify settings for different environments like production and development.  This is covered thoroughly in the [Variables]({% link _docs/variables.md %}) section.  `UFO_ENV` defaults to `development` when not set.
@@ -27,12 +27,10 @@ The most interesting way to set `UFO_ENV` is with the `aws_profiles` setting in
 
 ```yaml
 development:
-  aws_profiles:
-    - my-dev-profile
+  aws_profile: my-dev-profile
 
 production:
-  aws_profiles:
-    - my-prod-profile
+  aws_profile: my-prod-profile
 ```
 
 In this case, when you set `AWS_PROFILE` to switch AWS profiles, ufo picks this up and maps the `AWS_PROFILE` value to the specified `UFO_ENV` using the `aws_profiles` lookup.  Example:

data/docs/_docs/ufo-logs.md

@@ -1,6 +1,6 @@
 ---
 title: ufo logs command
-nav_order: 20
+nav_order: 23
 ---
 
 The ufo logs command will tail the logs of the ecs service if you are using the awslogs driver.
@@ -46,5 +46,4 @@ The generated .ufo task definition defaults to the awslogs driver. If you need i
 }
 ```
 
-
 {% include prev_next.md %}

data/docs/_docs/ufo-task-params.md

@@ -1,6 +1,6 @@
 ---
 title: Ufo Task Params
-nav_order: 24
+nav_order: 27
 ---
 
 You can run one off task with the [ufo task](https://ufoships.com/reference/ufo-task/) command.

data/docs/_docs/upgrading.md

@@ -1,6 +1,6 @@
 ---
 title: Upgrading
-nav_order: 34
+nav_order: 38
 ---
 
 <ul>

data/docs/_docs/upgrading/upgrade4.5.md

@@ -1,9 +1,9 @@
 ---
 title: Upgrading to Version 4.5
 short_title: Version 4.5
-order: 1
+order: 2
 categories: upgrading
-nav_order: 35
+nav_order: 40
 ---
 
 In ufo version 4.4 and 4.5, the default cloudformation stack names used by ufo were changed.

data/docs/_docs/upgrading/upgrade4.md

@@ -1,9 +1,9 @@
 ---
 title: Upgrading to Version 4.0
 short_title: Version 4.0
-order: 2
+order: 3
 categories: upgrading
-nav_order: 36
+nav_order: 41
 ---
 
 A major change in ufo from version 3 to 4 is that the ECS service is now created by CloudFormation. If you have an existing ECS service deployed by ufo version 3, when you deploy your app again with ufo version 4, there will be a new additional ECS service created. Here is the recommended upgrade path.

data/docs/_docs/upgrading/upgrade5.md

@@ -0,0 +1,19 @@
+---
+title: Upgrading to Version 5
+short_title: Version 5
+order: 1
+categories: upgrading
+nav_order: 39
+---
+
+In ufo v5, the ufo went from underscore key names in the [cfn settings files]({% link _docs/settings/cfn.md %}) to camelized key names. So the auto_camelize behavior is disabled for newly `ufo init` projects. This mean ufo is backwards compatiable. You can enable the v5 behavior with `auto_camelize: false`. If you have not adjusted this setting, then ufo should still work with your current `.ufo` files.
+
+## Upgrading Instructions
+
+If you want to upgrade to the latest ufo v5 default behavior.
+
+1. Adjust your .ufo/settings/cfn files so that the keys are camelized
+2. Add to your .ufo/settings.yml `auto_camelize: false`
+3. Deploy and verify that your ECS app stil works
+
+{% include prev_next.md %}

data/docs/_docs/variables.md

@@ -1,6 +1,6 @@
 ---
 title: Shared Variables
-nav_order: 17
+nav_order: 18
 ---
 
 Often, you end up using the set of common variables across your task definitions for a project.  Ufo supports a shared variables concept to support this.  You specify variables files in the `.ufo/variables` folder and they are made available to your `.ufo/task_definitions.rb` as well as your `.ufo/templates` files.

data/docs/_includes/cfn-customize.md

@@ -5,11 +5,11 @@ The properties in the file `.ufo/settings/cfn/default.yml` map directly to ufo's
 Let's customize the `AWS::ElasticLoadBalancingV2::TargetGroup` resource created by CloudFormation.  We'll adjust the `deregistration_delay.timeout_seconds` to `8`.  Here's the relevant section of the `.ufo/settings/cfn/default.yml`
 
 ```
-target_group:
+TargetGroup:
 ...
-  target_group_attributes:
-  - key: deregistration_delay.timeout_seconds
-    value: 8
+  TargetGroupAttributes:
+  - Key: deregistration_delay.timeout_seconds
+    Value: 8
 ```
 
 The value will be injected to the generated CloudFormation template under the corresponding "TargetGroup Properties".  The generated template looks something like this:

data/docs/_reference/ufo-init.md

@@ -107,20 +107,19 @@ If you would like to use a local template that is not on GitHub, then created a
 ## Options
 
 ```
-[--force]                                  # Bypass overwrite are you sure prompt for existing files.
---image=IMAGE                              # Docker image name without the tag. Example: tongueroo/demo-ufo. Configures ufo/settings.yml
-[--app=APP]                                # App name. Preferably one word. Used in the generated ufo/task_definitions.rb.  If not specified then the app name is inferred as the folder name.
-[--launch-type=LAUNCH_TYPE]                # ec2 or fargate.
-                                           # Default: ec2
-[--execution-role-arn=EXECUTION_ROLE_ARN]  # execution role arn used by tasks, required for fargate.
-[--template=TEMPLATE]                      # Custom template to use.
-[--template-mode=TEMPLATE_MODE]            # Template mode: replace or additive.
-[--vpc-id=VPC_ID]                          # Vpc id. For settings/network/default.yml.
-[--ecs-subnets=one two three]              # Subnets for ECS tasks, defaults to --elb-subnets set to. For settings/network/default.yml
-[--elb-subnets=one two three]              # Subnets for ELB. For settings/network/default.yml
-[--verbose], [--no-verbose]                
-[--mute], [--no-mute]                      
-[--noop], [--no-noop]                      
-[--cluster=CLUSTER]                        # Cluster.  Overrides .ufo/settings.yml.
+[--force]                        # Bypass overwrite are you sure prompt for existing files.
+--image=IMAGE                    # Docker image name without the tag. Example: tongueroo/demo-ufo. Configures ufo/settings.yml
+[--app=APP]                      # App name. Preferably one word. Used in the generated ufo/task_definitions.rb.  If not specified then the app name is inferred as the folder name.
+[--launch-type=LAUNCH_TYPE]      # ec2 or fargate.
+                                 # Default: ec2
+[--template=TEMPLATE]            # Custom template to use.
+[--template-mode=TEMPLATE_MODE]  # Template mode: replace or additive.
+[--vpc-id=VPC_ID]                # Vpc id. For settings/network/default.yml.
+[--ecs-subnets=one two three]    # Subnets for ECS tasks, defaults to --elb-subnets set to. For settings/network/default.yml
+[--elb-subnets=one two three]    # Subnets for ELB. For settings/network/default.yml
+[--verbose], [--no-verbose]      
+[--mute], [--no-mute]            
+[--noop], [--no-noop]            
+[--cluster=CLUSTER]              # Cluster.  Overrides .ufo/settings.yml.
 ```
 

data/docs/articles.md

@@ -1,6 +1,6 @@
 ---
 title: Articles
-nav_order: 46
+nav_order: 51
 ---
 
 * [How to Create Unlimited Extra Environments

data/lib/template/.secrets

@@ -1,3 +1,5 @@
-# fine to have comment in this file
-NAME1=SSM:parameter_name
-NAME2=SECRETSMANAGER:secret_name-AbCdEf
+# Example starter secrets file. Be sure that the SSM parameters or Secrets exist.
+# Docs: https://ufoships.com/docs/secrets/
+#
+# NAME1=SSM:parameter_name
+# NAME2=SECRETSMANAGER:secret_name-AbCdEf

data/lib/template/.ufo/iam_roles/execution_role.rb

@@ -0,0 +1,7 @@
+# Example starter execution role. Add the iam role permissions that the host needs here:
+#
+# More docs: https://ufoships.com/docs/iam-roles/
+#
+managed_iam_policy("AmazonSSMReadOnlyAccess")
+managed_iam_policy("SecretsManagerReadWrite")
+managed_iam_policy("service-role/AmazonECSTaskExecutionRolePolicy")

data/lib/template/.ufo/iam_roles/task_role.rb

@@ -0,0 +1,21 @@
+# Example starter task role. Add the iam role permissions that the container needs here:
+#
+# More docs: https://ufoships.com/docs/iam-roles/
+#
+# Examples:
+#
+# iam_policy("AmazonS3ReadOnlyAccess",
+#   Action: [
+#     "s3:Get*",
+#     "s3:List*"
+#   ],
+#   Effect: "Allow",
+#   Resource: "*"
+# )
+# iam_policy("CloudwatchWrite",
+#   Action: [
+#     "cloudwatch:PutMetricData",
+#   ],
+#   Effect: "Allow",
+#   Resource: "*"
+# )

data/lib/template/.ufo/templates/fargate.json.erb

@@ -2,7 +2,6 @@
   "family": "<%= @family %>",
   "requiresCompatibilities": ["FARGATE"],
   "networkMode": "awsvpc",
-  "executionRoleArn": "<%= @execution_role_arn || raise("@execution_role_arn needs to be set") %>",
   "cpu": "<%= @cpu %>",
   "memory": "<%= @memory %>",
   "containerDefinitions": [

data/lib/ufo/dsl/helper.rb

@@ -46,11 +46,11 @@ module Ufo
       end
 
       def secrets(text)
-        Vars.new(text: text, secrets: true).secrets
+        Vars.new(text: text).secrets
       end
 
       def secrets_file(path)
-        Vars.new(file: path, secrets: true).secrets
+        Vars.new(file: path).secrets
       end
 
       def current_region

data/lib/ufo/dsl/helper/vars.rb

@@ -8,7 +8,6 @@ class Ufo::DSL::Helper
       # use either file or text. text takes higher precedence
       @file = options[:file]
       @text = options[:text]
-      @secrets = options[:secrets] # true or false
     end
 
     def content

data/lib/ufo/init.rb

@@ -9,7 +9,6 @@ module Ufo
         [:image, required: true, desc: "Docker image name without the tag. Example: tongueroo/demo-ufo. Configures ufo/settings.yml"],
         [:app, desc: "App name. Preferably one word. Used in the generated ufo/task_definitions.rb.  If not specified then the app name is inferred as the folder name."],
         [:launch_type, default: "ec2", desc: "ec2 or fargate."],
-        [:execution_role_arn, desc: "execution role arn used by tasks, required for fargate."],
         [:template, desc: "Custom template to use."],
         [:template_mode, desc: "Template mode: replace or additive."],
         [:vpc_id, desc: "Vpc id. For settings/network/default.yml."],
@@ -56,7 +55,6 @@ module Ufo
       # map variables
       @app = options[:app] || inferred_app
       @image = options[:image]
-      @execution_role_arn_input = get_execution_role_arn_input
       # copy the files
       puts "Setting up ufo project..."
       exclude_pattern = File.exist?("#{Ufo.root}/Dockerfile") ?

data/lib/ufo/sequence.rb

@@ -17,22 +17,6 @@ module Ufo
       File.basename(Dir.pwd)
     end
 
-    def get_execution_role_arn_input
-      return @execution_role_arn if @execution_role_arn
-
-      if @options[:execution_role_arn]
-        @execution_role_arn = @options[:execution_role_arn]
-        return @execution_role_arn
-      end
-
-      return unless @options[:launch_type] == "fargate"
-      # execution role arn required for fargate
-      puts "For fargate ECS tasks an ECS Task Execution IAM Role is required. "
-      puts "More details here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html"
-      print "Please provide a execution role arn role for the ecs task: "
-      @execution_role_arn = $stdin.gets.strip
-    end
-
     def override_source_paths(*paths)
       # Using string with instance_eval because block doesnt have access to
       # path at runtime.

data/lib/ufo/stack/builder/base.rb

@@ -33,21 +33,21 @@ class Ufo::Stack::Builder
       settings_key = "#{type}_security_groups".to_sym
       group_ids = Ufo::Setting::SecurityGroups.new(@service, settings_key).load
       # no security groups at all
-      return if !managed_security_groups_enabled? && group_ids.blank?
+      return if !managed_security_groups? && group_ids.blank?
 
       groups = []
       groups += group_ids
-      groups += [managed_security_group(type.to_s.camelize)] if managed_security_groups_enabled?
+      groups += [managed_security_group(type.to_s.camelize)] if managed_security_groups?
       groups
     end
 
     def managed_security_group(type)
-      logical_id = managed_security_groups_enabled? ? "#{type.camelize}SecurityGroup" : "AWS::NoValue"
+      logical_id = managed_security_groups? ? "#{type.camelize}SecurityGroup" : "AWS::NoValue"
       {Ref: logical_id}
     end
 
-    def managed_security_groups_enabled?
-      managed = settings[:managed_security_groups_enabled]
+    def managed_security_groups?
+      managed = settings[:managed_security_groups]
       managed.nil? ? true : managed
     end
   end

data/lib/ufo/stack/builder/resources/ecs.rb

@@ -56,6 +56,10 @@ class Ufo::Stack::Builder::Resources
       }
 
       props[:TaskDefinition] = @rollback_definition_arn ? @rollback_definition_arn : {Ref: "TaskDefinition"}
+      if @container[:fargate]
+        props[:LaunchType] = "FARGATE"
+        props[:NetworkConfiguration][:AwsvpcConfiguration][:AssignPublicIp] = "ENABLED" # Works with fargate but doesnt seem to work with non-fargate
+      end
 
       props
     end

data/lib/ufo/stack/builder/resources/security_group/ecs.rb

@@ -1,7 +1,7 @@
 module Ufo::Stack::Builder::Resources::SecurityGroup
   class Ecs < Base
     def build
-      return unless managed_security_groups_enabled?
+      return unless managed_security_groups?
 
       {
         Type: "AWS::EC2::SecurityGroup",

data/lib/ufo/stack/builder/resources/security_group/ecs_rule.rb

@@ -1,7 +1,7 @@
 module Ufo::Stack::Builder::Resources::SecurityGroup
   class EcsRule < Base
     def build
-      return unless managed_security_groups_enabled?
+      return unless managed_security_groups?
       return unless @elb_type == "application"
 
       {

data/lib/ufo/stack/builder/resources/security_group/elb.rb

@@ -1,7 +1,7 @@
 module Ufo::Stack::Builder::Resources::SecurityGroup
   class Elb < Base
     def build
-      return unless managed_security_groups_enabled?
+      return unless managed_security_groups?
       return unless @elb_type == "application"
 
       {

data/lib/ufo/version.rb

@@ -1,3 +1,3 @@
 module Ufo
-  VERSION = "5.0.0"
+  VERSION = "5.0.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: ufo
 version: !ruby/object:Gem::Version
-  version: 5.0.0
+  version: 5.0.1
 platform: ruby
 authors:
 - Tung Nguyen
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2020-05-29 00:00:00.000000000 Z
+date: 2020-06-28 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: aws-logs
@@ -376,6 +376,7 @@ files:
 - docs/_docs/settings/aws_profile.md
 - docs/_docs/settings/cfn.md
 - docs/_docs/settings/cluster.md
+- docs/_docs/settings/manage-security-groups.md
 - docs/_docs/settings/network.md
 - docs/_docs/ssl_errors.md
 - docs/_docs/structure.md
@@ -394,6 +395,7 @@ files:
 - docs/_docs/upgrading.md
 - docs/_docs/upgrading/upgrade4.5.md
 - docs/_docs/upgrading/upgrade4.md
+- docs/_docs/upgrading/upgrade5.md
 - docs/_docs/variables.md
 - docs/_includes/about.html
 - docs/_includes/cfn-customize.md
@@ -512,6 +514,8 @@ files:
 - exe/ufo
 - lib/template/.env
 - lib/template/.secrets
+- lib/template/.ufo/iam_roles/execution_role.rb
+- lib/template/.ufo/iam_roles/task_role.rb
 - lib/template/.ufo/params.yml.tt
 - lib/template/.ufo/settings.yml.tt
 - lib/template/.ufo/settings/cfn/default.yml.tt