1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
Juju charm apache
=====================
The Apache Software Foundation's goal is to build a secure, efficient
and extensible HTTP server as standards-compliant open source
software. The result has long been the number one web server on the
Internet. It features support for HTTPS, virtual hosting, CGI, SSI,
IPv6, easy scripting and database integration, request/response
filtering, many flexible authentication schemes, and more.
How to deploy the charm
--------------------------
juju deploy apache2
juju set apache2 "schema=$(base64 < vhost.tmpl)"
Vhost templates
--------------------------
The charm expects a jinja2 template to be passed in. The variables in
the template should relate to the services that apache will be proxying
to (obviously no variables need to be specified if no proxying is needed).
The charm will create the service variable, with the unit_name, when
the reverseproxy relationship is joined and present this to the template
at which point the vhost will be generated from the template again.
For example to access squid then the {{{ squid }}} variable should be used.
This will be populated with the hostname:port of the squid service. The
individual hostname and port can also be accessed via squid_hostname and
squid_port.
Note: If an alias is used when deploying a charm then the alias name needs
to be used.
If the joining charm also present an all_services variable which contains
a list of services it provides in yaml format then variables for each
service will be created of the format unitname_stanza. For example if
haproxy contains stanzas named gunicorn and solr these can be accessed
via {{{ haproxy_gunicorn }}} and {{ haproxy_solr }}}.
Note: Currently the haproxy does not seem to be generating individual stanzas
correctly
For example a vhost that will pass all traffic on to an haproxy instance:
<VirtualHost *:80>
ServerName radiotiptop.org.uk
CustomLog /var/log/apache2/radiotiptop-access.log combined
ErrorLog /var/log/apache2/radiotiptop-error.log
DocumentRoot /srv/radiotiptop/www/root
ProxyRequests off
<Proxy *>
Order Allow,Deny
Allow from All
ErrorDocument 403 /offline.html
ErrorDocument 500 /offline.html
ErrorDocument 502 /offline.html
ErrorDocument 503 /offline.html
</Proxy>
ProxyPreserveHost off
ProxyPassReverse / http://{{ haproxy_gunicorn }}/
RewriteEngine on
RewriteRule ^/$ /index.html [L]
RewriteRule ^/(.*)$ http://{{ haproxy_gunicorn }}/$1 [P,L]
</VirtualHost>
Certs, keys and chains
--------------------------
ssl_keylocation, ssl_certlocation and ssl_chainlocation are file names in the
data directory.
{enable,disable}_modules
--------------------------
Lists of modules to be enabled or disabled. If a module to be enabled cannot be found
then the charm will attempt to install it.
TODO:
* Method to deliver site content. This maybe by converting the charm to a subordinate
and making it the master charms problem
* Delivery of SSL key. Implement secure method for delivering key.
* Tuning. No tuning options are present. Convert apache2.conf to a template and expose
config options
* Testing. I have only tested the relationship setup with 1 haproxy instance. Needs testing against
multiple instances
|