I like to be a technology-and-product-hands-on product manager to avoid losing my technical mojo. A while back I created a VagrantFile for a WildFly Swarm demo called booker. Booker is a technology demo to show a set of four Java EE-based fat-jar microservices to implement a bookstore. The demo integrates with ELK for microservice log visualization and analysis and Keycloak for single sign-on (SSO). Lots of moving parts that have to be set up. I initially created a bash shell script to set up everything because it was “what I knew”. Yeah, I new there were other tools out there like Ansible, Chef, and Puppet that might be able to do this more effectively, but time was short and I was already learning one tool – Vagrant itself.
A week or two ago Red Hat acquired Ansible, and I figured I’d get around to eventually replacing the setup shell script with an Ansible playbook some day. Well, that day started two days ago when I attended a meeting where I got a chance to see Ansible in action. On the flight back from the meeting (thanks Southwest WiFi) and then again last night (my play time), I have been learning Ansible basics. It’s been a bit rough but once I got remote vs local down (#!&@-ing copy task wasn’t copying), things cleared up. BTW, I code like a #!&@-ing drunking sailor when things don’t go well 🙂 (I also blog like a LISP programmer (a lot of the time (as thoughts randomly appear in my head))).
The good news is that I have the Ansible playbook pretty far along. The lines of code for the old setup script and the Ansible playbook are pretty close. However, what I do like is the idempotency of Ansible. I can apply the script multiple times and get the same result. I can’t say that I yet fully grok Ansible itself or the full power it has to offer, but I have a mostly working booker playbook. I do realize that applying an Ansible playbook to one machine isn’t exactly playing to its strength, but that’s all I need right now.
Once I finish off the booker Ansible playbook and get out of the trees, I’ll pull back and think about the forest of Ansible, docker, and microservices. What started as a “means to an end” for a demo is making me think about the role of tools like Chef, Puppet, and Ansible in the world of docker immutability and the world of collaborating microservices.
I should note that I need to revisit the booker demo a bit and document it more thoroughly. If you try it out and can’t get it to work, drop me a comment.
Also, if you have thoughts on Ansible/Play/Puppet in the world of microservices and docker, drop me a comment. I’d love to hear your comments.
And now for something completely different – getting my arms around vert.x. TTYL.