...
In some cases, you may want to provide Abiquo access to different departments or organisations with different DNS domain/ subdomain name and a customised Abiquo UI theme per each domain/ subdomain. There are several ways to achieve this setup depending on the needs and resources available but this document covers a simple path with minimal resources required.
...
We are going to describe this setup assuming the scenario described below. Note that you will need to adjust the rest of the commands in this document to suit your environment (mostly host names and IPs).
Machine | Host name | IP Address | ||
---|---|---|---|---|
Abiquo API | abiquo | 10.60.13.28 | ||
Remote services 1 | rsha1 | 10.60.13.57 | ||
Remote services 2 | rsha2 | 10.60.13.56 | ||
Cluster IP | rscluster | 10.60.13.58 | ||
Redis server | redis | 10.60.13.59 | ||
NFS repository | repository | 10.60.1.72Monolithic & Apache2 SSL front-end | api.example.com | 192.168.1.100 |
Datacenter2 Remote Services | dc2rs.example.com | 192.168.1.150 |
Note | ||
---|---|---|
| ||
|
Once environment has been described, we are going into changes needed to achieve Abiquo UI theming per subdomain.
Abiquo UI configuration
Abiquo
In the sample scenario the Apache2 SSL front-end is also running the API and Remote Services for Datacenter 1. As has been indicated previously, this is a sample but you will easily extrapolate required configuration
Remote services 1 and 2 will be the nodes forming our cluster, and serving the remote services webapps on the cluster-wide IP address. This IP will switch from one server to another in the case of a failure. Redis needs to be on a separate host, as the data must be shared for both remote services machines. It is out of the scope of this document to describe a highly available setup for Redis. If you want to run Redis in such a setup, please refer to to Redis's documentation.
...