To boostrap an environment means initializing it so that Services may be deployed on it.
The combination of a service name and a relation name.
The whole software here documented.
An Environment is a configured location where Services can be deployed onto. An Environment typically has a name, which can usually be omitted when there’s a single Environment configured, or when a default is explicitly defined. Depending on the type of Environment, it may have to be bootstrapped before interactions with it may take place (e.g. EC2). The local environment configuration is defined in the ~/.ensemble/environments.yaml file.
A Formula provides the definition of the service, including its metadata, dependencies to other services, packages necessary, as well as the logic for management of the application. It is the layer that integrates an external application component like Postgres or WordPress into Ensemble. An Ensemble Service may generally be seen as the composition of its Ensemble Formula and the upstream application (traditionally made available through its package).
A location where multiple formulas are stored. Repositories may be as simple as a directory in the local disk, or as complex as a rich smart server supporting remote searching and so on.
Relations are the way in which Ensemble enables Services to communicate to each other, and the way in which the topology of Services is assembled. The Formula defines which Relations a given Service may establish, and what kind of interface these Relations require. In many cases, the establishment of a Relation will result into an actual TCP connection being created between the Service Units, but that’s not necessarily the case. Relations may also be established to inform Services of configuration parameters, to request monitoring information, or any other details which the Formula author has chosen to make available.

Ensemble operates in terms of services.

A service is any application (or set of applications) that is integrated into the framework as an individual component which should generally be joined with other components to perform a more complex goal.

As an example, WordPress could be deployed as a service and, to perform its tasks properly, might communicate with a database service and a load balancer service.

Service Unit

A running instance of a given Ensemble Service. Simple Services may be deployed with a single Service Unit, but it is possible for an individual Service to have multiple Service Units running in independent machines. All Service Units for a given Service will share the same Formula, the same relations, and the same user-provided configuration.

For instance, one may deploy a single MongoDB Service, and specify that it should run 3 Units, so that the replica set is resilient to failures. Internally, even though the replica set shares the same user-provided configuration, each Unit may be performing different roles within th replica set, as defined by the Formula.

Service Configuration

There are many different settings in an Ensemble deployment, but the term Service Configuration refers to the settings which a user can define to customize the behavior of a Service.

The behavior of a Service when its Service Configuration changes is entirely defined by its Formula.

Provisioning Agent
Software responsible for automatically allocating and terminating machines in an Environment, as necessary for the requested configuration.
Machine Agent
Software which runs inside each machine that is part of an Environment, and is able to handle the needs of deploying and managing Service Units in this machine.
Service Unit Agent
Software which manages all the lifecycle of a single Service Unit.

Project Versions

Previous topic

Service configuration

This Page