Enabling online team collaboration with open source software

Teams across the world are looking for solutions that help them to work and collaborate online in these unprecedented times. There are many options that customers have, so this post will help provide you with some options if you are looking.

Many teams choose to use managed solutions to enable collaboration. If your business needs to scale to support hundreds or thousands of users simultaneously or does not want to deploy and manage new web services for this purpose, consider using Amazon Chime. Amazon Chime is a communications service hosted on AWS that lets you get started in just a few clicks. It allows you to meet, chat, and place business calls inside and outside your organisation, all using a single application. With Amazon Chime, you have the flexibility to choose the features that you need for online meetings, video conferencing, and business calling, and pay only when you use them. To learn more Amazon Chime, visit https://aws.amazon.com/chime.

Some business however, may prefer to use open source technologies to enable this. Jitsi is one such open source project that enables a rich online web conferencing capability. The rest of this post is a technical walkthrough of how you can host your own instances of Jitsi to enable this.

Introducing Jitsi

Jitsi is an open source web conference application built using JavaScript. You might find this useful if you are looking for tools to help you and your teams as you work remotely. You can check out the project here, but in this walk through will enable you to host your own version of this application. I will help you through installing this project on AWS and you should be able to deploy this to any AWS region nearest to you and the users you want to communicate with.

History of Jitsi

A number of people who are discovering Jitsi today are curious about its origins. The project dates back all the way to 2003: the glorious early days of Voice Over IP (VoIP) when best practices for media transport were still being worked out as people were battling NAT traversal issues and the plague of one way audio calls.

Jitsi was one of the first fully open source communications options with a strong accent on security and privacy. It was, for example, one of the earliest options for people to jump on fully end-to-end ZRTP encrypted calls.

In late 2013, with the arrival of WebRTC, Jitsi migrated to the cloud with its Jitsi Videobridge (some small fragments of that code still date back to the very early days although most have been completely rewritten multiple times) and the rest of its web conferencing components like Jitsi Meet.

Jitsi kept its strong focus on security and is today arguably the easiest options to spin out a fully private and secure conferencing server (which is what we are explaining in this post). It has gained adoption by privacy sensitive users all around the world, including the Freedom of Press Foundation (wired article), among others.

The majority of Jitsi’s contributors are employed by cloud communications provider 8x8(www8x8.com) that also operates Jitsi’s popular sample deployment at meet.jit.si

This walk through will enable you to host your own version of this application, with the corefunctionality. I have provided two walk throughs; one for those who want to run this via Amazon EC2 instances, and the other for those who prefer to use containers, so running this through the Amazon ECS.

If you want the advanced functionality then you should work with the maintainers behind Jitsi, or follow the documentation to setup those advanced features on the github repository. Those are outside the scope of this post.

Lets begin with the Amazon EC2 walkthrough; if that is not your thing, jump ahead to the Amazon ECS walkthrough.

Deploying Jitsi on Amazon EC2

What you will need

You will need the following things to complete this walkthrough.

• AWS Account - you will be configuring services so you need an account with a user that can provision those services
• A DNS provider - this is needed to obtain an SSL certificate. You can use Amazon Route 53 or other DNS provider.

If you skip this step you will be able to get Jitsi up and rnning, but you will then have to deal with potential issues with your users having SSL errors in the browser, as well as issues with the webcam and microphone not working.

Provision your Amazon EC2 instance

The first thing you need is to create a running Linux instance on which to run your Jitsi server.

1. SSH keypair

[Optional - if you already have SSH keypairs, you can use an existing one]

Create a keypair that you will use to ssh into your Jitsi server. From the EC2 console, on the left hand side click on Key Pairs and then use the CREATE button to create a PEM (default option) key pair.

Note! If you are using Windows and likely using Putty, use the ppk key format.

Click on the CREATE KEY PAIR button and then make sure you save the key that pops up on your machine. Keep this safe. You will need to change the permissions of this file

Tip! Key pairs are regional, so make sure you match up the key pair you generate with the region you are going to launch your EC2 instances into.

Important!
Secure access to your EC2 instance. Make sure that you do NOT open up port ssh (22) to the world. Either limit it to just your IP address, or better still, use an existing bastion or jump host you have setup to do this. If you are not sure about this, then ask via the comments below and I will walk you through this.

2. Launch instance

Before you launch the instance, you need to think about the instance type you want to select and how much this will cost. Jitsi needs a fair bit of memory, so using the micro instances will not work without tuning/hacking and that is outside the scope of this post.

