Konzepte¶

Grundideen¶

Betrieb und Deployment sind anspruchsvolle Aufgaben, die über Erfolg und Misserfolg eines Projekts mit entscheiden – informiert Euch, erstellt ein Konzept und lasst Euch beraten.

Python-Webanwendungen haben ein paar Besonderheiten, die man beachten sollte. Aber: Keine substantielle Python-Webanwendung wird in einer reinen Python-Umgebung vollständig sein und andere Komponenten wie Webserver, Datenbanken etc. … benötigen.

Hier sind einige Prinzipien, die dein Leben leichter machen werden:

• Separation of concerns

• Sparsamkeit

• Infrastruktur/Plattform als Voraussetzung

• Verständlichkeit

• Wiederholbarkeit

• Vorhersagbarkeit

• Debugbarkeit/Testbarkeit/Beobachtbarkeit/Nachvollziehbarkeit

• Robustheit

• Portabilität

• Isolation

• Kompetenz-Zuschnitt und Schnittstellen zwischen: Infrastruktur/Plattform vs. Service-Deployment ala DevOps

• Ziele vor Maßnahmen

h2. Konzeption

Zeitplan fuer Live-gang

service-user, keine root-installation

separates verzeichnis im home fuer den service (um user-dotfiles und die service-dateien zu trennen)

multi-host:

• absichern, dass gleicher versionsstand benutzt wird

• kohärenz und kohesion:

  • einzelne teilkomponenten nach gemeinsamkeiten zusammenfassen

  • nach unabhängigkeit trennen um verteilung und skalierung über mehrere hosts zu unterstützen

sla

-> redundanzkonzepte?

-> support und bereitschaft

ressourcenauswahl:

• io (netz, disk)

• disk (größe)

• cpu (anzahl)

• speicher (größe)

tendenz: 1 VM = 1 CPU = 1 Dienst, denn das maximiert fuer diesen dienst die verfügbare disk, speicher und IO

kandidaten für mehr cpus: mail-server, postgresql, java im allgemeinen

kandidaten für viel ram: datenbanken

performance-anforderungen an dienst

platznutzung der datenbanken und teilkomponenten?

reproduzierbarkeit

entwicklung / testing / production gemeinsam zu behandeln

auswahl OS-komponenten und eigen-installation:

OS-Pakete / Komponente

• schnittstelle os-pakete, individualinstallation

  lxml + libxml, pil

• welche komponenten betriebssystemweit?

  • ist die komponente breit einsetzbar oder variiert sie (version, konfiguration) so stark, dass eine installation/konfiguration auf system-ebene keinen sinn macht?

  • ist die abhaengigkeit zu aenderungen auf betriebssystem-ebene instabil? z.b. wie werden notwendige rebuilds behandelt?

  • komponenten, die privilegierte aktionen brauchen (<1024 ports, …)

• spezifische komponentenauswahl

lastverteilung

h2. Technischer Ablauf

keinen rein python-spezifischen mechanismus, da “everything in python” (analog zu “java als plattform”) nicht wahr ist

h3. Software assembly

• eigener komponenten auf zielmaschinen

• Gescheites Python / Isolation

  virtualenv –no-site-packages “userspace” python?

  -> nope, ist nur 1 sys.path pro (unix-)user

• tools fuer reproduzierbarkeit bzgl. python: zc.buildout, pip?

h3. Laufzeitkonfiguration

• eigener komponenten auf zielmaschinen

• der betriebssystemweiten komponenten

• prozesse an/abschalten/reload

• ordering!

• geheime konfigurationsparameter auf maschinen abladen

  • passwoerter, ssh-keys, zertifikate

• tools fuer reproduzierbarkeit bzgl. python: zc.buildout, pip?

• dienste an/abschalten/neustarten

  • sinnvolle reihenfolge, auch host-uebergreifend

  • rolling restart/update

• koordinierte deployments um downtime zu minimieren

h3. Daten-Management

• datenbanken migrieren

• caches (bewusst erhalten oder bewusst löschen)

• koordinierung mit laufzeit-konfiguration?