Automated Playground (Part 0)

Posted on Sep 01, 2020 by Vincent TruchseƟ

I’m working, playing and loving as a sysadmin for quite a number of years now and I’ve gone my way from learning to carefully setup systems by hand to having an ansible-playbook for brushing my teeth over the last 10 Years. But, as it turns out, I am having a quite divergent relationship to automation.

Privately, I have automated everything that concerns setting up my own services in my own little environment using my own tools. This setup works for me but is definetively not ready (or meant to be) to be used in a large-scale, enterprise-ish system.
On the other hand I am working in a large-scale enterprise-ish environment and I often find myself performing tasks by hand. Whatever a config-management like ansible or puppet is useful for, I use it. But outside a VM, there is still creating VM-templates, managing DNS-Records, deploying TLS-certificates, managing IP-addresses and network-config. All done the old way.

Lessons learned

During the last big project I was involved with (the main reason this blog was so inactive) my team and I have tried out many new things regarding automation. I can’t go into details but I’d say we did pretty good given the timeframe, manpower and 'things we 've had to learn on the job'.
We’ve also learned a lot of things how not to do it. To put these lessons to a good use, I’ve planned to dig deeper into all that DevOps-tooling.

A Playground

Most of the documentation regarding tools like vagrant_ or terraform do not take into account that there are still people out there not running their shit on AWS or Azure. Same goes for pre-build VM-templates.
I need a playground to figure things out myself. An environment that resembles the circumstances I am confronted with on a daily basis.

This series of Blogposts will illustrate the building of a testbench, running locally on my machine, used to have a safe playground to learn new things.

Tags: linuxopsdevopsautomation