As a minimum I would go for 1 CPU and 8GB of memory, but you can go with AMD instances. I have not tried Graviton ARM based instances, but that will be something to try - it all depends on whether the application binaries have been compiled for ARM and are in the application repositories. If you try this let me know.

In this walkthrough, I use the T3.large instances - these provide 2vCPUs and 8GB of memory. This should support a small number of people using this. You might want to consider a couple of things when sizing your instances;

• the CPU/Memory combinations increasing with the number of users
• the network performance. The T instances have 5 Gbps, but you might get much better performance with the other instances types that go up to 25 Gbps

Instance launch instructions

1. From the AWS console, select the region you want to deploy your Jitsi server to (and making sure it matches where you have the key pair)
2. Go to the EC2 console, and select INSTANCES
3. Click on LAUNCH INSTANCE
4. In the search box type "Ubuntu" and hit return. Select the Ubuntu 18.04 LTS.
5. In the instance type, select the instance type you have decided (the bit above) and then click NEXT:CONFIGURE INSTANCE DETAILS
6. Accept defaults on the next page and click on NEXT: ADD STORAGE
7. Accept defaults on the next page and click on NEXT: ADD TAGS
8. Accept defaults on the next page and click on NEXT: ADD SECURITY GROUPS
9. Change the security group name to: JITSI-SECURITY-GROUP
10. Change the SSH SOURCE to your IP address (or your bastion host if you are using that)
11. Add HTTP and HTTPS rules from source ANYWHERE
12. Add custom TCP port 4443 rule from source ANYWHERE
13. Add custom UDP port 10000 rule from source ANYWHERE
14. Click on NEXT:REVIEW and LAUNCH
15. Click on LAUNCH
16. On the pop up select from the list the ssh key you created and tick the acknowledge.
17. Click on LAUNCH INSTANCE to kick off the creation, and on the following screen click on VIEW INSTANCES

It will take a few minutes for this to provision and setup. On the console, once your instance changes to status checks RUNNING and 2/2 checks passed you have completed the launch of your instance.

To the left of this, you should see an entry for INSTANCE ID - you will need this in the next section, so note this down.

Allocate Elastic IP

To ensure that your instance keeps its IP during re-starts that might happen, configure an Elastic IP. From the EC2 console;

1. Select ELASTIC IP's
2. Click on the ALLOCATE ELASTIC IP ADDRESS
3. Select the default (Amazon pool of IPv4 addresses) and click on ALLOCATE
4. From the ACTIONS pull down, select ASSOCIATE ELASTIC IP ADDRESS
5. In the box that comes up, note down the "Elastic IP Address" - this will be needed when you configure your DNS
6. In the search box under INSTANCE, click and find your INSTANCE ID and then click ASSOCIATE

Your instance now has an elastic IP associated with it.

Setup your DNS

[This step is optional but highly recommended. You can proceed without DNS, and you will configure your Jitsi server to use an IP address when accessing it. However, you will not be able to configure SSL certs successfully and your users may experience usability/browser issues when connecting]

You will need to configure a DNS entry for the new host you have provisioned, so that it can be used to generate the SSL certificates as part of the installation process.

Note! The LetsEncrypt script will do a reverse lookup and expect to resolve the name of this host from the IP. The process also expects this to be an A record. I have not tried to see what happens if you use an Alias or C record.

Before proceeding, make sure that when you do a nslookup (or whatever your preferred DNS lookup tool might be) that the DNS record you created now resolves to the instance IP address. Do not proceed until this is the case.

Install and configure Jitsi

We can now being the business of installing and configuring Jitsi. ssh into your instance. You will use the ssh key to do this and your command will be something like;

$ ssh -i {ssh-key} ubuntu@{ip address}

Where the {ssh-key} is the key you created, the the {ip-address} is the IP address of the instance that you launched. If you get a hang during this operation, you should check your security groups and your IP address as it is likely that your ssh is being blocked.

$ sudo su - 
# echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
# wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# apt-get update

This will take a few seconds/minutes to update all the local packages. Once this has completed, make some changes to your system.conf file to accommodate the needs of this application.

To update the values edit /etc/systemd/system.conf with your favourite editor (mine is vi)

# vi /etc/systemd/system.conf

and make sure you have the following values - you can either uncomment them in the file, or just add these to the end of the file (which I find easier to do)

DefaultLimitNOFILE=65000
DefaultLimitNPROC=65000
DefaultTasksMax=65000

