ufo 4.4.3 → 4.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA1:
-  metadata.gz: 2f3d71a890dc7dac92751517b4aecc81cbaf37d8
-  data.tar.gz: 00b13ce41a1175c882fef6fbc0d3df52ac0b5636
+SHA256:
+  metadata.gz: 4df81518380cf8da66e2b72a1ff6fd5a95e900d79d87c419a1517b2cd3386df8
+  data.tar.gz: a69061cdbb294e3d2a63a171f40d6b5f9ee2a28be1a3b18e54425c53b590d010
 SHA512:
-  metadata.gz: 70244a2dcc77c9bee7b1586745490fcff58cc7056be81597dfb3434c09caad7831909927419bd4920b490adb57ede2e1335f7ba6c5c8a2444fe14aab07ce5da4
-  data.tar.gz: ec407342a7d7c7520d6c33d99d1df53731a06692f238f5dacde6c774b4bac0a50737f7b16a0e25ed4d3445f6f0148738f584f8c230db66f6a2ca8f3ad95fe5f3
+  metadata.gz: 946b3c2c6cdbe86d537627741beeb0edbb17981c7b0553c7d9e148da9caff60ea85893579f17bf7e3e180321f7a1004825464b11305d2cf5e456adc324c3d566
+  data.tar.gz: 49c8121c9340643c0e3fdc34e56fd4912638c87a41b8f53523d2562c498f7b971a5f0e042e98ef82f53a08db7967f946b92b3213cf2113b3b94952cbfaf81e98

data/.gitignore

@@ -18,3 +18,4 @@ test/version_tmp
 tmp
 
 .ruby-version
+Gemfile.lock

data/CHANGELOG.md

@@ -3,6 +3,12 @@
 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.
 
+## [4.5.0]
+- #78 append_ufo_env to stack name, new default
+- #79 service_cluster map setting
+- #80 introduce Docckerfile.erb and dockerfile_variables.yml
+- #81 update to zeitwerk for autoloading
+
 ## [4.4.3]
 - fix edge case when target group name is too long: only occurs with UFO\_FORCE\_TARGET_GROUP mode
 - stdout sync true for improved codebuild status

data/docs/_docs/conventions.md

@@ -1,6 +1,6 @@
 ---
 title: Conventions
-nav_order: 18
+nav_order: 19
 ---
 
 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: 29
+nav_order: 31
 ---
 
 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

