LXD on zefanjas.de - Open Source & Education

Wekan – eine Open Source Trello Alternative

Fri, 03 Apr 2020 07:25:21 +0000

In den letzten Wochen habe ich eine Software ausprobiert, die schon lange auf meiner Liste stand: Wekan. Wekan ist eine Open Source Alternative für Trello, einer Kanban-Software. Mit ihr lassen sich mit der Kanban-Methode Projekte oder Abläufe managen. Manche verwenden es auch als Aufgabenmanagementsystem. Es gibt verschiedene Open Source Alternativen zu Trello – Wekan ist eine, die dem Original am nächsten kommt. Ich möchte heute zeigen, wie man Wekan installiert und einrichtet.

Installation

Wekan kann man auf verschiedene Art und Weise installieren (manuell, Docker, snap, …). Wir werden es heute in einem LXD Container (Ubuntu 18.04) einrichten (LXD Container waren hier schon mehrmals Thema im Blog). Als erstes erstellen wir einen Container für Wekan:

$ lxc launch ubuntu:b wekan

Nachdem der Container erstellt und gestartet ist, loggen wir uns im Container ein:

$ lxc exec wekan bash

Wir werden Wekan als Snap installieren. In den Ubuntu LXD Container ist snapd schon installiert. Wir können also direkt Wekan installieren mit

$ snap install wekan

Nun legen wir die Haupt-URL und den Port für Wekan fest:

$ snap set wekan root-url="http://wekan.example.com"
$ snap set wekan port="80"

Optional kann man noch einstellen, das Updates automatisch installiert werden:

$ snap set core refresh.schedule=02:00-04:00

Fertig 🙂

Einrichtung

Nun können wir unter der IP unseres LXD Containers Wekan aufrufen. Wenn man LXD nicht lokal, sondern auf einem Server betreibt, kann es unter Umständen hilfreich sein eine Netzwerkbrücke für den Container einzurichten. Alternativ kann man auch Nginx als Reverse Proxy verwenden. Hinweise zur Einrichtung findet man im Wiki von Wekan.

Hinweis: Der erste Benutzer, den wir einrichten, ist Administrator für Wekan.

Wir klicken als auf Registrieren und legen einen neuen Benutzer an.

Wenn wir nun auf Registrieren klicken, erscheint eine Fehlermeldung („Internal Server Error“). Das liegt daran, weil wir noch keinen EMail-Server eingerichtet haben.

Wekan funktioniert aber auch ohne einen EMail-Server, deswegen öffnen wir einfach wieder unsere Hauptseite (wekan.example.com bzw. die IP des Containers) und können uns mit den eben angelegten Benutzer anmelden.

Nun können wir neue Boards in diesen neue Listen und Karten erstellen. Die Funktionsweise ist dem von Trello sehr ähnlich.

Fazit

Wer nach einer Open Source Alternative für Trello sucht, die man selber hosten kann, findet in Wekan einen guten Ersatz. Ich habe bisher oft Trello verwendet. Mit Wekan habe ich endlich einen Ersatz gefunden, der so ziemlich ein 1:1 Ersatz für Trello ist.

Netzwerkbrücke für LXD Container einrichten

Thu, 07 Feb 2019 14:05:12 +0000

Die meisten unserer Webanwendungen laufen in LXD Containern. Nicht ohne Grund ist LXD für mich eines der wichtigsten Features von Ubuntu Server. Es gibt viele Wege um von außen auf eine Webanwendung in einem LXD Container zuzugreifen. So kann man z.B. einen Reverse Proxy nehmen und darüber die Zugriff auf die Container regeln (hier hatte ich schon mal davon berichtet). Eine andere Möglichkeit ist die Einrichtung einer Netzwerkbrücke, sodass sich die Container im gleichen Netz wie der Containerhost (Ubuntu Server) befinden. In diesem Artikel möchte ich kurz beschreiben, wie man eine Netzwerkbrücke für LXD Container einrichtet.

Netzwerkbrücke für LXD Container

Um eine Netzwerkbrücke unter Ubuntu einzurichten, muss man die bridge-utils installieren:

$ apt install bridge-utils

Danach kann man die Netzwerkbrücke einrichten.

bis Ubuntu 16.04

Bis Ubuntu 16.04 nutzt Ubuntu ifupdown um Einstellungen für die Netzwerkverbindungen festzulegen. Die Konfiguration nimmt man in den Dateien unter /etc/network/ vor. Eine einfache Netzwerkbrücke, um die Container in das Host-Netzwerk zu bekommen, könnte so aussehen:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The main Bridge
auto br0
iface br0 inet dhcp
    bridge-ifaces enp4s0
    bridge-ports enp4s0
    up ip link set enp4s0 up

# The primary network interface
iface enp4s0 inet manual

Hier bekommt die Brücke ihre Adresse vom DHCP-Server mitgeteilt. Die reale Netzwerkkarte enp4s0 wird in den manuellen Modus gesetzt und der Brücke zugewiesen.

ab Ubuntu 18.04

Ab Ubuntu 18.04 wird Netplan für die Konfiguration der Netzwerkverbindungen verwendet. Die Konfigurationsdateien befinden sich unter /etc/netplan/. Eine Definition für die Brücke könnte folgendermaßen aussehen:

$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp3s0:
            dhcp4: no
    version: 2
    bridges:
        br0:
            dhcp4: no
            addresses:
            - 10.10.10.5/24
            gateway4: 10.10.10.254
            nameservers:
                addresses:
                - 10.10.10.254
            interfaces:
            - enp3s0

Im oberen Teil konfiguriert man die reale Netzwerkkarte (enp3s0) und weißt ihr keine Adresse zu. Danach folgt die Definition der Netzwerkbrücke. Sie wird wie eine statische Netzwerkverbindung eingerichtet und enthält zusätzlich den Punkt interfaces. Dort legt man fest, welche reale Netzwerkkarte „überbrückt“ werden soll. Weitere (komplexere) Beispiele zu Netzwerkbrücken gibt es auf der offiziellen Website.

