An application at runtime. This is a collection of all the
Components of an application. Think of this as the running application including all the stuff it relies on (databases, load balancer setup, etc.). Every Assembly has at least one
A part of your application that you want to be able to manage through Solum (start, pause, resume, delete, etc.). These are grouped into an
Something offered by the platform which can be referenced as part of the deployment plan. These often become
components when the application is deployed. Some services will run / host / be configured by artifacts supplied by the user (e.g. a database initialised with a SQL script, or a web container hosting a WAR file), whereas some will not require any such artifact (e.g. an object store). Services may run in a single OS container, or they might run in multiple OS containers (elastic or otherwise), or they might be completely external.
Sensor resource represents dynamic data that can be collected from a resource through the API. For example, statistics about the access rate of a resource (usually a
Component). Sensors can be added to
Operation resource represents an action that can be taken on a resource through the API. Operations can be added to
Deployment Unit: (or OS container ?):
A deployment unit (DU) is a unit of deployment for the application being deployed into an
Assembly. For example, if Solum is configured to use containers for deploying application code, then the a DU would refer to a container instance. A deployment unit could be a Docker container, an LXC container, a VM, or something else. (NOTE: I've suggested "OS Containers" instead, as that means something to me in a way that "DU" does not. BTW my reading of the word "container" is a web container, not an OS container!)
A description of how to generate an
Assembly to run an application. (Sometimes called a deployment plan.)
A Solum service that builds/tests the
Application in accordance with the instructions in the
Plan to produce an
Artifact for deployment. The
Artifact generated will normally be a container image to be used within the
Repo: A hosted location where the source code for an application is stored. It may be internal to Solum, or externally hosted through a supported SCM API.
An application represents the raw ingredients of an application, i.e. the things which become an Assembly. It consists of a Deployment
Plan plus a set of artifacts or a code repository and build instructions. It may also link to the assemblies generated from it (which may be more than one in different environments -- e.g. dev/staging/prod -- when we get in to lifecycle management).
- Register: registers a new application in Solum and associates it with the user ( no application code is copied; no deployment is performed, yet).
- Deploy: deploys the application bits and generates a running application in an
Assembly. Associates dependent services as needed. Builds the application bits from code if required.
- Build: builds the application, but does not create an
Assemblyto run it in. This is used for build-once-deploy-many use cases.