pixel
Seite wählen

NETWAYS Blog

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:

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

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

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
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.

 

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.

How To NWS: Infrastructure as a Service mit OpenStack

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/ressourcen/

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
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.

Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging


 
„Das @netways Blog kann man auch generell einfach mal empfehlen: https://www.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.
Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!
Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!
CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!
Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.
Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.
Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.
Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.
Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

Julia Hornung
Julia Hornung
Lead Marketing Manager

Julia ist seit Juni 2018 bei NETWAYS. Mit ihren Spezialgebieten Texte/Konzepte, Branding und PR ist sie für Tone of Voice und Wording von NETWAYS und Icinga verantwortlich. Davor war sie als Journalistin und in der freien Theaterszene spannenden Geschichten auf der Spur. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Ihre innere Mitte findet sie beim Klettern und Yoga.