Nun werden mit dem folgenden Befehl die Änderungen an den Netzwerkeinstellungen angewendet:

$ netplan apply  --debug

Netzwerkbrücke zuweisen

Hat man die Netzwerkbrücke fertig eingerichtet und bekommt sie auch die richtige IP-Adresse, muss man dem LXD Container noch mitteilen, dass er seine IP-Adresse über die Netzwerkbrücke beziehen soll. Das erledigt man mit folgendem Befehl:

$ lxc config device add containername eth0 nic nictype=bridged parent=br0 name=eth0

Mit name=eth0 legt man fest, unter welchen Namen man die Netzwerkkarte im Container findet. Nun kann man im Container eth0 nach Belieben konfigurieren. Ab sofort sollte der Container eine IP-Adresse aus dem Host-Netzwerk bekommen.

Fazit

Eine einfache Netzwerkbrücke lässt sich schnell einrichten und man kann sie ohne Probleme einem Container zuweisen. Andere Benutzer im Netzwerk können so ohne die Einrichtungen eines Reverse-Proxys auf eine Webanwendung zugreifen. Auch komplexere Szenarien sind denkbar (VLANs, mehrere Brücken, um die Container in verschiedene Netz zu bekommen etc.), doch das würde den Rahmen dieses kurzen Artikels sprengen.

Backup für LXD-Container

Sat, 12 May 2018 02:44:26 +0000

[LXD][1] ist ein Hypervisor für Linuxcontainer, den es seit einigen Versionen in Ubuntu gibt. Ein Linuxcontainer ist im Prinzip wie eine virtuelle Maschine, nur leichtgewichtiger. Wir verwenden LXD / LXC für viele unserer Anwendungen an der Schule. LXD lässt sich leicht bedienen und es gibt so [einige Gründe][2], warum wir es verwenden. Heute möchte ich zeigen, wie man das Backup für LXD-Container machen kann.

1. Möglichkeit: lxc copy

Die einfachste Möglichkeit besteht darin, das man einen LXD-Container einfach auf einen anderen Rechner kopiert. Dazu braucht man einen zweiten LXD-Host, den man auf dem ersten als Remote hinzufügt.

$ sudo lxc remote add lxd2 192.168.1.50

lxd2 ist dabei der Name, den man dem zweiten LXD-Host geben wollen, gefolgt von der IP. Beim Setup des zweiten LXD-Hosts muss man darauf achten, dass er über das Netzwerk erreichbar ist und man muss auch ein Admin-Passwort vergeben. Dieses Passwort muss man eingeben, wenn man die Remote hinzufügen will.

Ist alles eingerichtet kann man sich z.B. alle Container auf der Remote anzeigen lassen:

$ lxc list lxd2:

Um nun ein Backup eines Containers zu machen, kopiert man ihn bzw. einen Snapshot auf die eben hinzugefügte Remote:

$ lxc snapshot my-container my-snapshot
$ lxc copy my-container/my-snapshot lxd2:my-backup

In umgekehrter Weise kann man den Container wieder auf dem ursprünglichen Host wiederherstellen.

$ lxc copy lxd2:my-backup my-container-restored

2. Möglichkeit: lxc export und lxc publish

Mit LXD kann man auch einen Container als komprimiertes Image exportieren und dann auf einem NAS, einem Offsite-Backup oder einem Cloud-Speicher sichern. Später können diese Images dann mit lxc import wieder importiert bzw. wiederherstellt werden.

Auf [Github habe ich ein Skript gefunden][3], welches genau unsere Anforderungen erfüllt. Es exportiert den gewünschten Container und sichert ihn dann mit rclone (tolles Projekt!!!) auf einen Cloud-Speicher/NAS unserer Wahl.

Dazu muss man sich erst noch rclone installieren und einrichten. Ein Anleitung für die Installation und Pakete für alle Plattformen gibt auf der [Projektwebseite][4]. rclone unterstützt so ziemlich jeden Cloud-Speicher und Protokoll (ssh, webdav, …). Wir haben uns für ein Backup auf Google Drive entschieden, da wir da durch GSuite for Education unbegrenzten Speicherplatz haben 🙂

Ist rclone eingerichtet lädt man sich das Backup-Skript herunter, macht es ausführbar:

$ wget https://raw.githubusercontent.com/cloudrkt/lxdbackup/master/lxdbackup
$ chmod +x lxdbackup

Damit der Upload des Backups auch funktioniert muss man noch einige Parameter festlegen (v.a. RCLONETARGET).

$ nano lxdbackup
# Settings

# The target bucket or container in your Rclone cloudstorage 
RCLONETARGETDIR="lxdbackup" 
# Optional Rclone settings.
RCLONEOPTIONS=""
# Rclone target cloud used in your rlcone.conf
RCLONETARGET="my-remote"
# Directory were local images are stored before upload
WORKDIR="/tmp/lxdbackup"
```

Nun kann man das Skript mit folgendem Aufruf testen:

```
$ lxdbackup my-container
```

Wenn alles gut geht, sollten man sein Backup nach einiger Zeit (der Export eines Containers kann etwas dauern, je nach Größe) auf dem Speichern finden, den man in `rclone` konfiguriert hat.

### Fazit

Bisher haben wir einfach den LXD-Host im Gesamten gesichert. Das reicht in der Regel aus, aber man verliert die Möglichkeit einzelne Container getrennt voneinander wiederherstellen zu können. Mit dem lxdbackup-Skript und der Kombination mit `rclone` haben wir nun viel mehr Möglichkeiten und können unsere Container sehr flexibel sichern. Mit Hilfe von Cronjobs haben wir das Backup automatisiert. Manche Container werden z.B. 2x am Tag gesichert, andere nur 1x in der Woche ([und das nur, wenn keine Schulferien sind][5]) – je nach Anwendungsfall.

 [1]: https://linuxcontainers.org/lxd/
 [2]: https://zefanjas.de/5-gruende-warum-wir-lxd-verwenden/
 [3]: https://github.com/cloudrkt/lxdbackup/
 [4]: https://rclone.org/
 [5]: https://github.com/anschuetz/linuxmuster/tree/master/schultag

5 Gründe warum wir LXD verwenden

Mon, 08 Jan 2018 00:27:45 +0000

Linuxcontainer und der Container-Hypervisor LXD sind eine meiner Lieblingstechnologien seit Ubuntu 16.04. Wir verwenden [Linuxcontainer][1] bei uns in der Schule für unsere [Webanwendungen oder auch andere Dienste][2]. Es gibt einige Dinge, die ich an LXD sehr mag. Also: Warum LXD?

Einige Dinge, wie Installation, einen ersten Container erstellen usw. habe ich in [diesem kleinen Screencast][3] zusammengefasst:

1. LXC Client und REST API

Neben LXD gibt es noch das Kommandozeilenprogramm lxc. Es ist sehr einfach zu bedienen und dabei sehr mächtig. Es macht einfach Spaß damit zu arbeiten. lxc greift dabei auf die Rest API von LXD zurück. Hier ein paar kleine Beispiele:

Einen neuen Ubuntu Container erstellen und starten (x steht für Xenial):

$ lxc launch ubuntu:x mein_container

Root im Container werden:

$ lxc exec mein_container bash ``` Alle Container anzeigen: ``` $ lxc list ``` Eine Datei in den Container kopieren: ``` lxc file push /mein/lokaler/Pfad mein_container/mein/Pfad/im/Container ``` Das Tolle ist IMHO auch, dass man die API über das Netzwerk verfügbar machen kann. So kann ich an meinem Rechner mehrere Remotes hinzufügen. Wir haben z.B. mehrere LXD Hosts im Einsatz. Möchte ich nun auf diese Hosts zugreifen, ohne mich jedes Mal per SSH anzumelden, füge ich diese einfach als Remote hinzu: ``` $ lxc remote add host1 IP-des-Hosts ``` Nun kann ich die gleichen Befehle wie oben nutzen. Vor dem Containername muss einfach nur der Name des Remote-Hosts angegeben werden: ``` $ lxc launch ubuntu:x host1:container2 $ lxc list hosts1: $ lxc exec host1:container2 bash ``` ### 2. Geschwindigkeit Linuxcontainer sind schnell erstellt und man kann sie sehr schnell starten und beenden. Das dauert i.d.R. nur wenige Sekunden. Das ist vielleicht kein Alleinstellungsmerkmal für LXD, denn das Gleiche gilt auch für Docker oder andere Containertechnologien. ### 3. Snapshots & Migration Ein Feature von LXD sind Snapshots. Ich kann von jedem Container einfach ein Abbild erstellen, auf welches ich später wieder zurück kann. ``` $ lxc snapshot mein_container ``` Mit `lxc info mein_container` kann ich mir meine Snapshots anzeigen lassen und mit folgendem Befehl zum letzten Snapshot zurückkehren: ``` $ lxc restore mein_container snap0 ``` Ich kann aber auch aus einem Snapshot einen neuen Container (hier _test_) erstellen, um z.B. ein Update oder eine Änderung zu testen. ``` $ lxc copy mein_container/snap0 test ``` Auch hier gilt, dass ich das nicht nur lokal auf einem Host machen kann, sondern so z.B. einen Container von einem Host auf einen anderen (live) migrieren kann. Es gibt dabei zwei Möglichkeiten. Entweder erstelle ich eine Kopie oder ich verschiebe den Container. Ich mache davon manchmal Gebrauch, wenn ich z.B. eine neue Anwendung lokal auf meinem Rechner teste, kann ich sie später einfach auf den Host in der Schule schieben. ``` $ lxc copy mein_container host1:mein_container $ lxc move mein_container host1:mein_container ``` ### 4. Ressourcenschonend Linuxcontainer verbrauchen sehr wenig Speicherplatz, da sie sich viele Komponenten mit dem Container-Host teilen. Ein frisches Ubuntu-Image z.B. verbraucht nur wenige MB an Speicherplatz. Alle Container teilen sich zudem Arbeitsspeicher und CPU-Ressourcen. So kann eine viel höhere Dichte im Vergleich zu virtuellen Maschinen erreicht werden, die wesentlich mehr Ressourcen brauchen. Canonical spricht davon, dass auf einem Server [10x mehr Container-VMs][4] möglich sind im Vergleich zu klassischen virtuellen Maschinen (z.B. KVM). ### 5. Flexible Netzwerk und Speicherkonfiguration Mit LXD sind verschiedenste Anwendungsszenarien möglich. Es werden verschiedene Speicher-Backends unterstützt und verschiedene Netzwerktreiber. Man kann auch mehrere Speicher-Backends auf einem Host haben und bei der Erstellung eines Containers entscheiden, auf welchem Speicher er gestartet werden soll. Eine [Übersicht über alle möglichen Speicher][5] findet man in der Dokumentation. Auch netzwerktechnisch sind unterschiedliche Optionen vorhanden. Standardmäßig erstellt LXD ein eigenes Subnet für die Container. Man kann aber auch Netzwerkbrücken einrichten oder VLANs nutzen, um den Container die gewünschte IP zu geben bzw. die vorhandene Infrastruktur zu nutzen. ### Fazit Wer viel mit Linux-VMs arbeitet, sollte sich [LXD][6] auf jeden Fall anschauen. LXD ist für mich die perfekte Mischung aus den Vorteilen, die Container bringen und der gewohnten Umgebung, die man von einer Linux-VM gewohnt ist. Es ist wie eine „richtige“ virtuelle Maschine, nur schneller.

Welche Erfahrungen hast du bereits mit Container allgemein bzw. mit LXD konkret gemacht?

