Deployment locations

Use deployment locations to specify where the network automation software deploys resources when the resources are instantiated. Deployment locations are associated with a specific infrastructure type such as Red Hat® OpenShift®, Kubernetes, AWS, Azure, OpenStack, and others.

Deployment locations are also associated with the Brent resource manager. Brent uses the deployment location and the name of a resource to discover the resource. Depending on the context, deployment locations might be referred to as data centers, projects (in OpenStack), or availability zones (also in OpenStack).

The properties of a deployment location include an infrastructure type. The infrastructure type must be one of the types that are specified in the infrastructure section of the relevant resource descriptor. The infrastructure type in the resource descriptor specifies which driver a resource must use for a specific lifecycle transition. The infrastructure type in the deployment location must match the infrastructure type of the lifecycle transition. Lifecycle transitions can be associated with more than one type of infrastructure. For more information, see the infrastructure section in Resource descriptors.

The properties of a deployment location also include infrastructure-specific properties. When the network automation software runs a lifecycle step, the resource properties and the infrastructure-specific properties are both sent to Brent. In this way, the driver has access to two sets of properties. You can reference both sets of properties.

A resource can have only one deployment location, but an assembly can deploy resources into more than one deployment location. You can use this feature to deploy resources into multiple places at the same time. This feature also means that if you want to, for example, move a resource from one location to another, all you need to do is update the deployment location.

Resource drivers run lifecycle and operation requests from the orchestration component. Resource drivers run independently of the orchestration component and conform to the Resource drivers API.

After you onboard resource drivers during the installation process, you must set up a deployment location to the driver to be used.

You might want to take some time to plan the structure of your deployment locations. For example, you might want to consider the following points:

• Whether to use multiple deployment locations for different technologies of different locations. For example, you might want separate AWS or Azure deployment locations, or you might want to use different deployment locations to represent different geographic locations.
• Whether to store some of the data that is required for the automation in the deployment location rather than in the resources that are being deployed. The values in deployment locations are stored securely, so you might want to use them to store secure information such as keys and passwords. For example, if your deployment location uses the OpenStack infrastructure type, you can store the security key for OpenStack in the deployment location.

For more information about how to create deployment locations, see Modifying deployment locations.