Skip to main content

Anatomy of an environment

If you initialized an environment in the previous step, you should now have a folder structure that looks something like this in your project folder:

.xlrte
β”‚
└───config
β”‚
└───environments
β”‚ β”‚
β”‚ └───[environment name]
β”‚ β”‚ resources.yaml
β”‚ β”‚ versions.yaml
β”‚ └───pubkeys
β”‚ β”‚ β”‚ [name & email].asc
β”‚ └───secrets
β”‚
└───services
β”‚ [service.yaml-files go here!]

A minimal resources.yaml should look something like this:

context: [gcp project you chose]
region: [gcp region]
state_store: [gcp bucket for storing environment state]

xlrte follows a folder convention, where:

Folder/FilePurpose
config/environmentscontains the separate environment specific configurations in sub-folders named after each environment.
config/environments/[env]/resources.yamlcontains basic environment information and customizations to the resources used (such as virtual CPUs, memory, storage etc). For now, you do not need to concern yourself with any configuration other than context and region, as by default we provide sensible defaults for a low-traffic, cheap-to-run development environment.
config/environments/[env]/versions.yamlcontains service versions to deploy for this environment. This file is not mandatory, and the -v cli argument can be used instead to define a version for services. versions.yaml is however necessary if you want to have different versions of the numerous services you might deploy.
config/environments/[env]/secretscontains all secrets for an environment, encrypted at rest. Run xlrte secret help to get more information on how to use secrets from the cli.
config/servicesis the folder that contains all services and their dependency definitions, independent of environment.