A blueprint models an application stack in a specific configuration. Blueprints are created in YAML. Each blueprint is defined in a YAML file of its own. 

The blueprint's YAML defines a set of applications and their dependencies and provides a way to define the required infrastructure and application parameters. All blueprints' YAML files must be placed in your space's blueprints repository under your /blueprints folder.

The following is the standard structure of a blueprint:

TIP: For more information about each sequence or key-value pair, click the  icon next to it.

spec_version: 1
kind: blueprint       
metadata:             
  description: ...
  tags: ...
clouds:               
  - ...: ...
Artifacts:            
  - ...: ...
  - ...: ...
inputs:               
  - ...: ...  
  - ...: ...
applications:         
  - ...
      instances: ...    
      input_values:
        - ...: ...    
        - ...: ...
  - ...:
      target: ...     
      depends_on:     
        - ...
      input_values:
        - ...: ...
        - ...: ...

Basic Attributes

#blueprint.yaml
kind: blueprint
spec_version: 1

kind/ spec_version: These are mandatory YAML attributes classifying this file as a blueprint and specifying which version of the spec you'll be using. Currently, version 1 is the latest version available.

Metadata

#blueprint.yaml
---
kind: blueprint     
spec_version: 1
metadata:
    description: This blueprint is used for web testing
    tags:
        test_stage: integration
        product: api-gw

• Description: A description of the blueprint and its usage. The description will be visible to users when selecting the sandbox blueprint as well as in the sandbox itself.
• Tags: These tags will be applied to the sandbox and its assets on the cloud it is deployed to, in order to allow better administration, budgeting, and monitoring. In addition to the tags specified in this section, Colony will automatically tag all sandbox resources with information on the user, the space name and the blueprint name.

Clouds

clouds:
    - aws: eu-west-1

In this section the cloud account, and the region (if AWS) is specified.

NOTE: Currently it is possible to specify only one cloud account. In the future, multiple accounts in the same blueprint will be supported.

Artifacts

This section is where you define your artifacts repository. By adding artifacts to your blueprint you are making them available for your application’s deployment scripts.

artifacts:
- demoapp-server: demoapp-server/production/demoapp-server.tar.gz
- demoapp-client: demoapp-client/production/demoapp-client.tar.gz

The artifact definition consists of the application name and optionally a default value that indicates the path to the artifact file.

To learn all about working to define your blueprint artifacts, see Adding Artifacts to your Blueprint.

Applications

applications:
    - acme_web_server
    - acme_database

This section of the YAML file lists the applications that are part of the blueprint.

NOTE: You can only reference applications you have already added to your repository. To learn more about modeling applications in Colony, see Developing Applications.

Any application item listed under this section directly maps to a folder of the same name which must exist in the /applications folder of your repository. For the blueprint to be valid, for example, the space repository must contain at least the following structure:

/applications/acme_web_server/acme_web_server.yaml

/applications/acme_database/acme_database.yaml

• depends_on: applications can depend on one another. This means they should be configured and deployed in a specific order.
  To learn how to specify the dependencies between application and the dependency hierarchy, see Specifying application deployment order and dependencies.
  
  
• instances and target: CloudShell Colony allows you to deploy an application to multiple compute instances (you can add the 'instances' property) or configure all applications to run on the same instance (done by naming that target instance and assuring the applications point to the same-named instance).
  To learn how to map your applications to the required compute instances, see Mapping Applications to Compute Instances.

Redirecting traffic to certain applications using Ingress rules

Advanced scenarios call for a more flexible configuration of your sandbox environment’s application load balancer. For example, in cases where your sandbox environment includes multiple applications and you need to redirect the traffic to certain applications based on a URL path. 

Such flexibility can be added to your sandbox environment by adding Ingress rules to your blueprint. To learn more about adding Ingress rules to your sandbox environment, see Redirecting Traffic to Certain Sandbox Applications.

Inputs

The inputs section is where you declare your blueprint parameters. Parameters are defined in your blueprint and can then be passed on to applications. Any input parameter specified under the inputs section of the blueprint can be provided by the user, API or Jenkins plugin when creating a sandbox from this blueprint.

Once a parameter is defined it can optionally be assigned with a default value. Assigning a value is done in the applications section of your blueprint.

To learn more about creating input parameters and assigning them with values, see Working with Parameters.