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. There are can be 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/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 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:
||If you have the
||The name of the cfn profile settings file to use. Maps to .ufo/settings/cfn/NAME.yml file|
||Docker images generated from ufo are cleaned up automatically for you at the end of
||By convention, the ECS cluster that ufo deploys to matches the
||If you are using AWS ECR, then the ECR images can also be automatically cleaned up at the end of
||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. 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 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.
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.
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, 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.
Pro tip: Use the <- and -> arrow keys to move back and forward.