In preparation of a meeting to discuss ways of working to optimize server operations in a mid-size datacenter, I was seeking a lightweight approach to automate server installations. In the past, I was primarily using Puppet for the data center management. Although it’s still a good choice for an enterprise level, full automation, it also has some disadvantages. First of all, it’s a client/server infrastructure which requires by nature more installation effort compared to clientless solutions. It also requires more resources on the client to permanently get the state of the client. Last but not least, it’s also a bit more complex when it comes to writing generic usable modules.
Long story short, I decided to give the number one competitor of Puppet called Ansible a try. Ansible has a similar, slightly smaller scope and is designed to be more lightweight then Puppet. You don’t need to install agents on the clients and the whole architecture looks a little bit straighter forward.
As a proof of concept, I built a small automation procedure for my home office. As Ansible is owned by RedHat I used CentOS as the server operating system. CentOS can be automatically installed by using kickstart and is as such, a good platform to test the general idea. As a first step, I’ve created a generic kickstart file that enables me to install CentOS 7 with a minimal package set. This is my preferred approach as I tend to use the automation tool for the setup work. In my proof of concept, I use the root user for the configuration management. In a real-world scenario, you should use a dedicated configuration management user in conjunction with sudo:
The last part of the kickstart file is used to distribute the authorized_keys file to enable a passwordless login to the root account. Again, in a real-world scenario, you should use this section to create the dedicated management user as well as the required sudo configuration. Alternatively, you can use Ansible to create individual administrative user accounts on the target hosts.
The now still remaining part is to tell the installer that he should use the kickstart file instead of asking the user how and what to install. This is simply done by adding inst.ks= to the kernel parameter. The installer can use different methods to get the file which is described in the kickstart documentation. In this proof of concept I simply use a web target:
Once the Kickstart based installation is finished, the configuration management done with Ansible will take over. If you move the proof of concept to a real datacenter you should consider extending the automated Kickstart installation by tools like Cobbler. This will enable a fully fledged automation by using PXE boot (network boot without a local operating system). Another option, depending on your security and update strategy, is to use templates to provision the operating system instead of doing a real installation. But this approach has, at least from my point of view, too many disadvantages (especially in the operating area).