After almost a year with Puppet, I finally get to diagram and document how the infrastructure that I use for virtually everything looks like. Since I am a big fan of the movie Videodrome (as shown in the header image!), it is called Xuxodrome. I share it here just in case any of you want to replicate it!
My idea with Xuxodrome is to provide a real, mini datacenter that it is always available and can take real changes, adapt. It is not only used for demos but also for the real hands-on workshops that I do.
Xuxodrome can be represented in the following illustration. We will go through each numbered section.
The environment diagram includes a reference to a master in AWS, but we won’t cover that here as it is external. The only relationship to Xuxodrome is the relationship with my GitHub repository.
- The Puppet Enterprise Master. It manages all assets inside Xuxodrome.
- Shared Services. A Windows 2012 domain controller, built by Puppet, acts as DNS and Active Directory.
- Code Stuff. Puppet’s code-manager is actively retrieving the latest Infrastructure code from a repo in my GitHub site. Every time I commit something, Travis-CI checks it for me to determine how bad of a coder I am.
- Traditional Infrastructure. This area has VMs that live and die often. Systems include Windows, RHEL, and Debian.
- Modern Infrastructure. Puppet’s Blueshift stuff. CoreOS cluster, Docker engines and Consul backend reside here. Clusters include ELK Stack, Jenkins CI, and other things that I can use for examples. It also provides an Nginx load balancer.
- Other. Every now and then I might attach an AIX LPAR from Puppet’s corporate infrastructure or provision VMs using vSphere.
Convert everything into a HEAT template as the core of Xuxodrome is all on OpenStack. In this fashion, I can rebuild the whole thing push-button!
On part two, I will show you a simple monitor that I run to keep track of some nodes. It is not great, but a good example of some Ruby and some Puppet.