You will now need to reload the systemd to incorporate these changes, so run the following command;

systemctl daemon-reload

Now install the Jitsi application using the following command.

# apt-get -y install jitsi-meet

This should take a minute, before being prompted with a nice pink screen to enter the hostname of the current installation. This is where you enter the DNS name you registered and now resolves to the host IP.

Once you have entered that, it will ask you whether you want to generate certificates or use existing ones. For this walkthrough, select the default option of generate certificates.

Once you hit return it should complete the installation process. It will not take more than a couple of minutes. You will see output similar to the following:

Replacing debian:VeriSign_Universal_Root_Certification_Authority.pem
Replacing debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem
Replacing debian:Visa_eCommerce_Root.pem
Replacing debian:XRamp_Global_CA_Root.pem
Replacing debian:certSIGN_ROOT_CA.pem
Replacing debian:ePKI_Root_Certification_Authority.pem
Replacing debian:thawte_Primary_Root_CA.pem
Replacing debian:thawte_Primary_Root_CA_-_G2.pem
Replacing debian:thawte_Primary_Root_CA_-_G3.pem
Adding debian:auth.jitsi.beachgeek.co.uk.pem
done.
done.
Setting up jitsi-meet (1.0.4101-1) ...
Processing triggers for systemd (237-3ubuntu10.33) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

done.
done.
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...

Once that has completed, you new to generate the certificates. From the command line run this

/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

You will prompted for your email address, and once you have entered, the script will automate the process of requesting and installing the SSL certs. You will get output similar to the following:

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for {yourdomanin}
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/jitsi.beachgeek.co.uk/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/{yourdomain}/privkey.pem
   Your cert will expire on 2020-06-04. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

That is it - the application is now installed, SSL certificates configured and the application ready to go. The script shuts the server down, so you may need to restart this.

Managing the instance

To stop/start and check the status of the services, use the following commands;

$ sudo service jitsi-videobridge restart
$ sudo service jitsi-videobridge stop
$ sudo service jitsi-videobridge start
$ sudo service jitsi-videobridge status

The key directories you need to be aware about are as follows:

• /var/log/jitsi - this contains the java system logs as well as the application logs
• /usr/share/jitsi-meet - this contains the main application directory
• /etc/jitsi - system configuration files for all the components of Jitsi

When you reboot, the services should all come up automatically when you start.

Optimizing costs

You probably dont need to run this 24x7, so consider using something like the Amazon EC2 instance scheduler to automate the shutting down/restarting of the instance to save costs.

Deleting/uninstalling

Once you do not need these capabilities, you should make sure that you remove the EC2 instance and the DNS records you have configured.

Advanced installation

Refer to the project installation documents here to get more details on how to configure Jitsi behind a NAT instance. I have tried to keep it simple in this walkthrough in order to minimise the cost of setting up and running an instance.

Automation of the installation

I will add this later, but I will provide some AWS Cloudformation templates that automate these steps and make it easier for you to get this up and running.

Deploying Jitsi on AWS ECS

Container instructions

If you prefer to deploy Jitsi onto container infrastructure, the open source maintainers have your back here, and there is a repository that has docker instructions here. I will use that as a starting point for deploying Jitsi on Amazon ECS.

Note! This has been tested on Linux and MacOS. If you do not have access to Linux or a Mac OS, may I suggest you try running this via a Cloud9 IDE environment - once you try it, you will never want to go back!. It might work on Windows, so let me know if you get into problems and I will try and help out.

Jitsi provides a docker repository that allows you to very easily get this up and running on your local machine. We will use this as the base for creating the configuration files needed to build and deploy Jitsi on Amazon ECS.

Install and configure pre-requisites

You will need to install and setup to access your AWS environment;

• AWS Account - you will be configuring services so you need an account with a user that can provision those services
• A DNS provider - this is needed to obtain an SSL certificate. You can use Amazon Route 53 or other DNS provider.

You will also need the following tools. They are easily setup, make sure they are all the latest versions and up and running before proceeding.

• ECS-CLI - Install the AWS ECS client
• Docker and Docker-compose

SSH key pair

[Optional - if you already have SSH key pairs, you can use an existing one] Create a key pair that you will use to ssh into your Jitsi server. From the EC2 console, on the left hand side click on Key Pairs and then use the CREATE button to create a PEM (default option) key pair.

Note! If you are using Windows and likely using Putty, use the ppk key format.

