Elevator Pitch

Worum geht es in diesem Kurs?

Wie baut und betreibt man heute Web-Applikationen?

Themen

• {Infrastruktur, Platform, Software} as a Service
• Technologien
  • Virtuelle Machinen: Vagrant + Virtual Box
  • Containers: Docker
  • PaaS: Cloud Foundry (IBM Cloud)
  • Serverless (Functions as a Service): OpenWhisk
• Application Design Patterns: Microservices, Monolith, Service Discovery

Themen (2)

• Markup: JSON, YAML (auch Tools)
• Configuration Management (Ansible)
• Continuous Integration
• Protokolle: HTTP, REST (curl, jq)
• Infrastructure as Code: evtl. Terraform, BOSH

1.-3. Vorlesungstag

• 180 min Vorlesung
• 90 min Übung
• Experiment: Pomodoro Technique

2.times:
  3.times:
    25 Min Vorlesung
    5 min Pause
  10 min Pause

4. Vorlesungstag

• 90 min Vorlesung (Pomodoro)
• ab 15:45 Abnahme der Belegarbeit
  • 15 min / Team
  • Näheres in der zweiten Vorlesung

Regeln

Offiziell:

• Anwesenheitspflicht (~liste)

Meine Interpretation

Mit der erfolgreichen Präsentation der Belegarbeit weisen Sie nach, dass sie den Kurs absolviert haben.

Interaktion

Während der Vorlesung

• Am besten immer sofort fragen
• Umfragen mit Pingo
  • Teilnahme ist freiwillig
  • Sie benötigen Computer oder Smartphone mit Internet-Zugang

Interaktion

Nach der Vorlesung

• eMail: s@uhlig.it
• Signal
• Threema

Skript

ws.uhlig.it

Fehler in den Folien?

• Die Vorlesung ist noch jung
• Fehlermeldungen willkommen

Übungen

• Selbständiges Anwenden und Vertiefen der Vorlesungsinhalte
• Keine formale Kontrolle
• Erfahrungswert: Absolvieren der Übungen erhöht Chancen auf Testat 😆

Steffen Uhlig

Geboren 1970 in Chemnitz

Chemnitz?

Bild: André Karwath

Verheiratet, 2 Kinder

Studium in Mittweida…

…und Aberdeen (Scotland)

Quelle: Alexrk2

IBM Research & Development

Quelle: GeRanD

Job: IBM Cloud

IBM Cloud (seit 2014)

Interessen

• #ruby, #golang
• #pair-programming
• #unix

Und jetzt Sie:

Folgende Technologien kenne ich bereits:

https://pingo.coactum.de/593295

Moderne Geschäftsanforderungen

1. Agilität
2. Daten über alles
3. Rigorose Kosten / Nutzen Analyse => Skalierbarkeit

Beispiel

• Globales Logistik-Unternehmen
• Senkung der Wartungs- und Instandhaltungskosten = Wettbewerbsvorteil
• Idee: Vorausschauende Wartung (“predictive maintenance”)

Liebes ChatGPT, wann wird mein Kühlschrank voraussichtlich kaputt gehen?

Umsetzung?

• Größenordnung des Erfolgs ist nicht sicher abschätzbar
  • Iteratives Vorgehen
  • Lösung muss skalierbar sein
  • Schnelle Umsetzung / Scheitern ist entscheidend
• Und das mit der eigenen IT-Abteilung, die allein 6 Monate für die Anschaffung eines Servers benötigt?

Antworten aus der (Technik-)Geschichte

Telefon

Bilder: Wikimedia, Wikimedia

Automobilbau

Bilder: Wikimedia, Wikimedia

Banken

Bilder:

Wikimedia, Wikimedia

Gemeinsamkeiten?

• Virtualisierung
• Automatisierung
• Standardisierung

=> “Service Management”

Gibt es ein Problem?

• Software wird seit ~70 Jahren produziert
• Immer noch:
  • dauert die Entwicklung länger als gedacht und
  • kostet mehr als erwartet;
  • die Software leistet oft das falsche und hat
  • Fehler, und ist meist
  • schwer zu warten und zu ändern

Softwarekrise

Gründe für die Softwarekrise?

https://pingo.coactum.de/593295

Mögliche Ursachen

Conways Law:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway (1967)

Unique Snowflakes

• Jemand installiert Standard-Software auf einem Server
  • z.B. nginx als Web Server
• Eine andere Person kopiert selbstentwickelte Software dorthin und startet sie manuell
  • z.B. eine node.js Anwendung
• Eine Dritte konfiguriert System- und Anwendungssoftware
  • Port, Prozessmonitor, Logfiles

Was passiert, wenn der Server kaputt geht?

Unzählige Konfigurationsmöglichkeiten

• implizit (in Software eingebaut)
• Windows Registry
• Config Files
• Kombinationen obiger

Wo erscheint Log-Output?

• stdout
• Log file (wie heißt es? Wo liegt es?)
• Syslog
• Log Management System

Abhängigkeiten

• A, B und C sind Module mit eigener Version
• A hängt von B v1.0 ab
• C hängt von B v2.0 ab
• B ist nicht rückwärtskompatibel

Neue App benötigt A und C

Welche Version von B wird aktiviert?

Quelle. Bilder von npm (unter ISC License).

Software unterliegt Moden

• 70er: Zentraler Mainframe
• 80er: Client / Server
• 90er: Dezentrales Internet
• 00er: Zentralisierung des Internet
• 10er: Microservices, Container, Cloud
• 20er: Renaissance der KI (incl. neuer Ernüchterung)

Warum überhaupt Software einsetzen?

https://pingo.coactum.de/593295

Lösung?

Keine

(sorry)

Vielleicht doch?

Was wäre, wenn …

… wir die Konzepte des Service Management auch auf Software anwenden?

Service Management für Software

Kosten senken und Qualität sichern durch:

• Virtualisierung
• Automatisierung
• Standardisierung

Was wäre, wenn …

… die IT eine neue Rolle hätte?

• IT-Prozesse sind leichtgewichtig und einfach zu ändern
• Alignment von Geschäft und IT optimieren das Kerngeschäft
• IT wird Schlüssel zum Geschäftserfolg

Willkommen im Industriezeitalter der IT

oder auch:

Cloud Computing

Literaturempfehlung

Service

Eine Resource und zugehörige Operationen, die einen Geschäftsvorfall (use case) unterstützt.

Beispiele:

• Rechnung erstellen
• Lohnsteuer berechnen
• Server bereitstellen

