Ich implementiere derzeit eine Webanwendung in Microsoft Azure. Meine Sorge ist, wie man den Staging-Slot zusammen mit ACS verwendet.
Ich möchte meine Anwendung in den Bereitstellungsslot schieben, sicherstellen, dass sie funktioniert und dann einen VIP-Swap für die Produktion durchführen.
Der Ansatz ist ziemlich einfach, außer der Konfiguration des ACS. Da der Bereitstellungsslot während der Bereitstellung eine zufällige URL erhält, muss die ACS-Konfiguration anschließend durchgeführt werden. Die web.config- und Relying Party-Anwendung der WebRole im ACS muss mit der URL des neuen Bereitstellungsslots konfiguriert werden.
Vittorio Bertocchi beschreibt in seinem blog post , wie die web.config ohne erneute Bereitstellung aktualisiert werden kann, und ich denke, dass das ACS nach der Bereitstellung im Staging mit einem Skript aktualisiert werden kann.
Dieser Ansatz erscheint ziemlich kompliziert und spröde; Ich suche nach einer einfachen und soliden Lösung für meinen Bereitstellungsprozess. Gibt es etwas, das ich vermisst habe?
Da die ACS-Konfiguration in einem Produktions-Slot recht einfach und unkompliziert ist, habe ich darüber nachgedacht, das Testen der Anwendung im Staging-Slot zu überspringen und nur den VIP-Swap für die Produktion durchzuführen (die Anwendung wird getestet) in seinem eigenen "QA" Hosted Service).
Was halten Sie von diesem Ansatz? Kann es Unterschiede zwischen den gehosteten Diensten in Azure geben?
Vielleicht könnte Ihre Anwendung die Rückgabe-URL programmgesteuert festlegen, wenn sie zum ACS umleitet. Dies würde den Benutzer nach der Authentifizierung entweder zum Staging-Slot oder zum Produktions-Slot umleiten.
Diese Frage zeigt Ihnen, wie Sie den Realm festlegen, aber die Rückgabe-URL ist nur ein weiterer Parameter: WIF-Cross-Domain auf einer IIS-Site, dynamische Einstellung von Realm
Ich habe das gelöst, indem ich einen neuen Cloud-Service namens "test" erstellt habe. Wenn ich also meine Anwendung auf den Bereitstellungsslot schiebe, drücke ich eine andere Instanz (mit einer anderen web.config) an den Produktions-Slot meines "Test" -Dienstes. Wenn die "Test" -Anwendung ordnungsgemäß funktioniert, lösche ich die Test-App und tausche meine Produktionsbereitstellungs-Slots.
Es ist nicht die ideale Lösung, aber es könnte Ihr Problem lösen.
Ich verwende nur Hosts-Dateieinträge, um Staging-Instanzen zu testen. Angenommen, Ihr Dienst wird in myservice.cloudapp.net gehostet. Ihr Staging-Slot erhält normalerweise eine URL wie [guid] .cloudapp.net, erhält aber auch einen öffentlichen VIP (Sie können ihn über das Dashboard des Service oder über nslookup [guid] .cloudapp.net) abrufen. Sie können einen Host-Dateieintrag als "[Public VIP] myservice.cloudapp.net" hinzufügen. Sobald Sie dies getan haben, können Sie Ihre Staging-Instanz nur mithilfe von myservice.cloudapp.net und die ACS-Konfiguration nicht ändern.