The behavior of ufo can be configured with a
settings.yml file. A starter project
.ufo/settings.yml file is generated as part of the
ufo init command. You can have multiple settings files. The options from the files get merged and respected in the following precedence:
- current folder - The current folder’s
.ufo/settings.ymlvalues take the highest precedence.
- user - The user’s
~/.ufo/settings.ymlvalues take the second highest precedence.
- default - The default settings bundled with the tool takes the lowest precedence.
Let’s take a look at an example
base: image: tongueroo/hi # 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. development: # cluster: dev # uncomment if you want the cluster name be other than the default # the default is to match UFO_ENV. So UFO_ENV=development means the ECS # cluster will be name 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 production: # cluster: prod # aws_profiles: # - prod_profile
The table below covers each setting:
||Docker images generated from ufo are cleaned up automatically for you at the end of
||If you are using AWS ECR, then the ECR images can also be automatically cleaned up at the end of
||By convention, the ECS cluster that ufo deploys to matches the
||If you have the
ECS Cluster Convention
Normally, the ECS cluster defaults to whatever UFO_ENV is set to by convention. 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:
ufo ship hi-web UFO_ENV=development ufo ship hi-web # same UFO_ENV=development ufo ship hi-web --cluster development # same
If you use a specific
UFO_ENV=production, these are the same
UFO_ENV=production ufo ship hi-web UFO_ENV=production ufo ship hi-web --cluster production # same
Override the convention by explicitly specifying the
--cluster option in the CLI.
ufo ship hi-web --cluster custom-cluster # override the cluster UFO_ENV=production ufo ship hi-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.
development: cluster: dev production: cluster: prod
An interesting option is
aws_profiles. Here’s an example:
development: aws_profiles: - dev-profile1 - dev-profile2 production: aws_profiles: - prod-profile
In this case, when you set the environment variable
AWS_PROFILE to switch AWS profiles in your shell, ufo picks this up and maps the
AWS_PROFILE value to the specified
UFO_ENV using the
aws_profiles option. Example:
AWS_PROFILE=dev-profile1 => UFO_ENV=development AWS_PROFILE=dev-profile2 => UFO_ENV=development AWS_PROFILE=prod-profile => UFO_ENV=production
This behavior prevents you from switching
AWS_PROFILEs and then accidentally deploying a production based docker image to development and vice versas because you forgot to also switch
UFO_ENV to its respective environment.
Pro tip: Use the <- and -> arrow keys to move back and forward.