Formal

\(y = f(x)\)

Pizza as a Service

Quelle: Albert Barron, IBM

? as a Service

Umfrage As-A-Service

• Welche Beispiele für ‘X as a service’ kennen Sie?
• Hint: Nicht nur Software!

https://pingo.coactum.de/593295

Typen von Clouds

• Traditional IT
• Public Cloud
• Private Cloud
• Hybrid Cloud

Traditionelle IT

Alles In-House:

• Anforderungen erfassen (build vs. buy)
• Beschaffung
• Integration in existierende Systeme
• Strom, Netzwerk, Kühlung

Public Cloud

• betrieben von einem Dienstleister für die Öffentlichkeit
• Massengeschäft
• keine Anpassungen für einzelne Kunden

Private Cloud

• betrieben von einem Dienstleister für einen Kunden, oder
• vom Kunden selbst für die eigene Organisation
• auf kundeneigener oder Dienstleister-Hardware

Hybrid Cloud

• Verbindung von public und private Cloud
• Workload kann frei verschoben werden, je nach Anforderung

Potentiale (1)

• Einsparung von Personalkosten durch Standardisierung und Automatisierung von
  • Konfiguration
  • Betrieb
  • Verwaltung
  • Überwachung

Potentiale (2)

• Verbesserte Kapitalnutzung durch erhöhte Auslastung der Hardware
• Verringerte Lizenzkosten durch gemeinsamen Betrieb
• Beschleunigte Bereitstellung von Resourcen (Minuten statt Tagen)

Risikofaktoren (1)

im wesentlichen nicht-technischer Natur:

• Gewährleistung und Haftung
• Vertragsarten
  • Dienstvertrag
  • Mietvertrag
  • Werkvertrag
  • Kaufvertrag

Risikofaktoren (2)

• Cloud-Anbieter haben ggf. Geschäftsbeziehung mit Endanwender (Fernabsatzgesetz, AGB, MWSt.)
• Urheberrecht (an Software und den mit ihr erstellten Werken)
• Datenschutz (“EU-Cloud”)

vir|tu|ell (1)

Herkunft:

• französisch virtuel, lateinisch virtus: Tüchtigkeit; Mannhaftigkeit; Tugend
• englisch virtual: nicht in Wirklichkeit vorhanden, aber echt erscheinend

vir|tu|ell (2)

Beispiele:

• virtueller Speicher: scheinbarer, nur logisch vorhandener Speicher
• virtuelle Realität: vom Computer simulierte Wirklichkeit, künstliche Welt, in die sich jemand mithilfe der entsprechenden technischen Ausrüstung scheinbar hineinversetzen kann

Idee

Heutige Computer-Hardware kann mehr als

1. ein OS und
2. eine Applikation

zu einer Zeit.

Idee (2)

• Mehrere virtuelle (“VM”) in einer physischen Maschine (“Host”)
• Alle teilen sich die Hardware
• Jede VM hat
  • eigenes OS, und
  • eigene Apps

Characteristiken

• Abstraktion
• Partitionierung
• Isolation
• Kapselung
• Simulation und Emulation
• Teilen
• Aggregation

Abstraktion

Virtuelle Maschinen abstrahieren Hardware

Partitionierung

• Mehrere Betriebssysteme auf einer physischen Maschine
• Systemresourcen zwischen VMs geteilt:
  • CPU
  • Hauptspeicher
  • Festplatte
  • Netzwerk

Isolation

• Fehler und Sicherheitsprobleme werden beschränkt
• Performance wird “gerecht” verteilt

Kapselung

• Kompletter Zustand der VM als File im Host
• Verschieben, Kopieren, Backup wird zur simplen File-Operation

Simulation und Emulation

• Hardware-Komponenten der VM können in Software emuliert werden
• Vereinfacht Tests und “was-wäre-wenn”-Simulationen

Teilen

• Eine Vorlage kann vielfach kopiert werden
• Effizientes Teilen und Wiederverwenden von kompletten Maschinen

Aggregation

• Lastprofile verschiedener Apps können sich ergänzen
• Portabilität der VMs erlaubt dynamische Konsoliderung

Vorteile der Virtualisierung

• Bessere Ausnutzung der Hardware
• Geringere Hardware-Verwaltungskosten
• Flexiblere Nutzung von Hardware
• Bessere Sicherheit
• Höhere Verfügbarkeit
• Bessere Skalierbarkeit
• Interoperabilität und Investitionsschutz
• Verbesserte Provisionierung

Umfrage Cloud

• Virtualisierung bringt Hardware-Unabhängigkeit
• Ist das schon eine Cloud? Was fehlt noch?

https://pingo.coactum.de/593295

Vergleich

Virtualisierung

• langlebige VMs (“pets”)
• betrieben von einem dedizierten Administrator
• zentralisiert Verwaltung der Virtualisierung, nicht der VMs
• Hoher Grad an Anpassung (customization)
• Priorität: Verfügbarkeit und QoS jeder einzelnen VM
• Host: meist spezielle Hardware (“enterprise class”)

Cloud

• eher kurzlebige VMs (“cattle”)
• betrieben von Entwicklern, Endanwendern oder automatisierten Prozessen (CI/CD)
• Dezentrale Verwaltung / self-service
• Hoher Grad an Standardisierung
• Priorität: Verfügbarkeit der Control Plane
• Host: bestimmt von Software

=> Infrastructure As A Service (IaaS)

Wie nutzen wir im Team gemeinsame Infrastruktur?

Fokus auf Reproduzierbarkeit

1. Eine Maschine gemeinsam nutzen

Oh, das wird toll! Jeder überschreibt die Änderungen der Anderen.

2. VM kopieren

Auch virtuelle Festplatten werden sehr schnell sehr groß.

There is only one thing that is better than bandwidth: MORE BANDWIDTH!

3. Jeder baut eine eigene VM

nach einem Kochrezept

Hmm, könnte funktionieren.

Los geht’s!

Wir bauen:

• Eine Linux VM
• gemeinsamer Ordner zwischen Host und Gast
• SSH-Zugang
• einige Ports weitergeleitet

So geht’s mit VirtualBox:

‘New’ klicken

Einen Namen vergeben

Wieviel RAM?

Festplatte hinzufügen

Welcher Typ?

Mehr Entscheidungen …

Noch ein Name

Netzwerk brauchen wir auch

Ports zuweisen

Geteilte Ordner

Puh!

Und zum Schluß …

Zu viele Entscheidungen!

Das geht besser.

