Difference between revisions of "Solum/FeatureBlueprints/Definitions"
Adrian Otto (talk | contribs) |
Alexheneveld (talk | contribs) |
||
| Line 1: | Line 1: | ||
'''Assembly:''' | '''Assembly:''' | ||
| − | + | An application at runtime. This is a collection of all the <code>Components</code> 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 <code>Component</code>. | |
'''Component:''' | '''Component:''' | ||
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 <code>Assembly</code>. | 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 <code>Assembly</code>. | ||
| − | '''Deployment Unit:''' | + | '''Service:''' |
| − | A deployment unit (DU) is a unit of deployment for the application being deployed into an <code>Assembly</code>. 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. | + | Something offered by the platform which can be referenced as part of the deployment plan. These often become <code>components</code> 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. |
| + | |||
| + | '''Deployment Unit:''' (or '''OS container''' ?): | ||
| + | A deployment unit (DU) is a unit of deployment for the application being deployed into an <code>Assembly</code>. 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!) | ||
| + | |||
| + | '''Plan''': | ||
| + | A description of how to generate an <code>assembly</code> to run an application. (Sometimes called a '''deployment plan'''.) | ||
| + | |||
| + | '''Project''' (proposed): | ||
| + | A project represents the raw ingredients of an application, i.e. the things which become an assembly. It consists of a deployment <code>plan</code> 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). | ||
'''Common actions''' | '''Common actions''' | ||
Revision as of 02:43, 29 October 2013
Assembly:
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 Component.
Component:
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 Assembly.
Service:
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.
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!)
Plan:
A description of how to generate an assembly to run an application. (Sometimes called a deployment plan.)
Project (proposed):
A project 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).
Common actions
- Init: 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.
