Tag Archives: Ansible

Raspberry Pi Cluster – Part 1: The Hardware

Technical Stuff, ,

For  a long time I had wanted my own Raspberry Pi cluster and I finally managed to get started. There will be five nodes, which will give me 20 cores to play with. The overall plan is to manage the nodes with Ansible and run a Kubernetes cluster on them.

Let’s start with putting these boards together. I quickly settled for using spacer bolts. There are special ones for Raspberry Pi available, but I just got some cheap ones from AliExpress, as shown below. They have two disadvantages, though. Firstly, their diameter is a little bit too big for the wholes in the PCB (printed circuit board). So I used a wood drill size 3 to extend the wholes by just a fraction of a millimeter. You can somewhat see the white left-overs from the drilling at the lower left whole in the picture below.

The second problem is that my spacer bolts are pretty short. So in order to avoid short circuiting things, I put insulation tape on top of the USB ports.

With these two small modifications I went ahead and assembled the Raspberry Pis into a nice stack.

As power supply I chose a 5-port 50 watts USB model from Aukey, which I got a while ago from Amazon when they were on special offer. Aukey does such promotions quite frequently, so if you can wait a bit, you will be able to safe a few bucks.

And this is what things look like connected (excluding network of course).

That’s it for today. Stay tuned for the next part in this series.

Configuration Management – Part 6: The Secrets

ALM, Configuration Management, DevOps, Technical Stuff, Tools, , , ,

Every non-trivial application needs to deal with configuration data that require special protection. In most cases they are password or something similar. Putting those items into configuration files in clear is a pretty bad idea. Especially so, because these configuration files are almost always stored in a VCS (version control system), that many people have access to.

Other systems replace clear-text passwords found in files automatically with an encrypted version. (You may have seen cryptic values starting with something like {AES} in the past.) But apart from the conceptual issue that parts of the files are changed outside the developer’s control, this also not exactly an easy thing to implement. How do you tell the system, which values to encrypt? What about those time periods that passwords exist in clear text on disk, especially on production systems?

My approach was to leverage the built-in password manager facility of webMethods Integration Server instead. This is an encrypted data store that can be secured on multiple levels, up to HSMs (hardware security module). You can look at it as an associative array (in Java usually referred to as map) where a handle is used to retrieve the actual secret value. With a special syntax (e.g. secretValue=[[encrypted:handleToSecretValue]]) you declare the encrypted value. Once you have done that, this “pointer”will of course return no value, because you still need to actually define it in the password manager. This can be done via web UI, a service, or by importing a flat file. The flat file import, by the way, works really well with general purpose configuration management systems like Chef, Puppet, Ansible etc.

A nice side-effect of storing the actual value outside the regular configuration file is that within your configuration files you do not need to bother with the various environments (add that aspect to the complexity when looking at in-file encryption from the second paragraph). Because the part that is environment-specific is the actual value; the handle can, and in fact should, be the same across all environments. And since you define the specific value directly within in each system, you are already done.