Deploying OpenVidu Pro on AWS

• Deployment instructions
  • 1) Access to the console of AWS Cloud Formation
  • 2) Select 'Create Stack' 🠚 'With new resources'
  • 3) Option 'Specify template' 🠚 'Amazon S3 URL' with the following URL
  • 4) Specify stack details
  • 5) Create your stack
  • 6) Administration
• Scalability
  • Set the number of Media Nodes on startup
  • Change the number of Media Nodes on the fly
• Updating OpenVidu Pro configuration
• Troubleshooting
  • CREATE_FAILED CloudFormation stack
  • Kurento Media Server crash

Deployment instructions 🔗

1) Access to the console of AWS Cloud Formation 🔗

Go to CloudFormation

2) Select Create Stack 🠚 With new resources 🔗

3) Option Specify template 🠚 Amazon S3 URL with the following URL 🔗

https://s3-eu-west-1.amazonaws.com/aws.openvidu.io/CF-OpenVidu-Pro-latest.yaml Copy

To deploy a fixed version, including previous ones, replace latest with the desired version number.
For example: https://s3-eu-west-1.amazonaws.com/aws.openvidu.io/CF-OpenVidu-Pro-2.14.0.yaml

4. Specify stack details 🔗

First of all, indicate a name for your deployment. Next fill each section of the Parameters formulary:

Domain and SSL certificate configuration 🔗

Configuration for your CloudFormation stack certificate. We provide 3 different scenarios: you can use the default SELF-SIGNED CERTIFICATE stored in the application (users will need to accept the browser security alert) or if you have a custom domain, either allow LET'S ENCRYPT to automatically generate a valid and free certificate for your domain or use your own CUSTOM CERTIFICATE if you already have one (and for some unknown reason you still want to use that).

If you are using LET'S ENCRYPT CERTIFICATE, of course you will need to register your ElasticIP in your DNS hosting service and associate it with the fully qualified domain name. Until your domain name is not accessible through the public IP you chose, this deployment won't work

OpenVidu configuration 🔗

There are many other configuration values that can be set once the deployment has completed. Check out section Updating OpenVidu Pro configuration once the deployment is done.

Kibana configuration 🔗

Username and password for the Kibana service deployed with OpenVidu Pro. You will need these credentials for later access to the Kibana dashboard of your OpenVidu Pro deployment. Visit section Detailed session monitoring for further information.

EC2 Instance configuration 🔗

These properties configure specific details of the EC2 machines that will be launched by CloudFormation.

Networking configuration 🔗

Other configuration 🔗

These properties configure some other options of your stack.

5. Create your stack 🔗

No extra options are necessary. Click on Next ➞ Next ➞ Create stack

CREATE_IN_PROGRESS status will show up. You will now have to wait for a few minutes (about 10) until it shows CREATE_COMPLETE.

To connect to OpenVidu Inspector and the Kibana dashboard, simply access Outputs tab after CREATE_COMPLETE status is reached. There you will have both URLs to access both services.

To consume OpenVidu REST API, use URL https://OPENVIDUPRO_PUBLIC_IP/. For example, in the image above that would be https://ec2-34-244-193-135.eu-west-1.compute.amazonaws.com/ using AWS domain. When deploying with a custom domain name (which you should do for a production environment), of course you must use your domain name instead.

If you have deployed OpenVidu Call you can also access to it through that same URL. You can now add your own application to your instance. To learn how check out section Deploy OpenVidu based applications.

6. Administration 🔗

AWS deployments of OpenVidu Pro are internally identical to on premises deployments. This means that you can manage OpenVidu platform very easily by connecting to your instances through SSH.

• OpenVidu Server Pro Node: located at the default installation path /opt/openvidu as root user ($ sudo su), you will be able to manage the services as explained in on premises OpenVidu Server Pro Node administration.
• Media Nodes: located at the default installation path /opt/openvidu as root user ($ sudo su), you will be able to manage the services as explained in on premises Media Nodes administration.

Scalability 🔗

Set the number of Media Nodes on startup 🔗

When filling the CloudFormation form, simply set the desired number in section OpenVidu configuration.

In section EC2 Instance configuration you can choose the size of your OpenVidu Server Pro Node and your Media Nodes.

Change the number of Media Nodes on the fly 🔗

You can launch and drop Media Nodes dynamically in two different ways:

From OpenVidu Inspector 🔗

In Cluster page you can launch and drop Media Nodes just by pressing buttons.

With OpenVidu Pro REST API 🔗

You can programmatically launch and drop Media Nodes from your application by consuming OpenVidu Pro REST API.

• Launch a Media Node: POST /pro/media-nodes
• Drop a Media Node: DELETE /pro/media-nodes

WARNING: there are some important aspects to keep in mind when launching and dropping Media Nodes in AWS deployments, especially through OpenVidu Pro REST API (OpenVidu Inspector UI is quite self-descriptive):