[1]: https://zefanjas.de/wie-man-mehrere-webseiten-mit-nginx-und-haproxy-mit-lxd-hosten-kann/ [2]: https://zefanjas.de/5-grossartige-open-source-programme-die-wir-in-unserer-schule-einsetzen/ [3]: https://www.youtube.com/watch?v=14MS_NKTKUE [4]: https://www.ubuntu.com/containers/lxd [5]: https://lxd.readthedocs.io/en/latest/storage/#storage-backends-and-supported-functions [6]: https://zefanjas.de/tag/lxd/

HAProxy, Nginx, LXD und Let’s Encrypt

Mon, 01 Jan 2018 04:55:59 +0000

In meinem letzten Beitrag habe ich beschrieben, wie man verschiedene Webserver, die in einem LXD Container laufen, von außen über einen Reverse-Proxy (in unserem Fall HAProxy) erreichbar machen kann. Diese Setup läuft aber nur über HTTP (Port 80) und damit über einen unverschlüsselte Verbindung. Heutzutage ist es unabdingbar, dass man seine Website auch verschlüsselt. Deswegen möchte ich heute das Setup erweitern, sodass die Webserver über eine verschlüsselte Verbindung erreichbar sind. HAProxy wird dabei SSL/TLS Termination Proxy agieren, d.h. wir müssen nur an einer Stelle alle unsere Zertifikate verwalten und nicht auf jedem einzelnen Webserver selbst. Der Vorteil ist, dass den Webservern Arbeit durch den Proxy abgenommen wird, allerdings muss man wissen, dass die Kommunikation zwischen HAProxy und den Webservern unverschlüsselt erfolgt. Dieses private Netz sollte als sicher angesehen werden. In unserem Fall ist das das Subnet von LXD, in dem sich die Container befinden. Folgende Grafik veranschaulicht den Prozess:

Container überprüfen

Zuerst überprüfen wir, ob alle unsere Container laufen und eine IP haben. Das können wir mit dem bekannten lxc list Befehl machen:

$ lxc list
+---------+---------+-----------------------+------+------------+-----------+
|  NAME   |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+------+------------+-----------+
| haproxy | RUNNING | 10.10.10.10 (eth0)    |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web1    | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web2    | RUNNING | 10.10.10.200 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+

Alle unsere Container sind online und haben eine IP-Adresse bekommen. Weiterhin sollten die DNS-Einträge unserer beiden Webserver auf die öffentliche IP des Servers zeigen. Dies können wir z.B. mit dem host-Befehl überprüfen:

$ host web2.example.com
web1.example.com has address 1.2.3.4

Weiterleitung für HTTPS einrichten

Bisher wird nur Traffic, der auf Port 80 auf unserem Server ankommt an den HAProxy Container weitergeleitet. Für HTTPS brauchen wir aber noch eine Weiterleitung für Port 443. Diese können wir mit einer ähnlichen iptables Regel einrichten:

$ sudo iptables -t nat -I PREROUTING -i eth0 -p TCP -d server_ip/32 --dport 443 -j DNAT --to-destination haproxy_ip:443

Diese Regel ist nach einem Neustart wieder weg. Um sie dauerhaft einzurichten, kann man z.B. das Paket iptables-persistent installieren.

HAProxy anpassen

Als nächsten müssen wir den HAProxy Konfiguration anpassen. Dazu loggen wir uns als root in dem Container ein:

$ lxc exec haproxy bash

Nun können wir die Konfigurationsdatei (/etc/haproxy/haproxy.cfg) öffnen (im HAProxy-Container) und anpassen.

$ nano /etc/haproxy/haproxy.cfg

Damit unser SSL Setup möglichst sicher ist, fügen wir folgende Zeilen im global Abschnitt hinzu. Ich habe Sie mit dem Mozilla SSL Configuration Generator erzeugt:

global
    ...
    # set default parameters to the modern configuration
    ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
    ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
    ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

Im defaults Block fügen wir folgende Zeilen hinzu:

defaults
     ...
     option forwardfor
     option http-server-close
     ...

Nun sind einige Anpassungen im frontend www_frontend Abschnitt notwendig:

frontend www_frontend
    # Http
    bind *:80
    # Https mit Ordner für Certifikate
    bind *:443 ssl crt /etc/haproxy/certs/
    # allen Traffic nach https weiterleiten
    redirect scheme https if !{ ssl_fc }
    # TLS Termination. HAProxy informiert hier unseren Webserver darüber. 
    reqadd X-Forwarded-Proto:\ https

    # Unterscheide zwischen sicheren und unsicheren Requests (wird in den nächsten zwei Zeilen verwendet).
    acl secure dst_port eq 443
    
    # Markiere alle Cookies als sicher, wenn sie über SSL gesendet werden.
    rsprep ^Set-Cookie:\ (.*) Set-Cookie:\ \1;\ Secure if secure
    # Füge den HSTS-Header mit einem maximalen Alter von 1 Jahr hinzu.
    rspadd Strict-Transport-Security:\ max-age=31536000 if secure

In in den Backend Abschnitten müssen wir keine Änderungen vornehmen.

Let’s Encrypt Zertifikate einrichten

Nun brauchen wir für die verschlüsselte Kommunikation noch ein Zertifikat für unsere Webserver. Let’s Encrypt bietet kostenfreie Zertifikate schon seit einigen Jahren an und ab diesem Jahr sogar Wildcard-Zertifikate.

Damit wir die Zertifikate einrichten können, brauchen wir den Let’s Encrypt Client, den wir wie folgt installieren (im HAProxy Container):

$ sudo apt install letsencrypt

Wir generieren ein Zertifikat, welches für alle unsere Domains gültig ist:

$ letsencrypt certonly -d example.com -d web2.example.com

Wenn alles geklappt hat, haben wir nun ein gültiges Zertifikat für unsere beiden Webserver. Jetzt müssen wir nur noch HAProxy die richtigen Zertifikate zur Verfügung stellen. Dazu müssen wir die Certificate Chain und den Private Key zusammenfügen, damit HAProxy etwas damit anfangen kann. Wir legen im ersten Schritt das Zielverzeichnis an und fügen dann die Zertifikate und den Key zusammen:

$ mkdir -p /etc/haproxy/certs/
$ DOMAIN='example.com' sudo -E bash -c 'cat /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/letsencrypt/live/$DOMAIN/privkey.pem &gt; /etc/haproxy/certs/$DOMAIN.pem'

Zum Schluss starten wir den HAProxy neu:

$ systemctl restart haproxy

Testen

Wir sind fast am Ziel und möchten unsere Domains noch testen, ob auch alles richtig konfiguriert wurde. Zuerst rufen wir die Seiten in einem Webbrowser auf. Es sollte neben der Adresse ein grünes Schloss erscheinen (im Firefox). Weiterhin sollten wir noch einen SSL Server Test durchführen. Das Ergebnis lässt sich sehen:

Fazit

Mit wenigen Schritten haben wir ein Setup geschaffen, in dem wir mehrere Webseiten nach außen hin erreichbar machen können. Das Ganze lässt sich leicht erweitern und skalieren. Besonders angenehm finde ich die Verwaltung der Zertifikate an einer Stelle und nicht auf jedem Webserver einzeln. LXD und Let’s Encrypt, sowie HAProxy sind für mich eine der großen persönlichen Entdeckungen der letzten zwei Jahre.

Was sind für dich die größten Herausforderung bei der Bereitstellung von Webservern?

Wie man mehrere Webseiten mit Nginx und HAProxy mit LXD hosten kann

Tue, 26 Dec 2017 14:16:50 +0000

LXD und Linuxcontainer sind eine meiner Lieblingstechnologien in Ubuntu. In wenigen Sekunden kann man einen neue virtuelle Maschine in einem Container starten. Wir machen davon in [unserer Schule][1] [stark Gebrauch][2]. Fast alle Webanwendungen laufen in einem solchen Container. So haben wir die einzelnen Anwendungen besser getrennt. Weiterhin kann man sehr schnell einen Snapshot eines Containers machen und vieles mehr. Wenn man nun diese verschiedenen Webseiten öffentlich zugänglich machen möchte, gibt es ein Problem, denn i.d.R. hat man nur eine öffentliche IP zur Verfügung (fest bzw. dynamisch). Eine Lösung wäre, dass die Webanwendungen auf verschiedenen Ports laufen, aber das ist nicht unbedingt benutzerfreundlich. In diesem Beitrag möchte ich zeigen, wie man mehrere Webseiten mit Nginx und HAProxy mit LXD hosten kann.

Voraussetzungen

Wir brauchen:

einen Server (ab Ubuntu 16.04) mit öffentlicher IP
Zugang mit Rootrechten (root / sudo)
eine Domain und Subdomain, die mit je einem DNS A Eintrag auf die öffentliche IP des Servers zeigen

Schritt 1 – Benutzer der lxd – Gruppe hinzufügen

Damit man mit einem Nicht-Root-Benutzer lxd verwalten kann, müssen wir zuerst den Benutzer der Gruppe hinzufügen:

sudo usermod --append --groups lxd username
```

Damit die Änderungen wirksam werden, müssen wir uns einmal _aus- und wieder einloggen_!

### Schritt 2 – lxd konfigurieren

lxd ist in Ubuntu 16.04 vorinstalliert. Falls nicht, können wir es mit

```
sudo snap install lxd
```

nachholen. In LXD gibt es verschiedene Möglichkeiten, wie und wo die Container ihren Speicherplatz haben. Man kann verschiedene Dateisysteme auswählen und entscheiden, ob die Container in einer Datei oder extra Partition bzw. Festplatte gespeichert werden. In diesem Tutorial verwenden wir ZFS für Linux mit einen sogenannten „loop device“. Das installieren wir mit

sudo apt-get install zfsutils-linux
```

Nun können wir mit der Einrichtung von lxd beginnen:

sudo lxd init
```

Es werden verschiedene Fragen gestellt, die man wie folgt beantworten kann (Achtung: Die Netzwerkbrücke nur für IPv4 aktivieren! Das Subnet kann frei gewählt werden)

```
Name of the storage backend to use (dir or zfs) [default=zfs]: zfs
Create a new ZFS pool (yes/no) [default=yes]? <span style="color: yes
Name of the new ZFS pool [default=lxd]: lxd
Would you like to use an existing block device (yes/no) [default=no]? no
Size in GB of the new loop device (1GB minimum) [default=15]: 15
Would you like LXD to be available over the network (yes/no) [default=no]? no
Do you want to configure the LXD bridge (yes/no) [default=yes]? yes
LXD has been successfully configured.
```

Die Netzwerkbrücke ist notwendig, damit jeder Container seine eigene IP bekommt und Zugang zum Internet hat.

 

So, jetzt ist alles eingerichtet und wir können unsere ersten Container erstellen!

### Schritt 3 – Container erstellen

Um unsere Container zu verwalten, brauchen wir den `lxc` Befehl. Diese feine Programm ist sehr einfach zu verwenden und dabei sehr mächtig. Zuerst wollen wir uns mal alle Container anzeigen lassen. Das geht mit `lxc list`:

$ lxc list
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
```

Es werden keine Container angezeigt, weil wir ja noch keine erstellt haben.

Für unser Beispiel brauchen wir drei Container: einen für HAProxy und 2 Webserver mit Nginx (oder Apache, wenn das jemand bevorzugt).

Wir werden den Befehl `lxc launch` verwenden, um einen Ubuntu 16.04 (`ubuntu:x`) Container namens `web1` zu erstellen und zu starten. Das `x` in `ubuntu:x` ist eine Abkürzung für den ersten Buchstaben von Xenial, der Codename von Ubuntu 16.04. `ubuntu:` ist der Bezeichner für das vorkonfigurierte Repository von LXD-Images.

Unsere drei Container können wir also mit folgenden Befehlen erstellen:

```
$ lxc launch ubuntu:x web1
$ lxc launch ubuntu:x web2
$ lxc launch ubuntu:x haproxy

```

Wenn man den ersten Container erstellt, wird zuerst das Image heruntergeladen, dass etwas dauern kann. Die anderen beiden Container werden dann sehr schnell erstellt.

Nun können wir mit lxc list schauen, ob unsere Container auch alle da sind:

```
$ lxc list
+---------+---------+-----------------------+------+------------+-----------+
|  NAME   |  STATE  |         IPV4          | IPV6 |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+------+------------+-----------+
| haproxy | RUNNING | 10.10.10.10 (eth0)    |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web1    | RUNNING | 10.10.10.100 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
| web2    | RUNNING | 10.10.10.200 (eth0)   |      | PERSISTENT | 0         |
+---------+---------+-----------------------+------+------------+-----------+
```

In dieser Liste sehen wir zuerste den Namen des Containers und seinen Status (RUNNING, STOPPED). Dann die IP Adresse(n) (die hier exemplarisch ist) und der Typ. Zum Schlusso noch die Anzahl der Snapshots / Sicherungspunkte. Die IP-Adressen werden wir gleich brauchen (am besten notieren).

### Schritt 4 – Nginx-Container einrichten

Um eine Verbindung zum Container herzustellen, verwenden wir den Befehl `lxc exec`, der den Namen des Containers und die auszuführenden Befehle enthält.

```
$ lxc exec web1 -- sudo --login --user ubuntu
```

Die Zeichenkette `--` gibt an, dass die Befehlsparameter für lxc dort zu Ende sind, und der Rest der Zeile wird als der auszuführende Befehl innerhalb des Containers übergeben. Der Befehl ist `sudo --login --user ubuntu`, der eine Login-Shell für das vorkonfigurierte Konto `ubuntu` im Container bereitstellt.

> Hinweis: Wenn man eine Verbindung zu den Containern als _root_ herstellen müssen, kann man stattdessen den Befehl `lxc exec web1 -- /bin/bash` verwenden

Nun sind wir in der Konsole des Containers (_ubuntu@web1_) und können nginx installieren:

```
$ sudo apt update
$ sudo apt install nginx
```

Damit wir später besser erkennen auf welchem Webserver wir uns gerade befinden, ändern wir die Standard-Seite des Webservers:

```
$ sudo nano /var/www/html/index.nginx-debian.html
```

Für die Änderung bieten sich der _title_-Tag und die erste Überschrift (_h1_) an:

```
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx on LXD container web1!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx on LXD container web1!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
```

Nachdem wir die Datei an den beiden Stellen geändert haben, können wir mit **Strg+X** und **Y** die Datei speichern. Mit **Strg+D** oder `logout` verlassen wir wieder den Container.

Zurück auf dem Server testen wir, ob der Webserver auch ordnungsgemäß funktioniert. Mit dem folgenden Befehl sollten wir die Willkommenseite sehen, die wir gerade eben angepasst haben:

```
$ curl http://10.10.10.100/
```

Wenn alles geklappt hat, kann der zweite Container nach dem gleichen Muster eingerichtet werden.

### Schritt 5 – HAProxy konfigurieren

Jetzt, da alle beiden Webserver-Container eingerichtet sind, fehlt nur noch der Reverse Proxy. Er ist dafür verantwortlich, dass die Anfragen von außen vom richtigen Container verarbeitet werden. [HAProxy][3] ist ein sehr leistungsstarker Proxy, der auch von Gihub oder Twitter verwendet wird. Die Möglichkeiten sind auch hier wieder sehr vielfältig. Wir werden deshalb nur ein sehr einfaches Setup machen.

Zuerst loggen wir uns wieder in den Container ein und installieren HAProxy:

```
$ lxc exec haproxy -- sudo --login --user ubuntu
$ sudo apt-get update
$ sudo apt-get install haproxy
```

Nun konfigurieren wir HAProxy. Dazu öffnen wir die Datei _**/etc/haproxy/haproxy.conf**_ mit einem Texteditor:

$ sudo nano /etc/haproxy/haproxy.cfg
```

Im Abschnitt `defaults` fügen wir die Optionen _forwardfor_ und _http-server-close_ hinzu.

global
...
defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
    <span class="highlight">option   forwardfor</span>
    <span class="highlight">option   http-server-close</span>
    timeout connect 5000
    timeout client  50000
    timeout server  50000
...
```

#### Frontends

Als nächstes konfigurieren wir das Frontend so, dass es auf unsere beiden Backend-Container zeigt. Wir fügen einen neuen Frontend-Abschnitt mit dem Namen _wwww_frontend_ hinzu, der so aussieht:

```
frontend www_frontend
    bind *:80 # Port 80 (www) an den Container binden

    # Es gibt eine Übereinstimmung sobald das HTTP Host: field einen der Hostnamen enthält (nach dem '-i').
    acl host_web1 hdr(host) -i example.com www.example.com
    acl host_web2 hdr(host) -i web2.example.com

    # Leite die Verbindung zum richtigen Servercluster um, je nach Übereinstimmung.
    use_backend web1_cluster if host_web1
    use_backend web2_cluster if host_web2
```

Die _acl-Befehle_ stimmen mit den Hostnamen der Webserver überein und leiten die Anfragen an den entsprechenden Backend-Abschnitt weiter.

#### Backends

Dann definieren wir zwei neue Backend-Abschnitte, eine für jeden Webserver, und nennen sie _web1_cluster_ bzw. _web2_cluster_. Wir fügen den folgenden Code zur Datei hinzu, um die Backends zu definieren:

```
backend web1_cluster
    balance leastconn
    # Wir setzen den X-Client-IP HTTP-Header. Dies ist nützlich, wenn wir wollen, dass der Webserver die tatsächliche Client-IP kennt.
    http-request set-header X-Client-IP %[src]
    # Dieses Backend, hier "web1" genannt, verweist auf den Container "web1.lxd" (Hostname).
    server web1 web1.lxd:80 check

backend web2_cluster
    balance leastconn
    http-request set-header X-Client-IP %[src]
    server web2 web2.lxd:80 check

```

