You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _build/html/_sources/deployment.txt
+79-27Lines changed: 79 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,11 @@ Deployment
6
6
WSGI Server
7
7
-----------
8
8
9
-
There are many ways to deploy Alerta. It can be run as ``alertad`` during development or testing but when run in a production environment, it should `always be deployed`_ as a WSGI application. See the list of `real world`_ examples below for different ways to run Alerta as a WSGI application.
9
+
There are many ways to deploy Alerta. It can be run as ``alertad``
10
+
during development or testing but when run in a production environment,
11
+
it should `always be deployed`_ as a WSGI application. See the list
12
+
of `real world`_ examples below for different ways to run Alerta as
13
+
a WSGI application.
10
14
11
15
.. _always be deployed: http://flask.pocoo.org/docs/0.10/deploying/
@@ -16,17 +20,24 @@ There are many ways to deploy Alerta. It can be run as ``alertad`` during develo
16
20
Web Proxy
17
21
---------
18
22
19
-
Running the Alerta API behind a web proxy can greatly simplify the Web UI setup which means you can completely `avoid`_ the potential for any cross-origin issues.
23
+
Running the Alerta API behind a web proxy can greatly simplify the
24
+
Web UI setup which means you can completely `avoid`_ the potential
Also, if you run the API on an HTTPS/SSL endpoint then it can reduce the possibility of `mixed content`_ errors when a web application hosted on a HTTP endpoint tries to access resources on an HTTPS endpoint.
29
+
Also, if you run the API on an HTTPS/SSL endpoint then it can
30
+
reduce the possibility of `mixed content`_ errors when a web
31
+
application hosted on a HTTP endpoint tries to access resources
This example nginx server is configured to serve the web UI from the root ``/`` path and reverse-proxy API requests to ``/api`` to the WSGI application running on port 8080::
38
+
This example nginx server is configured to serve the web UI from
39
+
the root ``/`` path and reverse-proxy API requests to ``/api`` to
40
+
the WSGI application running on port 8080::
30
41
31
42
server {
32
43
@@ -50,24 +61,29 @@ This example nginx server is configured to serve the web UI from the root ``/``
50
61
server localhost:8080 fail_timeout=0;
51
62
}
52
63
53
-
The web UI configuration file :file:`config.js` for this setup would simply be ``/api`` for the ``endpoint`` value, as follows::
64
+
The web UI configuration file :file:`config.js` for this setup would
65
+
simply be ``/api`` for the ``endpoint`` value, as follows::
54
66
55
67
'use strict';
68
+
56
69
angular.module('config', [])
57
70
.constant('config', {
58
71
'endpoint' : "/api",
59
72
'provider' : "basic"
60
-
})
61
-
.constant('colors', {});
73
+
});
62
74
63
75
.. _static website:
64
76
65
77
Static Website
66
78
--------------
67
79
68
-
The Alerta web UI is just a directory of static assets that can be served from any location. An easy and cheap way to serve the web UI is from an `Amazon S3 bucket`_ as a static website.
80
+
The Alerta web UI is just a directory of static assets that can be
81
+
served from any location. An easy and cheap way to serve the web UI
82
+
is from an `Amazon S3 bucket`_ as a static website.
69
83
70
-
.. note:: Serving the Alerta web UI from a static web hosting site **will not work** unless that domain is listed in the ``CORS_ORIGINS`` Alerta API server configuration settings.
84
+
.. note:: Serving the Alerta web UI from a static web hosting site
85
+
**will not work** unless that domain is listed in the
86
+
``CORS_ORIGINS`` Alerta API server configuration settings.
@@ -76,39 +92,52 @@ The Alerta web UI is just a directory of static assets that can be served from a
76
92
Authentication & SSL
77
93
--------------------
78
94
79
-
Alerta supports several authentication mechanisms for both the API and the web UI and some key features of the web UI, like :ref:`watching alerts <watched alerts>`, are only available if authentication is enabled.
95
+
Alerta supports several authentication mechanisms for both the API
96
+
and the web UI and some key features of the web UI, like
97
+
:ref:`watching alerts <watched alerts>`, are only available if
98
+
authentication is enabled.
80
99
81
-
The API can be secured using :ref:`API keys` and the web UI can be secured using :ref:`Basic Auth <basic auth>` or an :ref:`OAuth <oauth2>` provider from either Google or Github.
100
+
The API can be secured using :ref:`API keys` and the web UI can
101
+
be secured using :ref:`Basic Auth <basic auth>` or an :ref:`OAuth <oauth2>`
102
+
provider from either Google or Github.
82
103
83
-
If you plan to make the web UI accessible from a public URL it is strongly advised to :ref:`enforce authentication <Authentication>` and use HTTPS/SSL connections to the Alerta API to protect private alert data.
104
+
If you plan to make the web UI accessible from a public URL it is
105
+
strongly advised to :ref:`enforce authentication <Authentication>`
106
+
and use HTTPS/SSL connections to the Alerta API to protect private
107
+
alert data.
84
108
85
109
.. _auth_cv:
86
110
87
111
Authorisation & Customer Views
88
112
------------------------------
89
113
90
-
To restrict access to certain features use roles and customer views.
91
-
92
-
93
-
114
+
To restrict access to certain features use :ref:`roles <user roles>`
115
+
and :ref:`customer views <customer views>`.
94
116
95
117
.. _scalability:
96
118
97
119
Scalability
98
120
-----------
99
121
100
-
Alerta can scale horizontally, in the same way any other web application scales horizontally -- a load balancer handles the HTTP requests and distributes those requests between all available application servers.
122
+
Alerta can scale horizontally, in the same way any other web
123
+
application scales horizontally -- a load balancer handles the
124
+
HTTP requests and distributes those requests between all available
.. note:: If using multiple API servers ensure the same ``SECRET_KEY`` is used across all servers otherwise there will be problems with web UI user logins.
129
+
.. note:: If using multiple API servers ensure the same ``SECRET_KEY``
130
+
is used across all servers otherwise there will be problems
131
+
with web UI user logins.
105
132
106
133
.. _high availability:
107
134
108
135
High Availability
109
136
-----------------
110
137
111
-
To achieve high system availability the Alerta API should be deployed to scale out :ref:`horizontally <scalability>` and the MongoDB database should be deployed as a `replica set`_.
138
+
To achieve high system availability the Alerta API should be
139
+
deployed to scale out :ref:`horizontally <scalability>` and
140
+
the MongoDB database should be deployed as a `replica set`_.
@@ -117,32 +146,53 @@ To achieve high system availability the Alerta API should be deployed to scale o
117
146
House Keeping
118
147
-------------
119
148
120
-
There are some jobs that should be run periodically to keep the Alerta console clutter free. To timeout *expired* alerts and delete old *closed* alerts run a contributed MongoDB script_ called :file:`housekeepingAlerts.js` at regular intervals via ``cron``.
149
+
There are some jobs that should be run periodically to keep the
150
+
Alerta console clutter free. To timeout *expired* alerts and
151
+
delete old *closed* alerts run a contributed MongoDB script_
152
+
called :file:`housekeepingAlerts.js` at regular intervals
:ref:`Heartbeats <heartbeats>` can be sent from any source to ensure that a system is 'alive'. To generate alerts for stale heartbeats the ``alerta`` command-line tool can be used::
159
+
:ref:`Heartbeats <heartbeats>` can be sent from any source to
160
+
ensure that a system is 'alive'. To generate alerts for stale
161
+
heartbeats the ``alerta`` command-line tool can be used::
127
162
128
163
$ alerta heartbeats --alert
129
164
130
-
Again, this should be run at regular intervals via ``cron`` or some other scheduler.
165
+
Again, this should be run at regular intervals via ``cron`` or
166
+
some other scheduler.
131
167
132
168
.. _metrics:
133
169
134
170
Management & Metrics
135
171
--------------------
136
172
137
-
Use the management endpoint :file:`/management/status` to keep track of realtime statistics on the performance of the Alerta API like alert counts and average processing time. For convenience, these statistics can be viewed in the *About* page of the Alerta web UI or using the `alerta` command-line tool :ref:`status <cli_status>` command.
173
+
Use the management endpoint :file:`/management/status` to keep
174
+
track of realtime statistics on the performance of the Alerta API
175
+
like alert counts and average processing time. For convenience,
176
+
these statistics can be viewed in the *About* page of the Alerta
177
+
web UI or using the ``alerta`` command-line tool
178
+
:ref:`status <cli_status>` command.
138
179
139
180
Web UI Analytics
140
181
----------------
141
182
142
-
Google analytics can be used to track usage of the Alerta web UI console. Just create a new tracking code with the `Google analytics`_ console and replace the ``@@TRACKING_ID`` placeholder in the `index.html` file during deployment of the web UI::
183
+
Google analytics can be used to track usage of the Alerta web UI
184
+
console. Just create a new tracking code with the `Google analytics`_
185
+
console and add it to the ``config.js`` web console configuration
186
+
file::
143
187
144
-
$ export GOOGLE_TRACKING_ID=UA-xxxxxxxx-x
145
-
$ sed -i s/@@TRACKING_ID/${GOOGLE_TRACKING_ID}/ index.html
188
+
'use strict';
189
+
190
+
angular.module('config', [])
191
+
.constant('config', {
192
+
'endpoint' : "/api",
193
+
'provider' : "basic",
194
+
'tracking_id' : "UA-NNNNNN-N" // Google Analytics tracking ID
@@ -151,7 +201,9 @@ Google analytics can be used to track usage of the Alerta web UI console. Just c
151
201
Real World Examples
152
202
-------------------
153
203
154
-
Below are several different examples of how to run Alerta in production from a Debian `vagrant box`_, an `AWS EC2 instance`_, `RedHat Openshift PaaS`_ to a `Docker container`_.
204
+
Below are several different examples of how to run Alerta in production
205
+
from a Debian `vagrant box`_, an `AWS EC2 instance`_,
206
+
`RedHat Openshift PaaS`_ to a `Docker container`_.
0 commit comments