Select Page

NETWAYS Blog

Docker Swarm auf Proxmox oder es muss nicht immer Kubernetes sein.

Neulich habe ich begonnen meine “Heim”-IT auf einen aktuellen Stand zu bringen. Da wir uns bei NETWAYS auch mit Proxmox Virtual Environment als Virtualisierungsplattform beschäftigen, habe ich mich ebenfalls für diese Plattform für meine drei NUC PC entschieden.

Sie bilden mit einem Ceph RBD (RADOS Block Devices) über alle drei Knoten die Basis für hochverfügbare virtuelle Maschinen oder LX Container. Für Shared Storage für Dateisysteme, z.B. für meine Nextcloud oder auch nur Zertifikate für die Web- und Mailserver ist im RBD auf Platz für mehrere CephFS.

Meine Nextcloud ist inzwischen über einige Docker Container verteilt, ich habe mich hier gegen die von Proxmox hauseigenen LXC entschieden, da ich mit Traefik als Proxy direkt auf die DockerAPI (siehe hier) zugreifen wollte, um weitere neue Webserver unkompliziert einbinden zu können. Zusätzlich versorgt mich Traefik automatisch mit benötigten Zertifikaten von Let’s Encrypt.

Kubernetes ist zwar als Technologie sehr interessant, aber meiner Ansicht nach, etwas für sehr große Umgebungen. Da ich sicherlich nicht über 200 Container hinaus komme, benutze ich Docker Swarm auf momentan drei VM. Zur Zeit ist diese Umgebung mit nur einigen Containern für die Nextcloud, Traefik und einem Webserver noch recht übersichtlich und lässt dich gut von der Kommandozeile verwalten, komme jedoch weitere Container hinzu, wird sich mit an Sicherheit grenzender Wahrscheinlichkeit auch eine webbasierte Management Console finden.

Auch durfte ich mich neulich auf der Arbeit mit SDN (Software Defined Network) im Zusammenhang mit Proxmox beschäftigen. Hiebei ging es um eine auf mehrere Standorte verteilte Umgebung, der Verbindung via VPN (hier Wireguard) und der über alle Standorte zur Verfügungsstellung eines einzigen Netzsegments. Proxmox bietet, z.Z. noch experimentell, auch hier die Konfiguration mittels GUI. Das zugrundeliegende OpenVSwitch ist aber natürlich stabil und kann notfalls auch per Hand von der Konsole in den entsprechenden Dateien eingerichtet werden.

Für mein Heimnetzwerk sicherlich zu groß gedacht, aber für den ein oder anderen vielleicht auch interessant. Bei Interesse … ihr wißt an wen ihr euch wenden könnt – NETWAYS.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Proxmox Routed NAT für die NWS Openstack Cloud, Hetzner uva.

Warum Proxmox? Weil Du damit einen robusten AGPL3-Lizenz basierten, sicherheits- und privacy-technisch (Debian) unbedenklichen, KVM-Hypervisor bekommst, der Out-of-the-Box LXC kann, was extrem ressourcenfreundlich ist, und Du damit wie gewohnt Deine Linux-Befehle abfeuern und automatisieren kannst.

Unter Debian befinden sich die direkt greifenden Kern-Netzwerkkonfiguration unter /etc/network/interfaces und nachfolgender Teil basiert darauf. Auskommentierte Parameter werden wie gewohnt durch # dargestellt – an einigen Teilen habe ich Parameter auskommentiert gelassen, die aber zum Testen & Debuggen wichtig waren und die ich auch für Zukünftiges oder Nachzuschlagendes nicht verstecken möchte.

Bridged-Home

Eine default Proxmox Konfiguration für Zuhause sieht z.B so aus:

[bash language=”language”]
auto lo
iface lo inet loopback

iface ens3 inet manual

auto vmbr0
iface vmbr0 inet static
address 10.77.15.38/24
gateway 10.77.15.254
bridge-ports ens3
bridge-stp off
bridge-fd 0
[/bash]

Erklärung: Wie Du siehst läuft alles über einen virtuellen Netzwerkadapter vmbr0, der IP & Gateway behandelt: das eigentlich echte Interface ens3 wird hier nur auf manual geschalten, während das vmbr0 auf static gesetzt ist. Dieses vmbr0 Interface wirst Du auch pro VM / LXC -Container dann jeweils auswählen, und eine passende IP vergeben bzw. vergeben lassen. Beachte allerdings den Punkt bridge-ports ens3 , machst Du so etwas bei einem externen VPS/Bare-Metal Provider, musst Du eventuell zusätzlich eine gekaufte virtuelle MAC mitgeben – oder könntest offline genommen werden, da nun über mehrere MACs mehrere reelle IPS laufen würden, wo die Sicherheitsfeatures des Gateways des Providers Alarm schlagen sollten. Daher folgender Routed-NAT Ansatz:

Routed-NAT in der Cloud

Metadata

Hinweis: Nachfolgendes im OpenStack mit Metadaten ist minimal hacky, aber es “tut”, ob Du so etwas in der Production benutzen willst ist Dir überlassen. Bei LXC-Containern wirst Du genauso Performanz haben wie nativ in Deiner Instanz da diese CGroup basierend sind.

Willst du maximales Vertrauen und maximale Sicherheit nimmst Du Dir eine eigene Proxmox ISO und lädst diese hoch – was bei NWS kein Problem ist: Noch besser, Du lädst ein eigenes Debian 11 Bullseye hoch, installierst und verschlüsselst dieses, und installierst Proxmox on Top.

Nach dem Hochladen der ISO findest Du die Möglichkeit Metadata-informationen anzupassen, um die VM im Openstack Hypervisor auf  Virtualisierung einzustellen. Nachfolgende Flags zu setzen hat für mich funktioniert:

Du kannst nun Deinen Server hochfahren, und kannst danach nach dem Booten, über “Console” die Installation starten. Du solltest im Anschluss das Boot-ISO unmounten, sonst kommst du nach dem Reboot wieder zur Installation, tust Du es nicht, kannst Du aber auch einfach über Rescue-Shell die Proxmox-Instanz starten. In meinen Tests wurden DHCP und Gateway automatisch angezogen und die Installation lief problemlos durch.

Proxmox Routed-NAT Konfiguration

[bash language=”language”]
auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
address 10.77.15.38/24
gateway 10.77.15.254
# pointopoint 10.77.15.254

auto vmbr0
iface vmbr0 inet static
address 10.77.15.38/24
netmask 255.255.255.0
gateway 10.77.15.254
bridge-ports none
bridge-stp off
bridge-fd 0
pre-up brctl addbr vmbr0
up route add 10.10.10.2/32 dev vmbr0
up route add 10.10.10.3/32 dev vmbr0

auto vmbr1
iface vmbr1 inet static
address 10.9.9.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up iptables -t nat -A POSTROUTING -j MASQUERADE
post-up iptables -t nat -A POSTROUTING -s ‘10.9.9.0/24’ -o vmbr0 -j MASQUERADE
post-down iptables -t nat -F

# post-up echo 1 > /proc/sys/net/ipv4/ip_forward
# post-down iptables -t nat -D POSTROUTING -s ‘10.9.9.0/24’ -o vmbr0 -j MASQUERADE
# post-up iptables -t nat -A POSTROUTING -o eth0 -s ‘10.9.9.0/24’ -j SNAT –to 10.9.9.1
# post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT –zone 1
# post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT –zone 1
[/bash]

Erklärung: Hier siehst Du im Vergleich Routed NAT, welches Du bei jedem VPS, auch bei uns bei NWS, nutzen könntest.
Hinweis: Für Bare-Metal-Instanzen bei Hetzner würdest Du nur noch pointtopoint einkommentieren müssen.
Im Vergleich zu einer Bridged-Konfiguration siehst Du nun bei vmbr0 bridge-ports none auch magst Du Dich wundern wieso denn genau address 10.77.15.38/24 sowie gateway 10.77.15.254 je in ens3 und vmbr0 vorkommen. Das liegt daran dass wir nun im Vergleich zu Bridged keine zweite MAC einholen, sondern alles über iface ens3 inet static durchgeben –  und vmbr0 und vmr1 praktisch routen. Du könntest nun auch vmbr0 benutzen, aber vmbr1 ist in dem Beispiel bequemer, und setzt Dir ein komplettes ‘10.9.9.0/24’-Netz mit entsprechenden NAT-Regeln das mit dem 10.9.9.1 Gateway kommunizieren kann.
Wichtig: Obwohl Du auch hier den ipv4-Forward aktivieren könntest, habe ich es in der /etc/sysctl.conf gemacht via net.ipv4.ip_forward=1  bzw. respektive net.ipv6.conf.all.forwarding=1.
Tipp: Ich persönlich benutze ab dieser Stelle (wo auch immer möglich) Nested-Docker in LXC-Containern um Server-Performanz zu sparen, und lege bequem Wireguard Clients in die jeweiligen Container, um diese von überall aus anzusprechen. Guides zu Wireguard findest Du von Markus und mir hier unserem NETWAYS Blog.
Übrigens: Meine Chefs von NETWAYS Professional Services bieten bald im Portfolio auch Consulting zu Proxmox an, welches von Icinga 2 überwacht werden kann.

 

How To NWS: Infrastructure as a Service mit OpenStack

This entry is part 4 of 7 in the series How To NWS

Im letzten Blog habe ich mit unserer Software as a Service Plattform den ersten Teil unseres Portfolios vorgestellt. Hier kann sich jeder standardisierte Apps schnell und einfach selber anstarten. Manchmal lassen sich die Anforderungen unserer Kunden aber nicht über die Apps abdecken, da beispielsweise per Default deaktivierte Funktionen benötigt werden oder wir schlichtweg den benötigten Dienst nicht in unserem App-Portfolio haben. Wer individuelle Anforderungen an seine IT Umgebung hat, der ist in unserem Infrastructure as a Service Bereich richtig.

Abhängig davon ob virtuelle Maschinen oder Container zu orchestrieren sind, können sich unsere Kunden zwischen OpenStack und Kubernetes entscheiden.

In dem heutigen Blog möchte ich unser OpenStack Angebot vorstellen:

Bei OpenStack handelt es sich um ein OpenSource-Projekt, das von zahlreichen namenhaften Unternehmen (Suse, Linux, HP etc.) unterstützt und ständig weiterentwickelt wird. Ursprünglich ins Leben gerufen wurde es von Rackspace und der NASA. Es setzt sich aus einzelnen Softwareelementen (Nova, Keystone, Glance, Neutron, Cinder, Swift, Horizon) zusammen, mit denen man im Verbund eine Cloud-Plattform erstellt.  Es handelt sich also um ein Cloud-Betriebssystem mit einer Vielzahl an Funktionen. Eine wesentliche Voraussetzung für das Cloud-Computing ist die Virtualisierung, das heißt die Trennung der Stack-Ebenen. Das ermöglicht, dass mehrere Betriebssystem-Instanzen auf der selben Hardwareeinheit betrieben werden können. Auch der Zugang zu Speicher und Netzwerken wird virtualisiert. Im Endeffekt können so sämtliche Bausteine eines Rechners durch Schnittstellen und Konfigurationen referenziert werden. Man erhält eine flexibel änderbare und skalierbare Struktur.

Dadurch, dass OpenStack von Cloud-Computing-Experten aus aller Welt – also großen Konzernen (z.B. Telekom), mittelständischen Unternehmen (wie uns) und kleinen, hippen Startups – genutzt und ständig weiterentwickelt wird, bleibt gewährleistet, dass das Projekt ständig auf der Höhe der Zeit und den Ansprüchen des Marktes gewachsen ist. Ein weiterer, großer Vorteil gegenüber den großen, bekannten Cloud-Anbietern ist der Wegfall des Vendor Lock-in. Es sind ausschließlich standardisierte Schnittstellen im Einsatz. So kannst Du bei Bedarf Deine Unternehmensdaten unkompliziert migrieren, was einen Anbieterwechsel jederzeit möglich macht.

Mit unserem OpenStack kannst du Server und Netzwerke schnell und einfach starten. Virtuelle Maschinen, Speicher und Netzwerke lassen sich mühelos einrichten und vor allem auch jederzeit dynamisch an sich verändernde Anforderungen anpassen. Dabei kann bei den Virtuellen Maschinen aus einem Pool von vorgefertigten Images für alle gängigen Betriebssysteme mit unterschiedlichen Sizing-Varianten gewählt werden. Diese lassen sich ganz einfach per Knopfdruck starten. Sollte das gewünschte Sizing nicht dabei sein, kann man sich die Ausstattung der VM selbstverständlich auch individuell nach seinen Vorstellungen anlegen. In Puncto Sicherheit kann man mit Methoden wie Firewalls, Verschlüsselung und Dienstrichtlinien festlegen, wer wie auf welchen Server zugreifen kann und beim Thema Backup kann man frei entscheiden, ob Snaphots oder Images in welcher, freiwählbaren Rotation gesichert werden sollen. Alle Daten liegen 3-fach redundant gesichert auf unseren Ceph-Cluster, der sich über unsere beiden DIN ISO 27001 zertifizierten Rechenzentren verteilt.

So lässt sich das OpenStack Projekt bequem und übersichtlich über unser Dashboard zusammenstellen und einrichten. Der Punkt der Übersichtlichkeit führt mich auch gleich zu einem weiteren wichtigen Vorteil unseres OpenStack Angebots: Bezüglich der Kosten können wir ein maximales Maß an Transparenz bereitstellen. Es gibt keine undurchsichtigen Pauschalen und Gesamtpakete. Alle verwendeten Ressourcen werden stundengenau abgerechnet. Über unseren Cost Explorer siehst Du die für den Monat bereits entstanden Kosten und bekommst anhand der aktuell genutzten Ressourcen auch gleich eine Hochrechnung über die voraussichtliche Summe am Monatsende. Man hat die Kosten also zu jeder Zeit im Blick und  kann im Bedarfsfall sofort reagieren. Das liegt auch daran, dass es keinerlei Vertragslaufzeiten gibt. Wird eine VM nicht mehr benötigt, kann man diese umgehend runterfahren. Am Monatsende zahlst Du dann nur den Betrag, der bis zu der Abschaltung entstanden ist. Das gibt Dir absolute Flexibilität in beide Richtungen – Du kannst schnell wachsen und, wenn nötig, Dein Setup auch direkt verkleinern.

Und natürlich haben wir auch hier technische Unterstützung im Angebot. All diejenigen, die ihre Zeit nicht mit der Einrichtung und Wartung ihrer IT-Infrastruktur verbringen wollen, können unseren MyEngineer-Service dazu buchen. Auf diesen werde ich aber erst in dem übernächsten Blogartikel genauer eingehen.

Hier geht es zu unserer OpenStack Seite: https://nws.netways.de/de/cloud/

Hier findest du unsere Preisliste: https://nws.netways.de/de/preise/

Und hier findest Du Tutorials und Webinare zu OpenStack: https://nws.netways.de/de/

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab’s Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen.
Der GitLab Runner ist eine zusätzliche Anwendung, welche sich ausschließlich darum kümmert, bei einer GitLab-CE/-EE Instanz die CI/CD-Aufträge abzuholen und diese abzuarbeiten. Der Runner muss dabei nicht zwingend auf dem selben System wie das GitLab installiert sein und kann somit auch extern auf einem anderen Host laufen. Der Hintergrund, weshalb man das auch so umsetzen sollte, ist eigentlich recht klar: ein GitLab Runner steht bei einer aktiven CI/CD-Pipeline oftmals unter hoher Last und würde er auf dem gleichen Host wie das GitLab selbst laufen, so könnte er dessen Performance stark beeinträchtigen. Deshalb macht es Sinn, den GitLab Runner z.B. auf eine VM in OpenStack auszulagern.
In diesem Blogpost werde ich kurz darauf eingehen, wie man schnell und einfach eine GitLab Runner VM per CLI in OpenStack aufsetzen kann. Da ich den Runner als Docker-Container starten möchte, bietet sich CoreOS an. CoreOS kommt mit Docker vorinstalliert und es bietet die Möglichkeit per Ignition Config nach dem Start des Betriebssystems Container, oder auch andere Prozesse, automatisch starten zu lassen.

Sobald man sich bei seinem OpenStack-Anbieter in sein Projekt eingeloggt hat, kann man sich dort unter “API Zugriff” die OpenStack-RC-Datei herunterladen. Damit kann man sich dann recht einfach per CLI bei OpenStack authentifizieren. Voraussetzung für die Nutzung der CLI ist, dass man bei sich den OpenStack Command-Line Client installiert hat.
Sobald man beides hat, kann es auch schon losgehen:

    1. Runner Registration Token abholen
      Dazu loggt man sich als Admin in sein GitLab-CE/-EE ein und navigiert zu “Admin Area” -> “Overview” -> “Runners”. Hier findet man den aktuellen Registration Token.
    2. CoreOS Ignition Config
      Die Konfigurationsdatei für CoreOS nennt man z.B. config.ign. Diese legt man sich ebenfalls auf dem Rechner ab.
      Der Inhalt muss im nächsten Schritt geringfügig angepasst werden.

      config.ign

      { "ignition": { "version": "2.2.0", "config": {} }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "wipeFilesystem": true, "label": "ROOT" } }] }, "storage": { "files": [{ "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,core1" } }, { "filesystem": "root", "path": "/home/core/config.toml", "mode": 644, "contents": { "source": "data:,concurrent=4" } } ] }, "systemd": { "units": [ { "name": "gitlab-runner.service", "enable": true, "contents": "[Service]\nType=simple\nRestart=always\nRestartSec=10\nExecStartPre=/sbin/rngd -r /dev/urandom\nExecStart=/usr/bin/docker run --rm --name gitlab-runner -e 'GIT_SSL_NO_VERIFY=true' -v /home/core:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v11.8.0 \n\n[Install]\nWantedBy=multi-user.target" }, { "name": "gitlab-runner-register.service", "enable": true, "contents": "[Unit]\nRequires=gitlab-runner.service\n[Service]\nType=simple\nRestart=on-failure\nRestartSec=20\nExecStart=/usr/bin/docker exec gitlab-runner gitlab-runner register -n --env 'GIT_SSL_NO_VERIFY=true' --url https://$URL -r $TOKEN --description myOpenStackRunner--locked=false --executor docker --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-image ruby:2.5 \n\n[Install]\nWantedBy=multi-user.target" } ] }, "networkd": {}, "passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "$your-ssh-pub-key" ] } ] } }
    3. Ignition Config anpassen
      Beim Systemd-Unit “gitlab-runner-register.service” setzt man im Content bei den Variablen “$URL” den FQDN der eigenen GitLab-Instanz und bei “$TOKEN” den in Schritt 1 kopierten Registration Token ein.
      Außerdem kann man gleich noch seinen SSH-Key mitgeben, damit man später auch per SSH auf die VM zugreifen kann. Diesen hinterlegt man unter dem Abschnitt “passwd” im Platzhalter “$your-ssh-pub-key”.
    4. CLI Commands
      Nun kann man sich auch schon das Kommando zum anlegen der VM zusammenbauen.
      Als erstes muss man sich bei OpenStack authentifizieren, indem man die Datei sourced, die man sich eingangs aus seinem OpenStack Projekt geladen hat und dabei sein OpenStack Passwort angibt:

      source projectname-openrc.sh

      Man sollte außerdem sicherstellen, dass in dem Projekt ein CoreOS Image zur Verfügung steht.
      Anschließend kann man nach folgendem Schema die Runner-VM anlegen:

      openstack server create --network 1826-openstack-7f8d2 --user-data config.ign --flavor s1.medium --image CoreOS_Live "GitLab Runner"

      Network, Flavor und Image sollten aber individuell noch angepasst werden.

    Nach ca. zwei Minuten sollte dann der Runner auch schon zur Verfügung stehen. Überprüfen lässt sich das, indem man sich als Admin in seine GitLab-Instanz einloggt und im Bereich unter “Admin Area” -> “Overview” -> “Runners” nach einem Runner mit dem Namen “myOpenStackRunner” nachsieht.

    Wer noch auf der Suche nach einem OpenStack-Provider ist, der wird bei den NETWAYS Web Services fündig. Mit nur wenigen Clicks hat man sein eigenes OpenStack-Projekt und kann sofort loslegen.

Gabriel Hartmann
Gabriel Hartmann
Senior Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

Mit MyEngineer voll ins Schwarze getroffen

Fachkräftemangel? Keine Ressourcen für neue Hostingprojekte? Mit MyEngineer von Netways kein Thema mehr!

Nach Einführung unserer IaaS OpenStack buchen immer mehr Kunden zusätzlich unseren MyEngineer-Service. MyEngineer ist praktisch Ihr persönlicher und erfahrener Hosting-Administrator (Systems Engineer), der nie krank wird und ohne Urlaub auskommt, der Ihnen auf Wunsch sogar 24 Stunden an 7 Tagen die Woche zu Verfügung steht.

Gibt es nicht? Doch! Bei Netways Managed Services!

Und Ihr MyEngineer ist auch noch mehr als fair zu Ihnen. Seine Arbeiten werden nur abgerechnet, wenn er für Sie tätig wurde. Also z.B. keine monatlichen Pauschalen mehr, bei denen man oft nicht weiß, was darin verborgen ist. Oder keine festen Ersteinrichtungsgebühren. Es wird nur abgerechnet, was VORHER als Dienstleistung vereinbart wurde und nur nach tatsächlich erbrachtem Aufwand in 15-Minuten-Intervallen.

Welche Kunden buchen ihren MyEngineer?

  • Startups, die sich nicht mit eigener IT belasten wollen
  • Marketing Agenturen, die für neue Kundenprojekte zusätzliche, erfahrene Manpower benötigen
  • Hosting-Kunden, die für ihre Projekte spezielle Expertise benötigen
  • Kunden, die ihre eigene IT reduzieren wollen oder müssen und gleichzeitig auf Grund unserer Erfahrungen ihre IT-Leistungen verbessern wollen
  • Kunden mit „Not am Mann“

Fragen? Bitte fragen!

Überzeugt? Kommen Sie mit Ihrem Projekt zu uns! Alles weitere zu OpenStack finden Sie hier und Ihren MyEngineer hier.