Confirmed users
12
edits
Web Operations/Reference Specification/Platform Blueprint: Difference between revisions
Web Operations/Reference Specification/Platform Blueprint (view source)
Revision as of 16:35, 1 August 2014
, 1 August 2014no edit summary
(Created page with "=== Networking === Each app functions in a completely isolated private network. === Instances === Instances connect to ports which are in turn connected to networks. === Im...") |
No edit summary |
||
| Line 1: | Line 1: | ||
== Networking == | |||
Each app functions in a completely isolated private network. | Each app functions in a completely isolated private network. | ||
== Instances == | |||
Instances connect to ports which are in turn connected to networks. | Instances connect to ports which are in turn connected to networks. | ||
== Images == | |||
A hybrid-golden image approach is used for building base images. To build an image, | A hybrid-golden image approach is used for building base images. To build an image, | ||
a tool called [https://github.com/openstack/diskimage-builder diskimage-builder] | a tool called [https://github.com/openstack/diskimage-builder diskimage-builder] | ||
| Line 65: | Line 64: | ||
before attempting to upload the image to glance. | before attempting to upload the image to glance. | ||
== Service Configuration == | |||
The services which are installed on instances are defined in the service matrix | The services which are installed on instances are defined in the service matrix | ||
(TODO, link to service matrix). A service will be implemented by two halves: a | (TODO, link to service matrix). A service will be implemented by two halves: a | ||
| Line 113: | Line 112: | ||
* Front end definitions should only use user defined resource definitons | * Front end definitions should only use user defined resource definitons | ||
== The Service Matrix == | |||
All services listed in the service matrix will have a single corresponding back | All services listed in the service matrix will have a single corresponding back | ||
end module. For each service there can be multiple front end implmentations. For | end module. For each service there can be multiple front end implmentations. For | ||
| Line 149: | Line 148: | ||
|} | |} | ||
=== Location of puppet code === | |||
Fully featured back end implementations of services will always live in external | Fully featured back end implementations of services will always live in external | ||
git repositories. There is a need for a centeral puppet repository where front | git repositories. There is a need for a centeral puppet repository where front | ||
| Line 169: | Line 168: | ||
''This section needs more thought'' | ''This section needs more thought'' | ||
== Consuming Services == | |||
An application consumes application services. The format by which comsumption | An application consumes application services. The format by which comsumption | ||
described is via the <code>SoftwareConfig</code> and <code>SoftwareDeploy</code> | described is via the <code>SoftwareConfig</code> and <code>SoftwareDeploy</code> | ||
| Line 215: | Line 214: | ||
</code> | </code> | ||
== | == Application Data == | ||
Early prototypes feed data directly into SoftwareDeployments via environment | |||
variables. We eventually want to replace heat directly passing variables with | |||
heat passing data to zookeper and then configuration actions consuming | |||
configuration data from zookeeper. | |||
== Installing the Application Code == | |||
Scripts will have an install script in their application code that will be run | |||
when the code is installed onto an instance. | |||
== Deploying Code Changes to the Application == | |||
Captain Shove will be used to push changes to applications. | |||
== Design Principles == | |||