Freelancer Rancher / Kubernetes (m/w/d)

Upgrade/Neuinstallation, remote oder in Nürnberg

    1. Hintergrund

    Wir sind ein kleines Unternehmen in Nürnberg mit unter 10 Angestellten. Gestartet sind wir 2003 als CRO (Contract Research Organization) mit Schwerpunkt Schmerztherapie. Nachdem wir verschiedene klinische Prüfungen und Nicht-Interventionelle Studien teils als Hybrid durchgeführt hatten, haben wir Ende der 2000er Jahre eine Software zur Erfassung von medizinischen Daten entwickelt. Darauf aufbauend haben wir 2014 die Software iDocLive (https://idoclive.de) als reine Webanwendung entwickelt.

    Da sowohl der Kundenstamm als auch der Funktionsumfang gewachsen ist, haben wir uns 2020 dazu entschieden, eine Version 2 als komplette Neuentwicklung auf Microservice-Architektur zu konzeptionieren und sind mittlerweile so weit, dass die grundlegenden Funktionen und Services laufen.

    Wir haben dabei von Anfang an auf Rancher gesetzt, da alles auf eigener Hardware laufen soll bzw. auf dedicated Servern in Deutschland. Ende 2020 kam auch ein festangestellter DevOps dazu, der dieses System aufgebaut und gepflegt hat.

    Diese Umgebung funktioniert grundsätzlich, muss aber aktualisiert und erweitert werden. Da uns unser DevOps verlassen hat und das Ausmaß der Arbeit keine Festanstellung erfordert, möchten wir diese Aufgabe nach extern vergeben. Dazu gehört sowohl die einmalige Aktualisierung / Konfiguration mit Dokumentation als auch in näherer Zukunft (zumindest 2025) die Aktualisierung nach Bedarf.

    Da die Webanwendung noch nicht in production ist, kann auch mit down-time geplant werden.

    2. Aktuelle / Geplante Rancher Installationen

    2.1 Infrastruktur

    2.1.1 Aktuell

    Rancher (Version 2.7.1) läuft als Cluster über drei VMs, die auf unseren Servern vor Ort laufen. Der Working-Cluster läuft über drei dedicated Server bei Hetzner (Falkenstein). Auf den drei Servern läuft nichts anderes.

    2.1.2 Geplant

    Das soll auch weiterhin so laufen. Sollte eine komplette Neukonfiguration sinnvoll sein, dann können wir dafür auch neue Server verwenden (sowohl für Rancher als auch für den Working Cluster). Da unsere Webanwendung noch nicht in production ist, muss nur die Entwicklungsdatenbank migriert werden.

    Upgrade auf die aktuelle Version und Upgrade aller 6 Server (Betriebssystem ist debian, Umstieg auf ubuntu möglich).

    2.1.3 Nice to have

    Wünschenswert wäre ein Konzept, ob und wie wir den kubernetes-Cluster bei Engpässen dynamisch erweitern könnten (bei Hetzner, stackit, AWS).

    2.2 Namespaces / Workloads

    2.2.1 Aktuell:

    Es gibt vier namespaces, in die per Pipeline (bitbucket Server => drone => rancher) automatisch deployed wird:

    1. dev:
      1. Für die Entwickler.
      1. Entwickler können eigenständig Deployments durchführen.
    2. qa:
      1. Für die Qualitätssicherung.
      1. Deployments dürfen nur vom Projektleiter durchgeführt werden.
    3. staging:
      1. Für die Zertifizierungsstelle (MDR).
      1. Deployments dürfen nur vom Projektleiter durchgeführt werden.
    4. production:
      1. Für die Anwender.
      1. Deployments dürfen nur vom Projektleiter durchgeführt werden.

    Neben den Deployments laufen pro namespace:

    • MariaDB-Datenbank
    • RabbitMQ
    • Redis

    2.2.2 Geplant:

    Wir arbeiten mit LimeSurvey. LimeSurvey ist aktuell separat auf VMs installiert, sollte aber auch pro namespace konfiguriert werden.

    2.2.3 Nice to have

    Über kurz oder lang müssen wir bitbucket Server verlassen. Wir würden hierbei zu github tendieren. Hier wäre ein Konzept zur Migration wünschenswert.

    2.3 Storage

    2.3.1 Aktuell

    Wir haben Longhorn (Version 1.3.2) über die drei Server hinweg konfiguriert und speichern darauf die Volumes.

    2.3.2 Geplant

    Upgrade auf die aktuelle Version

    2.4 Monitoring

    2.4.1 Aktuell

    Seit dem letzten Upgrade (2.5 => 2.7) funktioniert das Monitoring nicht mehr.

    2.4.2 Geplant

    Monitoring mit dem in Rancher integrierten Grafana Dashboard. Die Entwickler sollen hierbei Zugriff haben und sich eigene Dashboards erstellen können.

    Health Checks und Auslastungswarnungen sollen implementiert werden.

    2.5 Logging

    2.5.1 Aktuell

    Seit dem letzten Upgrade (2.5 => 2.7) funktioniert das zentrale Logging nicht mehr.

    Auf Projektebene wurde jaeger als Tracinginstrument implementiert.

    2.5.2 Geplant

    Zentrales Logging mit den in Rancher integrierten Möglichkeiten. Die Entwickler sollen hierbei Zugriff haben und sich eigene Dashboards erstellen können.

    Jaeger soll weiterhin laufen und verwendet werden können.

    2.6 Scaling

    2.6.1 Aktuell

    Keine Regeln hinterlegt

    2.6.2 Geplant

    Implementierung von Scaling-Regeln (automatisches Hoch- und Herunterfahren von zusätzlichen Pods)

    2.7 Sicherheit

    2.7.1 Aktuell

    Deployments, die von außen erreichbar sein müssen (frontend, api), verfügen über Ingress mit automatisch erneuernden Let’s Encrypt Zertifikaten.

    Secrets werden pro Namespace verwaltet.

    2.7.2 Geplant

    Keine Änderung

    2.8 Backup / Wiederherstellung

    2.8.1 Aktuell

    Die Longhorn-Volumes werden auf eine Hetzner Storagebox gesichert. Das erfolgt per NFS, da die verwendete Longhorn-Version keine andere Möglichkeit bietet.

    2.8.2 Geplant

    Minimumlösung ist die Umstellung der Backuplösung auf SMB/CIFS.

    Wünschenswert wäre eine größere Lösung wie z.B. velero

    3. Sonstiges

    3.1 Dokumentation

    Alles muss dokumentiert werden, da wir in den nächsten Jahren eine Zertifizierung zum Medizinprodukt anstreben. Die Softwareentwicklung läuft streng mit Ticketsystem (noch jira) und nach Möglichkeit soll auch die Aktivität in Rancher und im Working-Cluster ticketbasiert erfolgen. Wir verwenden aktuell taiga.io (on-premise) für neue Projekte als Ticketsystem und möchten auch die Rancher-Arbeiten über taiga.io steuern. Für Dokumentation verwenden wir wiki.js on-premise.

    Während die Projektsprache deutsch ist, erfolgt sämtliche Codedokumentation in englischer Sprache.

    3.2 Zeithorizont

    Die Arbeiten sollten bis März 2025 abgeschlossen sein.

    3.3 Anwesenheit

    Die Arbeiten können remote durchgeführt werden. Auf Wunsch kann ein Arbeitsplatz im Nordostpark in Nürnberg gestellt werden.

    3.4 Weitere Services

    Aktuell laufen die meisten unserer Services auf einem Proxmox-Cluster. Hier ist zu überlegen, ob nicht Services nach Rancher migriert werden könnten.

    4. Kontakt

    Verantwortlich für diese Ausschreibung ist Gert Lankes: gert.lankes@omeany.de

    Unsere Website ist https://omeany.de.

    Ein erstes Treffen mit Fragen zur genaueren Aufwandsanalyse kann gerne kurzfristig persönlich oder remote durchgeführt werden.