Getting started with Jitsi, an open source web conferencing solution

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 organization, 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 about Amazon Chime, visit https://thinkwithwp.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 walk-through 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 on the Jitsi GitHub repository, but this tutorial will enable you to host your own version of this application. I will help you through installing this project on Amazon Web Services (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 8×8(www8x8.com) that also operates Jitsi’s popular sample deployment at meet.jit.si

This tutorial will enable you to host your own version of this application, with the core functionality. I have provided two parts: one for those who want to run this via Amazon Elastic Compute Cloud (Amazon EC2) instances, and the other for those who prefer to use containers, so running this through the Amazon Elastic Container Service (Amazon ECS).

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

Let’s begin with the Amazon EC2 part. If that is not your thing, jump ahead to the Amazon ECS part.

Deploying Jitsi on Amazon EC2

Prerequisites

You will need the following to complete this tutorial:

AWS Account: You will be configuring services, so you need an account with a user that can provision those services.
DNS provider: You will need to register your application via DNS as this is needed to obtain an SSL certificate. You can use Amazon Route 53 or other DNS providers.

Note: If you do not use DNS, you will be able to get Jitsi up and running, 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

First you must create a running Linux instance on which to run your Jitsi server.

1. SSH keypair

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.

This is important: Secure access to your EC2 instance. Make sure that you do not open up port ssh (22) to the world. Either limit it just to your IP address, or better still, use an existing bastion or jump host you have set up 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 launching the instance, you must 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, which is outside the scope of this article.

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 tutorial, I use the t3.large instances; these provide 2vCPUs and 8GB of memory, which 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, and
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.

Tip: When looking at sizing options, network performance and memory are the two key parameters to prioritize.

Instance launch instructions

From the AWS console, select the region to which you want to deploy your Jitsi server, and make sure it matches where you have the key pair.
Go to the EC2 console, and select Instances.
Click on Launch InstanceE.
In the search box type Ubuntu and hit return. Select the Ubuntu 18.04 LTS.
In the instance type, select the instance type you have decided (the bit above) and then click Next: Configure Instance Details.
Accept defaults on the next page and click on Next: Add Storage.
Accept defaults on the next page and click on Next: Add Tags.
Accept defaults on the next page and click on Next: Add Security Groups.
Change the security group name to Jitsi-Security-Group.
Change the SSH Source to your IP address (or your bastion host if you are using that).
Add HTTP and HTTPS rules from source Anywhere.
Add custom TCP port 4443 rule from source Anywhere .
Add custom UDP port 10000 rule from source Anywhere .
Click on Next: Review and Launch.
Click on Launch.
On the pop-up list, select the ssh key you created and tick the acknowledge.
Click on Launch Instance to kick off the creation, and on the following screen click on View Instances.

For this to provision and set up will take a few minutes. 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, which you will need in the next section, so note this down.

Allocate Elastic IP

To ensure that your instance keeps its IP during restarts that might happen, configure an Elastic IP. From the EC2 console:

Select ELASTIC IPs.
Click on the ALLOCATE ELASTIC IP ADDRESS.
Select the default (Amazon pool of IPv4 addresses) and click on ALLOCATE.
From the ACTIONS pull down, select ASSOCIATE ELASTIC IP ADDRESS.
In the box that comes up, note down the Elastic IP Address, which will be needed when you configure your DNS.
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.

Set up 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

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

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

# vi /etc/systemd/system.conf

Make sure you have the following values; you can either and comment 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 about a minute, then you will be 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 whether you want to generate certificates or use existing ones. For this part, select the default option of generate certificates.

The installation process should complete after you hit Return, which will not take more than a couple of minutes. Output similar to the following will be displayed:

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 need to generate the certificates. From the command line run:

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

You will prompted for your email address, and after you have entered that, 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 are configured, and the application is 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 must be aware of are as follows:

/var/log/jitsi: Contains the Java system logs as well as the application logs.
/usr/share/jitsi-meet: 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 do not need to run this 24×7, 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 to get more details on how to configure Jitsi behind a NAT instance. I have tried to keep it simple in this tutorial to minimize the cost of setting up and running an instance.

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 a GitHub repository has Docker instructions. 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 macOS, I suggest you try running this via an AWS Cloud9 IDE environment. The instructions 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 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.

Prerequisites

You must install and set up 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.
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; make sure they are all the latest versions and up and running before proceeding.

ECS-CLI: Install the AWS ECS client link.
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 into which you are going to launch your EC2 instances.

Modify your docker-compose.yml

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

$ git clone https://github.com/jitsi/docker-jitsi-meet &amp;&amp; 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 okay for the installation, but you may want to change the values once you have become familiar with the setup.

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 that 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 AWS CloudFormation console and you should now see a new stack that has been created for this.

The next step is to create the taskDefinition, which is where you will create the definition for the four containers that make up Jitsi. By default, the taskDefinition takes 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 taskDefinition for jitsi-central up and running. Now we need to amend configuration options before we can start and then access our Jitsi application.

Changing the configuration

From the Amazon ECS console, select Task Definition and, from 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 change, 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 and 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; you will need to experiment with this for your set up, 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 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, which 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, the status may be Pending, but it should quickly change to Running.

Click on the running task, which should display a details page, and with your four running containers displayed near the bottom. Click on Web, which will show 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 ACM (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 Certificate 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 tutorial, 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 taken 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 Load Balancer

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 Listener.

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 tutorial, I only configured one, so I will only add one. Click Review and then Create.

Provisioning the load balancer will take time. 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

Remember these are container optimized 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}

Useful packages to know are vim for editing, dnsutils, and 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 change 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 AWS CloudFormation. 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 on GitHub to get more details on configuring Jitsi behind a NAT instance. There will probably be more complexities getting some of those working on Amazon ECS, so get in touch via the comments below and let us know how you get on.

Supporting the open source project

Thanks to Massimo and Javier and Ian for getting me started. Huge thanks to Michael Moussa who got me 90 percent of the way there and Brent Langston for sanity checking, and then Saul Corretge from 8×8 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 collaborative experience.

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.

What other open source projects do you know that can help remote workers?

Let us know in the comments whether there are other open source projects that can help remote workers to better collaborate and work together if you’d like tutorials on how to use them with AWS solutions.

Feature image by Pixabay.

AWS Open Source Blog

Getting started with Jitsi, an open source web conferencing solution

Introducing Jitsi

History of Jitsi

Deploying Jitsi on Amazon EC2

Prerequisites

Provision your Amazon EC2 instance

1. SSH keypair

2. Launch instance

Instance launch instructions

Allocate Elastic IP

Set up your DNS

Install and configure Jitsi

Managing the instance

Optimizing costs

Deleting/uninstalling

Advanced installation

Deploying Jitsi on AWS ECS

Container instructions

Prerequisites

SSH key pair

Modify your docker-compose.yml

Changing the configuration

Update the running containers

Update security group

Add an SSL certificate

Configuring a Load Balancer

Testing

Troubleshooting the installation

Changing the size of your cluster

Deleting/uninstalling

Advanced installation

Supporting the open source project

What other open source projects do you know that can help remote workers?

Resources

Follow