• Trying to drop a Media Node which is currently hosting an OpenVidu Session will fail by default. You can manage the drop policy when calling DELETE /pro/media-nodes through parameter deletion-strategy.
  
  
• Launching/Dropping Media Nodes in AWS OpenVidu Pro deployments will automatically start/terminate EC2 instances. The termination of an EC2 instance that was hosting a removed Media Node will be done only when it is safe. This moment is reached when OpenVidu Webhook event mediaNodeStatusChanged is triggered with value terminated.

Updating OpenVidu Pro configuration 🔗

You may want to change the current configuration of an existing OpenVidu Pro cluster. This configuration includes all of the parameters listed in these pages:

• OpenVidu CE configuration
• OpenVidu Pro configuration

Once the cluster is running, there are different ways you can update the value of the configuration parameters. Take into account that all of them require restarting your OpenVidu Server Pro process, so any active OpenVidu Session will be terminated.

1) With OpenVidu Inspector 🔗

OpenVidu Inspector allows you to restart the OpenVidu Server Pro process from Config page just by filling a formulary.
More information here.

NOTE 1: take into account that not all configuration properties are able to be updated this way
NOTE 2: new values will be stored and remembered, so they will be used when OpenVidu Server Pro is restarted in the future

2) With OpenVidu Pro REST API 🔗

You can consume REST API method POST /pro/restart to programmatically restart the OpenVidu Server Pro process and update its configuration values.

NOTE 1: take into account that not all configuration properties are able to be updated this way
NOTE 2: new values will be stored and remembered, so they will be used when OpenVidu Server Pro is restarted in the future

3) Manually connecting through SSH 🔗

The ultimate and most definitive way of updating the configuration parameters of an OpenVidu Pro cluster is connecting to the OpenVidu Server Pro Node through SSH and changing the desired values:

1. SSH to the OpenVidu Server Pro Node machine using your private rsa key
2. Using root user with sudo su command, go to OpenVidu Pro installation folder (default and recommended is /opt/openvidu)
3. Update file .env with the new configuration values
4. Restart OpenVidu Server Pro with ./openvidu restart

Keep an eye on the OpenVidu logs that will automatically display after restarting the service to check that everything went well.

Troubleshooting 🔗

CREATE_FAILED CloudFormation stack 🔗

First of all, an AWS CloudFormation stack may reach CREATE_FAILED status for missing a default VPC. Check out this FAQ on how to fix it.

If that is not the problem, then follow these steps:

• 1) Try to deploy again, but this time disabling option Rollback on failure (Configure stack options 🡆 Advanced Options 🡆 Stack creation options). This will prevent the instance to be terminated in case of failure so logs can be gathered. Once you re-deploy with this option, the stack will still fail but you’ll be able to access instances through SSH and retrieve some files to debug the problem.

• 2) We will also need the parameters you've used to deploy, to check possible problems in their values

• 3) Once you have performed step 1) and the stack creation has failed, please SSH into the instances created and share with us Cloudformation logs

  • /var/log/cloud-init.log
  • /var/log/cloud-init-output.log
    
    

• 4) Get also the log output of all the services with this command and share with us the output file:

  • docker-compose logs -f

AWS deployments of OpenVidu Pro work under the hood in the exact same manner as on premises deployments. So everything explained in Troubleshooting section of on premises deployments also applies to AWS deployments. There you have detailed instructions on how to debug all of OpenVidu Pro services in case some unexpected problem appears.

Kurento Media Server crash 🔗

Sometimes Kurento Media Server (the service in charge of streaming media inside of Media Nodes) may crash. If this happens on a regular basis, or better, you have isolated a specific use case where KMS always crashes, then perform the following steps to collect a crash report that will help us fix the issue.

In AWS deployments of OpenVidu Pro, KMS crash reports are enabled by default. You can directly get them with the following steps:

1) Download the KMS crash reports 🔗

ssh -i AWS_SSH_KEY ubuntu@MEDIA_NODE_IP "sudo tar zcvfP ~/core_dumps.tar.gz /opt/openvidu/kms-crashes/*"
scp -i AWS_SSH_KEY ubuntu@MEDIA_NODE_IP:~/core_dumps.tar.gz .

Replace AWS_SSH_KEY with the path to the SSH key of your Media Node EC2 instance and MEDIA_NODE_IP with its IP address. This only applies to a single Media Node. If you have more Media Nodes experiencing KMS crashes, perform these same steps in all of them. Send us the resulting zipped report files.

2) Clean the KMS crash reports 🔗

So as not to consume too much hard drive, delete the crash reports once you have downloaded them. IMPORTANT: obviously, do NOT do this before downloading the report.

ssh -i AWS_SSH_KEY ubuntu@MEDIA_NODE_IP "sudo rm /opt/openvidu/kms-crashes/* && sudo rm ~/core_dumps.tar.gz"

Replace AWS_SSH_KEY with the path to the SSH key of your Media Node EC2 instance and MEDIA_NODE_IP with its IP address. This only applies to a single Media Node and must be performed for each Media Node from which you downloaded a crash report.