Click on the CREATE KEY PAIR button and then make sure you save the key that pops up on your machine. Keep this safe. You will need to change the permissions of this file

Tip! Key pairs are regional, so make sure you match up the key pair you generate with the region you are going to launch your EC2 instances into.

Modify your docker-compose.yml

On your workstation, clone the repo in a clean folder;

$ git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
$ cp env.example .env

You will now need to edit the docker-compose file and strip out all the VOLUME lines, so for example

    networks:
        meet.jitsi: null
    volumes:
      - /home/ubuntu/.jitsi-meet-cfg/jicofo:/config:rw

Would become

    networks:
        meet.jitsi: null

(Your volume paths may vary, this was from my output.)

You should review the .env file you have created. The defaults are typically ok for the installation but you may want to change the values once you have become familiar with the setup.

So, you now have the necessary source files to begin the proper installation and configuration.

Create your Amazon ECS cluster using the following command. In this example, we will create an ECS cluster called jitsi-central hosted in the eu-central-1 region.

$ ecs-cli configure --cluster jitsi-central --default-launch-type EC2 --region eu-central-1 --config-name jitsi-central

You will not get any output, but if you check your ~/.ecs/ folder, you will have a file which
will contain output like the following:

version: v1
default: jitsi-central
clusters:
  jitsi-central:
    cluster: jitsi-central
    region: eu-central-1
    default_launch_type: EC2

Now run the following command to create the Cloudformation template and build the cluster. You will see here that we are using an EC2 key pair - this will allow you to ssh into these instances if you need to troubleshoot.

$ ecs-cli up --keypair jitsi-central --capability-iam --size 1 --instance-type m4.xlarge --launch-type EC2

This should generate output like the following:

INFO[0000] Using recommended Amazon Linux 2 AMI with ECS Agent 1.37.0 and Docker version 18.09.9-ce 
INFO[0000] Created cluster                               cluster=jitsi-central region=eu-central-1
INFO[0001] Waiting for your cluster resources to be created... 
INFO[0001] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
INFO[0061] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
INFO[0121] Cloudformation stack status                   stackStatus=CREATE_IN_PROGRESS
VPC created: vpc-0eeacc205a44d937c
Security Group created: sg-08d90fc4ee48edde3
Subnet created: subnet-02ea5c5d22f9692c5
Subnet created: subnet-098b26c7298c21bff
Cluster creation succeeded.

You can check your Cloudformation console and you should now see a new stack which has been created for this.

Next step is to create the Task definition. This is where you will create the definition for the four containers that make up Jitsi. The task definition takes by default the directory name, so we will create a directory and move our docker composer file into that first.

$ mkdir jitsi-central
$ mv docker-jitsi-meet jitsi-central
$ cd jitsi-central/docker-jitsi-meet
$ ecs-cli compose --file docker-compose.yml up 

And you should get output as follows;

WARN[0000] Skipping unsupported YAML option for service...  option name=depends_on service name=jicofo
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=jicofo
WARN[0000] Skipping unsupported YAML option for service...  option name=depends_on service name=jvb
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=jvb
WARN[0000] Skipping unsupported YAML option for service...  option name=expose service name=prosody
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=prosody
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=web
INFO[0000] Using ECS task definition                     TaskDefinition="jitsi-central:1"
INFO[0000] Starting container...                         container=55d4770b-d356-447e-b079-c3c743da5e08/jicofo
INFO[0000] Starting container...                         container=55d4770b-d356-447e-b079-c3c743da5e08/jvb
INFO[0000] Starting container...                         container=55d4770b-d356-447e-b079-c3c743da5e08/prosody
INFO[0000] Starting container...                         container=55d4770b-d356-447e-b079-c3c743da5e08/web
INFO[0000] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/web desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0000] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/jvb desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0000] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/jicofo desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0000] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/prosody desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0012] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/web desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0012] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/jvb desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0012] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/jicofo desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0012] Describe ECS container status                 container=55d4770b-d356-447e-b079-c3c743da5e08/prosody desiredStatus=RUNNING lastStatus=PENDING taskDefinition="jitsi-central:1"
INFO[0018] Started container...                          container=55d4770b-d356-447e-b079-c3c743da5e08/web desiredStatus=RUNNING lastStatus=RUNNING taskDefinition="jitsi-central:1"
INFO[0018] Started container...                          container=55d4770b-d356-447e-b079-c3c743da5e08/jvb desiredStatus=RUNNING lastStatus=RUNNING taskDefinition="jitsi-central:1"
INFO[0018] Started container...                          container=55d4770b-d356-447e-b079-c3c743da5e08/jicofo desiredStatus=RUNNING lastStatus=RUNNING taskDefinition="jitsi-central:1"
INFO[0018] Started container...                          container=55d4770b-d356-447e-b079-c3c743da5e08/prosody desiredStatus=RUNNING lastStatus=RUNNING taskDefinition="jitsi-central:1"

