All About DragonOps
While our quickstart is the fastest way to get started, there’s a lot more to DragonOps if you want to learn it! These docs describe some of the high-level ideas you’ll come across when deploying your applications with DragonOps.
Contents
Group v Application
In DragonOps, we’ve separated out infrastructure into two management parts: groups and applications.
Group
A group is used to organize infrastructure that are not directly related to applications. While your applications with utilize the infrastructure deployed in groups, they do not only belong to a single application. Group resources are ones that are shared across multiple applications. You store the configuration for these resources in a DragonOps config yaml file. We’ll go over some examples of what this looks like below.
Groups contain a variety of resources that you can customize and configure however you want. By default, and to cost-optimize, DragonOps creates an initial group (named preprod) for you, to showcase that a single group can actually house multiple environments of your application!
This is what that looks like:
# By default, DragonOps creates a single group (default is preprod) that can be used for multiple environments for cost-optimization.
preprod_group:
account: "035473786027"
region: us-east-1
type: group
name: preprod
# DragonOps creates a main cluster that can house multiple environments for cost-optimization.
main_network:
type: network
name: main
cidr: 10.100.0.0/16
# DragonOps creates a main network that can house multiple clusters for cost-optimization.
main_cluster:
type: cluster
name: main
network: preprod_group.main_network
grafana:
enabled: true
subdomain: monitoring
# DragonOps creates both a dev and stage environment in the preprod group, so you have two environments to deploy applications to right away.
dev_environment:
type: environment
name: dev
cluster: preprod_group.main_cluster
# DragonOps creates both a dev and stage environment in the preprod group, so you have two environments to deploy applications to right away.
stage_environment:
type: environment
name: stage
cluster: preprod_group.main_cluster
Alternatively, if you don’t mind a little more cost overhead, you can choose to instead have a group per environment, or even a single preprod group, with separate networks and/or clusters for each environment you need.
Here’s what a single group, with separate networks/clusters/environments would look like:
# We create a single group (preprod) to logically contain all our lower environments/bse infra resources.
preprod_group:
account: "035473786027"
region: us-east-1
type: group
name: preprod
# Here, we create a dev network, cluster, and environment.
dev_network:
type: network
name: main
cidr: 10.100.0.0/16
dev_cluster:
type: cluster
name: main
network: preprod_group.dev_network
grafana:
enabled: true
subdomain: monitoring
dev_environment:
type: environment
name: dev
cluster: preprod_group.dev_cluster
# Here, we create a stage network, cluster, and environment, which is more cost but decouples environments completely.
stage_network:
type: network
name: main
cidr: 10.100.0.0/16
stage_cluster:
type: cluster
name: main
network: preprod_group.stage_network
grafana:
enabled: true
subdomain: monitoring
stage_environment:
type: environment
name: dev
cluster: preprod_group.stage_cluster
It gets even more customizable! You can have multiple groups with any number of resources in each, and can reference resources across those groups however you’d like, giving you complete control over the organization of your infrastructure.
Here’s an example of what we mean.
Let’s say you have two teams, a data team and a backend team, and they each want to be responsible for managing their own infrastructure (or they want things decoupled so that no one is stepping on each others’ toes!).
You can have a group called backend_group and a group called data_group, each with their own isolated networks, clusters, and environments. Or, maybe for ease of inter-connectivity, the data and backend teams want to utilize the same network but have their clusters and environments completely decoupled. These teams could even have a single network in one of the groups (or it’s own group!) and each team could manage their own clusters and environments separately in two other groups.
For more specific examples (and associated config files) take a look at our docs here.
Application
An application (aka app) is used to provide configuration for the application code you want deployed. This file will have things like the port your application runs on, cpu and memory needs, as well as the environments you want to deploy your application to. You store this configuration in a DragonOps app yaml file.
By default, DragonOps will use the below configuration when you use the dragonpos app add command for the first time:
my-app:
name: my-app
type: app
port: "8080"
health_check_path: /
environments:
- environment: dev_environment
group: preprod_group
- environment: stage_environment
group: preprod_group
cpu: 0.25
memory: 1
Once your app has been added, you can customize your config file any way you’d like! You can add and remove environments, change the port your application runs on, or increase the cpu and memory needs.
We want deploying your first app to be a seamless process, so we even provide out-of-the-box CI/CD files for both Github and GitLab as well as instructions for what to do next (like how to add environment variables, and how to push your newly generated CI/CD files).
For more specific examples and full configuration options take a look at our docs here.
The DragonOps Orchestrator
One of the great features of DragonOps is the ability to start asynchronous deployment jobs without needing to wait for them to complete. This is accomplished with what we call the orchestrator. This orchestration engine is deployed to your account when you run the init command, and the code is completely open source, so you have visibility into exactly what is happening when jobs are run.
The orchestrator works by retrieving jobs from a queue (also in your account) and applying any Terraform changes you made to your DragonOps config file. The orchestrator will wait for the Terraform apply to complete, and update the status of the infrastructure (group or app-environment) so that you know when it is completed.
This diagram shows the way the orchestrator is designed to work.
