Configuration Files
Configure apps using a single .toml
file
Config files allow you to define a BYOC application using a single .toml
file.
Under the hood, Nuon will handle keeping your configuration in sync.
Create an app
Config files are used to sync the configuration for a single app. To create an app and an example config file:
This will create an example config file named nuon.<app-name>.toml
.
Sync an App
To sync an app, and it’s configuration run:
This will sync each configuration file in the current working directory.
To sync only a single file:
Nuon uses terraform
to keep your application config in sync. If you would
like to migrate from a config file to terraform
, you can run nuon apps export-terraform
.
Export Terraform
You can export terraform
from your application configuration using:
Breaking up Config Files
As your config grows, keeping everything in a single file can become
unmanagable. You can break out each section of an app config into it’s own file
— and even re-use those sections with multiple apps — using the source
and
sources
keywords.
For example, to break out each component into it’s own file, you would the following.
When loading a component from a source, the components
prefix is not needed
for each field, like it is in the main config file.
You can also override fields from a source config file, by setting the values directly in your main toml file:
Config Variables
You can define config variables to be used throughout your config, allowing you to set variables for common values.
To add a configuration variable, add the config_vars
block to the top of your
config file:
You can then reference anywhere in your config:
Config variables do not currently work with reusable component files.
Validate
You can validate a config file using nuon apps validate
:
The CLI will automatically generate Terraform code from your config and run
terraform validate
on it and print any errors.
Reference
Input Config
Define inputs for an app using the [input]
block.
To configure a sensitive api_key
and vpc_id
input:
Inputs are not required, unless you are using a sandbox that requires inputs (such as a byovpc one).
Runner Config
Define the runner for an app using a [runner]
block.
To configure a runner for an ecs
sandbox:
Runners are a required configuration for all apps. In most cases, you do not need to customize them using environment variables.
Installer Config
Define an installer for an app using an [installer]
block.
Sandbox Config
Define the sandbox for an app using a [sandbox]
block.
To define an aws-ecs-byovpc
sandbox:
Component Config
You can define components using a [components]
block. Components must declare
a type
field and any relevant component-specific configuration.
Each component will have dependencies automatically defined based on the order in the config file. Learn more about depencencies here.
Terraform Module Component
To define a terraform module component use the
terraform_module
type.
To configure a terraform component using a connected repo:
Helm Chart Component
To define a helm chart component use the
helm_chart
type.
To configure a helm chart in a connected repo:
Docker Build Component
To define a docker build component use the
docker_build
type.
To configure a docker build component from a private repo:
Container Image Component
To define a container image component use
the container_image
type.
To configure a public container image:
To configure a container image from an ECR repo:
Job Component
To define a job component use the job
type.
To configure a job using a docker image from another component:
To configure a job using a docker image from docker hub: