Laden...

mycsharp.de ist nun auf Azure umgezogen

Erstellt von Abt vor 4 Jahren Letzter Beitrag vor 4 Jahren 6.098 Views
Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 4 Jahren
mycsharp.de ist nun auf Azure umgezogen

Hallo zusammen,

wie manche bereits bemerkt haben, haben wir nach unserer Ankündigung vor zwei Wochen am Samstag erfolgreich mycsharp.de auf Azure umgezogen.

Warum Cloud bzw. Azure?

Das Forum war bisher auf einem einzelnen, nicht-redundanten virtuellen Server, den wir selbst warten, sichern, aktualisieren und betreiben mussten.
Wir alle betreiben das Forum aber in der Freizeit und wollen dementsprechend so wenig Zeit wie Möglich in das Management des Forums investieren.

Daher waren wir schon länger damit beschäftigt das Forum technisch so zu verändern, dass es sich auf Azure im Rahmen eines Lift and Shifts einfach migrieren lässt.
Probleme des Forums, die wir gelöst haben, waren:

  • Bisher wurden alle User-Dateien (Attachements, Avatare) direkt im Root der Applikation gespeichert.
    Wir haben das Forum an den gewissen Stellen nun so umgeschrieben, dass diese Dateien auf einem Azure Blob gespeichert werden und nicht mehr direkt in der Applikation selbst.
  • Durch das Auslagern der Dateien konnten wir nun den Quellcode des Forums sauber in Azure DevOps mit einer Quellcodeverwaltung bearbeiten, ohne, dass dann Avatare oder Attachments teil der Quellcodeverwaltung sein müssen
  • Wir können damit das Forum nun in mehreren Stages betreiben (Dev/Test/Prod) bzw. im neueren Sprachgebraucht Deployment Rings.
  • Eine Änderung des Quellcodes ist binnen 30 Sekunden auf unserem Testsystem und binnen 2 Sekunden auf dem Produktivsystem.
    Dank Deployment Slots haben wir dabei keinerlei Downtime.
  • Durch das Auslagen der Dateien auf einen Blob Storage werden diese auch nicht mehr direkt durch die Webanwendung ausgeliefert, sondern durch einen CDN (Content Delivery Network). Daher werdet ihr im Networking des Forums nun auch den Zugriff auf cdn.mycsharp.de sehen.
  • Der CDN cached dabei statische Ressourcen 30 Tage (bisher 2h) und User-Dateien 7 Tage (bisher gar nicht). Dadurch hat der Webserver weniger Last, der Traffic sinkt.
  • Durch die geringere Last des Webservers konnen wir das Forum nun mit geringeren Ressourcen betreiben und Kosten sparen.
  • Nebeneffekt: das Forum ist insgesamt spürbar schneller.

Technisch gesehen basiert das Forum nun auf:* Quellcode via Git auf Azure DevOps mit automatischer Build- und Release Pipeline

  • Azure Web Apps mit Deployment Slots und Firewall
  • Azure Managed MySQL inkl. Managed Backups und Firewall
  • Azure Blob Storage als CDN inkl. Managed Snapshots
  • CloudFlare für Zugriffsschutz und zusätzlichem Caching

Wir haben damit eine Basis, die es uns insgesamt vereinfacht langfristig von phpBB ganz weg zu kommen, woran wir parallel bereits arbeiten.

Weitere Anpassungen* Die Links in der Navigation wurden aktualisiert bzw. veraltete Links entfernt

  • Die Minicity wurde aus dem Forum entfernt
  • Zugriffe auf statische Dateien auf www.mycsharp.de werden auf den CDN automatisch umgeleitet.

Sollte irgendjemand einen Fehler finden (falsche Verlinkung etc...) bitte Kontakt zum Team aufnehmen.

Besten Dank und viele Grüße
myCSharp.de-Team

3.003 Beiträge seit 2006
vor 4 Jahren

Tolle Arbeit. Muss auch mal gesagt werden.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
64 Beiträge seit 2010
vor 4 Jahren

Tolle Arbeit. Muss auch mal gesagt werden.

Und Dankeschön für die Tolle Arbeit! 😁 👍

