Nginx as reverse proxy for RabbitMQ MochiWeb server

Hi all,

I’ve suffered a hard day trying to find the solution to a problem that apparently has no a clear solution in the internet, at least, i couldn’t find it. So, i made mine.

RabbitMQ offers several plugins to enhance its usability, like the RabbitMQ management plugin (provides an HTTP-based API for management and monitoring of your RabbitMQ server, along with a browser-based UI and a command line tool) among others. Every plugin that requires any HTTP interaction works over a MochiWeb server automatically installed once installing the plugin. This server offers the 55672 port (default one) to interact with the API. For example, you can ask for the current RabbitMQ queues.

curl -u guest:guest http://localhost:55672/api/queues

In my case, i had to use Nginx web server as a reverse proxy for the MochiWeb server in order to have the management plugin web interface along with the default domain name, something like:


Therefore, i configured Nginx in this super easy way:

location /rabbitmq/ { 

But the problems started when i tested the full web interface and there were some parts not working, like consulting the queues: go to the queues tab and click in a queue, you will get this:

Not found

The object you clicked on was not found; it may have been deleted on the server.

Continue reading


Great stuff at #DevOps days in Rome!!

I was in Rome attending the DevOps days conferences and IMO it was an awesome success.

Apart from the conferences, there were a bunch of open spaces really really useful. Thanks to everyone for being so collaborative in these small talks.

I love how this DevOps movement is growing and how its foundations are being formed.
We talked about testing, code quality, scripting, monitoring, continuous integration, continuous delivery, how to introduce DevOps in a company, how to start doing DevOps, how to deal with Devs and Ops,… this is the great thing of DevOps, it covers lots of things.

Some stuff said in Rome that i really liked:

  • Talking about monitoring and metrics:
    • Do you know how many people clicks this awesome button?
    • No
    • Then, why do you have this button?
  • What happen if your most important server dies? can you make it run in 10 minutes? ( Chaos Monkey )
  • How DevOps should be? centralized or decentralized?

Let’s explain DevOps at

Continue reading

Devopsdays conference in the south of Europe! In Rome!

The 5th and 6th of October there will be the Devopsdays conference in the south of Europe.

The Tuenti Devops team will try to go because it’s one of the most important Devops conference in the world and we need to take the advantage of being very close to Spain, in Rome, Italy.

At this moment they are still gathering speakers proposals and the registration is not yet opened, but let’s wait for a few days or weeks and all of you will be able to register in.

Come on! Let’s do the Rome edition be the best!! It will be fun and i’m sure there will be many beers to share with all of you guys

Looking for a Devops Engineer / Release Manager

We are looking for a Devops Engineer / Release Manager here at

Join our amazing Devops team to improve the development workflow of more than 150 engineers, to write tools to automate EVERYTHING within this company like a single button to push code to live or a tool to merge branches automatically and to manage the releases we do almost everyday pushing code to more than 14 million users.

Enjoy this company: international environment ( people from more than 20 countries ), football table, ping-pong, beer+pizza every friday afternoon, trips, young and very talented people, etc.

Check the offer out or contact me!!

The Python Jenkins API

In this post, i’m going to show you a very useful tool to manage Jenkins using Python.

As you probably know, Jenkins offers a cool API in XML, JSON and Python, if you don’t know it yet, take a look to its documentation, you will love it:

Almost every programming language can handle JSON and XML rest APIs but i’m going to take advantage of the Python API because i love this language.

There exists a project called jenkinsapi written in Python that ease the usage of the API:

I’ve been contributing to this tool, specially with the part of handling downstream and upstream jobs.

With this tool you can manage Jenkins in a very easy way, for example, if you want to know the status of the last build of the job “MyAwesomeJob”, you just need this dummy code:

from jenkinsapi import api
jenkins = api.Jenkins('http://your-jenkins-server/api/python/')
awesome_job = jenkins.get_job('MyAwesomeJob')
awesome_build = awesome_job.get_last_build()
if awesome_build.is_good():
    print "The build passed successfully"
    print awesome_build.get_status()

Continue reading

After Selenium Conf 2012

I’m one of the guys who went to the Selenium Conf 2012 in London and it was awesome!

Very good talks and very nice people, congratulations to the organizers and specially to Simon Stewart and Jason Huggings.

I could write lots of things of what i saw there, but i don’t have much time so i’m going to write some brief conclusions:

  • Most of the top tier companies test their software in a ( more or less ) similar way, which indicates that the testing world is going through a single line and this involves very good things such a future standardization and good cooperation between people within this testing world. Great news.
  • In my current job at Tuenti, we are also in the same page. We achieve, in some cases, better results and have a better testing framework/infrastructure than some companies that are in the same vein. That thing made me feel very proud and happy of what we are doing at Tuenti.
  • Everyone has problems with their tests:
    • slowness
    • flakiness
    • brittle tests
    • undeterminism produced by AJAX asynchronous requests
    • DOM changes made by the developers and its consequent test update
    • Third party elements in tests
  • Some of them could (kind of) fix their problems, but there isn’t a good nor standard solution for all these problems. Here, the testing world has a big room of improvement.  I have some ideas for some of them.
  • Surprisingly for me, Cucumber ( or at least BDD ) is being more and more popular.

When i was seeing some of the talks, i though that maybe in the future i can write an article or even do a talk of how the testing at Tuenti has evolved since my first days in October 2009, some points:

  • We ran 400 tests in 3 hours, now we run 11000 in 23 minutes
  • We used Cruisecontrol, now we use Jenkins
  • Every release we had about 40 tests out of 400 failing randomly due to an important flakiness, now, helped with some magic tricks, i’m proud to says that zero tests fail out of 11000

Triggering Jenkins jobs from the SCM push to avoid the evil polling


If you have a continuous integration infrastructure with Jenkins you might have you jobs configured to make polling over your SCM in order to trigger a job when there are changes. But this has some problems when Jenkins has several nodes and there are a big amount of jobs.

In my case, i configured the Jenkins jobs to poll the SCM repository ( Mercurial ) every 5 minutes. What that means?

  • A very big load in the SCM repository server due to the big amount of pollings from every Jenkins job.
  • Unexpected behaviour of the polling due to Jenkins bugs or SCM plugin bugs ( at least in the Mercurial one )
    • Jobs launched with no changes because the polling couldn’t be done because maybe the workspace of the previous build is not available
    • Jobs not launched although there are changes because of the loss of threads that manage the channel connections between the master and the slaves (Jenkins bug)

Continue reading