PageRenderTime 101ms CodeModel.GetById 40ms app.highlight 1ms RepoModel.GetById 39ms app.codeStats 0ms

/docs/terminology.txt

https://bitbucket.org/ianb/silverlining/
Plain Text | 89 lines | 69 code | 20 blank | 0 comment | 0 complexity | 43cdaad5bc274b17fd39e0608331bcd0 MD5 | raw file
 1Silver Lining Terminology
 2=========================
 3
 4This terminology is not yet implemented, but with a refactoring it
 5will be:
 6
 7
 8Provider:
 9    This is a provider like Rackspace, EC2, etc.  This is generally
10    defined in ``~/.silverlining.conf``.  This generally includes account
11    information in addition to the actual provider, so if you are
12    working with multiple accounts you will have multiple providers.
13
14Node:
15    This is a virtual server that has been setup.  It has a name,
16    which is also the domain name it can be accessed by.  The name
17    doesn't have to be in DNS (``/etc/hosts`` is setup for this).
18    Hostnames can be substituted for node names in all cases (but a
19    node that has just been created has no hostnames because no sites
20    have been deployed to it).  Node names and hostnames can overlap.
21
22Location (FIXME: not a great name):
23    This is a hostname, and optionally a path where an application
24    will live.  For example, ``blog.example.com/about/``.  Multiple
25    locations can be mapped to a single application.
26
27Hostname:
28    The host part of a location.
29
30Application Package:
31    This is a codebase that can be run.  It has an app.ini file, and a
32    runner for the application.
33
34Application:
35    This is an application package, ready to deploy.  It also has an
36    application name.  Application Packages specify a default name,
37    but application names are unique on a node; so if a deployment
38    uses a particular application name then it is the identical
39    application and will replace the old application.  If, for
40    instance, you want to install two distinct versions of the same
41    application package -- e.g., two versions of a blog product --
42    then you must give them two separate application names.
43
44Deployment:
45    This is a specific deployment of an application.  It is named
46    based on the application name and a timestamp and unique integer.
47    The name is referred to as ``instance_name``.
48
49Site:
50    This is an arrangement of applications and their locations, and
51    potentially an arrangment of servers to support those applications
52    (if the entire site is not deployed on a single server).
53
54Services:
55    These are persistent services that the application will use.
56
57deb Package:
58    This is unsurprisingly a deb package, installed with apt-get.
59    Generally these will be Ubuntu packages, but you can use other
60    repositories and install packages by other providers.
61
62``app_dir``:
63    This is the directory where Application files have been uploaded
64    on a server, generally ``/var/www/APP_NAME.TIMESTAMP``.
65
66``instance_name``:
67    This is the name of the deployment, e.g., ``APP_NAME.TIMESTAMP``.
68
69``hostname``:
70    This is a host that can be ssh'd to.
71
72``app_name``:
73    This is the name of the app on the server (``APP_NAME``).
74
75``node``:
76    There are a limited number of times when ``node`` is distinct from
77    ``hostname``:
78
79    * first, if you provide ``--node`` then that overrides the
80      hostname for ssh, etc.  This can be useful when there is a load
81      balancer in front of the server, or many servers provide the
82      same hostname (e.g., many load-balanced app servers).
83
84    * second, if the hostname is not mapped to anything (it has not
85      been created, it is not in ``/etc/hosts``), then this lets the
86      hostname be mapped to a specific node/server.
87
88    In other cases, hostname and node are equivalent, and if a command
89    includes the hostname it doesn't require an explicit node.