Sprint: Deployment von Python-Webandwendungen

Veit Schiele <[email protected]> Thu, 31 May 2012 12:49:50 +0200
Newsgroups gmane.comp.web.zope.german
Organization Veit Schiele Communications GmbH
Message-ID <[email protected]>
Hallo zusammen,

wir wollen Euch hier einen kurzen chronologischen Bericht von unserem
Sprint zum Deployment von Python-Web-Anwendungen
<http://python-verband.org/events/sprint-deployment-von-python-webanwendungen>
geben:


      1. Tag


        Ziele

Folgende Ziele wollen wir während des Sprints erreichen:

  * Aufwände verringern
  * Downtime minimieren
  * Vorhersagbare Ergebnisse erhalten


        Konzepte

Dabei sind uns folgende Konzepte wichtig:

  * Service-User
    Unterschiedliche Environments für verschiedene Services
    *Keine* root-Installation
    Trennung der User-Dot-Dateien von der Service-Konfiguration
  * Multi-Host

    Kohäsion <http://de.wikipedia.org/wiki/Koh%C3%A4sion_%28Informatik%29>
        Eine Komponente soll genau eine Aufgabe für den gewünschten
        Service übernehmen
    Kohärenz
        Die Komponenten sollen gut zusammenspielen

  * Reproduzierbarkeit
  * Gemeinsame Behandlung verschiedener Umgebungen für Entwicklung,
    Tests und Produktion
  * Technischer Ablauf
    Kein Python-spezifischer Ablauf, da selten alle beteiligten
    Komponenten in Python geschrieben sind.

    Software-Assembly

      o Komponenten in sortierter Reihenfolge installieren
      o Pyton-Installation mit den benötigten Komponenten via virtualenv
        <http://pypi.python.org/pypi/virtualenv>
      o Reproduzierbarkeit der Komponenten mit zc.buildout,
        <http://pypi.python.org/pypi/zc.buildout/1.5.2> pip
        <http://pypi.python.org/pypi/pip> etc.

    Laufzeitkonfiguration

      o Betriebssystemweite Komponenten konfigurieren
      o Einzelne Komponenten auf den Zielmaschinen konfigurieren
      o Geheime Konfigurationsparameter (sog. /Secrets/ wie z.B.
        Passwörter, ssh-Keys und Zertifikate) auf den
      o Reihenfolge von Start und Stop der Komponenten festlegen (→
        rolling restart/update)
      o Minimieren der Downtime durch koordinierte Deployments
  * Daten-Management
      o Migration der Datenbanken
      o Geplantes Löschen oder Erhalten der Caches
      o Koordinierung mit der Laufzeit-Konfiguration


      2. Tag


        Werkzeuge

Im folgenden eine unvollständige Liste von Deployment-Werkzeugen:

Batou <http://pypi.python.org/pypi/batou/>
    Deployment auf mehreren Hosts und unterschiedlichen Environments.
Mercurial <http://mercurial.selenic.com/>
    Zum aktuellen Zeitpunkt unterstützt Batou nur Mercurial zum
    Verwalten der Projektdaten.
pypimirror <http://pypi.python.org/pypi/z3c.pypimirror>
    gewährleistet, dass externe Abhängigkeiten zu Python-Eggs
    auch später zur Verfügung stehen
zc.buildout <http://pypi.python.org/pypi/zc.buildout/1.5.2>
    Konfigurationsbasiertes Erstellen einer reproduzierbaren Python-Umgebung
supervisor <http://supervisord.org/>
    Prozessüberwachung und -kontrolle auf Unix-Betriebssystemen

Anschließend begannen wir, als Beispiel das Deployment einer
Django-Anwendung mit Batou zu beginnen, das Ihr auf bitbucket unter
sprintsite <https://bitbucket.org/ctheune/sprintsite> selbst
ausprobieren könnt. Hierfür erstellten wir exemplarisch verschiedene
Umgebungen
<https://bitbucket.org/ctheune/sprintsite/src/fe8e5ca91a62/environments>
und die Batou-Komponenten django
<https://bitbucket.org/ctheune/sprintsite/src/fe8e5ca91a62/components/django>
und supervisor
<https://bitbucket.org/ctheune/sprintsite/src/fe8e5ca91a62/components/supervisor>.
Im Folgenden überlegten wir uns, wie die Abhängigkeiten zwischen den
Komponenten besser gefasst werden kann. Dabei sind wir zu einer Lösung
gekommen, bei der die Komponenten nicht mehr voneinander wissen müssen.
Weitere Vorteile des neuen Konzepts sind:

  * unbenutzte Komponenten können erkannt werden
  * ermitteln der Reihenfolge, in der die Komponenten installiert werden
    können, ohne diese explizit festlegen zu müssen


      3. Tag

Weiterer Ausbau unserer Beispielanwendung:

  * der »alte« hook-Mechanismus von Batou wurde ersetzt durch provide
    und require-Funktionen.
    Ein Nebeneffekt dieser neuen Funktionen ist, dass Batou beim
    Erstellen der Deployment-Umgebung Fehler abfängt, die sich im
    Prozess der Installation und Konfiguration ergeben.
  * Weitere Komponenten wurden begonnen: nginx
    <https://bitbucket.org/ctheune/sprintsite/src/2181f4e3bf9e/components/nginx>.


Schöne Grüße
    Christian Theune
    Jens Vagelpohl
    Michael Hierweck
    Stephan Diehl
    Veit Schiele



_______________________________________________
zope mailing list
[email protected]
https://mail.dzug.org/mailman/listinfo/zope