|
.. highlight:: yaml
|
|
|
|
reverse_proxy
|
|
=============
|
|
|
|
This role provides the mean of exposing a machine to the web (http and https), it is currently bound to the *reverse_proxy* host but it will be extended to be available to other as well.
|
|
|
|
Usage
|
|
-----
|
|
|
|
To expose the web services to the internet (http and https) for the resource pippo (a machine or a group) add the role **reverse_proxy** to the playbook.
|
|
|
|
This will first connect to the `pippo` hosts, execute the `role1` and then connect to the `reverse_proxy` host to add the proxy rules for `pippo`.
|
|
|
|
.. code-block:: yaml
|
|
|
|
- hosts: pippo
|
|
roles:
|
|
- role: role1
|
|
- role: reverse_proxy
|
|
|
|
By default the domain exposed is created from the resource name, i.e. `pippo.lilik.it` but this can be changed by setting the `hostname` variable for the role `reverse_proxy`.
|
|
|
|
.. code-block:: yaml
|
|
|
|
- hosts: pippo
|
|
roles:
|
|
- role: role1
|
|
- role: reverse_proxy
|
|
hostname: pluto
|
|
|
|
Rationale behind this role
|
|
--------------------------
|
|
|
|
We have choosen to use **nginx** as our reverse proxy and because of the number of targets this can't be accomplished using a unique configuration file for nginx as it would need to know every rule every time it's configuration changes.
|
|
|
|
Nginx provides the featuer to load configuration files from multiple directories and then merge the into one so we have choose to use three different directories.
|
|
|
|
.. code-block:: bash
|
|
|
|
nginx.conf
|
|
map.conf.d/
|
|
upstream.conf.d/
|
|
http.conf.d/
|
|
|
|
`nginx.conf` is the nginx configuration file, there we specify to include the the three directories in specific directives.
|
|
|
|
`http.conf.d` contains the files for the *http* reverse proxy directive.
|
|
|
|
`upstream.conf.d` contains the files where we specify a map from an id to the pool of the machines associated.
|
|
|
|
`map.conf.d` contains the files where we specify the list of domains and their mappings to a resource id.
|
|
|
|
We have choosen to separate this relation domain <-> machine by using an id because it will be used to make fun things such as high-availability or mapping more domains to the same resource id (but in different files) without the assle of checking if the nginx configuration will be broken by our automation.
|
|
|
|
As an example take the mapping from `ca.lilik.it` to the machine `10.150.42.x`, we can have another mapping from `certificationauthority.lilik.it` to the same machine without the hassle of checking if a upstream rule is used by some mappings when we want to deprecate `certificationauthority.lilik.it`
|