@@ -0,0 +1,60 @@
+---
+title: Dynamic Dockerfile.erb
+nav_order: 32
+---
+
+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 as-is.
+
+## Example
+
+The Dockerfile.erb has access to variables defined in `dockerfile_variables.yml`. The variables should defined underneath an `UFO_ENV` key. Examples:
+
+.ufo/settings/dockerfile_variables.yml:
+
+```yaml
+---
+development:
+  base_image: 112233445566.dkr.ecr.us-west-1.amazonaws.com/demo/sinatr:base-2019-06-10T03-22-34-f91cdd350
+production:
+  base_image: 778899001122.dkr.ecr.us-west-1.amazonaws.com/demo/sinatr:base-2019-06-10T03-23-34-abccddxzy
+```
+
+Note, the `base_image` key is automatically updated by [ufo docker base](http://ufoships.com/reference/ufo-docker-base/) when Dockerfile.erb exists.
+
+Here's what the `Dockerfile.erb` looks like:
+
+```Dockerfile
+FROM <%= @base_image %>
+# ...
+CMD ["bin/web"]
+```
+
+When `UFO_ENV=production`, it'll produced the following.
+
+Dockerfile:
+
+```Dockerfile
+FROM 778899001122.dkr.ecr.us-west-1.amazonaws.com/demo/sinatr:base-2019-06-10T03-23-34-abccddxzy
+# ...
+CMD ["bin/web"]
+```
+
+The above example is demonstrates a good use-case. You may want a different FROM statement in your Dockerfile on a per-environment basis.  In this case, we're using different ECR repositories from different AWS accounts for development vs production. The FROM statement changes based on which AWS account you're using.
+
+## General Steps
+
+The generl steps are:
+
+1. Create a Dockerfile.erb with `<%= @base_image %>`
+2. Run: `ufo docker base` to generate `dockerfile_variables.yml`
+3. Run: `ufo docker build` to build a Dockerfile. Note, the `ufo ship` command also builds the Dockerfile.
+
+Remember when using the Dockerfile.erb, the Dockerfile is generated and overwritten. So you should update the Dockerfile.erb.
+
+## Build Args
+
+Why not use [build args](https://www.jeffgeerling.com/blog/2017/use-arg-dockerfile-dynamic-image-specification)?
+
+Ufo uses a yaml file so users will not have to remember to provide the build arg. It is also easy to update the `dockerfile_variables.yml` with the `ufo docker base` command.
+
+{% include prev_next.md %}

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

@@ -1,6 +1,6 @@
 ---
 title: ECS Network Mode
-nav_order: 24
+nav_order: 26
 ---
 
 ## Pros and Cons: awsvpc vs bridge network mode

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

@@ -1,6 +1,6 @@
 ---
 title: Load Balancer Support
-nav_order: 22
+nav_order: 24
 ---
 
 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: 28
+nav_order: 30
 ---
 
 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/redirection-support.md

@@ -1,6 +1,6 @@
 ---
 title: Redirection Support
-nav_order: 27
+nav_order: 29
 ---
 
 ## Application Load Balancers

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

@@ -1,6 +1,6 @@
 ---
 title: Route53 Support
-nav_order: 26
+nav_order: 28
 ---
 
 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:

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

@@ -1,6 +1,6 @@
 ---
 title: Security Groups
-nav_order: 23
+nav_order: 25
 ---
 
 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,6 +1,6 @@
 ---
 title: SSL Support
-nav_order: 25
+nav_order: 27
 ---
 
 You can configure SSL support by uncomment the `listener_ssl` option in `.ufo/settings/cfn/default.yml`.  Here's an example:

data/docs/_docs/faq.md

@@ -1,6 +1,6 @@
 ---
 title: FAQ
-nav_order: 41
+nav_order: 44
 ---
 
 **Q: Is AWS ECS Fargate supported?**
@@ -8,7 +8,7 @@ nav_order: 41
 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/params.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).
 

data/docs/_docs/helpers.md

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

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

@@ -1,28 +1,24 @@
 ---
 title: Auto Completion
-nav_order: 40
+nav_order: 43
 ---
 
 Ufo supports bash auto-completion.  To set it up add the following to your `~/.profile` or `.bashrc`:
 
-```
-eval $(ufo completion_script)
-```
+    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]
-```
+    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,6 +1,6 @@
 ---
 title: Automated Clean Up
-nav_order: 39
+nav_order: 42
 ---
 
 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: 34
+nav_order: 37
 ---
 
 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.
@@ -20,13 +20,13 @@ You can override the source template that ufo uses by creating your own and savi
 
 ## CloudFormation Stack Name
 
-The CloudFormation stack name is based on the cluster, service name and UFO_ENV_EXTRA.  A few examples help demonstrate:
+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 | development-demo-web
-ufo ship demo-web -\-cluster dev | dev-demo-web
-UFO_ENV_EXTRA=2 ufo ship demo-web -\-cluster dev | development-demo-web-2
+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
 

data/docs/_docs/more/migrations.md

@@ -1,26 +1,20 @@
 ---
 title: Database Migrations
-nav_order: 38
+nav_order: 41
 ---
 
 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:
 
-```sh
-ufo task demo-web -c bundle exec rake db:migrate
-```
+    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.
 
-```sh
-ufo task demo-web -c bin/migrate
-```
+    ufo task demo-web -c bin/migrate
 
 The `bin/migrate` script can look like this:
 
-```bash
-#!/bin/bash
-bundle exec rake db:migrate
-```
+    #!/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:
 

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

@@ -1,6 +1,6 @@
 ---
 title: Run in Pieces
-nav_order: 36
+nav_order: 39
 ---
 
 The `ufo ship` command goes through a few stages:
@@ -13,23 +13,17 @@ The CLI exposes many of these steps as separate commands.  Here is now you would
 
 Build the docker image first.
 
-```bash
-ufo docker build
-ufo docker push # pushes last built image to a registry
-```
+    ufo docker build
+    ufo docker push # pushes last built image to a registry
 
 Build the task definitions.
 
-```bash
-ufo tasks build    # generates task definition json files to .ufo/output
-ufo tasks register # registers all genreated task definitions .ufo/output to ECS
-```
+    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.
 
-```bash
-ufo deploy demo-web
-```
+    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`.
 

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

