Zum Inhalt springen
Expertise

Docker und Kubernetes

Windchill als Container-Images, mit Helm auf Azure Kubernetes Service oder Ihrem eigenen Cluster ausgerollt, mit Umgebungen, die Sie in Stunden klonen.

Was sich mit Containern ändert

Die Anwendung wird zu einem Image, das einmal gebaut wird und in jeder Umgebung gleich läuft. Method Server skalieren als Replicas statt über von Hand bearbeitete Properties. Eine Testumgebung ist ein Helm-Release, das morgens erstellt und abends wieder gelöscht werden kann, und ein fehlgeschlagenes Upgrade wird per Rollback auf das vorherige Release rückgängig gemacht.

Was gleich bleibt

Datenbank und File Vaults brauchen weiterhin sorgfältig geplanten, persistenten Speicher, Backups und einen Wiederherstellungsplan. Lizenzierung und die Support-Bedingungen von PTC gelten weiterhin. Container machen Windchill leichter zu betreiben, aber nicht von seinen Regeln befreit. Deshalb prüfen wir mit Ihnen die Support-Position von PTC für Ihr Release, bevor wir irgendetwas entwerfen.

Unser Referenz-Stack

  • Docker-Images, von der Pipeline gebaut und in Ihrer Container Registry abgelegt
  • Helm Charts mit einer Values-Datei pro Umgebung
  • Azure Kubernetes Service, OpenShift oder Upstream-Kubernetes On-Premises
  • Azure Files, NetApp oder Ihre Storage-Plattform für Vaults und gemeinsame Dateien
  • Managed SQL Server oder Oracle, außerhalb des Clusters
  • Prometheus und Grafana oder Azure Monitor, mit Alerts, die die richtige Person erreichen

Produktion in Stunden klonen

Weil Daten und Konfiguration vom Image getrennt sind, bauen wir eine vollständige Kopie der Produktion für einen Upgrade-Probelauf oder eine Schulung in wenigen Stunden auf, bei Bedarf mit maskierten sensiblen Daten.

Nächster Schritt

Zeigen Sie uns Ihr Windchill. Wir zeigen Ihnen die Pipeline.

Nennen Sie uns Ihr Release, Ihre Systemlandschaft und die Änderung, die immer wieder verschoben wird. Innerhalb einer Woche erhalten Sie einen schriftlichen Plan mit Umfang, Team und Zeitplan.