Skip to main content

Posts

Dockerize a node.js WebSocket server in 5 minutes

Docker is an incredibly useful tool to build prototypes of Linux hosts and applications. You can easily build a network of servers inside a single virtual machine, with each server represented by a docker container. Clients can access the services on the same IP address, but different ports. In this post I'd like to talk about a common prototype case in WebRTC  platforms: a WebSocket server. This will be a node.js server and will run inside a Docker container (hosted by an Ubuntu Trusty VM). The server logic can be as complex as you can imagine, but since it's not the point of this post I'll keep it as simple as the server example in the node.js websocket module : The WebSocket server will listen on port 8080, accept incoming connections, send back "something" upon client connection, and log the content of the messages from the clients. We can assume all the files in this article are in the same folder, and we're cd into it. The server logic is...

Easy VPN setup accross multiple sites

I recently had a scenario where I needed to connect servers belonging to: - Digitalocean , on data center X - Digitalocean, on data center Y - A private data center and each architecture needed to be replicated on a number of "logical" environments (e.g. 'development', 'testing', 'production'). They needed to "see" each other, in a secure way. Note that virtual machines on Digitalocean (they call them 'droplets') can belong to different data centers. When the droplets use the optional private interface there are two things to consider: 1. Traffic inside the same data center is potentially visible to any equipment on the same data center. In other words, the fact that two droplets belong to the same customer account doesn't mean that their private traffic is isolated from any other traffic belonging to droplets on other accounts. You are responsible to secure that traffic. 2. Droplets on different data centers cannot ...

Testing a PR for Asterisk Puppet module on Docker

Just wanted to share what approach I'm following to test Pull Requests for the trulabs Asterisk Puppet module . Run a docker container, choosing the base target distribution, e.g. one of: docker run -i -t debian:wheezy /bin/bash docker run -i -t ubuntu:precise /bin/bash docker run -i -t ubuntu:trusty /bin/bash Inside the Docker container, set up some preconditions: apt-get update apt-get install -y git apt-get install -y puppet apt-get install -y vim Clone the git project: mkdir -p git/trulabs cd git/trulabs git clone https://github.com/trulabs/puppet-asterisk.git cd puppet-asterisk Create a new branch: git checkout -b PULL_REQUEST_BRANCH master Checkout the project from which the Pull Request is created: git pull https://github.com/CONTRIBUTOR/puppet-asterisk.git PULL_REQUEST_NAME Build and install the Asterisk Puppet module built with this Pull Request changes: puppet module build . puppet module install pkg/trulabs-asterisk-VERSION.tar.gz ...

Bridging WebRTC and SIP with verto

Verto is a newly designed signalling protocol for WebRTC clients interacting with FreeSWITCH . It has an intuitive, JSON-based RPC which allows clients to exchange SDP offers and answers with FreeSWITCH over a WebSocket (and Secure WebSockets are supported). It’s available right now with the 1.4 stable version (1.4.14 at the moment of writing). The feature I like the most is “ verto.attach ”: when a client has an active bridge on FreeSWITCH and, for any reason (e.g. a tab refresh) it disconnects, upon reconnection FreeSWITCH automatically re-offers the session SDP and allows the client to immediately reattach to the existing session. I have not seen this implemented in other places and find it extremely useful. I’ve noticed recently that this does not fully work yet when the media is bypassed (e.g. on a verto-verto call), but Anthony Minnesale, on the FreeSWITCH dev mailing list said this feature is still a work in progress, so I’m keeping an eye on it. Initially I was ex...

Don't trust the kernel version on DigitalOcean

This was tricky. I was setting up a VPN connection with a newly built DigitalOcean droplet (standard debian wheezy 64bit in the London1 data center). The connection is based on openvpn , and it's the same on many other nodes, but openvpn wasn't starting properly (no sign of the tun interface). Googling the problem brought me to this reported debian bug , where apparently the problem was associated to an older version of the linux kernel. But I had the latest installed: ii  linux-image-3.2.0-4-amd64          3.2.63-2+deb7u1               amd64        Linux 3.2 for 64-bit PCs The reason why this problem was present is that the version actually loaded was different! Apparently [...] it seems that grub settings are ignored on digital ocean, and that you instead have to specify which kernel is booted from the Digital Ocean control panel, loaded from outside the droplet [...] So to see w...

Deploying Kamailio with Puppet

Almost three years ago I started automating the deployment of all server-side applications with Puppet . One of the key applications in Truphone's RTC platform (and arguably in most of VoIP/WebRTC platforms today) is Kamailio , so with some proper encapsulation it’s been possible to build a Puppet module dedicated to it. This is now publicly available on PuppetForge . Puppet Forge is a public repository of Puppet modules. We use many of them, and they can be incredibly useful to get you up to speed and solve common problems. You can also fork it on github , if you want. You can use this module in different ways: To quickly deploy a kamailio instance, with default configuration files. As the basis for a custom configuration, where you use the official debian packages but with your own configuration details and business logic. The first approach is very simple. Imagine you start from and empty VM or base docker container: all you have to do is install pup...

Puppet module support on 2.7.13

Yesterday I just noticed that on Ubuntu Precise, with a stock Puppet installation (2.7.13), 'puppet module' ( a tool to build and install modules ) was not available. Soon found an explanation on superuser : 'puppet module' was released with 2.7.14. There is a straightforward way to get out of this: upgrade Puppet as recommended by PuppetLabs and go straight to version 3 (unless of course you have constraints to stay on 2). These steps will allow you to get Puppet directly from PuppetLabs repos (just choose the target distribution). At the moment of writing this procedure would upgrade Puppet on Ubuntu Precise from '2.7.11-1ubuntu2.7' to '3.7.3-1puppetlabs1'.