Performing Red5 Pro Updates

metaverse
SHARE

Updates. You know, those annoying little pop-ups that just keep appearing no matter how many times you close them. Who even has time to restart their computer, right? Nonetheless, you can only click "Remind me tomorrow" so many times before something essential noticeably stops working. You certainly can’t perform your job correctly without proper emoji… Continue reading Performing Red5 Pro Updates

Updates. You know, those annoying little pop-ups that just keep appearing no matter how many times you close them. Who even has time to restart their computer, right?

Nonetheless, you can only click "Remind me tomorrow" so many times before something essential noticeably stops working. You certainly can’t perform your job correctly without proper emoji insertion.

With that in mind, we would like to outline some best-practice procedures to ensure that the Red5 Pro upgrading process goes smoothly.

But before that…

Why Update?

Quite simply, it makes everything run better. Red5 Pro updates can improve performance, increase stability (bug fixes), and maintain security. Not to mention we add new features. It’s all well worth taking the time to install.

Oftentimes, we will release updates to the server and the client side (SDK) separately. While having to upgrade both your client-side and server-side code adds another step, it is often necessary, especially with certain new features. There may be changes to the server that have to be enabled in order for the feature to work properly.

For example, in one of our previous releases, we added SRTP (or encryption) to the mobile SDK streams. In order for this new feature to work, the server side needed to know how to handle the symmetric key exchange and to decrypt and re-encrypt the incoming and outgoing data. It became pretty clear that in order for this feature to work we had to update both the server and client side at the same time.

Even though we are always working to improve Red5 Pro, we do our best to consolidate everything into manageable updates. We don’t want you constantly updating your system every month, but we also want to make sure that you have everything you need. It’s a balancing act.

As a developer-focused product, Red5 Pro gives you the flexibility and power to build dynamic, live streaming media apps. As such, it remains imperative that you ensure that your app still works with the updated implementation.

In that regard, here are some pointers to help you upgrade your Red5 Pro app.

How to Update

We usually recommend a Blue/Green style rolling updates strategy.

Itay Shakury defines the Blue/Green process this way:

Spin up a new separate deployment for the new version, without affecting the current one. Test the new version, and once ready start routing users to the new version.

So how does this apply to Red5 Pro installations? Let’s assume that you are upgrading an Autoscale setup with a load balancer in front of the Stream Manager(s). With this setup, you create a secondary autoscale cluster installation (optionally with all of your custom code included). We’ll call this secondary one Blue and your production environment Green. Blue will have its own load balancer with its own unique domain name with its DNS configured to point to its own unique stream manager. You can then install the update on the Blue version updating the Stream Manager(s), Origin(s), Relay(s), and Edge(s).

blue/green upgrading

Now with all of that done, you point your client-side code to the Blue domain, and it automatically starts using the new system. Of course, if there’s also been a Red5 Pro SDK update, then you need to update your app to use that as well.

The duplicate server-side environments ensures that you will have your original system (Green) running untouched while you test the secondary system (Blue) for any irregularities. Once you’ve ironed out any bugs (if any) and are comfortable that everything is working correctly, you switch the primary DNS to point to the Blue Load balancer, which in turn points to the updated Stream Manager. At that point, you can shut down the now deprecated system, and you can now call the Blue environment your new Green.

If your app doesn’t make use of Red5 Pro autoscaling, and you only have a single server deployed, it’s even easier. You just install a new version of Red5 Pro on a single instance leaving your production version alone. Then change your client-side code to point to the updated server while you test. Once things look good, update the production server with the latest code.

For more on upgrading with specific cloud providers, and upgrading autoscaled Red5 Pro with the Stream Manager, please follow our documentation:

A Note on Stream Managers and Load Balancers

As you can see from the Blue/Green Upgrade process we’ve outlined above, using a load balancer with your application is extremely useful. If you currently don’t use one, you may want to as this will make the updating process much much easier. Since the Load Balancer sits in front of the Stream Manager, as soon as you turn off your production environment, your clients will automatically be connected to the new Stream Manager of the upgraded system.


If you’d like to find out more about our low-latency, fully scalable live streaming solution, please send a message to info@red5.net or give us a call.