T
415 Beiträge seit 2007
vor 4 Jahren

Bravo! Super Arbeit. Man könnte meinen ihr habt ein paar erfahrene Berater in euren Reihen, die erfolgreich eine Legacy App ins Jahr 2019 portiert haben 😉

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 4 Jahren

So ist das - auch wenn Legacy-Work immer weniger wird; Gott sei Dank 😃

5.941 Beiträge seit 2005
vor 4 Jahren

Top Abt! 😃

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

T
708 Beiträge seit 2008
vor 4 Jahren

Da kommt man nichts ahnend aus dem Urlaub zurück und stellt fest:
Nix!

So muss ein Umzug laufen! Klasse Arbeit & Danke 😃

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 4 Jahren

Ich wurde nun ein paar mal angeschrieben, wie wir die Azure DevOps Pipelines konfiguriert haben: sehr simpel.

  • Nach einem Build (gegen den master-branch, GitHub Flow) wird automatisch ein Release auf unsere Test WebApp gespielt.
  • Sollte dies positiv sein ist der nächste Schritt, dass auf eine Staging WebApp deployed wird. Diese Staging WebApp ist ein Deployment Slot
  • Anschließend laufen ein paar Tests gegen die Staging WebApp
  • Nun erfolgt ein Slot Swap von Staging auf Production

Mit dem Setup haben wir technisch gesehen drei verschiedene WebApps, die vollständig getrennt laufen und angesprochen werden.
Der Deployment Slot sorgt dafür, dass nach einem Deployment die WebApp wieder läuft und es keinen Cold Start gibt, sobald User drauf zugreifen; zeitgleich sorgt der Slot Swap dafür, dass keiner das Deployment selbst bemerkt (außer wir haben in der App mist gebaut): es gibt keinerlei Downtime.
Ist nichts anderes als zu einem bestimmten Moment die User nicht mehr auf App A sondern auf App B zu leiten - alles "under the hood".

Wird prinzipiell alles in Azure DevOps konfiguriert und sieht dann so aus:

T
415 Beiträge seit 2007
vor 4 Jahren

Sehr cool. Erfolgt der Swap automatisch oder durch ein manuelles "approval"?

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 4 Jahren

Automatisch wäre in diesem Fall gefährlich - die bescheidene Forenquellcode-Basis besitzt keinerlei Tests für die Runtime selbst 😉 Erfolgt daher manuell.
Siehst im Bild auch an den Haken vor dem People-Icon.

Abt Themenstarter:in
16.807 Beiträge seit 2008
vor 4 Jahren

Leider sind wir heute morgen in unerwartete Datenbank-Limits gelaufen, weshalb das Forum extrem träge war.

Das Forum lief bisher auf einem Azure MySQL Basic, was prinzipiell mehr Performance hat als unser alter MySQL Server.
Trotzdem hatte dies durch die unerwarteten Wachstumszahlen der Anfragen wohl nicht mehr gerreicht, sodass wir hier in Limits gelaufen sind.
Das Monitoring hatte dazu auch angeschlagen - nur die Reaktionszeit war hier Arbeitsbedingt nicht lang genug.

Da keine automatische Skalierung von Azure MySQL Basic auf Azure MySQL General Purpose möglich ist (leider steht in der Doku nicht wieso), mussten wir erneut manuell die Datenbank migrieren auf das höhere Skalierungsmodell.

Das Forum war daher ca. 3 Stunden schlecht erreichbar (Antwortzeiten zwischen 10 Sekunden und 3 Minuten) und eine Stunde durch die Migration down.

Sorry dafür; Lessons learned 😉

T
2.219 Beiträge seit 2008
vor 4 Jahren

Kann passieren.
Und einige Stunden werden wir ohne das Forum bestimmt mal auskommen können 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

4.931 Beiträge seit 2008
vor 4 Jahren

Und ich wollte schon einen Bug-Report schreiben, aber es kam dann ein Netzwerkfehler (Timeout) 😉.

2.921 Beiträge seit 2005
vor 4 Jahren

Auch von mir: ebenfalls danke dafür. 😃

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.