Existing Infrastructure

No Touchy!

Overview

It is possible to refer to already existing infrastructure when you are designing a blueprint. Tuono provides two ways to reference existing infrastructure:

1. Imported infrastructure will identify If a resource already exists in the venue and allow you to reference it in the blueprint. This is a new feature that is not available for all blueprint objects (yet!), but for objects it is available, it is the simplest way to reference your infrastructure.

2. Defining an object and marking it as readonly will ensure compliance of that object with its definition and allow you to use it, but will not allow you to make changes to it.

Consider a scenario where you have a virtual network already established and you want to add another subnet to it along with some resources. For this to work properly your infrastructure does need to meet the following requirements:

1. You must have read access to those resources. Tuono will not change them, but we will inspect them when necessary to make decisions about how to proceed with provisioning.

2. If you are importing the object, you must know its ID and its location OR

3. If you are defining the object as readonly, it must have a name (some AWS resources are not required to have a name).

Imported Resources

Imported resources are defined in an import directive mirroring the blueprint structure. The desired object will be looked for on the venue and, if found, will be available for use. Anything the object depends on (e.g. the network a subnet belongs to) will also be imported.

Imported objects are all imported as readonly and are NOT modifiable.

The schema reference for imports defines what objects are importable. After applying an environment including import directives, you can view our modeling of your resources in Inventory.

AWS Import

AWS imports objects with the object ID. Networking ID's are found in the AWS VPC console.

AWS VPC ID's

AWS Subnet ID's

Example of importing an AWS subnet

---
import:
  networking:
    subnet:
      my-subnet:
        id: subnet-12345678
        region: aws

Azure Import

AWS imports objects with the object subscription ID. Networking ID's can be found in the Virtual Network overview Json View in the Azure portal.

The Resource JSON will provide you a direct copy of the Virtual Network ID. Subnet ID's you wish to reference in your Blueprint are under the Virtual Network JSON output.

Example of importing an Azure subnet

---
import:
  networking:
    subnet:
      my-subnet:
        id: /subscriptions/eeeeeeee-eeee-eeee-eeee-eeeeeeeeeeee/resourceGroups/my-folder/providers/Microsoft.Network/virtualNetworks/my-network

Read-Only Resources

If you add the readonly property to a resource in a blueprint, the Tuono Provisioning Engine will treat the resource as something that must already exist to provision successfully. Here are some additional rules you will need to know about readonly resources:

1. The Tuono Schema defines required fields, for example a networking.network requires a range to be set. In our system today, you will need to set these required properties along with the readonly property.

2. The value of these required properties does not have to be an exact match. If the provisioning engine detects a difference between the blueprint's required properties and the actual properties in the venue, you will get a warning that indicates the discrepancy, but no action will be taken.

3. [Azure Only]: Existing resources in Azure will be in a resource group. If that resource group is different than the Tuono folder (remember that they are the same concept), you will need to define an additional folder in your blueprint, or you may choose to make an "read only resources" blueprint.

AWS Behavior

When we encounter a readonly resource on AWS, we employ the following lookup strategy:

1. We attempt to locate the resource by matching the type and name, and scoping the lookup to the folder. If this locates one and only one resource, we consider it found. This allows us to locate resources that Tuono created previously. This is in fact our standard lookup behavior.

2. We attempt to locate the resource by matching the type and name, and explicitly ignore any resource that was previously created by Tuono. If this locates one and only one resource, we consider it found. This allows us to locate resources that you may have created manually or with another provisioning product.

3. If the results are ambiguous or nothing is found, an error occurs.

If the resource was not created by Tuono you may add it directly to your blueprint with the readonly property set, and it will be located due to lookup rule #2 above. We recommend that you maintain a separate blueprint for "read only resources" to keep them conceptually separate from your reusable blueprint. This is the most common situation for readonly resources.

If the resource was created by Tuono and is located in another folder, you should create an "read only resources" blueprint and define the other folder and resources all as readonly, and they will be located due to lookup rule #1 above.

Azure Behavior

On Azure all resources are inherently inside a resource group, which corresponds to a Tuono folder. To locate existing infrastructure on Azure you must define the resource as well as the folder that it is in. Both of them can be marked as readonly. We recommend that you maintain a separate blueprint for "read only resources" to keep them conceptually separate from your reusable blueprint.

Example

The following "read only resources" blueprint for Azure, when added to an environment, defines an existing network that cannot be modified (note: adding a subnet to a network is not considered a modification of the network):

# my "read only" blueprint
---
location:
  folder:
    my_prod_rg:                  # name of existing resource group
      name: my_prod_rg           # hard code the existing name
      readonly: true             # it already exists
      region: my-region          # use the region from your other blueprint

networking:
  network:
    my_prod_net:                 # name of existing virtual network
      name: my_prod_net          # hard code the existing name
      folder: my_prod_rg         # the resource group of the existing network
      readonly: true             # it already exists
      range: 10.0.0.0/16         # required, but does not have to match

Then if you combine that "read only resources" blueprint with another one, you can manage your own subnet (and other contents) on a network that was already in place:

# my "new stuff" blueprint
---
location:
  region:
    my_new_region:
      country: USA
      area: northwest
  folder:
    my_new_rg:
      region: my_new_region

networking:
  subnet:
    myappnet:
      folder: my_new_rg
      range: 10.0.77.0/24
      network: my_prod_net       # defined in "read only resources" blueprint

For more information on multiple regions or resource pools, see the section "Resource Placement".