@@ -1,29 +1,24 @@
 ---
 title: Run Single Task
-nav_order: 37
+nav_order: 40
 ---
 
 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
-```
+    ufo task demo-web -c bundle exec rake db:migrate
 
 At the end of the output you should see you the task ARN:
 
-```sh
-$ 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
-$
-```
+
+    $ 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:
 
-```sh
-aws ecs describe-tasks --tasks arn:aws:ecs:us-west-2:994926937775:task/a0e4229d-3d39-4b26-9151-6ab6869b84d4
-```
+    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.
 

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

@@ -1,6 +1,6 @@
 ---
 title: Stuck CloudFormation
-nav_order: 35
+nav_order: 38
 ---
 
 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: 33
+nav_order: 36
 ---
 
 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: 43
+nav_order: 46
 ---
 
 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/settings.md

@@ -43,69 +43,12 @@ Setting  | Description
 `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
 
-## ECS Cluster Convention
-
-Normally, the ECS cluster defaults to whatever UFO_ENV is set to by [convention]({% link _docs/conventions.md %}).  For example, when `UFO_ENV=production` the ECS Cluster is `production` and when `UFO_ENV=development` the ECS Cluster is `development`.  There are several ways to override this behavior. Let's go through an example:
-
-By default, these are all the same:
-
-```sh
-ufo ship demo-web
-UFO_ENV=development ufo ship demo-web # same
-UFO_ENV=development ufo ship demo-web --cluster development # same
-```
-
-If you use a specific `UFO_ENV=production`, these are the same
-
-```
-UFO_ENV=production ufo ship demo-web
-UFO_ENV=production ufo ship demo-web --cluster production # same
-```
-
-Override the convention by explicitly specifying the `--cluster` option in the CLI.
-
-```sh
-ufo ship demo-web --cluster custom-cluster # override the cluster
-UFO_ENV=production ufo ship demo-web --cluster production-cluster # override the cluster
-```
-
-Override the convention by setting the cluster option in the `settings.yml` file, so you won't have to specify the `--cluster` option in the command repeatedly.
-
-```yaml
-development:
-  cluster: dev
-
-production:
-  cluster: prod
-```
-
-
 ## AWS_PROFILE support
 
-An interesting option is `aws_profile`.  Here's an example:
-
-```yaml
-development:
-  aws_profile: dev_profile
-
-production:
-  aws_profile: prod_profile
-```
-
-This provides a way to tightly bind `UFO_ENV` to `AWS_PROFILE`.  This prevents you from forgetting to switch your `UFO_ENV` when switching your `AWS_PROFILE` thereby accidentally launching a stack in the wrong environment.
+An interesting option is `aws_profile`.  This allows you to tightly connect an AWS_PROFILE to a UFO_ENV. The details are in the [Settings AWS_PROFILE docs]({% link _docs/settings/aws_profile.md %}).
 
+## ECS Cluster Convention
 
-AWS_PROFILE | UFO_ENV | Notes
---- | --- | ---
-dev_profile | development
-prod_profile | production
-whatever | development | default since whatever is not found in settings.yml
-
-The binding is two-way. So:
-
-    UFO_ENV=production ufo ship # will deploy to the AWS_PROFILE=prod_profile
-    AWS_PROFILE=prod_profile ufo ship # will deploy to the UFO_ENV=production
-
-This behavior prevents you from switching `AWS_PROFILE`s, forgetting to switch `UFO_ENV` and then accidentally deploying a production based docker image to development and vice versa because you forgot to also switch `UFO_ENV` to its respective environment.
+Normally, the ECS cluster defaults to whatever UFO_ENV is set to by [convention]({% link _docs/conventions.md %}).  For example, when `UFO_ENV=production` the ECS Cluster is `production` and when `UFO_ENV=development` the ECS Cluster is `development`.  There are several ways to override this behavior. This is detailed in the [Settings Cluster docs]({% link _docs/settings/cluster.md %}).
 
 {% include prev_next.md %}