Giacomo Vacca

Fan of Homer ? So am I, and as sometimes happens I'm a fan who could join the team! If despite the title of this post you're still reading, then it's a good sign and we can move on. Homer is a vast project that aims to provide a tool, with a GUI, to correlate all the signalling, RTCP stats, events, logs in your RTC network. It focuses heavily on SIP , for historical reasons, but it's also an extendible framework to store other types of signalling, correlate data, and compute statistics. People browsing their github account are often heard saying "Do they have this too? And this ? Wow!". It is compatible off the shelf with common applications like Kamailio, opensips, FreeSWITCH, Asterisk, so if you're into VoIP, adding Homer to your platform is as easy as installing it and telling your apps where to send their data. There are also standalone tools like captagent ,  nodejs apps to parse and collect specific logs, to be associated with the re...

This is a topic I really care about. Please take a look at the slides (they are quite verbose) used in a seminar at a local developers group: Docker and Puppet for Continuous Integration from Giacomo Vacca

The other day I was browsing the slides of "Continuous Deployment with Jenkins" , from PuppetLabs . One sentence in particular I found relevant for what I was doing, and important in general: Puppet manifests are code too. To be honest, I don't think I need to sale this very hard, so I'll proceed to a practical consequence: unit testing for puppet modules . Unsurprisingly, there's a app tool for that: rspec-puppet . At least this is what I've been using for some time and find very useful and easy to use. I've even created some Jenkins jobs just to unit test Puppet modules. You can find a tutorial for rspec-puppet here . Feel free to leave this article, read the tutorial, experiment a little and come back later. What I wanted to share is some tricks/settings that I had to use, which I haven't found in one single place so far. As you can see in the tutorial, rspec-puppet generates a dir skeleton for you (with the command 'rspec-puppet in...

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

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

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

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

Automatic Configuration Management For Kamailio And Asterisk from Giacomo Vacca

A few months ago a question in the very useful 'ask puppet' site attracted my attention. The authors of Beginning Puppet were asking for feedback about the desired content. Since my answer has had some success, I'd like to report it here: These are the things I would have liked to see as soon as I started experimenting with Puppet (in no specific order - this is mainly a brain dump): What's a catalogue and how Puppet builds it Recommended file structure for Puppet manifests How to divide your infrastructure in environments A clear indication that Puppet doesn't guarantee an "order of execution", and how to define dependencies between resources and classes (i.e. the "arrow" syntax to ensure that a class is always applied before/after another one). Before ever writing a module, how to test it (and as a consequence, Continuous Integration for Puppet modules) How to publish a module on github or puppetforge A "build-up example...