It’s been quite a while since my last post, but I promise I have somewhat of a decent reason. I wrote a book on AWS design patterns!
In my current set-up I have now deployed a very ugly HBase RPM (0.96) with a puppet manifest to help other devs bring up hbase quickly as well as a more resilient version of the same setup to a coworkers hbase stargate project. I decided to sit down and make it “legit” by adding best-practices and real usage tests.
I finally broke down and bought a 3d printer.
I released a new Puppet module to the forge out of another work necessity. Mirth is used pretty heavily for HL7 ETL, and has a ton of other uses.
So. We have an application that it’s constantly pushed to Yum when it’s modified. We have a puppet manifest (with tests) that can deploy this application and keep it up to date, and we even have r10k handling the deployment of those puppet modules so that we don’t have to worry about dependencies, and we can even stage them! What we don’t have is a way of getting changes to that puppet module to the puppet master without remoting in and running r10k. That’s easy to fix with jenkins!
Now that we have a package, we need a way of installing it amirite? We’re going to write a puppet module for this package complete with rspec tests
Our application will be simple, as its goal is only to demonstrate a daemon that needs to be managed via init.d and packaged as an RPM.
You’re going to need a minimum of 4 servers. Before you freak out, that’s to keep things simple. Again, calm down. Also, you’ll see I like CentOS. All the servers I built were CentOS 6.5 x86_64
This will be by far my biggest post to date. I’ve been asked from multiple sources about the system I’ve set up at my current company, so this is a very small version of it. By the end of this, assuming you follow along, you’ll have a multiple node system set up that will deploy a linux service, packaged as an RPM, to internal Yum feeds, with Puppet along the way to keep this continuously deployed. The puppet module I’ll write to do this will also be continuous, with all changes to it causing tests to run, and r10k to redeploy them if successful.
I have continued to want more out of my UDOO, so I decided to make use of a cracked LCD I had sitting around from Adafruit, by having the UDOO display system information to it.