DevOps – Automating Infrastructure
I’ve been putting a lot of time and thought into the relationship between Development and Operations. Particularly the void between what Dev thinks is their responsibility and what Operations thinks is their’s. In the middle is that actual deployment, configuration management, etc.
This led me to Puppet. I first heard about it at JavaOne 2011 (along with Chef, Fabric, and cfEngine). We have a lot of Wintel at my employer, and I assume MSFT has a similar tool, but I have not been able to verify that System Center Configuration Manager meets the needs I’ve outlined. In any case, it would likely have an extreme Wintel bias.
Puppet works in a client-server model. The server (puppet master) runs as a daemon on the host and contains the configuration information that should be on each client. Agents reside on these clients and connect back to the master to see if there are any configuration changes to apply.
I’ve gotten server only tests to run and complete to create files and stop and start services. I now have a VM that can act as a server so that I can test more sophisticated Use Cases. I’ve found the documentation on the Puppet site to be excellent and have been suplementing it with the book “Pro Puppet”.
I see many uses for this where I work. Looking at the capabilities, I believe we can get to a point in our Configuration Management capabilities that it would be a fail to actually have to log in manually to servers to install or verify conditions. This is how many companies have environments where an individual server admin manages 1000+ servers.