Übersicht über die Migration von Heroku zu Azure Container Apps

Wenn Sie von Heroku zu Azure Container Apps wechseln, hilft Ihnen dieser Leitfaden bei der Planung der Migration, indem Sie die Heroku-Konzepte zuordnen, die Sie bereits kennen, ihren Azure-Entsprechungen. Verwenden Sie diesen Artikel, um den Umfang Ihrer Migration zu bewerten, die benötigten Azure-Dienste zu identifizieren und häufige Fallstricke zu vermeiden, bevor Sie beginnen.

Schrittweise Migrationsverfahren finden Sie unter Migrieren einer App von Heroku zu Azure-Container-Apps.

Konzeptzuordnung

Die folgende Tabelle ordnet die wichtigsten Heroku-Plattformfeatures ihren Azure-Container-Apps-Entsprechungen zu.

Heroku-Konzept	Entsprechung von Azure Container Apps	Hinweise
App (web Dyno)	Container-App	Eine einzelne bereitstellungsfähige Einheit, die Ihren Anwendungscode ausführt.
Dyno-Typen + manuelle Skalierung	KEDA-basierte Automatische Skalierung	Regelbasiertes automatisches Skalieren mit Skalieren-auf-Null. Ersetzt das manuelle Dyno-Management.
Buildpacks (Slug-Kompilierung)	Container-Images oder Cloud Native Buildpacks	Verwenden Sie az containerapp up --source für ein buildpack-ähnliches Erlebnis oder bringen Sie Ihre eigene Dockerfile mit.
Konfigurationsvariablen	Umgebungsvariablen + Azure Key Vault	Nicht sensible Werte verwenden Umgebungsvariablen. Geheimnisse verwenden Key Vault-Referenzen oder Geheimnisse von Container Apps.
Add-Ons (Postgres, Redis usw.)	Verwaltete Azure-Dienste	Siehe Dienstäquivalente für eine vollständige Zuordnung.
heroku CLI	az containerapp CLI	Azure CLI mit der containerapp Erweiterung bietet entsprechende Verwaltungsbefehle.
Heroku Pipelines / Apps überprüfen	GitHub-Aktionen oder Azure-Pipelines	Die CI/CD-Pipelines, die Sie konfigurieren und verwalten.
Einmalige Dynos (heroku run)	Container-Apps-Aufträge	On-Demand- oder geplante Ausführung ohne eine lang andauernde App.
Procfile (Prozesstypen)	Separate Container-Apps pro Prozesstyp	Stellen Sie Ihre Web- und Arbeitsprozesse als unabhängige Container-Apps in derselben Umgebung bereit.
Benutzerdefinierte Domäne + ACM	Benutzerdefinierte Domäne + kostenloses verwaltetes Zertifikat	Verwaltete Zertifikate sind kostenlos und werden automatisch erneuert.

Dienstäquivalente

Wenn Sie von Heroku migrieren, ersetzen Sie Heroku-Add-Ons durch verwaltete Azure-Dienste. Die folgende Tabelle ordnet allgemeine Add-Ons ihren Azure-Entsprechungen zu.

Heroku-Add-On	Azure-Äquivalent	Migrationskomplexität
Heroku Postgres	Azure-Datenbank für PostgreSQL – Flexible Server	Mittel: Erfordert Datenexport und Wiederherstellung.
Heroku Redis	Azure Cache für Redis	Niedrig: In der Regel ist keine Datenmigration erforderlich (nur Cacheverwendung).
Heroku Scheduler	Container-Apps-Aufträge (geplanter Auftragstyp)	Niedrig – Erstellen Sie Cron-Ausdrücke als Auftragspläne neu.
Papertrail / Logentries	Azure Monitor + Log Analytics	Niedrig – Die Protokollierung ist in Container-Apps integriert.
New Relic	Azure Application Insights	Mittel – erfordert SDK- oder automatische Instrumentierungsänderungen.
SendGrid	SendGrid über Azure Marketplace oder Azure Communication Services	Niedrig – SendGrid funktioniert weiterhin von Azure; Aktualisieren Sie nur Verbindungsinformationen.
CloudAMQP (RabbitMQ)	Azure Service Bus	Hoch – verschiedene Messaging-API; erfordert Codeänderungen.
Heroku Kafka	Azure Event Hubs (Kafka-kompatibler Endpunkt)	Niedrig – Event Hubs unterstützt das Kafka-Protokoll direkt.
Bucketeer/S3-Erweiterungen	Azure Blob Storage	Mittel – erfordert SDK- oder API-Änderungen für Dateivorgänge.
Memcachier	Azure Cache für Redis	Niedrig – Redis unterstützt Memcache-kompatible Protokolle.
Heroku Connect (Salesforce)	Azure Logic Apps oder Power Automate	Hoch — unterschiedlicher Integrationsansatz; erfordert eine Neugestaltung des Workflows.