Die _balance_-Option bezeichnet die Load-Balancing-Strategie. In diesem Fall entscheiden wir uns für die geringste Anzahl von Verbindungen. Die Option _http-request_ setzt einen HTTP-Header mit der realen Web-Client-IP. Wenn wir diesen Header nicht setzen würden, würde der Webserver die HAProxy-IP-Adresse als Quell-IP für alle Verbindungen aufzeichnen, was die Analyse der Herkunft des Datenverkehrs erschwert. Die Server-Option spezifiziert einen beliebigen Namen für den Server (web1), gefolgt von Hostname und Port des Servers.

LXD stellt einen DNS-Server für die Container zur Verfügung, so dass web1.lxd sich auf die mit dem web1-Container verknüpfte IP auflöst. Die anderen Container haben eigene Hostnamen, wie z.B. web2.lxd und haproxy.lxd.

Der c_heck_-Parameter weist HAPRoxy an, auf dem Webserver Überprüfungen durchzuführen, um sicherzustellen, dass er verfügbar ist.

Um zu testen, ob die Konfiguration gültig ist, führen Sie den folgenden Befehl aus:

```
$ haproxy -f /etc/haproxy/haproxy.cfg -c
Configuration file is valid
```

Nun müssen wir noch den HAProxy neu laden:

```
$ sudo systemctl reload haproxy

```

Damit sind wir im HAProxy-Container fertig und können uns wieder mit **Strg+D** bzw. **logout** abmelden.

Wir haben HAProxy so konfiguriert, dass es als Reverse-Proxy fungiert, der alle Verbindungen, die es auf Port 80 empfängt, an den entsprechenden Webserver in den beiden anderen Containern weiterleitet. Testen wir, ob es Haproxy tatsächlich gelingt, die Anfragen an den richtigen Web-Container weiterzuleiten. Dazu führen wir den folgenden Befehl aus:

```
$ curl --verbose --header 'Host: web2.example.com' http://10.10.10.10
```

Dies stellt eine Anfrage an HAProxy und setzt einen HTTP-Host-Header, den HAProxy verwenden soll, um die Verbindung zum entsprechenden Webserver umzuleiten.

Als Ausgabe sollten wir nun die Standarseite des Nginx-Servers vom web2-Container erhalten!

HAProxy hat die Anfrage richtig verstanden und an den web2-Container weitergeleitet. Dort zeigt der Webserver der Standard-Indexseite an, die wir zuvor bearbeitet haben, und zeigt den Text auf dem LXD-Container web2 an.

### Schritt 6 – Eingehende Verbindungen an den HAProxy weiterleiten

Zum Schluss müssen wir noch dafür sorgen, dass alle externen Anfragen auf Port 80 an HAProxy weitergeleitet werden, damit die Welt auf unsere Websites zugreifen kann.

HAProxy haben wir in einem Container installiert und ist standardmäßig aus dem Internet nicht erreichbar. Um dies zu lösen, erstellen wir eine iptables-Regel, um Verbindungen weiterzuleiten.

Der Befehl iptables benötigt zwei IP-Adressen: die öffentliche IP-Adresse des Servers (server\_ip) und die private IP-Adresse des Haproxy-Containers (haproxy\_ip), die man mit dem Befehl `lxc list` erhält.

Führen Sie diesen Befehl aus, um die Regel zu erstellen:

```
$ sudo iptables -t nat -I PREROUTING -i eth0 -p TCP -d server_ip/32 --dport 80 -j DNAT --to-destination haproxy_ip:80
```

Um diesen iptables-Befehl zu speichern, damit er nach einem Neustart erneut angewendet wird, installieren wir das Paket _iptables-persistent_:

```
$ sudo apt-get install iptables-persistent
```

Bei der Installation des Pakets werden wir aufgefordert, die aktuellen iptables-Regeln zu speichern. Akzeptieren und speichern wir alle aktuellen iptables-Regeln.

### Schritt 7 – Zugriff von außen testen

Wenn wir die beiden Domains (DNS A Eintrag) eingerichtet haben, sollten wir in der Lage sein, sich mit Ihrem Webbrowser mit jeder Website zu verbinden. Alternativ und nur zum lokalem Test können wir auch einen Eintrag in der **_/etc/hosts_** Datei machen:

```
server_IP example.com
server_IP web2.example.com
```

Um zu testen, ob die beiden Webserver tatsächlich über das Internet erreichbar sind, greifen wir von einem lokalen Computer aus mit einem Browser auf unsere beiden Domains zu (example.com bzw. web2.example.com). In beiden Fällen sollten wir nun die entsprechende Standardseite des Webservers sehen!

### Fazit

Wir haben zwei Websites eingerichtet, jede in einem eigenen Container, wobei HAProxy den Datenverkehr steuert. Diesen Prozess können wir wiederholen, um viele weitere Websites zu konfigurieren, die jeweils auf einen eigenen Container beschränkt sind.

So könnten wir z.B. auch MySQL in einem neuen Container hinzufügen und dann ein CMS wie WordPress installieren, um eine Website zu starten. Weiterhin könnten wir  diese Vorgehensweise auch verwenden, um ältere Softwareversionen zu unterstützen. Zum Beispiel, wenn eine Installation eines CMS eine ältere Version von Software wie PHP5 erfordert, dann können wir Ubuntu 14.04 in den Container installieren (`lxc launch ubuntu:t`), anstatt zu versuchen, die Paketmanager-Versionen, die auf Ubuntu 16.04 verfügbar sind, herabzusetzen.

