Bootstrap with Ansible, part 1

Wed, 2 Jan. 2019     Thomas Bendler     ~ 4 min to read

In preparation for a meeting to discuss ways of working to optimize server operations in a mid-size data center, I was seeking a lightweight approach to automate server installations. In the past, I was primarily using Puppet for 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 that 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 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:

# Kickstart installation file with minimal package set
# Author:       Thomas Bendler <>
# Date:         Wed Jan  2 17:25:26 CET 2019
# Revision:     1.0
# Distribution: CentOS
# Version:      7
# Processor:    x86_64

# Kickstart settings

# System language settings
lang en_US.UTF-8
keyboard --vckeymap=de-nodeadkeys --xlayouts='de (nodeadkeys)'
timezone Europe/Berlin --isUtc

# System password for root (create with i.e. pwkickstart)
rootpw --iscrypted $6$aaa[]zzz

# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
ignoredisk --only-use=sda

# System partition information
clearpart --all --initlabel --drives=sda
autopart --type=lvm

# System network settings
network  --bootproto=dhcp --device=link --onboot=on --ipv6=auto --hostname=node_1.local.domain

# System security settings
auth --enableshadow --passalgo=sha512
selinux --permissive
firewall --service=ssh

# System services
services --enabled="chronyd"

# System packages

# System addons
%addon com_redhat_kdump --enable --reserve-mb='auto'

# Post installation settings
%post --log=/root/kickstart-post.log
/usr/bin/logger "Starting anaconda postinstall"

/usr/bin/mkdir /root/.ssh
/usr/bin/chmod 700 /root/.ssh
/usr/bin/echo "ssh-rsa AAA[...]ZZZ admin1@management" > /root/.ssh/authorized_keys
/usr/bin/chmod 400 /root/.ssh/authorized_keys

exit 0

The last part of the kickstart file is used to distribute the authorized_keys file to enable password less login to the root account. Again, in a real-world scenario, you should use this section to create a 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 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).

Share on: