Migrieren von Ressourcen zwischen verschiedenen Azure-Abonnements

Ich habe ein paar Fragen an die Azure-Gurus da draußen. Ich arbeite für ein Softwareentwicklungshaus und wurde gebeten, unsere Azure-Infrastruktur zu entwickeln. Ich hatte die Idee, drei Pay-As-You-Go-Abonnements für die folgenden Abteilungen einzurichten:

1) Produktion (Live-Umgebung). 2) Qualitätssicherung. 3) Testen.

Meine Fragen sind:

1) Beim Erstellen von Ressourcen wie Websites; Können virtuelle Maschinen ua zwischen den verschiedenen Abonnements migriert werden? Hier ist ein Szenario: Nehmen wir an, wir starten eine neue Anwendung, müssen sie jedoch zuerst testen. Also platzieren wir es zuerst in Testing. Sobald strenge Tests durchgeführt wurden, verschieben wir sie in die Qualitätssicherung. Danach verschieben wir es in die Produktion (Live-Umgebung), wenn alle Qualitätsprüfungen abgeschlossen sind. 2) Ich entwickle auch eine Sicherheitsmatrix, in der ein Benutzer in einer Abteilung nichts in einer anderen Abteilung ändern kann.

Was sagen Sie Damen & Herren? Ist es machbar?

Michael - Der von Ihnen verwendete Migrationsprozess hängt stark von der zugrunde liegenden Infrastruktur / dem zugrunde liegenden Service ab, den Sie verwenden.

Als Ausgangspunkt würde ich vorschlagen, zu prüfen, wie Sie Build-Services verwenden können, um von Ihnen erstellte Software automatisch bereitzustellen. Die MSDN-Dokumentation ist ein guter Ausgangspunkt.

• Websites und Cloud-Dienste (Web- oder Worker-Rollen): Sie müssen Ihren Code auf der entsprechenden Instanz im richtigen Abonnement erneut bereitstellen. Sie können die zugrunde liegende Hosting-Infrastruktur nicht "verschieben".
• Auf virtuellen Maschinen gehostete Dienste: Sie können VMs zwischen Abonnements verschieben, dies erfordert jedoch einen erheblichen Aufwand, je nachdem, welche anderen Abhängigkeiten Sie haben (Netzwerke, Datenbanken usw.). Am besten versuchen Sie, den gleichen Ansatz wie für Websites / Cloud-Dienste zu wählen.
• Azure SQL-Datenbank: Sie müssen die Datenbank zwischen den Abonnements sichern / wiederherstellen.
• Andere Azure-Dienste: hängen sehr stark von der Bereitstellung ab (Entschuldigung, wenn diese vage ist, aber in Azure viele bewegliche Elemente vorhanden sind).

In der Regel ist es in Ihrem Szenario sinnvoll, Wege zu finden, um die Bereitstellung / Neubereitstellung von von Ihnen erstellten Lösungen zu skripten oder zu automatisieren.

Wir verwenden Visual Studio Online (VSO) für automatisierte Builds und Bereitstellungen in unseren verschiedenen Azure-Umgebungen. Dies funktioniert unabhängig davon, ob Sie Ihre Umgebungen durch unterschiedliche Abonnements trennen oder unterschiedliche Ressourcengruppen in demselben Abonnement verwenden.

Unser Setup ist, dass jedes Einchecken von Code einen Build auslöst, die Komponententests ausführt und bei erfolgreichen Triggern in der Testumgebung bereitgestellt wird.

Dann stellt unsere QS-Abteilung routinemäßig einen Build über VSO in die Warteschlange, um einen bestimmten Änderungssatz / ein bestimmtes Datum auszuwählen. Wenn die Build- und Unit-Tests erfolgreich sind, wird eine Bereitstellung für die Qualitätssicherung ausgelöst. Dieser Build wird auch technisch für Prod erstellt, jedoch nicht für Prod bereitgestellt.

Sie erledigen alle ihre Qualitätssicherungsarbeiten, und wenn alles golden ist, reichen sie ihre Zustimmung für ihre Seite der in VSO integrierten Gatekeeper-Logik ein. Wir haben es dann eingerichtet, sodass 2 andere Personen sich abmelden müssen, wenn der Build in die Produktion übertragen wird (was sofort oder geplant sein kann).

Wenn Sie vor Ort sind, können Sie stattdessen deren TFS verwenden, was im Wesentlichen dasselbe ist.

TLDR; Sie können dies über VSO erreichen und zur Authentifizierung und Steuerung in Azure Active Directory integrieren.