Home
tobami edited this page May 17, 2011
·
9 revisions
This wiki aims to design an Infrastructure Deployment Specification that defines nodes as code, and which, coupled with a Configuration Managment System, should completely define an infrastructure as code.
The first version of the spec is purposely simple, with the goal of starting a basis accepted by the community on which to further develop features. "Future Versions" below discusses other possible spec elements.
| Key | Value |
|---|---|
| name | ASCII string |
| version | version of the deployment file |
| description | Text describing the purpose of this group of nodes |
| environment | deployment environment for all nodes |
| nodes | array of nodes to be deployed |
| Key | Value |
|---|---|
| name | ASCII string |
| description | Text describing the node |
| provider | Cloud provider |
| image | OS Image |
| size | VM Size/Type |
| zone | Availability Zone |
| roles | Array of roles that the Configuration Management System should apply |
| attributes | Associative array of node attributes that overwrite defaults |
There are many other features that can be added at the cost of increasing complexity:
-
Node/Step: An integer that defines dependencies between nodes, with the purpose of allowing implementations to provision and configure nodes in parallel. Several nodes could have the value
"step": 1, another group"step": 2and so on. - Node naming: To be able to provision a deployment file several times (for example for different environments), nodes may have to be named following some sort of convention. For example deployment_name.node_name This is something that can be handled by individual implementations, by at least a general recommendation could be made.
- Idempotency: As above, it could be left to individual implementations. The spec though, could define how deployment naming should be. For example there can be a template file, called webapp.json, and it can be deployed with a name. Then a "deployed" file is created called myshop.webapp.json. The current deployment files, could also have an added field like "status", or "ip", that allows a server-less implementation of the spec to maintain idempotency over multiple deployment runs.