Chef Cookbook for Rapid EmonCMS Development Now Available

Hello! I’ve been working on a Chef cookbook to automate setting up an EmonCMS environment with all the dependencies. This takes the EmonSD build instructions and makes the process automated, repeatable, and pins the dependencies so that you can (eventually) be sure of getting the same versions of all the bits that make a functioning EmonPI everytime. This is now ready as an early release at https://github.com/davidski/chef-emoncms.

What can you do with this cookbook?

  • With a single command, launch a Debian 8.8 based virtual machine with a freshly configured emonCMS 9.8.7 with MySQL, Redis, MQTT, and all low-write configurations for testing, development, etc.
    • EmonCMS will be exposed at http://localhost:8080/ecmoncms by default (note the 8080 port vs. the standard port 80, this is to avoid conflicts on your local machine).
  • That fully configured system stands up in 5-10 minutes (depending on your internet connection and local processing power).
  • Runs on Windows, MacOS, or Linux hosts with HyperV, Virtualbox, VMWare support (or any of the virtualization engines supported by Vagrant.
  • Stand up the same code in a cloud platform such as AWS, Azure, Google Cloud etc. No local VM required! (thanks to Vagrant’s awesome cloud support)
  • Use a tool such as packer to build a gold image for AWS, deploying to an SD card, etc.

“Sounds neat? How do I use this?”

  • If you don’t care about all this CI/CD, devops-y, cloud-y stuff, here’s five short steps to get a functioning EmonCMS system:
    1. Install the local Chef development kit, ChefDK.
    2. Clone the cookbook (git clone davidski/chef-emoncms emoncms)
    3. Change into the cookbook directory you just cloned (cd emoncms)
    4. Launch and converge (build) a test instance with the included KitchenCI (kitchen converge)
    • Go grab a glass of water and watch while a base Debian box is pulled down and all the hard work of setting up emoncms scrolls past.
    1. Surf to http://localhost:8080/emoncms
  • But what about shell access?
    • No problem! Enter kitchen login to get a shell prompt. From there you can sudo -i -u pi to become the pi user, just like on emonPI!
  • But what about getting data in?
    • MQTT? It’s exposed as localhost:1883 with the standard credentials.
    • API? Right there at http://localhost:8080 for handy use by something such a emoncmsr.

Why Chef (or other config management tools)?

  • To develop (bug hunt, new features, simulate setups, etc.) on the emoncms platform you need a functioning system that’s not your production box but that has all the same code bits.
  • Even with multiple physical Raspberry PIs, swapping out SD cards and restarting is a pain, prone to hardware failures, and with limited CPU, disk, and RAM power. Virtual Machines are much simpler!
  • There are a lot of dependencies in a functioning low-write emonCMS setup. The emonSD instructions are complete, though quite long (multiple documents with hundreds of lines of instructions). Going through the emonSD instructions will give you different versions of all those dependencies as git commits are made, packages are updated on feeds, etc. Tools such as Chef (or Ansible/Salt/Puppet/etc.) give you a declarative, idempotent fashion for describing the state of a system and lets the tooling handle the hows.

Neat, but what about ____?

  • As a virtual machine, hardware such as the RFM69 are not available. The software bits are all there, though, and if you’re an advanced virtualization user you could probably hook something up to your VMs serial port and make this work. That would be a neat project!
  • OpenHAB and Node-RED are not included. Getting newer versions than what is included in the shipped emonSD image was another reason I wanted to get this project going, so this will be coming soon (though may not get incorporated into this specific cookbook).
  • A few bits are newer than what are present in the Nov 16 EmonSD image. This includes minor revisions to MySQL, the 3.x version of the Redis PHP extension, and a few minor other bits. Part of my motivation with this work is to go in and help pin these dependencies so that random pip or pecl (or composer) updates don’t break emoncms.
  • There may be (almost certainly) other bugs that I haven’t come across. Your help in finding these less than polished areas is urgently requested! Issues on GitHub are preferred for bug reports, but I’ll try to monitor this forum as well.
  • “Chef? Come on, @davidski, where’s the Docker image?” le grande sigh Yes, I know docker, docker, docker is all the rage, but I primarily work on Windows where the docker story is still not great. A containerized version of emoncms would be terrific and I’d love to help out if someone wants to take that on (though I’d prefer rkt)! With all the subservices, docker compose is probably going to be the way to go here.

Fin

  • It’s been an awful lot of (mostly) fun diving into all the bits that make emoncms go bing. Big shout outs to the community for all the documentation on this. It’s truly made this project possible!
1 Like

Sounds really interesting, thanks.
Raspberry Pi’s are used extensively within the emoncms community, is there compatibility with Pi’s/Jessie.

Paul

The default image in the kitchen setup is Debian 8 (Jessie), which is the upstream source for Raspbian Jessie. Apart from running on x86 instead of ARM, everything should be compatible! Commands, packaging names, etc. are all the same, though you are pulling from different repositories (again because of running on x86/x64 instead of ARM chips).

I almost always have my laptop with me or access to a cloud machine. I don’t have Raspberry PIs always on hand. I know, blasphemy! :stuck_out_tongue_winking_eye: