Tuono provides configuration abstraction for cloud providers, making your infrastructure provisioning truly portable. Our portable cloud infrastructure definition language lets you describe what you need using well-known concepts such as networks, subnets, disks, virtual machines, and load balancers. You describe the infrastructure that you need, and Tuono takes care of how those resources are created and managed.
Understanding these concepts will help you acclimate to the Tuono solution.
We typed in "cloud_provider" so many times, it actually started to hurt! We needed shorter term for cloud provider that not only could describe one, but also any other infrastructure provider - on-premises or cloud. We call it a venue, and you will see venue used throughout the Tuono product and documentation in place of "cloud provider".
Details on features supported for each resource type can be found in the Schema Reference.
Venue permissions refer to the AWS account and Azure subscription service account(s) that allow Tuono to create, modify and delete infrastructure within the venue. See our knowledge base articles on how to perform this one-time venue setup:
Venue Credentials are the keys that allow Tuono to access your AWS Account(s) or Azure Subscription(s). These credentials are available to all members of your Organization. However you choose to manage your environment(s), all infrastructure objects within an environment can be created, modified and deleted independently from other environments.
Your credentials are sacred, which is why we use a dedicated Vault instance for each paid subscriber. The vault instance holds provisioning secrets necessary to deploy blueprints safely and securely. Using separate vault instances is part of our overall defensive security strategy, which includes:
Protecting secrets in transit.
Protecting secrets while stored.
Ensuring secrets are never logged.
Ensuring no Tuono employee can access secret content that is not theirs.
Using enclave strategies to protect secrets during use, and wipe them after use.
A Blueprint is a reusable, abstract definition of infrastructure definitions. You create one or more blueprints containing a description of what resources need to exist. Blueprints can be customized for different situations using variables, making them reusable not only across different use cases, but even across different venues. Examples of blueprints:
A blueprint for a corporate network.
A blueprint for a mongo database cluster.
A blueprint for a custom web application.
Our own tutorial has a blueprint.
Using variables allows us to customize blueprints for a wide variety of environments without creating a new blueprint. This increases the reusability of a blueprint. An example might be a variable for cores, and perhaps a default value for the the most common value, e.g. 2
variables:cores:description: Define the core count for this VM.type: integerdefault: 2....vm:my_machine:cores: (( cores ))
The blueprint development view allows users to iteratively make changes and verify a Blueprint under construction. It provides complete control over environment operations, versioning and drafts from a single pane workflow.
An environment defines a unique namespace in which you can deploy venue resources described in one or more blueprints. With an environment, you combine:
The venue and credentials (account or subscription) to use.
The blueprints to deploy.
The variables that customize the blueprints, if any.
Once all the information is provided, you can apply the environment to your venue. You can upgrade your blueprints and continue to apply them to modify your environment. When you no longer need the environment, you can destroy it.
You may find silly comments scattered throughout the documentation. This is normal. Don't Panic.
In the Italian language, Tuono means thunder. Can you hear the disruption? Tuono is also a high performance motorcycle, something a couple of our founders apparently dream about at night (and probably during the day too!)