We now have our Task Definition for jitsi-central up and running. Now we just need to amend some configuration options before we can start and then access our Jitsi application.

Changing the configuration

From the Amazon ECS console, select TASK DEFINITION and on the list, select the task you have just created (in the example above, this will be jitsi-central).

When you click on it, you will see a list of versions of the task. If this is the first, you will only see one, but as you changed, edit, configure the tasks, the versioned list will grow (and you will see that each version as the next sequential number added to it - for example, jitsi-central:1, jitsi-central:2, jitsi-central:3, etc)

Click on the newest (highest number) version. On the screen that follows, click on the CREATE NEW REVISION.

Scroll down to the area called CONTAINER DEFINITIONS, you should see the four containers (jvb, prosody, web and jicodo).

The first thing we are going to do is change memory allocations as the defaults are too low. (Note! You will need to experiment with this for your setup, and tune it depending on how busy your server will be)

Click on JVB. On the screen that pops up, change the MEMORY LIMITS (MiB) from the default of 512 to 4096. Click on UPDATE. Change PROSODY and change it to 1024 and JICOFO and change it to 1024, making sure you click on UPDATE each time.

When you get this up and running, you might want to modify the memory settings to optimize the performance of the application

Scroll to the bottom of the screen and click on CREATE. You should get a green box that says you have created a new revision of the task.

We will now update the networking. From this screen click on the CREATE NEW REVISION again. Scroll down to the area CONTAINER DEFINITIONS again. Click on JVB.

Scroll down to the NETWORK SETTINGS and in the box called LINKS enter
'prosody:xmpp.meet.jitsi' and then click on UPDATE.

Repeat this for the JIFOCO and WEB containers.

Select the PROSODY container, and scroll down to the NETWORK settings, and this time enter 'xmpp.meet.jitsi' in the HOSTNAME and then click on UPDATE.

Scroll to the bottom of the screen and click on CREATE. You should get a green box that says you have created a new revision of the task.

Update the running containers

From the Amazon ECS console, click on CLUSTERS and select the jitsi-central (or whatever you have called yours) cluster.

From the screen that comes up, click on TASKS. You should see that revision :1 (or a revision older than what you have just created) is running.

Click on the current, RUNNING task and then select STOP. A warning pop will appear, but click on STOP. You should now have no more running TASKS.

Click on RUN NEW TASK. From the next screen, click on the SWITCH TO LAUNCH TYPE (it will be in small writing and is easily missed).

Select EC2, and then scroll down and select the newest (highest number) revision of the task definition.

Scroll to the bottom and click RUN TASK. When you return to the TASKS dashboard, you may see the status in PENDING, but it should quickly change to RUNNING.

Click on the running task,. You should see a details page, and towards the bottom you should see your four running containers. Click on the WEB, and you will now see the public IP address which is open. However, the Security group has blocked these, so they will not work yet.

Update Security Group

You will need to amend the security group to allow inbound traffic. Change the security group so that it allows incoming UDP on port 10000 from ANY for the container host. To find the security group, look at the EC2 host that is running the ECS containers, and you will find the security group you need to update.

Add an SSL certificate

You can use AWS Certificate Manager (ACM) to generate an ssl certificate or you can upload an existing one via your preferred certificate authority (CA).

From the AWS console, launch the Certificate Manager (it is under Security, Identity and Compliance), and then click on GET STARTED.

If you want to use a certificate from your preferred certificate authority, use the IMPORT CERTIIFICATE and add the key files (in PEM format).

Click on REQUEST A PUBLIC CERTIFICATE and in the next screen enter the domain you are going to be using to access your jitsi server. Click on NEXT.

You will be provided two options for domain validation. If you select DNS, you will need to add a CNAME alias into your existing DNS record (this is pretty standard). If you select email, then the email alias listed in the WHOIS record will be contacted and must respond within a set amount of time. For the purpose if this walkthrough I will select DNS.

In the next screen (TAGS) select REVIEW, and then click on CONFIRM and REQUEST if you are ok with what you have entered.

