News
Das Neuste aus der Welt von Adfinis SyGroup
Freedomvote.ch ist zurück! Auch 2019 steht es den Kandidat:innen und Wähler:innen als Orientierung zur Verfügung. Bereits über 160 Kandidierende zeigen auf Freedomvote.ch ihr digitales Profil.
Freedomvote.ch ist ein Wahlhilfetool, das die fortschreitende Digitalisierung und Vernetzung ins Zentrum stellt. Bereits 2015 bot es den Kandidat:innen die Möglichkeit, sich gegenüber der Wählerschaft zu präsentieren. Es wurde rege genutzt. Über 100 Profile bewiesen, dass digitale Themen bewegen.
Am 20. Oktober ist es wieder soweit, die Nationalratswahlen stehen an. Die Vielfalt und Anzahl der Kandidat:innen macht die Wahlentscheidung auch 2019 nicht leicht – insbesondere zu Fragen, welche die Rechte und Freiheiten im digitalen Raum betreffen.
Im Informationszeitalter wollen die Bürger:innen wissen, wie sich die Kandidat:innen in den zentralen Fragen zu Datenschutz, Freie Software, Open Data, Netzsperren, E-Voting und Überwachung positionieren. Welche Werte vertreten sie in einer vernetzten Welt? Haben sie ein Bewusstsein für ihre digitale Verantwortung?
Der Spider von Freedomvote gibt Antworten und schafft Klarheit. Die Profile lassen sich aber nicht nur untereinander vergleichen, der Fragebogen kann auch von Wähler:innen ausgefüllt und so direkt mit den eigenen Werten und Prioritäten verglichen werden. Die Spider der Kandidat:innen sollen mit der Wählerschaft auf Social Media unter dem Hashtag #freedomvote geteilt werden.
Freedomvote 2019 steht ab sofort unter freedomvote.ch zur Verfügung.
Freedomvote.ch wird durch die Lokalgruppe Zürich der Free Software Foundation Europe betreut und ist eine Initiative der überparteilichen Parlamentarischen Gruppe Digitale Nachhaltigkeit (Parldigi) und des Umsetzungspartners Adfinis SyGroup, mit Unterstützung der Verbände Digitale Gesellschaft, CH Open und Opendata.ch.
2019 ist ein gutes Jahr für uns, neben dem Best Partner of the Year Award von SUSE und Red Hat, steigen wir, pünktlich zur Eröffnung der Schweizer Microsoft-Azure-Rechenzentren, zum Microsoft Gold Partner auf. Die Schweizer Datenhoheit, welche durch die neuen Rechenzentren garantiert wird, wirkt sich auch positiv auf unsere angebotenen Dienstleistungen aus. Zukünftig können Kunden der Adfinis also von lokaler Datenhaltung profitieren.
Alles dazu in der Pressemitteilung.
Seit Anfang 2019 ist Red Hat OpenShift in der Version 4 verfügbar. Die Version 3 (genauer 3.11) ist noch bis 2022 offiziell unterstützt [1]. Wir haben das stark überarbeitete Produkt frühzeitig unter die Lupe genommen und erste Erfahrungen gesammelt. Inzwischen betreiben wir die erste produktive Kundenumgebung auf Basis von OpenShift 4.1. Dieser Blog beschäftigt sich also mit unseren Learnings und beleuchtet ein paar Spezialitäten von OpenShift 4.
Die Basis
Red Hat hat mit dem Wechsel von OpenShift auf die Version 4 sehr grosse Änderungen eingeführt. Das zugrundeliegende Betriebssystem wurde mit Red Hat CoreOS ersetzt. Die OpenShift Nodes werden nicht mehr klassisch mit Ansible oder von Hand gepatched, CoreOS installiert die Updates “over the air”, vollständig selbstständig mit Hilfe von Ignition Configs.
Die OpenShift Komponenten, die bei der Version 3 noch als Prozess auf den Mastern oder als App in einem Pod betrieben wurden, finden sich heute in der Form eines Operators wieder. Red Hat setzt damit stärker auf die Kubernetes Standards und wird einige Eigenheiten los.
Was ändert sich?
Als System Integrator kann nur sehr bedingt auf die Erfahrungen mit OpenShift 3 zurückgegriffen werden. Die Installation und Integration von OpenShift 4 ist nicht mehr mit der früheren Methode zu vergleichen. Der Konsument/Entwickler hingegen erhält immer noch die gleich ausgereifte und umfangreiche Lösung und muss sich nicht umstellen. Seine Möglichkeiten erweitern sich, ohne alte Gewohnheiten aufgeben zu müssen. Für den System Engineer und das Operations Team ändert sich dafür ALLES und zwar GRUNDLEGEND.
Der OpenShift Installer: Aus Red Hat Ansible wird HashiCorp Terraform
Die Installations-Routine von OpenShift 4 entstand mit dem Fokus auf Public Cloud Umgebungen und dem Ansatz der vollständigen Automatisierung. Der frühere ansible-installer für OpenShift 3 hat zwar auch sehr viel Automatisierung mitgebracht, die Basis-Infrastruktur (VMs, Netzwerke, Storage) musste jeder selber erstellen bzw. automatisieren. Diesen Umstand haben wir im Rahmen eines Kundenprojekts zu korrigieren versucht und waren damit erfolgreich. Dazu haben wir den Ansible Installer von Red Hat mit Terraform Code ergänzt. Das Ziel war eine von Grund auf automatisierbare Installation, die alle Komponenten miteinbezieht und auf den grossen Cloud Providern funktioniert.
Plot Twist: Kurz nach der Fertigstellung der ersten Version, die vor allem auf AWS fokussiert war, hat Red Hat die neuen Installationsmethoden für OpenShift 4 öffentlich gemacht (GitHub Repo auf public gesetzt).
Mit Erstaunen und gleichzeitiger Begeisterung mussten wir die vielen Parallelen erkennen, was unsere eigene, um Terraform erweiterte Version, in der Bedeutungslosigkeit verschwinden liess. Nichtsdestotrotz nutzen wir den Code immer noch bei einigen Kunden und werden das auch noch so lange tun, wie OpenShift 3 im Einsatz ist.
Natürlich funktioniert ein vollständig automatisierter Installer nur, wenn die Infrastruktur auch eine API dafür anbietet. Das machen die grossen Cloud Provider, aber auch Lösungen wie OpenStack oder VmWare. Der OpenShift 4 Installer kann vorerst aber nur mit AWS und VMware umgehen, braucht man etwas anderes, bleibt einem nur eine sehr mühsame und schlecht dokumentierte manuelle Installation übrig. Wir durften bisher nur letzteres umsetzen, obwohl zwei der Installationen auf VMware waren. Die automatisierte Installation hat einige Voraussetzungen, die sich nicht auf jeder VMware Plattform umsetzen lassen.
First Hand Experience & Learnings
Unser Kunde betrieb bis vor kurzem ein OpenShift 3.6. Mit der Gefahr eines auslaufenden Supports und mit dem Wissen, diverse Funktionen zu vermissen, wurde zuerst ein Update auf 3.11 angestrebt. Im Rahmen der konzeptionellen Arbeiten und bedingt durch einige Verzögerungen, wurde dann doch OpenShift 4.1 als Zielplattform definiert. Ein Upgrade von OpenShift 3.11 auf OpenShift 4.1 ist nur mittels Sidegrade möglich, ein Upgrade-Pfad steht nicht zur Verfügung.
OpenShift 4.1 hat noch nicht die Qualität, die wir uns von OpenShift 3.11 gewohnt sind. Die Bare Metal Installation setzt umfangreiches Know-How voraus und ausserdem eine “Hacker Attitude”. Die Gründe kurz zusammengefasst:
- Mangelnder Proxy Support bei Version 4.1**
- Grundlegende Änderung der DNS Struktur für Cloud Installationen
- DHCP zwingend erforderlich**
**lässt sich umgehen
Die Installation der Master und Worker Nodes auf VMWare mussten wir mittels Bare Metal Installation angehen [2]. Die direkte Anbindung an Vsphere war aus Sicherheitsgründen nicht möglich. Beim Bootstrappen der Nodes, musste darauf geachtet werden, dass eine fixe IP gesetzt ist. Ein DHCP war in diesem VLAN nicht verfügbar (wird vom Installer vorausgesetzt). Die CoreOS ISO wurde dabei mittels dracut boot Parameter übergeben [3]. Nach der CoreOS Installation ergänzten wir manuell die Proxy Konfiguration, da ohne kein Weg ins Internet führt. Eine offizielle Proxy Unterstützung kommt erst mit OpenShift 4.2, also hoffentlich noch dieses Jahr.
Die Bootstrap Node wird nur für die Installation der Master Nodes benötigt. Ab dann kümmern sich die Master Nodes um das Bootstrappen der Worker Nodes. Das Bootstrap System kann nach der OS Installation gelöscht werden.
Die gesamte Konfiguration des Clusters basierte ab jetzt auf Day 2 Deployments. D.h. dass alle weitere Konfigurationen wie bspw. Anbindung an ein LDAP oder einspielen der eigene CA und eines Zertifikats für den Ingress-Router, mittels der OpenShift API umgesetzt wird. Ein direkter SSH Zugriff auf den Nodes ist nur bei Troubleshooting oder in dringenden Fällen vorgesehen. Die Maschinen werden nach jedem SSH Login entsprechend in der API markiert, so dass zu jedem Zeitpunkt ersichtlich ist, auf welchem Node ein Shell Zugriff stattgefunden hat.
Für die Datenpersistierung stellte unser Kunde einen NFS Server zur Verfügung, auf dem wir mittels nfs-client-provisioner [4] ganze PVs durch OpenShift provisionieren liessen. OpenShift wird ab Version 4 inklusive Prometheus und Grafana installiert. Auch einen ELK Stack hochzufahren ist dank einfachem Deployment über Operatoren ein Kinderspiel [5].
Bei der Migration der Applikationen mussten wir wieder erfinderisch werden. Ohne die Hoheit über die DNS Zone ist eine Applikations-Migration eine grössere Herausforderung. Wir wollten nicht alle Applikationen auf einmal migrieren, deshalb entwarfen wir eine Lösung, welche die Migration ohne weitere DNS Anpassungen möglich machte. Wir deployten einzelne Applikationen auf dem neuen Cluster und lenkten den Traffic mittels Socat-Proxies vom alten Cluster auf den neuen. Nach der erfolgreichen Migration, blieb nur die Anpassung des Wildcard DNS Eintrags und schon erreicht kein Traffic mehr die alten Cluster. Die Migration verlief ohne Probleme und Ausfälle.
Fazit
OpenShift 4 wird das beste OpenShift werden. Dazu müssen jedoch noch einige Stolpersteine aus dem Weg geräumt werden. Wir erhielten den Eindruck, dass Red Hat mit der Version 4.1 nur eine Beta Version veröffentlicht hat, um die stabile Version mit 4.2 in einigen Monaten nachzureichen. Auch wenn die Installation auf eine Cloudumgebung wie AWS jetzt schon viel einfacher ist, bleibt der grosse Teil der Schweizer Kundeninstallationen “on-prem”. Für den Schweizer Markt ist der starke Fokus auf Cloud Installation aktuell noch ein Hindernis.
Plant ihr ein OpenShift 4 Projekt oder eine Migration – kommt auf uns zu, wir wissen wie es geht.
Fast 900 Teilnehmer waren am Red Hat Forum 2019 im Stage-One in Zürich-Oerlikon mit dabei. Allerdings drehte es sich nicht nur um DevOps, offene Technologien und Container…
Den gesamten Beitrag der Netzwoche ist hier aufzufinden.
Adfinis SyGroup hat die Auszeichnung Best Swiss Red Hat Partner of the Year erhalten. Mit dem Award würdigt Red Hat die erfolgreich abgeschlossenen OpenShift-, Ansible- und S/4HANA-Projekte des Schweizer Dienstleisters.
Der ganze Artikel gibt es hier.
