Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Parallelisiert

Per Default führt Fabric die definierten Tasks hintereinander aus, jeweils auf einem Rechner nach dem anderen. Effizienter ist es aber, unabhängige Tasks auf mehreren Rechnern parallel auszuführen, was aktuelle Fabric-Versionen beherrschen. Dazu dient der Schalter »-P« . Um genau zu kontrollieren, welche Tasks hintereinander und welche parallel abgearbeitet werden, bietet Fabric die Dekoratoren »@serial« und »@parallel« .

Um Tasks flexibler zu gestalten, bietet Fabric die Möglichkeit, sie zu parametrisieren. Definiert werden solche Tasks etwa so:

@task
def apache(cmd):
   sudo("/etc/init.d/apache2 %s" % cmd)

Hiermit ruft Fabric das Init-Skript von Apache mit dem übergebenen Parameter auf. Der dazu gehörige Aufruf lautet dann zum Beispiel »fab apache:restart« . Um bei komplizierten Aufgaben den Überblick nicht zu verlieren, bietet sich die Modularisierung von Tasks an. Hierbei lassen sich Unteraufgaben in eigene Module ausgliedern, die sich dank Namespaces nicht gegenseitig ins Gehege kommen. Ein Beispiel für eine einfach Apache-Bibliothek zeigt Listing 3 .

Listing 3

apache.py

01 from fabric.api import *
02
03 @task
04 def start():
05    sudo("/etc/init.d/apache2 start")
06
07 @task
08 def stop():
09    sudo("/etc/init.d/apache2 stop")
10
11 @task
12 def restart():
13    sudo("/etc/init.d/apache2 restart")

Unter dem Namen apache.py gespeichert, lässt sich dieses Modul dann in anderen Fabfiles verwenden:

from fabric.api import *
import apache
@task
def uptime():
   run('uptime')

Nun zeigt »fab -l« den in dieser Datei definierte Task neben den vom Apache-Modul importieren an:

Available commands:
   uptime
   apache.start
   apache.stop
   apache.restart

Parameter und alles andere funktionieren damit weiterhin, die Namespaces bringen nur etwas Ordnung in die Skriptsammlung.

Dateioperationen

Wie man es von einem solchen Tool vielleicht erwarten könnte, bringt es ein paar eigene Tasks mit, um mit Dateien zu arbeiten. Die Core-API bietet »put()« und »get()« , um lokale Dateien auf den Server zu laden und umgekehrt. Das Modul »contrib.files« enthält noch einige Funktionen, die typische Aufgaben abdecken, etwa:

  • »append(Dateiname, Text)« hängt einen String oder eine Liste von Strings an eine Datei an, wenn sie noch nicht in der Datei enthalten sind.
  • »comment(Dateiname, Regex)« / »uncomment(Dateiname, Regex)« kommentiert eine Zeile in einer Datei ein oder aus, auf die die aufgeführte Regular Expression zutrifft.
  • »contains(Dateiname, Regex)« gibt »True« zurück, wenn die Regular Expression zutrifft.
  • »exists(Pfad)« liefert den Wert True, wenn der Pfad existiert.
  • »first(Pfad)« prüft eine Liste von Pfaden und gibt den ersten zurück, der existiert. Das ist zum Beispiel praktisch, wenn man mehrere potenzielle Orte für Konfigurationsdateien durchgehen möchte.

Die Funktion »upload_template()« lädt eine Template-Datei, trägt die übergebenen Werte ein und lädt das Ergebnis auf den Server hoch. Per Default verwendet die Funktion das Python-Format für String Interpolation. Es ist empfehlenswert, stattdessen das Jinja2-Template-Format zu verwenden, das sich mit dem Parameter »use_jinja=True« einschalten lässt.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023