Befolgen Sie für jedes Add-On in Ihrer Heroku-App dieses allgemeine Muster:

1. Stellen Sie den azure-äquivalenten Dienst bereit.
2. Migrieren Sie alle persistenten Daten (Datenbanken, Speicher).
3. Aktualisieren Sie Verbindungszeichenfolgen und Anmeldeinformationen in Ihren Container-App-Umgebungsvariablen.
4. Überprüfen Sie die Integration, bevor Sie das Heroku-Add-On entfernen.

Skalierungsvergleich

Heroku verwendet ein Modell mit festem Dyno, bei dem Sie eine bestimmte Anzahl von Instanzen festlegen. Azure-Container-Apps verwenden regelbasierte automatische Skalierung, die von KEDA unterstützt wird, wodurch Replikate basierend auf Bedarf angepasst werden.

Fähigkeit	Heroku	Azure Container Apps – ein Dienst für containerbasierte Anwendungen
Skalierungsmechanismus	Manuelle Dynamometeranzahl	Regelbasierte automatische Skalierung (HTTP, CPU, Warteschlangenlänge, Cron, benutzerdefiniert)
Skalierung auf null	Nicht verfügbar	Unterstützt – keine Kosten im Leerlauf
Mindestinstanzen	Mindestens 1 Dyno erforderlich	Konfigurierbar: 0 oder mehr Replikate
Maximale Instanzen	Planabhängig	Bis zu 300 Replikate pro Container-App
Skalierungstrigger	Keine – nur manuell	HTTP-Parallelität, TCP-Verbindungen, CPU, Arbeitsspeicher, Azure-Warteschlange, benutzerdefinierte KEDA-Scaler

Wichtige Skalierungskonzepte

• min-replicas: 0 ermöglicht die Skalierung auf Null, wenn kein Verkehr vorhanden ist, wodurch Kosten für inaktive Apps eliminiert werden.
• max-replicas begrenzt die Anzahl der Instanzen, um die Kosten zu steuern. Beginnen Sie konservativer und passen Sie sie basierend auf Überwachungsdaten an.
• Die HTTP-Parallelitätsskalierung ist der einfachste Ausgangspunkt für Web-Apps. Sie fügt Replikate hinzu, wenn gleichzeitige Anforderungen pro Instanz Ihren Schwellenwert überschreiten.
• Die warteschlangenbasierte Skalierung eignet sich ideal für Arbeitsprozesse. Stellen Sie Mitarbeiter als separate Container-Apps bereit, die basierend auf der Warteschlangentiefe skaliert werden.

Tipp

Für Produktions-Apps, die immer bereit sein müssen, setzen Sie min-replicas auf 1. Verwenden Sie min-replicas: 0, um in Entwicklungs- und Stagingumgebungen Kosten zu sparen.

Kostenvergleich

Scenario	Heroku (Standard-1X)	Azure-Container-Apps (Verbrauch)
Idle-App (24/7)	~ 25 USD/Monat pro Dyno	$0 (skaliert auf Null)
App mit geringem Datenverkehr	~ $25/Monat pro Dyno	~ $1–5/Monat
App mit hohem Datenverkehr (10 Instanzen)	~ $250/Monat	Variiert je nach tatsächlicher CPU- und Arbeitsspeichernutzung
Monatliche kostenlose Zuschüsse	Nichts	180.000 vCPU-Sekunden + 2 Millionen Anforderungen

Detaillierte Preise finden Sie unter Azure Container Apps-Preise.

Mitarbeiter und Hintergrundaufträge

Wenn Ihre Heroku-App Worker dynos (definiert in a Procfile) verwendet, stellen Sie jeden Arbeitstyp als separate Container-App in derselben Umgebung bereit. Verwenden Sie die warteschlangenbasierte Skalierung anstelle einer festen Instanzenanzahl.

Heroku-Muster	Azure-Container-Apps-Muster
web Prozesstyp	Container-App mit HTTP-Eingangs- und HTTP-basierter Skalierung
worker Prozesstyp	Container-App (kein Zugang) mit warteschlangenbasierter Skalierung
Geplante Vorgänge (Heroku Scheduler)	Container-Apps-Job mit einem Cron-Zeitplan
Einmalige Aufgaben (heroku run)	Container-Apps-Auftrag mit manuellem Trigger

Häufige Probleme

Überprüfen Sie diese häufig auftretenden Probleme vor und während der Migration, um Verzögerungen zu vermeiden.

Falle	Symptom	Beschluss
PORT-Umgebungsvariable	Die App antwortet nicht auf Anforderungen.	Container-Apps legen eine PORT Variable fest und erwartet, dass Ihre App darauf lauscht. Wenn Sie einen Port hartcodieren, stellen Sie sicher, dass --target-port beim Erstellen der Container-App übereinstimmt. Die meisten Heroku-Apps lesen PORT bereits aus der Umgebung und funktionieren ohne Änderungen.
Flüchtiges Dateisystem	Dateien, die zur Laufzeit geschrieben wurden, werden nach einem Neustart nicht mehr angezeigt.	Wie Heroku verwendet Container-Apps ein ephemeres Dateisystem. Stellen Sie für persistente Dateien eine Azure Files-Freigabe fest.
Falsche Konfiguration der Skalierung	Unerwartete Kosten oder schwache Leistung unter Last.	Beginnen Sie mit der HTTP-Parallelitätsskalierung für Web-Apps und überwachen Sie mit Azure Monitor. Vermeiden Sie es, max-replicas zu hoch einzustellen, bevor Sie den Ressourcenverbrauch Ihrer App verstehen.
Parität der Umgebung	Konfigurationsabweichung zwischen Dev, Staging und Produktion.	Verwenden Sie die Infrastruktur als Code (Bicep oder Terraform), um Umgebungen konsistent zu halten. Durch diesen Ansatz wird die von den Heroku-Pipelines bereitgestellte Konsistenz ersetzt.
Dienste von Drittanbietern	Unnötige Migrationsaufgaben für SaaS-Add-Ons.	Viele Heroku-Add-Ons sind eigenständige SaaS-Produkte (SendGrid, MongoDB Atlas, Elasticsearch). Diese Dienste funktionieren häufig weiterhin von Container-Apps – aktualisieren Sie nur die Verbindungs-URL. Nur heroku-verwaltete Dienste (Heroku Postgres, Heroku Redis, Heroku Kafka) erfordern eine Migration zu Azure-Entsprechungen.
Verfügbarkeit von CloudBuilds	az containerapp up --source schlägt mit ManagedEnvironmentNotFound- oder Erstellerfehlern fehl.	Cloud Build ist in allen Regionen oder für alle Sprachstapel nicht verfügbar. Greifen Sie auf den ACR-basierten Ansatz zurück: Erstellen Sie eine Docker-Datei, bauen Sie mit az acr build, und stellen Sie das Image bereit. Informationen zu beiden Ansätzen finden Sie unter Migrieren einer App von Heroku .
Reihenfolge der Secrets und Umgebungsvariablen	Umgebungsvariablen, die auf Geheimnisse verweisen, werden als leer aufgelöst.	Legen Sie geheime Schlüssel fest, az containerapp secret setbevor Sie sie in Umgebungsvariablen referenzieren. Beachten Sie außerdem, dass das Festlegen von geheimen Schlüsseln die App nicht neu startet – Sie müssen az containerapp update eine neue Revision erstellen.
Bereitstellungszeiten des Azure-Diensts	Die Migration dauert länger als erwartet.	Azure-verwaltete Dienste benötigen länger zur Bereitstellung als Heroku-Add-ons. Der Azure-Cache für Redis kann 10 bis 20 Minuten dauern. Die Azure-Datenbank für PostgreSQL kann 5 bis 10 Minuten dauern. Stellen Sie diese Dienste parallel bereit, während Sie Ihre App bereitstellen.

Nächster Schritt

Migrieren einer App von Heroku zu Azure-Container-Apps