Automatic Configuration Management for Kamailio and Asterisk in the era of Puppet

Editor's Notes

• #2: This presentation is about a practical example of automating the configuration of Linux-based RTC platforms, with particular emphasis on Kamailio and Asterisk. QUESTIONS TO AUDIENCE: Who’s being deploying Asterisk in any sort of automated fashion? Using Puppet? Using something else, like Chef, Ansible, Salt? Even if you’re already doing it, say for example with Chef, I hope this presentation will be useful to challenge or corroborate your process.
• #3: Truphone is a Global Mobile Network Operator: you can use Truphone in more than 200 countries, and in 66 countries like you do in your home country. Truphone Labs takes care mainly of the Truphone App. MISSION: “a phone in your mobile device”. iOS, Android, BB apps. Platform: Open Source applications and libraries. (and of course Asterisk plays – and has played since day 1– an important part in this)
• #4: I’ve been working with VoIP-related technologies for the last decade. DEV background.
• #5: THIS PRESENTATION IS ALSO ABOUT A PERSONAL PATH TOWARDS DEVOPS. I think the typical path to embrace configuration management is coming from a sysadmin role and willing to simplify your life. I come from a different direction: deploying applications and doing system integration, and willing to automate anything that’s possible: “Infrastructure as code”. Also wanted to: Have more time for dev, less for ops-related stuff Share a common language with Ops Get configuration documentation FOR FREE! Play with something new!
• #6: In 2012 I started challenging that only infrastructure and not apps configuration were automatically managed. Was Master/Slave. I started to move applications configuration into Puppet, incrementally. I reckon THE HARDEST PART IS GOING FROM 0% TO ABOUT 50%, then it’s all downhill. Now we have almost 100% of the apps deployed with Puppet, including pre-requisites, firewall, monitoring, etc.
• #7: Wheezy: puppet 2.7 Trusty: puppet 3.4
• #8: VISIBLE IMPROVEMENTS I’m afraid I don’t have terribly accurate numbers, but the order of magnitude – the important thing here – is about right. Build and configure a new VM From weeks to < 5’ Incl. pre-req libs, f/w, swap, Nagios, TCP ka, etc Configure an application of a new VM From hours to minutes From .deb + manual config to all automated Easier Triage/debugging Fewer cfg-related defects, quicker assessment From 3-ways diff to git tools Simpler Change Requests Require fewer iterations before approval Fewer surprises when simulating the deployment Easier to rollback (but fewer rollbacks needed) Higher team satisfaction Efforts shifted from deployment time to deployment preparation Increased confidence Deployments are now considered “cheap” and “low-risk”
• #9: Puppet has a “community version” or “enterprise version” (as Chef and most of the others)
• #12: Possibly an overlooked feature/potentiality of Puppet is that it does not mandate a Master! Master/Slave Need to build/configure master (SPOF) Need to secure master/slave connections More secure Standalone (our choice – so far!) No need to have a master at all Easier to extend Need care in handling sensitive data
• #15: This configuration will pull kamailio deb packages from sipwise repo (which is the official kamailio debian repo).
• #16: A very common structure for a Puppet module. Templates are based on the default configuration provided inside the official debian packages. You can change the templates depending on your needs.
• #17: Practical example: build a kamailio instance with WebSockets support. Let’s call it kamailio_ws. See the relevant configuration elements here: with_websockets set to TRUE. Here we’re telling Puppet that the installation phase requires the instantiation of a trulabs-kamailio class with those configuration properties. Puppet will do the job for us.
• #18: The surrounding conditions for such a host would be: Firewall TCP keepalive settings SSL certificates checks Swap memory configuration Monit Nagios fail2ban Other tools You can build the node with trulabs-kamailio and other 3rd party modules (e.g. puppetlabs-firewall), depending on your needs.
• #20: Finally, let’s move to Asterisk. If we think about the main components involved in an installation: pre-requisites: apt sources, DAHDI if needed. Packages to be installed: core, sounds, perhaps your own packages from your repos Configuration files (sip.conf, rtp.conf, etc) to set up TLS, ODBC, etc
• #21: A minimal configuration is the following. See we have the option to enable and manage directly asterisk as a service. We can also enable listening on TCP (default: disabled). This happens by interacting with the configuration files templates.
• #22: For example, if I apply the previous node definition to a debian wheezy machine, these packages are installed. (this is just the action of installing ‘asterisk’, which will pull the other packages automatically). This happens because the default value for the asterisk package is “latest”. You can set whatever version you want (as long as it’s reachable with the current apt source configuration).
• #23: Other things that are happening: asterisk is configured to listen on UDP 5060 and TCP 5060. This can be changed by specifying udpbindaddr and tcpbindaddr attributes when instantiating the class.
• #24: If you want to manage Asterisk’s configuration files outside of the basic trulabs module, You can do so by asking the module not to manage the configuration, and by Managing the desired configuration file(s) directly in Puppeteeze.
• #25: In analogy with “But I want my config files”, you can specify a custom version. You need to set up apt sources properly.
• #26: In analogy with what seen with kamailio, here’s the minimum amount of instructions needed to have an asterisk app up and running. You can try this easily inside a docker container.
• #27: You can add this to your asterisk node definition, so that you protect access (iptables) to UDP 5060 from kamailio only. The arrow in this slide shows an interesting thing: a FACT. Facts are pre-set variables that you can use in your manifests. They make it possible for you to refer to local properties automatically. On the other hand, $kamailio_ip is a variable that you can set, and will determine, in this example, the f/w configuration.