I ♥ command-line

Hmm, nicht viel besser 😔

Ruby to the rescue!

Vagrant.configure('2') do |config|
  config.vm.box = 'ubuntu/trusty64'
end

• Viele Entscheidungen bereits getroffen
• Sinnvolle Voreinstellungen
• Schöne DSL zum Beschreiben der Anpassungen
• Als Code in git pflegbar

Vagrant

Quelle: http://www.merriam-webster.com/dictionary/vagrant

Definition

Vagrant is a tool for building complete development environments.

Hmmm …

Definition

Vagrant - the command line utility for managing the lifecycle of virtual machines.

Schon besser.

Was bekommen wir?

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Setting the name of the VM: vagrant-intro_default_1462358969987_23599
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
==> default: Machine booted and ready!
==> default: Mounting shared folders...
    default: /vagrant => /Users/suhlig/workspace/vagrant-intro

Was genau bekommen wir?

• Eine Linux ‘box’ (mehr dazu später)
• Automatisch erstellter Name der VM
• RAM, Festplatte, Netzwerk bereits konfiguriert
• Gemeinsamer Ordner
  • Host: wo das Vagrantfile ist
  • Guest: /vagrant
• SSH port weitergeleitet (public key auth)

Was bekommen wir?

Architektur

Anmelden mit SSH

$ vagrant ssh
ubuntu@ubuntu-trusty:~$

Und jetzt?

Software installieren!

$ vagrant ssh
ubuntu@ubuntu-trusty:~$ sudo apt-get install nginx

Moment …

Doch wieder manuelle Installation?

Wir wollten doch Reproduzierbarkeit!

Provisioning

dt.: Bereitstellung

Supplying a vessel for an extended voyage

Source: Wikipedia

hier:

Alles, was getan werden muss, damit die VM ihre Aufgabe erfüllen kann, und das

voll automatisiert

Was bietet Vagrant dafür?

Hooks!

Ein Provisioner wird ausgeführt beim ersten Aufruf von:

$ vagrant up

und jedes mal bei

$ vagrant provision # und
$ vagrant reload --provision

Shell Provisioner: Inline

Skript im Vagrantfile:

Vagrant.configure('2') do |config|
  config.vm.box = 'ubuntu/trusty64'
  config.vm.provision 'shell', inline: 'apt-get -y install nginx'
end

Shell Provisioner: Separates Skript

Host-Pfad relativ zum Vagrantfile

Vagrant.configure('2') do |config|
  config.vm.box = 'ubuntu/trusty64'
  config.vm.provision 'shell', path: 'src/provision.sh'
end

Beispiel: VM mit Web Server

Vagrant.configure('2') do |config|
  config.vm.box = 'ubuntu/trusty64'
  config.vm.network 'private_network', type: 'dhcp'

  config.vm.provision 'file',
                      source: 'src/nginx-simple.conf',
                      destination: 'nginx-simple.conf'

  config.vm.provision 'shell', inline: <<-SCRIPT
    apt-get -y install nginx
    cp ~vagrant/nginx-simple.conf /etc/nginx/sites-available/kolloqium
    ln -sf /etc/nginx/sites-available/kolloqium /etc/nginx/sites-enabled/
    rm -f /etc/nginx/sites-enabled/default
    service nginx reload
    echo nginx is listening to:
    ip addr | grep 'inet ' | awk '{ print $2}' | grep -v 127.0.0.1 | cut -d/ -f1
  SCRIPT
end

Tips

• Es gibt viele Provisioners:

  File, Shell, Ansible, Ansible Local, CFEngine, Chef Solo, Chef Zero, Chef Client, Chef Apply, Docker, Puppet Apply, Puppet Agent, Salt

• Provisioner laufen als root (außer file)

  => privileged: false hinzufügen, um als Benutzer vagrant zu laufen

• Wenn das zu viel wird, kann man das Ergebnis als box veröffentlichen

Netzwerke

• Bridged: VM ist eigenständiger Teil des Host-Netzwerks
• NAT: Voller Netz-Zugriff durch den Host
• Host-only: Kommunikation nur Host <=> VM

Szenarien

Eine bestimmte Version von PostgreSQL?

Einfach in VM laufen lassen und Port 5432 weiterleiten

Web Server in einer VM

Files auf dem Host editieren:

Shared folders FTW!

VM als Entwicklungsumgebung

vi rocks!

Deploy to a IaaS box

Gesamte Konfiguration in einer Datei

Wann sollte man aufhören?

Fragwürdig?

$ vagrant status
Current machine states:

dev-master                not created (virtualbox)
dev-region-1              not created (virtualbox)
dev-region-2              not created (virtualbox)
int-master                not created (virtualbox)
int-region-1              not created (virtualbox)
int-region-2              not created (virtualbox)
db                        not created (virtualbox)
mq                        not created (virtualbox)
e2e                       not created (virtualbox)

This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.

Vagrantfile dazu

%w(dev int).each do |stage|
  rr.register(MasterRegion.new(stage))

  (1..REGION_COUNT).each do |i|
    rr.register(Region.new(stage, i))
  end
end

db = rr.register(Host.new('db'))
mq = rr.register(Host.new('mq'))

def erb(template, b = binding)
  require 'erb'
  ERB.new(File.read(File.join(File.dirname(__FILE__), 'provisioning', 'templates', template)), 0, "%<>").result(b)
end

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = 'ubuntu/trusty64'

  hosts = rr.hosts
  config.vm.provision 'shell', inline: erb('hosts.sh.erb', binding)

  config.vm.provider 'virtualbox' do |vb|
    vb.customize ['modifyvm', :id, '--memory', '1024']
  end
# ...
end

Wie fängt man an?

Installation

$ brew cask install virtualbox vagrant # auf dem Mac
$ mkdir hello-vagrant && cd hello-vagrant
$ vagrant init
$ vagrant up
$ vagrant ssh

Konfiguration bearbeiten

$ vi Vagrantfile
$ vagrant reload

Provisioner-Skript bearbeiten

$ vi src/provision.sh
$ vagrant provision

# Gute Idee: Von vorn beginnen
$ vagrant reload --provision

Diverses

Pets vs. cattle

• Wenn die VM kaputt ist, nicht lange debuggen, sondern einfach vagrant destroy; vagrant up
• Vagrantfile in git einchecken
• Vagrantfile ist ein Ruby-Skript - das kann man ausnutzen!

Plugins

