Structure of a cloudlet

Nepho cloudlets encapsulate infrastructure components and configuration code into a distributable bundle. The majority of the logic necessary to spin up a stack is contained without the cloudlet, rather than in Nepho's core code or the code for infrastructure providers.

Overview

In the most basic case, a user utilizes nepho to:

1. Search for and download a cloudlet (either from the curated list of cloudlets or a custom location)
2. View the list of blueprints provided by the cloudlet
3. Spin up a new stack by specifying a cloudlet and one of its blueprints. A "scenario" is created that incorporates the cloudlet, blueprint, live filesystem "payload", and a deployment context incorporating various "parameters".

Vocabulary

Consult the Nepho vocabulary page for definitions of terms used in this and other documentation.

Cloudlet components

A cloudlet is a Git repository that contains:

• A cloudlet info file, in YAML format. This file contains metadata such as author, description, and version, as well as a list of parameters applicable to all blueprints in the cloudlet.
• One or more blueprints, which consist of:
  • A blueprint info file in YAML format. This file contains metadata such as name and provider, as well as a list f parameters applicable to this blueprint.
  • An infrastructure template in a location under the resources directory specified by the provider.
    • For AWS, the blueprint template is located at resources/<blueprint name>/cf.json
    • For Vagrant, the blueprint template is located at resources/<blueprint name>/Vagrantfile
  • Payload data located under payload/<blueprint name> that will be transferred to created instances. The same payload is used for all blueprints, so it should be structured to work regardless of environment. Example payload data is:
    • Platform configuration specifications (i.e. Puppet manifests, Chef cookbooks, shell scripts)
    • Build artifacts/objects
• A set of hooks that are fired at set nepho lifecycle events, such as stack creation/update/delete actions. Currently the following hooks are specified:
  • bootstrap - Prepare an instance for configuration management
  • configure - Run a configuration management process to setup the platform environment (idempotent)
  • deploy - Run any actions necessary to deploy or setup application code/build artifacts (idempotent)
  • teardown - Prepare an instance for shutdown/removal

Hooks are shell scripts located under payload/hooks.

Infrastructure templates are processed through the Jinja2 templating engine prior to being run, which allows for very sophisticated infrastructure patterns to be created from shared building blocks. The templating engine uses both the specified blueprint template file as well as any additional data located under resources/common/<provider>.

Example cloudlet filesystem structure

This tree illustrates the cloudlet filesystem structure for the nepho-example cloudlet. We encourage cloudlet authors to use the nepho-example cloudlet as a starting point for constructing your own cloudlets according to current best practices. The current clouldet format is 1, any changes to the cloudlet structure will be captured in higher-numbered cloudlet formats.

nepho-example
├── cloudlet.yaml
├── README.md
├── blueprints
│   ├── aws-single-host.yaml
│   └── vagrant-single-host.yaml
├── payload
│   ├── hooks
│   │   ├── bootstrap
│   │   ├── configure
│   │   ├── deploy
│   │   └── teardown
│   └── puppet
│       ├── Puppetfile
│       ├── manifests
│       └── templates
└── resources
    ├── aws-single-host
    │   └── cf.json
    ├── common
    │   └── aws
    └── vagrant-single-host
        └── Vagrantfile