Tag Archives: RabbitMQ

The Magic Button

On March 19th we used The Magic Button ( a.k.a “The What Does This Button Do Button”) in our demo’s at the Dutch VMUG UserCon. It magically  made a CoreOS cluster appear out of nowhere, Launched our demo app and then it scaled it out so all people in the room could open the page. Of course you want to build your own now. Here is how.

IMG-20150210-WA0001

Hardware

The button itself is just a regular emergency stop button I got off e-bay (6$). Inside there is enough space for a battery holder with 2x AA batteries. These batteries power an ESP8266-01 board. The ESP8266 is a Wifi SoC, has a 80Mhz processor, wifi connection, 96KBytes of RAM, a couple of GPIOs, comes with SPI flash on the board, costs around 5$ and looks like this:

ESP8266_Wi-Fi_Module

The chip has a UART and was originally intended to function as a serial to wifi module. Out of the box it comes with an awkward AT firmware (hello 1990!). But thanks to a very active community we can now build ourfirmware for this neat little chip. I don’t have the time or the knowledge to write my own firmware in C++ but luckily someone created a firmware for this chip that let’s you run Lua code on it! I didn’t know any Lua before but it turns out to be rather easy. Since it’s an event driven interpreted language it has some commonalities with Javascript, which I am very familiar with.

Here is how I connected the board:

  • Connect the button between GPIO0 and Ground
  • Connect the LED between GPIO2 and Ground. I used a 100Ohm resistor to limit the current through the LED
  • Put a 1K pullup resistor between VCC and CH_PD
  • Batteries are directly connected to VCC and GND. No Caps or regulators.

The magic button internals

When everything is connected you can squeeze it all into the case. It actually doesn’t really fit. When I close the case the battery gets damaged a bit. But whatever, it works….

The MAgic Button Squeezed

Software

So How did I turn this wifi board into a magic button? The button simply does an HTTP POST to my webEye application. This application forwards the posted body to an AMQP bus where it get’s picked up by vRealize Orchestrator. vRO in turn runs a workflows which actually performs the magic. To enable your board to do the same, follow these steps:

  • Setup webEye or another webhook receiver to test the button
  • Flash this firmware on the chip: nodeMCU
  • Use ESPlorer or another tool to load these two Lua files: https://github.com/vChrisR/TheMagicButton.
  • Please edit the variable at the top of the files before copying to your ESP
  • Emergency stop buttons are normally closed. So make sure the button is pressed (open) when you power up the ESP. If you don’t do that it will keep GPIO0 low which makes it boot into bootloader (flash) mode.

Now build a cool workflow which you can trigger with this button. Share your creations in the comments or find me on twitter.

webEye – The webhook receiver

When building out the demo environment which I was going to use for our NLVMUG UserCon presentation I came accross a problem: I wanted to notify my private cloud whenever a new Docker image was build on Docker Hub. This proofed impossible with the existing VMware software so I created my own solution. And here it is: webEye – The webhook receiver. It will simply forward all received webhooks to an AMQP bus after checking that it’s a valid webhook message. You can pick up the message with your favourite orchestration tool and act on them.

docker

webEye

Every hook needs an eye to hook into. That’s why my little app is called webEye 🙂

nodejs

webEye is written in JavaScript and runs on node.js. It is designed to run in a docker container. However, it already evolved fom something that was originally intended to just receive docker hub webhooks. Currently it also has support for my “Magic Button” and even for vRealize Operations. Other web hook senders might follow.

Getting started

As I said, webEye is developed to run in a docker container so this “getting started” will only cover how to start the app in a docker environment.

  • All received hook are forwarded to an AMQP bus. So let’s start an AMQP Server: docker run –name rabbit -p 5672:5672 -p 15672:15672 dockerfile/rabbitmq
  • Now start webEye: docker run -p 80:80 -p 443:443 -e “DHKEY=12345” -e “MBKEY=12345” –name webEye –link rabbitmq:rabbit -t vchrisr/webeye
  • The DHKEY in the line above sets the API key that you need to send with the request. This adds a bit of security. Make sure to put in a random string instead of “12345”.  tip: random.org
  • Now make sure port 80 on your webEye server is mapped to a public ip address
  • Open the now running webEye page in a browser to to get it running. This first visit actually triggers phusion passenger in the container to start the node.js app. This in turn creates a persistent exchange on the rabbitMQ server.
  • Create a webhook on your docker hub repository to http://{your public ip}:{public port}/dockerhub?apikey=12345
  • Connect your consumer to the rabbitMQ server
  • Create a new Q to receive your messages
  • Create a binding which routes messages with routing key webeye.docker.hub to your Q
  • Create a suscription for the Q you created
  • If you’re using vRO you can now create a policy which triggers a workflow when a message appears in the subscription.
  • Create a workflow that does whatever you want when a docker hub hook is received.

Testing webEye

If you were able to make webEye available on the public internet and you’ve configured a webhook on your docker repo you can

  • now simply click “test” on the webhook configuration page.
  • To test offline I usually use the Firefox RESTClient plugin.Select “POST” as the method.
  • Enter this url: http://<ip of webEye machine>:<port>/dockerhub?apikey=<apikey>
  • Add this header: Content-Type: application/json
  • For the body you need some actual content. webEye will check the presence of some specific fields in the json to make sure it’s a Docker Hub webhook. I usually use the json from the Docker Hub Documentation:

resttest-webeye