• Bei häufigem apt-get hilft vagrant-cachier (cached Pakete)
• VMs kennen sich mit Namen m.H.d. vagrant-hostmanager (poor man’s consul)

Weiterführende Links

• Vagrant

Script

s.uhlig.it/handout

Pomodoro

https://pingo.coactum.de/440231

Musterlösungen

• Vagrant

Cloud

• Virtualisierung bringt Hardware-Unabhängigkeit
• Ist das schon eine Cloud? Was fehlt noch?

https://pingo.coactum.de/440231

Vagrant

ist ein Werkzeug für die Erstellung von:

1. Web Services
2. Viren und Schienen
3. Virtuellen Maschinen

https://pingo.coactum.de/440231

Belegarbeit

1. Vorstellung der Themen
2. Einschreiben => Moodle

Beispiel: OpenStack

… is a global collaboration of developers & cloud computing technologists working to produce an ubiquitous Infrastructure as a Service (IaaS) open source cloud computing platform for public & private clouds.

Aufbau (1)

Aufbau (2)

• Compute (Nova): Provision and manage large networks of virtual machines

• Storage (Swift, Cinder): Create secure, reliable (object, block) storage using standard hardware

• Networking (Neutron): Pluggable, scalable, API-driven network and IP management

• Dashboard (Horizon): Administrator, user access to provision cloud-based resources through a self-service portal.

Aufbau (3)

• Image Service (Glance): Catalog and manage massive libraries of server images

• Identity (Keystone): Unified tenant, user authentication & authentication for all component services

• Metering (Ceilometer): Monitoring and measurement of OpenStack components for accounting and alerting

• Orchestration (Heat): Allocates and combines OpenStack IaaS resources into a running cloud stack from AWS Cloud Formation (CFN) templates

Implementierung

• Python
• Öffentliche REST-Schnittstelle
• Interne Kommunikation ebenfalls über ^

Shell-Skripte

So alt wie UNIX: Shell Scripting (z.B. bash)

Shell-Skripte: Vorteile

• Überall vorhanden
• Leicht zu verstehen (straight forward)
• Schnell zu entwickeln (Interpreter)

Shell-Skripte: Nachteile

• Nur für UNIX¹
• Kompatibilitätsprobleme (bash vs. sh, 3.x vs. 4.x)
• Kaum höherwertige Programmierkonzepte
• Parallelität und Remoting nur rudimentär vorhanden
• Langsam
• Jedes Kommando ein neuer Prozeß

[1] bash für Windows existiert

Config Management

Wir brauchen ein höheres Abstraktionsniveau:

• Services
• Server
• Netzwerke
• Volumes / Storage

und das ganze unter Change Management!

Infrastruktur als Code

Infrastructure as code is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools¹.

[1] Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action. Manning Press. p. 93.

Config Management: Produkte

• Chef
• Puppet
• Salt
• Ansible

Was ist Ansible?

• Domänenspezifische Sprache zur Beschreibung von Infrastruktur (Playbook)
• Interpreter zum Ausführen der Beschreibung (Ansible)

Eigenschaften

• Leicht verständliche Sprache

• Keine Agents etc, nur SSH

• Deklarativ und Idempotent

• Module für:

  Cloud, Clustering, Crypto, Database, Files, Identity, Inventory, Messaging, Monitoring, Network, Notification, Packaging, Remote Management, Source Control, Storage, System, Web Infrastructure

Idempotenz

In der Informatik [wird] ein Stück Programmcode, das mehrfach hintereinander ausgeführt das gleiche Ergebnis wie bei einer einzigen Ausführung liefert, als idempotent bezeichnet.¹

[1] Wikipedia: Idempotenz

Voraussetzungen

• Controlling Machine:
  • Ansible-Installation
  • Playbook
• Nodes:
  • SSH-Server
  • Python

Architektur

Bestandteile

• Playbook
  • YAML-Files, die den gewünschten Zustand beschreiben
• Variablen
  • Kapseln veränderliche Werte
  • Können in Playbooks, Dateien, Command-Line, etc. gesetzt werden
  • “Entdeckt” (discovered variables)
• Inventory: Hosts, auf die Playbooks angewendet werden

Nomenklatur

• Playbooks enthalten 1..n Plays (Schauspiel)
• Plays enthalten Tasks (Aufgaben)
• Tasks verwenden Modules und laufen sequentiell ab
• Handler laufen am Ende eines Tasks ab
• Templates sind Vorlagen, die mit Variablen befüllt werden

Denkmuster

• Inventory ist das zu bearbeitende Material
• Playbook ist die Bauanleitung
• Modules sind die Werkzeuge

Beispiel

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: Apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: Apache config file is in place
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf
    notify:
    - restart apache
  - name: Apache is running and enabled at boot
    service:
      name: httpd
      state: started
      enabled: yes
  handlers:
    - name: restart apache
      service:
        name: httpd
        state: restarted

Details

Inventory

• Liste von Hosts
• Statische oder dynamische Liste
• Gruppierung möglich (special: all)
• 1..n inventories pro Play

Playbooks

• Enthält einen oder mehrere Plays
• Für jeden Play definierbar:
  • Liste der Hosts (aus dem Inventory)
  • User, der die enthaltenen Tasks ausführt
  • List der Tasks

Hosts

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

Hosts Patterns

[webservers]
www[01:50].example.com

Users

• remote_user: User Account, mit dem Tasks ausgeführt werden
• become: yes entspricht sudo
• become: postgres: Führe Tasks als User postgres aus

Tasks

• Ziel: Ein Module mit spezifischen Parametern ausführen
• Tasks werden
  • auf allen Hosts
  • in der angegebenen Reihenfolge ausgeführt.

Handlers

• Module sind idempotent
• Wenn sie eine Änderung verursachen, kann ein Handler ausgeführt werden

Beispiel Handler

tasks:
  - name: Configuration file exists
    template:
      src: template.j2
      dest: /etc/foo.conf
  notify:
     - restart apache
handlers:
  - name: Restart Apache
    service:
      name: apache
      state: restarted

Variables

• Drücken Unterschiede aus
• Können definiert werden in:
  • Inventory
  • Playbook
  • included files
  • Rollen

Verwendung von Variablen

• In templates:

My amp goes to {{ max_amp_value }}

(Antwort)

• In Playbooks:

template:
  src: foo.cfg.j2
  dest: {{ remote_install_path }}/foo.cfg

Variablen: Sonstiges

• Können auch entdeckt werden: “Facts”
  • z.B. ansible_nodename oder ansible_devices.sda.model