On the next screen you will now see the details you need to add in your CNAME record. Click on CONTINUE and you will be take to the certificate manager console. Your request should now be in PENDING VALIDATION. This should now take a few minutes once you have updated your DNS records, and you should see the status change to ISSUED.

Configuring a Loadbalancer

Before configuring this, make sure you identify the VPC and Subnet information your cluster has been deployed into. You can do this via the EC2 console via the INSTANCES.

From the Amazon EC2 console, select LOAD BALANCERS (it appears near the bottom) and then click on CREATE LOAD BALANCER.

Select APPLICATION LOAD BALANCER and click on CREATE.

For name, give it 'jitsi-lb'

Under LISTENERS add HTTPS by clicking on ADD LISTNER.

Under AVAILABILITY zones, select the right VPC and then select two Availability zones that your load balancer will work across.

Click on NEXT CONFIGURATION, and from the CONFIGURE SECURITY SETTINGS you should now be able to select the certificate you created from the previous step. Click on CONFIGURE SECURITY GROUPS.

Accept the default, and click on CONFIGURE ROUTING. Provide a name 'jitsi-target' leave target type to instance but change the protocol to HTTPS and the port to 8443. Click on REGISTER TARGETS.

On the bottom half of the screen (INSTANCES) click on the instance that is the ECS cluster and then click on ADD TO REGISTERED. Depending on how many hosts you have you will need to add them all here. (in this default walkthrough I only configured one, so I will only add one). Click REVIEW and then CREATE.

This will now take some time to provision the load balancer. When it completes, you will need to take the A Record details and update your DNS so that your host resolves to the load balancer.

Once this has completed, you should configure HTTP to HTTPS redirection from the LOAD BALANCER. Select the load balancer you have just created, and click on the LISTENERS tab. Click on the HTTP:80 and select EDIT and then delete the current default action and add a new one that does a redirect to 443.

Testing

You should now be able to access your Jitsi instance from the domain name you are using, and connect to it from your browser.

Troubleshooting the installation

If you run into issues, then open up the security group for the ECS cluster and allow SSH access from your specific IP address. This will then allow you to use the ssh key to log into the host running the containers, and then use the following commands to help troubleshoot:

$ docker ps - give you a list of the running containers with container IDs
$ docker exec -it {container id} bash - allow you to get a root user terminal into the container
$ docker logs {container id} - allows you to grab stdOut logs

Note! remember these are container optimised images, so you will not have any of the tools you are used to. In order to install these to help troubleshooting, you will need to run

apt-dpkg-wrap apt-get update && apt-get install {package}

some useful packages to know are 'vim' for editing, 'dnsutils', 'iputils-ping' for network testing

You can use the ecs-cli command line tool to monitor, stop and start your clusters. Run the ecs-cli command without parameters or consult the online documentation for more help.

Changing the size of your cluster

If you want to chance the size of your cluster, you have a couple of options:

• use the 'ecs-cli scale --capability-iam --size x' where x is the number of instances you want to scale your cluster to (you can scale up or down)
• You can also do this via Cloudformations. Locate the stack that was used to create your cluster (it should be called something like amazon-ecs-cli-setup-{clustername}) and then use the UPDATE and follow through the instructions to change the cluster configuration.

You might need to do this if you want to have more CPU/Memory for your running Jitsi instances.

Deleting/uninstalling

Once you do not need these capabilities, you should make sure that you remove the Amazon ECS Tasks and Cluster. You can use the CloudFormation script to automate the deletion of this via the ecs-cli command line tool

$ ecs-cli service down

Advanced installation

As per the Amazon EC2 instance, refer to the project installation documents here to get more details on how to configure Jitsi behind a NAT instance. There will probably be more complexities getting some of those working on Amazon ECS, so get in touch and let us know how you get on.

Supporting the open source project

Thank you!

Thanks to Massimo and Javier and Ian for getting me started. Huge thanks to Michael Moussa who got me 90% of the way there and Brent Langston for sanity checking, and then Saul Corretge from 8x8 who got me past the finish line. Final thank you to the Jitsi community who have put so much craft into this project. This has been a truly collaborate experience.

Support the project

Remember that this is only possible because of the Jitsi open source project. If you do use this, make sure you provide feedback, contributions or anything else that the project can use to help with their mission.

Thank you https://jitsi.org/ for Jitsi!

Related posts

If you found this post useful, be sure to check out the post from Alex Casalboni on How to live stream meet-ups on twitch without any special equipment. This is well worth your time reading. Thanks Alex!.