Schließlich bietet LXD die Möglichkeit, Snapshots des vollen Zustands von Containern zu machen, was die Erstellung von Backups und das Zurückrollen von Containern zu einem späteren Zeitpunkt vereinfacht. Darüber hinaus, wenn wir LXD auf zwei verschiedenen Servern installieren, dann ist es möglich, diese miteinander zu verbinden und Container zwischen Servern über das Internet zu migrieren. Doch darüber berichte ich vielleicht ein andern mal…

**Update:** [Als nächsten Schritt sollte man das Setup noch mit SSL sicherer machen.][4]


  Setzt du LXD ein und welche Erfahrungen hast du bisher gemacht?


 [1]: https://zefanjas.de/5-grossartige-open-source-programme-die-wir-in-unserer-schule-einsetzen/
 [2]: https://zefanjas.de/open-source-in-der-schul-it-teil-2/
 [3]: http://www.haproxy.org/
 [4]: https://zefanjas.de/haproxy-nginx-lxd-und-lets-encrypt/

Virtualisierung – Virtuelle Maschine oder Container?

Sat, 09 Apr 2016 07:35:56 +0000

Beim Planen und Nachdenken über die unsere zukünftige Schul-IT begegnete mir unweigerlich auch das Thema Virtualisierung. In den letzten Jahren ist dieses Thema teilweise sehr gehypt worden, wenn man z.B. nur an die Containerlösung Docker denkt. Insgesamt kann man wohl sagen, dass heute wesentlich mehr und häufiger virtualisiert wird, als das noch vor 5 Jahren der Fall war, wo man eher noch auf „bare-metal“ gesetzt hat.

In unserem konkreten Fall wollen wir auch virtualisieren, um die einzelnen Anwendungen auf dem Server besser zu isolieren und zu trennen. Im Opensource-Bereich gibt es einige Lösungen, wie man seine Anwendungen auf dem Server virtualisieren kann. Grundlegend unterscheidet man hier zwischen virtuellen Maschinen (der Hypervisor virtualisiert das ganze OS inkl. Kernel) und Containern (Container nutzen den Kernel des Hosts/Hypervisors). Jede Lösung hat seine Anwendungsszenarien, so kann man z.B. nie ein Windows in einem Container auf einem Linux-Host laufen lassen, da sie unterschiedliche Kernel verwenden. Allerdings kann man CentOS in einem Container auf Ubuntu starten (gleicher Kernel).

Ich habe mir in den letzten Monaten überblicksweise folgende Virtualisierungs-Lösungen angeschaut:

KVM (entwickelt von RedHat)
Virtualbox (hauptsächlich um auf dem Desktop verschiedenen Softwarelösungen auszuprobieren)
LXD (Canonical) → Container-VMs

Alternativen sind noch Xen oder VMWare, welche auch recht weit verbreitet sind, wobei bei VMWare nicht als Opensource-Lösung gilt und einiges an Lizenzkosten fällig wird.

Virtualbox

Virtualbox nutze ich gern auf meinem Rechner, um Software zu testen und auszuprobieren. Es ist recht einfach ein komplettes Netzwerk nachzubilden. So habe ich oft eine kleine Router-VM (vorzugsweise pfSense), welche ein weiteres (isoliertes) Netz bereitstellt. Dann habe ich meist ein oder zwei Server-VMs und noch ein paar Clients, um z.B. PXE-Boot und/oder andere Dienste zu nutzen. Das funktioniert recht gut, solange der Rechner mit genügend Cores und RAM ausgestattet ist (ist bei mir nur teilweise der Fall…)

KVM

KVM hat mir bisher am meisten zugesagt, wenn es um die Virtualisierung „richtiger“ VMs geht. Ich nutze hauptsächlich den virt-manager, um meine VMs zu verwalten, aber es gibt noch unzählige andere Frontends für KVM. Proxmox ist noch sehr bekannt oder virsh für die Konsole. KVM ist sicher nicht die einfachste VM-Lösung, aber dafür sehr flexibel einsetzbar. Snapshots der einzelnen VMs sind ohne Probleme mit dem virt-manager oder einem anderen Management-Werkzeug möglich.

LXD

LXD 2.0 ist erst vor kurzem Erschienen und wird in Ubuntu 16.04 am besten anwendbar sein. Es gibt derzeit eine Blogreihe von einem der Hauptentwickler, die ich jedem ans Herz lege, der sich damit auseinander setzen möchte. LXD finde ich äußerst spannend – aus verschiedenen Gründen:

Container VMs → man kann sehr einfach und schnell (!) ein Linux starten und seine Anwendung drin laufen lassen
durch den Einsatz von ZFS als Speicherbackend kann man super Snapshots im laufenden Betrieb usw. machen
man kann wesentlich mehr Container als echte VMs starten (bessere Ausnutzung des Servers)
Konfiguration und Bedienung von lxd finde ich sehr intuitiv
sehr geringer Overhead

Allerdings gibt es auch Sachen, die nicht oder nicht ohne weiteres möglich sind, da es halt Container und keine vollwertigen VMs sind. So kann man keine ISO „booten“ (es gibt aber für alle wichtigen OS Images). Ich wollte z.B. freeIPA / FOG in einem CentOS Container auf Ubuntu 16.04 testen und bin nicht ganz zum Ziel gekommen, da die Installation an manchen Stellen nicht sauber durchlief, da z.B. Ubuntu und CentOS verschiedene Technologien einsetzen (SELinux vs. Appamor). Das schaue ich mir aber noch mal genauer an. Insgesamt könnte ich mir LXD Container sehr gut für reine Webanwendungen vorstellen, sozusagen als Webserver-VMs. Das Anlegen, Starten, Backup und Restore sind einfach super easy mit LXD! Kann ich nur empfehlen sich das mal anzuschauen.

Derzeit tendiere ich zu KVM für vollwertige VMs für alle Infrastruktur-Dienste (AD, NFS, DHCP, DNS) und zu LXD für zusätzliche Webanwendungen, welche wir hier in der Schule zu einsetzen bzw. einsetzen werden. Dazu folgt noch ein extra Blogeintrag.