Bootstrapping mit Ansible samt Playbook erklärt!

Eine Linux-Server-Umgebung verändert sich ständig. So werden ab und an neue Systeme aufgesetzt und dabei die immer gleichen Arbeitsschritte durchgeführt. Und genau hier kommt dieses Tutorial ins Spiel. Ich möchte dir kurz und bündig zeigen, wie du an diesem Punkt in Zukunft eine Menge Zeit und vielleicht auch Nerven sparen kannst.

Dieser Beitrag geht also näher auf die Thematik Bootstrapping ein. Gemeint ist damit die Erstellung eines Playbooks, welche die Grundeinrichtung neuer Server erledigt. Außerdem kümmert man sich an dieser Stelle noch darum, einen User für Ansible samt passenden Public Key anzulegen. So ist auch gleich sichergestellt, dass die Ansible-Anmeldung in der eigenen Landschaft standardisiert ist.

Natürlich kann man in puncto Bootstrapping noch weit mehr machen. Was hier beispielsweise alles möglich ist, habe ich im Folgenden aufgelistet:

In großen Umgebungen kann es sogar sinnvoll sein, mehrere Bootstrapping-Playbooks zu nutzen. So kann man das Aufsetzen von Apache-Webservern ebenso automatisieren, wie die das Deployment von Docker-Containern. Und eines sei noch gesagt. Mithilfe von Ansible kann man alle Netzwerkkomponenten betanken, die via SSH erreichbar sind. Man denke da nur an Switche oder Router.

Wie man mein Bootstrapping-Playbook korrekt einsetzt:

Hier muss ich zum Glück nicht viel schreiben. Mein Playbook hat nämlich einen großen Vorteil. Man muss den Code nicht vor jedem Lauf anpassen. Gleich zu Beginn werden alle 3 benötigten Daten abgefragt. Das wären hier der Password-Hash für den User Ansible, dessen Pub-Key sowie die zu installierende Software.

Da ich jeden einzelnen Task mit einem Tag versehen habe, kann man bestimmte Abschnitte entweder gezielt benutzen oder diese im Voraus vom Run ausschließen. Die Syntax in der Kommandozeile ist dabei recht einfach. Das alleinige Einspielen von Patches lässt sich zum Beispiel so realisieren: ansible-playbook bootstrapping.yml –tags „update“

Möchte man diesen Task hingegen nicht ausführen, sollte man folgenden Befehl nutzen: ansible-playbook bootstrapping.yml –skip-tags „update“ Noch erwähnen möchte ich, dass das Playbook für das Bootstrapping bei RedHat, Suse, Debian und Ubuntu eingesetzt werden kann. Wichtig zu wissen ist hierbei, dass die zu installierende Software in den Paketquellen überall gleich heißen muss.

Da ich an dieser Stelle auch nicht mehr länger, um den heißen Brei herumreden möchte, folgt nun auch schon der lang ersehnte Code. Unterteilt ist dieser in 3 Blöcke. Man braucht also in seinem Projektordner 3 Dateien namens ansible.cfg, inventory sowie ein Playbook mit den Namen bootstrapping.yml Selbstredend muss man das Inventory-File an die eigene Umgebung anpassen.

# ansible.cfg

[defaults]
inventory = ./inventory

# inventory

[bootstrapping_server]
1.2.3.4

[bootstraping_server:vars]
ansible_user=root
#ansible_password=GeheimesPassw0rt
ansible_ssh_private_key_file=/root/.ssh/id_rsa

# Bootstrapping.yml - Das interaktive Playbook

---
- name: Bootstrap server for future ansible runs
  hosts: bootstrapping_server
  
  vars_prompt:
    - name: var1_password_hash
      prompt: "Please paste the password hash below: "
      private: true
      
    - name: var2_pub_key
      prompt: "Please add the pub key for the user ansible here: "
      private: true

    - name: var3_software
      prompt: "Please enter all required software: "
      default: "vim,htop"
      private: false
  
  tasks:

    - name: Update and upgrade the installed operating system
      tags: update
      apt:
        update_cache: yes
        upgrade: yes
      when: ansible_distribution == 'Debian' or ansible_distribution == 'Ubuntu'
      
    - name: Update and upgrade the installed operating system
      tags: update
      yum:
        name: '*'
        state: latest
      when: ansible_os_family == 'RedHat'
      
    - name: Update and upgrade the installed operating system
      tags: update
      zypper:
        name: '*'
        state: latest
      when: ansible_os_family == 'Suse' 
   
    - name: Install sudo package
      tags: sudo
      package:
        name: sudo
        state: latest  

    - name: Create user ansible on Debian based systems
      tags: user_creation
      user:
        name: ansible
        shell: /bin/bash  
        comment: user for ansible 
        groups: sudo
        append: yes
        password: "{{ var1_password_hash }}" 
      when: ansible_os_family == 'Debian'

    - name: Create user ansible on Suse and Rocky
      tags: user_creation
      user:
        name: ansible
        shell: /bin/bash  
        comment: user for ansible 
        groups: wheel
        append: yes
        password: "{{ var1_password_hash }}" 
      when: ansible_os_family == 'Suse' or ansible_os_family == 'RedHat'

    - name: Add SSH keys for user ansible
      tags: ssh_key
      authorized_key:
        user: ansible
        state: present
        key: "{{ var2_pub_key }}" 

    - name: Install required software on the new system
      tags: software
      package:
        name: "{{ var3_software }}"
        state: latest

    - name: Disable login via SSH as user root
      tags: ssh_login 
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: "#PermitRootLogin yes"
        state: present
      register: sshdaemon

    - name: Restart SSH daemon
      tags: ssh_daemon
      service:
        name: ssh
        state: restarted
      when: sshdaemon.changed  

Wie man das Playbook weiterentwickeln kann:

Mein obiger Code soll als kleine Anregung dienen oder einfach Lust auf den Einstieg in die Netzwerkautomatisierung mit Ansible machen. Je nach vorhandener Umgebung kann mein Playbook alle oder nur ganz wenige Erwartungen erfüllen, die man an das Bootstrapping neuer Systeme knüpft. Daher sollte man nach Möglichkeit selbst Hand am Playbook anlegen.

Denkbar wäre es beispielsweise die SSH-Konfiguration noch etwas sicherer einzurichten. Man kann mit den Ansible-Modulen nämlich nicht nur einzelne Zeilen in Dateien bearbeiten, sondern auch fertige Konfiguration hochladen. Je nach Veränderung am Code, könnte auch ein Handler für den Neustart des SSH-Dienstes die bessere Wahl sein.

Wie auch immer die Anpassungen am obigen Playbook aussehen mögen, eines ist auf jeden Fall sicher. Nur durch zusätzlichen Code können alle Bedürfnisse und Wünsche in Bezug auf den Bootstrapping-Prozess der eigenen Landschaft erfüllt werden. Aufgrund dessen wünsche ich viel Erfolg mit meinem Playbook als Grundlage und eine Menge Spaß beim Anpassen und Erweitern.