• Nested values über .-Operator
• Rangfolge (Precedence)
• Gültigkeitsbereich (Scopes)

Conditions

when

tasks:
  - name: Shut down Debian flavored systems
    command: /sbin/shutdown -t now
    when: ansible_os_family == "Debian"

Loops

- name: Several users exist
  user:
    name: "{{ item }}"
    state: present
    groups: "wheel"
  with_items:
     - testuser1
     - testuser2

Jinja Templates

Jinja2 is a modern and designer-friendly templating language for Python¹

[1] Jinja2 Doku

Jinja Templates (2)

<ul id="navigation">
{% for item in navigation %}
    <li><a href="{{ item.href }}">{{ item.caption }}</a></li>
{% endfor %}
</ul>

<h1>My Webpage</h1>
{{ a_variable }}

{# a comment #}

Roles

• Gruppieren einen Satz von Variablen, Tasks und Handlern
• Wohldefinierte Struktur
• Macht die Rolle wiederverwendbar
• Ansible Galaxy listet Rollen (mit Ratings und Reviews)

Best Practices

• Wiederverwendung: Mehrere verschiedene Plays auf einen Host anwenden (Rollen)
• Tasks sollten einen lesbaren Namen haben (name: Webserver aktualisieren)

Weiterführende Themen

• Roles
• with_items
• failed_when
• changed_when
• until
• ignore_errors

Aufruf

• Ad-hoc: ansible <inventory> -m <module>
• Playbook: ansible-playbook <playbook>.yml

Weiterführende Links

• docs.ansible.com

Was sind Container?

Gütertransport vor ca. 1960

Matrix from Hell

Lösung: Container für alles

Staging vor 2013¹

[1] vor Docker

Auch hier: Matrix from Hell

Container vereinheitlichen die Matrix

Wie?

Warum ist das für die Entwicklung interessant?

• Läuft überall¹
• Einheitliche Umgebung in dev, staging & prod
• Alle Abhängigkeiten enthalten
• Apps teilen sich keine Abhängigkeiten

[1] überall: x86, moderner Linux kernel, tlw. auch ARM, Power und SystemZ

Warum ist das für die Entwicklung interessant? (2)

• Einheitlicher Lebenszyklus ermögliche Standardisierung von
  • Deployment
  • Start
  • Stop
  • Scaling
  • Löschen
• Keine Kompatibilitätsprobleme mehr (?)

Warum ist das für den Betrieb interessant?

siehe oben plus:

• Kaum teurer als Prozesse (vgl. VM)
  • Weit weniger Hardware benötigt
• Einheitlicher Lebenszyklus aller Services
• Effizienzgewinn durch Standardisierung
• Continuous Deployment wird stark vereinfacht
• Trennung der Verantwortlichkeiten

Trennung der Verantwortlichkeiten

Idee

Achtung:

Containers == Docker?

• Falsch!

Geschichte

• Linux Kernel: process isolation
  • Namespaces (2006)
  • cgroups (2007)
  • LXC (2008)
  • CF Warden (2011)
  • Docker (2013)

Docker

• dotCloud (..2013)
• Marketing
• Tooling
• Mindshare (!)

Ab hier

Containers =~ Docker

Docker: Bestandteile

• Image: Vorlage oder Bauplan für Container
• Container: eine Instanz eines Images, die ausgeführt wird
• Registry: verwaltet Images
• Engine: Laufzeit-Plattform (dockerd, REST API, docker client)

Docker Engine

Architektur

Hands-on

Container starten

Achtung: Vor dem ersten Start is Setup nötig - siehe Übung!

$ docker run -it --rm alpine sh
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
Digest: sha256:f006ecbb824d87947d0b51ab8488634…
Status: Downloaded newer image for alpine:latest
/ # ▋

Was ist passiert?

• Image pulled (alpine)
• Container gestarted (run)
• Mit interaktivem Terminal (-it)
• Shell gestartet (sh)
• Shell interaktiv beendet
• Container gelöscht (--rm)

Container mit langlaufendem Prozeß (1)

$ docker run -it --rm alpine top

Container mit langlaufendem Prozeß (2)

Neues Terminal:

$ docker ps -l --format "{{.Names}}"
epic_jones
$ docker exec -it epic_jones sh
/ # ps ax
PID   USER     TIME   COMMAND
    1 root       0:00 top
    5 root       0:00 sh
   13 root       0:00 ps ax

Container stoppen

von innen:

$ docker ps -l --format "{{.Names}}"
cocky_nobel
$ docker exec -it cocky_nobel sh
/ # kill 1
$

Container stoppen

von außen:

$ docker ps -l --format "{{.Names}}"
gifted_newton
$ docker kill gifted_newton

Containers vs. VMs

Container-Image

• beschrieben durch Dockerfile:
  • Text-Datei mit Schritten zum Bau des Images
• gebaut mit docker build .

Dockerfile

• #: Kommentare
• FROM: Basis-Image (‘abgeleitet von’ oder ‘basiert auf’)
• RUN: Kommando ausführen und Ergebnis als Layer committen
• ADD: Lokale Dateien und Verzeichnisse hinzufügen
• CMD: Was bei docker run passiert
• EXPOSE: Deklaration von Ports (vgl. --publish)
• ENV: Umgebungsvariablen setzen

Multi-Container Orchestration

Ein Container kommt selten allein:

• Three-tier web app (siehe Vagrant-Übung)
• Wordpress (PHP-files + MySQL)
• mehrere Server-Prozesse pro Container (ssh)
  • Anti-Pattern

Prinzip

• YAML-Datei beschreibt eine “Komposition” aus mehreren Containern (‘Services’)
  • Image (z.B. postgres oder php)
  • Volumes
  • Abhängigkeiten
  • Umgebungsvariablen
  • Ports
  • etc.
• Images wie gewohnt mit Dockerfile beschrieben

Literatur

• Docker Überblick
• Levinson, Marc: “The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger”; Princeton University Press, 2008

IBM Cloud

Bitte einen IBM Cloud Account anlegen.

Musterlösungen

1. Ansible
2. Docker

Ansible

Ansible ist ein Werkzeug für die

1. Verteilung von Software
2. Infrastruktur-Automatisierung
3. Konfiguration von Servern

https://pingo.coactum.de/344715

Container

Container sind eine nützliche Erfindung, weil sie

1. Hardware effizienter nutzbar machen
2. Windows-Applikationen auf Linux verfügbar machen
3. das Deployment von Applikationen vereinheitlichen

https://pingo.coactum.de/344715

Nun können wir…

• … einen Container bauen
• … einen Container in Betrieb nehmen
• … einen Container löschen

EINEN Container?

• Wie viele Applikationen kennen Sie, die aus einem einzigen Prozess bestehen?

• Wer kümmert sich um die Verfügbarkeit?

  host kernel: Out of Memory: Killed process 4321 (nginx)

• Wartungsfenster like it’s 1999

  Nächste Woche kommt der Elektriker ins Rechenzentrum und wechselt die Hauptsicherung.

• “Hurra, wir haben über Nacht 2000 neue Kunden gewonnen!” 🎉

  Oops, schnell mal zehn neue Server aufsetzen 😓

• Im Unternehmen: Viele Apps und Teams

  Hardware teilen, ohne uns gegenseitig auf die Füße zu treten?

Brief vom Pizzabäcker (1)

Brief vom Pizzabäcker (2)

Was brauchen wir?

• Maschinenlesbare Beschreibung der Architektur
• Software, die sich um die Umsetzung der ^ kümmert
• Hardware, die das ausführt

War da nicht schonmal was?

Was ist anders?

Container-Architekturen sind anders!

Im Gegensatz zum Deployen von Software auf Hardware / virtuelle Maschinen sind Container:

• schnell zu erstellen,
• bringen alle Abhängigkeiten¹ mit, und sind
• schnell wieder zu löschen.

[1] statische Abhänigkeiten; dynamische ~ werden als Services konsumiert

Idee

fünf Instanzen meiner Pizza-Bestell-Applikation in der Version 3.4.2

- name: Luigi's Pizza                       # Name des Containers
  image: lothar-folkman/luigis-pizza:3.4.2  # Image URL
  command: [ /order ]                       # Start-Kommando
  args: [ serve ]                           # Argumente

replicas: 5                                 # 5 Instanzen

Idee (2)

wäre schön, wenn nicht wieder alles zusammenbricht, nur weil am Samstag um 19 Uhr…

Hochverfügbar => Container über mehrere Maschinen verteilen

Wie könnten wir das realisieren?

Wer sorgt dafür, daß diese Architektur entsteht?

Definition

Orchestration is the assignment of different instruments to play the different parts (e.g., melody, bassline, etc.) of a musical work.¹

[1] Wikipedia: Orchestration

Idee

Software…

• …setzt die Wunschliste in Realität um, und
• kümmert sich darum, daß es so bleibt.

Der zweite Teil ist wichtig!

Please welcome to the show

Was ist ein “Kubernetes”?

• Open Source Container Orchestrator
• 2015 von Google veröffentlicht
• heute von Cloud Native Computing Foundation gepflegt
• riesige Unterstützung aus der Industrie (Amazon, Google, IBM, Microsoft, Oracle, Red Hat, SUSE, VMware)
• Sourcecode in Go
• Kurzform: k8s

Architektur

Denkmodell

Wir vermieten¹ Platz², auf dem Kunden ihre Container betreiben können³.

• [1] virtuell endlosen
• [2] CPU, Speicher, Netzwerk
• [3] ohne sich mit Infrastruktur herumschlagen zu müssen

Konzepte

cluster = control plane + nodes

Nodes

• VMs, die die Arbeit (workload) verrichten
• 1..n nodes erlauben Skalierung des Clusters
• Agent setzt Anweisungen der control plane um für
  • Pods (kubelet)
  • Netzwerk (kube-proxy)
  • Laufzeitumgebung (container runtime interface)

Control Plane

• Werkzeug des Betreibers, um Nodes und Workloads zu verwalten
• Speichert die Wunschlisten, und setzt sie in Realität um
  • Verteilte Datenbank (etcd)
  • Platzierung von Containern (scheduler)
  • Konvergenz (controller manager)
  • Abstraktion (cloud controller manager)
• REST API

Rückschau

Korrektur

Pod Details

Pod Eigenschaften

• teilen sich Speicherplatz und Netzwerk
• werden gemeinsam:
  • geplant (co-scheduled), und
  • platziert (co-located)
• Anweisungen in pod spec

Pod Denkmodell

• Applikation¹ == Pod
• Häufig: Ein Container pro Pod

• Weitere Muster:

  • init container
  • side car
  • shared volume

[1] Instanz einer Applikation

Mehr Details

in der k8s Dokumentation:

• pods
• lifecycle, phases, probes

Vorsicht, Falle!

Pod weg?¹

Pech!   ¯\_(ツ)_/¯

Was wurde eigentlich aus…

Controller (1)

Verantwortlich für Konvergenz

• Wunschliste → Realität eines Resourcentyps
• z.B. Pod

Controller (2)

Klassisches Beispiel: Thermostat

• Wunschtemperatur (Sollwert) wird eingestellt
• Aktuelle Temperatur wird gemessen (Istwert)
• Heizung kann nur ein oder aus
• Regelkreis schaltet Heizung so ein und aus, dass Sollwert

  1. erreicht wird, und
  2. erhalten bleibt.

Controller (3)

Typische Sollwerte in k8s:

• Anzahl von bestimmten Pods
• Existenz von Services
• Platzierung von Pods (z.B. daemonset)

Anwendungsarchitekturen

a.k.a. workloads

Alles andere: CustomResourceDefinition (CRD)

ReplicaSet

Ich hätte gern fünf Instanzen meiner Pizza-Bestell-Applikation in der Version 3.4.2

• Anzahl von Pods
• für zustandslose¹ Apps
• Alle Pods sind identisch (austauschbar)

Bestandteile

1. Selector (scope)
2. Anzahl (how many)
3. Pod Template (what)

Beispiel

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels: { app: guestbook, tier: frontend }
spec:
  replicas: 3
  selector: { matchLabels: { tier: frontend } }
  template:
    metadata: { labels: { tier: frontend } }
    spec:
      containers:
        - name: php-redis
          image: gcr.io/google_samples/gb-frontend:v3

Deployment

ReplicaSet + Update-Strategie

• rollout und rollback
  • (nur) wenn sich das pod template geändert hat
  • Deployment als Ganzes bleibt verfügbar

StatefulSet

Deployment mit Pod-Identität

• Pods sind gleich, aber nicht identisch in Bezug auf
  • Netzwerk
  • Speicherplatz
  • Position (Rang) bei Deployment, Scaling & Updates

Wichtigster Anwendungsfall: jeder Pod hat seinen Storage (PVC)

DaemonSet

ReplicaSet mit einem Pod pro Cluster-Node

• Neuer Node => neuer Pod
• Node gelöscht => Pod gelöscht
• Anwendungen:
  • Log Forwarding
  • Monitoring
  • Storage Daemons

Job / CronJob

run to completion

• einmalig (job)
• regelmäßig (cron job)

Service (1)

EXPOSE für Apps

• Jeder Pod hat eigene IP-Adresse
• Pods sind i.A. durch Controller gesteuert
• Remember: Applikation == Pod
• Wie kann man eine App logisch addressieren?
  • verwandt: Load Balancer

=> Service

Service (2)

apiVersion: v1
kind: Service
metadata: { name: my-service }
spec:
  selector: { app.kubernetes.io/name: MyApp }
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Wie fängt man an?

1. Wunschliste in YAML schreiben
2. An Control Plane übergeben mit kubectl apply
3. Zustand beobachten mit kubectl get

Weiterführendes

• k8s Dokumentation
• Minikube - lokaler k8s cluster (macOS, Linux, Windows)
• Killercoda Playground
• Horizontal Pod Autoscaling
• Episode 72 des SoftwareArchitekTOUR-Podcasts: “Cloud-native Development”

Mögliche Themen der vierten Vorlesung

• PaaS
• FaaS
• Vergleich IaaS, PaaS, FaaS
• BOSH
• DevOps

Was noch?

Welche Inhalte wünschen Sie sich für die vierte Vorlesung?

https://pingo.coactum.de/344715

Rückblick

Wie weit sind Sie in der k8s-Übung gekommen?

https://pingo.coactum.de/783087

YAML Ain’t Markup Language

YAML is a human-friendly, cross language, Unicode based data serialization language designed around the common native data types of dynamic programming languages.¹

[1] yaml.org/spec/1.2.2

Problem

Lösung

invoice: 34843
date   : 2001-01-23
bill-to: &id001
  given  : Chris
  family : Dumars
  address:
    lines : |
      458 Walkman Dr.
      Suite #292
    city  : Royal Oak
    state : MI
    postal: 48046
ship-to: *id001

product:
  - sku         : BL394D
    quantity    : 4
    description : Basketball
    price       : 450.00
  - sku         : BL4438H
    quantity    : 1
    description : Super Hoop
    price       : 2392.00
tax  : 251.42
total: 4443.52
comments: >
    Late afternoon is best.
    Backup contact is Nancy
    Billsmer @ 338-4338.

Datentypen

• scalar: String, Zahl
• collection: Array / Liste
• structure: assoziatives Array / Hashtable

Skalare

$ cat <<EOM | yq
Das ist ein String.
EOM

Das ist ein String.

Scalare als Block (1)

• literal block: |
• alle line breaks sind signifikant

$ cat <<EOM | yq
|
  10 HOME
  20 SWEET
  30 GOTO 10
EOM

10 HOME
20 SWEET
30 GOTO 10

Scalare als Block (2)

• folded block: >
• jeder line break wird zum Leerzeichen

>
  How can I be so bad
  at everything I try,
  and still be so great?

How can I be so bad at everything I try, and still be so great?

Liste von Scalaren

- Fry
- Leela
- Bender

- 11
- 42
- 69

Mapping Scalar => Scalar

Fry: Human
Leela: Mutant
Bender: Robot

Mapping Scalar => Sequence

Robot Santa Claus:
  - Xmas Story
  - A Tale of Two Santas
  - The Futurama Holiday Spectacular
  - I Know What You Did Next Xmas
Bart Simpson:
  - A Big Piece of Garbage
  - Mars University
  - Simpsorama

Sequence von Mappings

- name: Turanga Leela
  gender: female
  status: alive
  age: 25-31
  species: mutant
- name: Philip J. Fry
  gender: male
  status: alive
  age: 1025-1031
  species: human

Referenzen

• a.k.a. repeated nodes
• Bezeichnet mit &
• Referenziert mit *

work:
  - Charles Montgomery Burns
  - Waylon Smithers, Jr.
  - &homer Homer J. Simpson
pub:
  - Moe Szyslak
  - *homer

{
  "work": [
    "Charles Montgomery Burns",
    "Waylon Smithers, Jr.",
    "Homer J. Simpson"
  ],
  "pub": [
    "Moe Szyslak",
    "Homer J. Simpson"
  ]
}

Tools

• yamllint.com
• yamllint
• yq

Komplettes Beispiel

apiVersion: v1
kind: Pod
metadata:
  name: plaintoot
  labels: { app: plaintoot }
spec:
  containers:
    - name: plaintoot
      ...

Finde den Namen des ersten Containers aller Pods mit dem Label plaintoot:

$ yq 'select(.metadata.labels["app"] == "plaintoot") | .spec.containers[0].name' < pod.yml
plaintoot
EOM

Warum müssen wir codieren?

Grundgedanke: Daten werden seriell übertragen

Absprache

• Sender und Empfänger müssen sich einig sein:
  • Reihenfolge der Interpretation (LSB oder MSB zuerst)
  • Wie werden Bits interpretiert?
• Bekanntes Problem => Standardlösungen
• Byte Order Mark

Bekannte Codecs

• Morsecode (1865¹)
• 7 bit: ASCII (1963)
• 8 bit:
  • EBCDIC (IBM, 1964)
  • ISO-8859-1 (Latin 1, 1985)
  • ISO-8859-8 (Hebräisch)
• 16 bit: UTF-16
• 8..24 bit: UTF-8

[1] erfunden ca. 1838; standardisiert 1865

Quelle: Wikipedia

Problem?

• ä,ö,ü
• Westeuropa: å, ô, ÿ
• €

Lösung: “Nimm ein bit mehr”

ISO 8859-1

• a.k.a. Latin 1
• 8 bit pro Zeichen
• verwandt: Windows-1252

Unicode

• Standardisierung von Schriftzeichen
• Definiert Zeichen, deren Codepoint, Normalisierung, Sortierung

UTF-8

• Kann jedes Unicode-Zeichen darstellen
• Ist robust (verzeiht Fehler)
• Text ist (binär) größer als single-byte Encodings (außer ASCII)
• Text ist (binär) kleiner als UTF-16 (für Europäische Sprachen)
• Chinesischer und japanischer Text ist (binär) größer als in UTF-16

Details

ISO8859-1

$ echo -n '<x>süß</x>' | iconv --to iso8859-1 | hexdump -C
00000000  3c 78 3e 73 fc df 3c 2f 78 3e  |<x>s..</x>|

ISO 8859-1

UTF-16

$ echo -n '<x>süß</x>' | iconv --to utf-16 | hexdump -C
00000000  fe ff 00 3c 00 78 00 3e 00 73 00 fc 00 df 00 3c
00000010  00 2f 00 78 00 3e

UTF-16

UTF-8

$ echo -n '<x>süß</x>' | iconv --to utf-8 | hexdump -C
00000000  3c 78 3e 73 c3 bc c3 9f 3c 2f 78 3e  |<x>s....</x>|

UTF-8

Spezialfall €

• UTF-16: 20 AC
• UTF-8: E2 82 AC
• Latin1: Nicht im Zeichencodec enthalten!
  • Umschreibung in HTML: € bzw. €
  • ISO8859-15 (1999): A4

Werkzeuge

$ iconv -f ISO88591 -t UTF8 < in.txt > out.txt

$ iconv --list | wc -l
1173

Tipp für die Praxis

PaaS

Vision

Plattformen ermöglichen Innovation

Workflow

Video courtesy of Matthias Diester

Grundidee

Services werden dynamisch gebunden.

Buildpack (1)

• Stellt Framework und Runtime für Applikationen bereit
• Untersucht die App auf Abhängigkeiten und bezieht diese
  • nodejs: npm install
  • Ruby: bundle install
  • Static files: Installiert nginx

Buildpack (2)

• Konfiguriert die App für gebundene Services
  • PORT
  • VCAP_SERVICES
• Erkennung läuft automatisch nach cf push
• Kann in manifest.yml überschrieben werden

Buildpacks in CF für:

• Go
• Java
• .NET
• Node.js
• PHP
• Python
• Ruby
• Staticfile

Community Buildpacks

Django, Perl, C++, TomEE, Eclipse Virgo, Jetty, Clojure, Haskell, Python, Zend Server (PHP), Null, JBoss, WebSphere Liberty, Erlang, Elixir, Swift

Empfehlung

s.uhlig.it/cf-intro-lf

Kurs ist kostenlos!

Everything is getting more fine-grained

Was heißt das?

Grundgedanke:

Code runs only on-demand, on a per-request basis

Computing wird zur Standard-Handelsware

Serverless is for compute what object storage is for storage

Charakteristik

• Serverless Deployment & Betrieb
• Optimale Ausnutzung der Resourcen (CPU, Memory, Storage)
• Feingranulare Preismodelle
• Skaliert auf Basis einzelner Requests

Welches Problem löst FaaS besser?

Traditionell (1)

Traditionell (2)

Herausforderungen:

• Skalierung
  • Wann? (Monitoring)
  • Opimierung für? (Speicher, CPU, Antwortzeit, …)
  • Wie schnell? (6 Monate, bis der neue Server da ist)

Traditionell (3)

Herausforderungen:

• Robustheit vs. Kosten
  • HA => mind. 2 Prozesse pro App “am laufen halten”
  • DR: mehrere Regionen
• Kosten fallen immer an (unabhängig vom Grad der Auslastung)
• Ereignisgesteuerte Architektur nicht verbreitet
  • Polling => unnütze Requests => Mehrkosten

Wie FaaS skaliert (1)

Wie FaaS skaliert (2)

• Für jeden Request ein Prozess
• Keine Mehrkosten für Robustheit
  • es gibt keine LRPs
• Inhärent ereignisgesteuert (event-driven)
• Bezahlt wird nur, was angefordert (requested) wurde
  • Auswirkung auf Code
  • Höhere Entwicklungsgeschwindigkeit
  • Geringere operationale Kosten

FaaS Fallstudie

Apache OpenWhisk

OpenWhisk

• FaaS Platform, um ereignisgesteuert Code auszuführen
• Open Source (Apache Foundation)
• Managed Service: IBM Cloud Functions

OpenWhisk Architektur (1)

OpenWhisk Architektur (2)

Programmiersprachen

Aufruf-Modelle

High-level Konstrukte

Ereignis-Quellen (1)

Ereignis-Quellen (2)

Granulares Preismodell

• Kosten fallen nur für die Laufzeit einer Action an
• Action nicht aufgerufen? Keine Kosten!

Preismodell (1)

\(p = t \cdot m \cdot \frac{\$0.000017}{GiB \cdot s}\)

Preismodell (2)

Beispiel

• Java-Funktion

  Speicherbedarf	\(1 GiB\)
  Laufzeit	\(60 s\)

• Preis pro Aufruf:

  \(1GiB \cdot 60s \cdot \frac{\$0.000017}{GiB \cdot s} = \$0.00102\)

Freikontingent (1)

\(400000 \frac{GiB \cdot s}{Monat}\)

Freikontingent (2)

Für das vorherige Beispiel:

\(\frac{400000\frac{GiB \cdot s}{Monat}}{60\frac{GiB \cdot s}{Request}} \approx 6666 \frac{Requests}{Monat}\)

Web Actions

• Volle Kontrolle über HTTP-Interaktionen
• Access an action anonymously without requiring authentication key

$ wsk action update hello --web true
ok: updated action hello

Beispiel: HTTP Redirect

function main(params) {
  return {
    headers: { location: 'http://openwhisk.org' },
    statusCode: 302
  };
}

Beispiel: Cookie setzen

function main(params) {
  return {
    headers: {
      'Set-Cookie': 'UserID=Jane; Max-Age=3600',
      'Content-Type': 'text/html'
    },
    statusCode: 200,
    body: '<html><body>Hello</body></html>'
  };
}

Beispiel: Bild senden

function main(params) {
  // errechnet, z.B. aus Parametern
  let png = 'base-64 encoded String';

  return {
    headers: { 'Content-Type': 'image/png' },
    statusCode: 200,
    body: png
  };
}

Einsatzgebiete

Wofür eignet sich FaaS?

• Wechselhafte Lasten
• teilbare Systeme (microservices, anyone?)
• passend für sporadische- als auch Hochlast-Apps

Links

• openwhisk.org
• bluemix.net/openwhisk
• slack.openwhisk.org
• github.com/openwhisk
• twitter.com/openwhisk
• medium.com/openwhisk
• slideshare.net/OpenWhisk
• youtube channel

Überblick

Functions (FaaS)

Apps (PaaS)

Containers

VMs

On-Premise

Bewertung (1)

Veranstaltungsfeedback

https://pingo.coactum.de/783087

Bewertung (2)

meinprof.de/uni/kurs/124788

Meta

rev. aeaa7e6
built on 2023-12-22 12:22:56 UTC