# scalelite-run
This document provides instructions on how to quickly [Scalelite](https://github.com/blindsidenetworks/scalelite), a stateful BigBlueButton load balancer, using docker-compose.
This can be performed as an [All-In-One-Box Deployment](#all-in-one-box-deployment) or making use of distributed services in the cloud (or virtual private cloud) through a cloud computing provider as a [Distributed Deployment](#distributed-deployment).
## Prerequisites
Scalelite requires a server with 4 CPU cores and 8 Gig of memory. Since all the component run under docker, the underlying OS need only support docker and docker-compose.
These steps were written for an Ubuntu 18.04 machine. It is assumed that your machine has the same (or a compatible version).
You need to have a fully qualified domain name (FQDN) for the Scalelite server, such as bbb-lb.example.com, that resolves to the public IP address of the server.
To setup the server, first install both [docker](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04) and [docker-compose](https://www.digitalocean.com/community/tutorials/how-to-install-docker-compose-on-ubuntu-18-04).
Next, clone the `scalelite-run` repository
```
git clone git@github.com:blindsidenetworks/scalelite-run.git
cd scalelite-run
```
## I. All-In-One-Box Deployment
### 1. Initial settings
Copy `dotenv` file located in the root of the project as `.env` and edit it.
```
cp dotenv .env
```
You need to replace the variable `HOST_NAME=sl.xlab.blindside-dev.com` with a hostname under your own domain name (e.g. `HOST_NAME=sl.john.blindside-dev.com`) or delegated sub-domain.
```
vi .env
```
Copy `dotenv` file located in the scalelite directory as `.env` and in the same way as before, edit it:
```
cp scalelite/dotenv scalelite/.env
```
You can start it as is, but you may want to replace both variables with your own values.
- `SECRET_KEY_BASE` is the Ruby On Rails secret key and must be replaced with a random one generated with `openssl rand -hex 64`.
- `LOADBALANCER_SECRET` is the shared secret used by external applications for accessing Scalelite LoadBalancer as if it was a BigBlueButton server. This variable must be defined in order for the application to start. A secret can be generated with `openssl rand -hex 24`
```
vi scalelite/.env
```
### 2. SSL Certificate
The docker-compose scripts come configured for using SSL Certificates, but you may want not to use an SSL certificate. If this is the case see the section [Removing SSL Certificate](#removing-ssl-certificate) in [Special Cases](#special-cases).
The procedure for setting up the SSL Certificate will be different depending if [Let's Encrypt SSL CA](#letsencrypt-ssl-ca) CA or [Other SSL CA](#other-ssl-ca) will be used.
#### 2.1. Using Let's Encrypt SSL CA
There are also two paths that can be followed whether the box where Scalelite is going to be installed is [visible from the Internet](#letsencrypt-ssl-public-network) or [NOT visible from the Internet](#letsencrypt-ssl-private-network).
##### 2.1.1. Server is visible from the Internet
If all the previous steps were properly followed and the machine is accessible in the Internet, only execute:
```
./init-letsencrypt.sh
```
This will generate the SSL certificates and run scalelite for the first time, so all the required files are automatically generated.
##### 2.1.2. Server is NOT visible from the Internet
If you are trying to install scalelite locally or in a private network, the SSL certificate must be generated manually using certbot and by adding the manual challenge to the DNS.
Install Let's Encrypt
```
sudo apt-get update
sudo apt-get -y install letsencrypt
```
Become root
```
sudo -i
```
Start creating the certificates
```
certbot certonly --manual -d sl..blindside-dev.com --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges=dns --email hostmaster@blindsdie-dev.com --server https://acme-v02.api.letsencrypt.org/directory
```
The output should look like this example
```
-server https://acme-v02.api.letsencrypt.org/directory
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for gl..blindside-dev.com
dns-01 challenge for gl..blindside-dev.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.sl..blindside-dev.com with the following value:
2dxWYkcETHnimmQmCL0MCbhneRNxMEMo9yjk6P_17kE
Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
```
Create a TXT record in the DNS for
`_acme-challenge.sl..blindside-dev.com` with the challenge string as
its value `2dxWYkcETHnimmQmCL0MCbhneRNxMEMo9yjk6P_17kE`
Copy the certificates to the scalelite-run directory. Although `/etc/letsencrypt/live/`
holds the latest certificate, they are only symbolic links. The real files must be copied and renamed
```
cp -R /etc/letsencrypt /scalelite-run/data/certbot/conf
```
#### 2.2. Using Other SSL CA
For adding an SSL certificate from an CA other than Let's Encrypt,
DO NOT execute the `./init-letsencrypt.sh` script
Place the SSL Certificate, Intermediate Certificate (or Bundle with both of them if you have it) and Private Key files inside `nginx/ssl` as `fullchain.pem` and `privkey.pem`.
E.g.
```
cd ~/
cat your_domain_name.crt Intermediate.crt >> bundle.crt
cp bundle.crt /scalelite/nginx/ssl/fullchain.pem
cp private.key /scalelite/nginx/ssl/privkey.pem
```
Edit the template for nginx.
```
cd /scalelite
vi nginx/sites.template
```
Comment the lines referencing the Let's Encrypt Certificate and uncomment the other two. After that, it should look like this:
```
...
## Configuration for Letsencrypt SSL Certificate
#ssl_certificate /etc/letsencrypt/live/$NGINX_HOSTNAME/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/$NGINX_HOSTNAME/privkey.pem;
## Configuration for SSL Certificate from a CA other than Letsencrypt
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
...
```
Comment out in `docker-compose.yml` the certbot container. After that, it should look like this:
```
...
## Configuration for Letsencrypt SSL Certificate
## comment out when using an SSL Certificate from a CA other than Letsencrypt
# certbot:
# image: certbot/certbot
# volumes:
# - ./data/certbot/conf:/etc/letsencrypt
# - ./data/certbot/www:/var/www/certbot
# entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
...
```
Start the containers as usual.
### 3. Start Up
And finally, start the application with docker-compose
```
cd /scalelite-run
docker-compose up
```
If everything goes well, the logs will show ip in the console for all the containers starting and scalelite will be available at:
```
https://sl..blindside-dev.com/bigbluebutton/api
```
Note that the application can be run in the background with `docker-compose up -d`
### 4. Final Steps
#### 4.1. Initializing pool of servers
Since there are no servers added by default, atleast 1 server must be added and enabled in order to get started.
Open a new console and get the IDs of the docker containers running:
```
docker ps
```
Get into the container running the api
```
docker exec -it sh
```
Once inside, all the rails commands can be executed as needed. In this case, and assuming that the current current BigBlueButton server is going to be enabled.
```
bundle exec rake servers:add[BIGBLUEBUTTON_SERVER_URL,BIGBLUEBUTTON_SERVER_SECRET]
bundle exec rake servers
bundle exec rake servers:enable["SERVER_ID_AS SHOWN"]
```
For more information on what rake commands can be executed, see [scalelite documentation](https://github.com/blindsidenetworks/scalelite#administration).
#### 4.2. Rolling-out updates
Scalelite is constantly updated. Either because of bug fixes or improvements. It is recommended to keep the deployment updated with the latest image available, which corresponds to the latest stable release.
Those updates can be performed manually (recommended for a production alike environment) or automatically.
##### 4.2.1. Manual updates
Simply run the `deploy.sh` script included under `scripts`.
```
cd /scalelite-run
sudo .scripts/deploy.sh
```
##### 4.2.2. Automatic updates
Use the scripts provided.
```
sudo ln -s /scalelite-run/scripts/deploy.sh /usr/local/bin/scalelite-deploy
sudo cp /scalelite-run/scripts/scalelite-auto-deployer.service /etc/systemd/system/scalelite-auto-deployer.service
sudo cp /scalelite-run/scripts/scalelite-auto-deployer.timer /etc/systemd/system/scalelite-auto-deployer.timer
sudo systemctl daemon-reload
sudo systemctl enable scalelite-auto-deployer.service
sudo systemctl enable scalelite-auto-deployer.timer
sudo systemctl start scalelite-auto-deployer.timer
```
##### 4.2.3. Automatic start
Use the scripts provided.
```
```
## II. Distributed Deployment
On a real production environment Scalelite should be deployed using distributed services in the cloud (or virtual private cloud) through a cloud computing provider like [AWS](https://aws.amazon.com/), [Google Cloud](https://cloud.google.com/), [Azure](https://azure.microsoft.com/en-ca/), [Digital Ocean](https://www.digitalocean.com/), [Alibaba Cloud](https://www.alibabacloud.com/), etc.
Contact us at [Blindside Networks Contact](https://blindsidenetworks.com/contact/) getting recommendations on best practices with any of those cloud providers.
## III. Special cases
### Building Docker image
If no access to the DockerHub registry is available, it is still possible to build the image. Either by running `docker build` where scalelite code is placed, or using the build script provided in this repo at `scripts/build.sh`. The only advantage of using the script is that the last commit is included as the build number.
```
cd /scalelite
docker build -t blindsidenetwks/scalelite:latest .
```
or
```
cd /scalelite
../scalelite-run/scripts/build.sh blindsidenetwks/scalelite latest
```
Keep in mind that the docker-compose.yml script makes use of some other configuration files that are mounted inside the containers. If any modification to nginx is needed it has to be done on the sites.template file. Also, whatever name is chosen for the image should match the one used in docker-compose.yml.
### Removing SSL Certificate
DO NOT execute the `./init-letsencrypt.sh` script
Edit the template for nginx.
```
cd /scalelite
vi nginx/sites.template
```
Comment out all the lines from 13 to 34. The sites.template file should look like this:
```
...
listen [::]:80;
# location /.well-known/acme-challenge/ {
# root /var/www/certbot;
# }
#
# location / {
# return 301 https://$host$request_uri;
# }
#}
#
#server {
# server_name $NGINX_HOSTNAME;
#
# listen 443 ssl;
# listen [::]:443;
#
# ## Configuration for Letsencrypt SSL Certificate
# ssl_certificate /etc/letsencrypt/live/$NGINX_HOSTNAME/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/$NGINX_HOSTNAME/privkey.pem;
#
# ## Configuration for SSL Certificate from a CA other than Letsencrypt
# #ssl_certificate /etc/ssl/fullchain.pem;
# #ssl_certificate_key /etc/ssl/privkey.pem;
location / {
...
```
Comment out in `docker-compose.yml` the certbot container. After that, it should look like this:
```
...
## Configuration for Letsencrypt SSL Certificate
## comment out when using an SSL Certificate from a CA other than Letsencrypt
# certbot:
# image: certbot/certbot
# volumes:
# - ./data/certbot/conf:/etc/letsencrypt
# - ./data/certbot/www:/var/www/certbot
# entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"
...
```
Start the containers as usual.