PageRenderTime 248ms CodeModel.GetById 63ms RepoModel.GetById 55ms app.codeStats 0ms

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