8 Jahre CPU an einem Tag

Kommen Sie nach Walhalla mit Azure DevOps #ftw

Brian A. Randell und Ian Griffiths, DuoMyth

Die Idee schien einfach: die globale Community zusammenzubringen, damit sie sich austauschen und lernen kann, wie man DevOps auf dem Microsoft-Stack mit Visual Studio Team Services, Microsoft Azure, mit Visual Studio 2017 und Xamarin-Tools am besten einsetzt. Machen Sie dies an einem Tag im Jahr und machen Sie die Veranstaltung global. Das bedeutete, Menschen, Standorte und Ressourcen auf der ganzen Welt zu vereinen. Aber ein globales Treffen war nicht genug. Xpirit wollte, dass die Veranstaltung praxisorientiert ist.

Am 16. Juni 2017 startete Xpirit sein erstes globales DevOps-Bootcamp in Neuseeland und beendete es im Westen des amerikanischen Kontinents. Mit Veranstaltungen in Australien, Indien, Europa, Süd- und Nordamerika jagten wir dem Sonnenaufgang hinterher, um an jedem Standort VMs startklar zu haben. Während der Veranstaltung hatte jeder Teilnehmer Zugriff auf seine eigene private virtuelle Dual-Core-Windows-Maschine, die in Azure lief. In der Spitze liefen 1.500 VMs mit 3.000 Rechenkernen und über 180 Terabyte Speicherplatz. Jeder Teilnehmer hatte seine eigene private Umgebung, in der er mit Visual Studio, Docker und den anderen Tools arbeiten konnte, die für die praktischen Übungen benötigt wurden, um sich die Hände mit DevOps in einer Laborumgebung schmutzig zu machen. All dies wurde durch die harte Arbeit von Hunderten von Teilnehmern, die Azure Cloud und Valhalla ermöglicht.

Kommen Sie nach Walhalla

Valhalla ist der Name unserer Lösung, die auf Azure aufbaut und mit der Veranstaltungen wie das Global DevOps Bootcamp, der DockerCon 2017 Pavillon und sogar praktische Workshops für 20 Personen einfach durchgeführt werden können, indem für jeden Teilnehmer eine oder mehrere virtuelle Maschinen bereitgestellt werden. Die erste Veranstaltung, die auf Valhalla stattfand, war ein Microsoft ALM-Labor Anfang 2014. Seitdem hat Valhalla eine solide Grundlage für die Durchführung traditioneller, von Trainern geleiteter Schulungen, Roadshows für Microsoft in den USA, Europa und dem Nahen Osten sowie für die DockerCon 2016 und die DockerCon 2017 geschaffen, bei denen jeder Teilnehmer drei Linux-basierte VMs und/oder drei Windows-basierte VMs für verschiedene Docker- und Windows-Container-Labore erhielt.

Valhalla entstand aus dem Bedürfnis heraus, die Kosten für den praktischen Zugang zum ALM-Stack von Microsoft zu senken. Wir arbeiteten mit den Mitarbeitern der Microsoft-Niederlassung in den USA zusammen, um Wege zu finden, wie Veranstaltungen bei Kunden vor Ort und offene Veranstaltungen in den Microsoft-Niederlassungen verbessert werden können, indem den Kunden die Möglichkeit geboten wird, die neuesten Versionen von Visual Studio und Team Foundation Server in einer praktischen Erfahrung auf Abruf zu testen. Wir hatten den Einsatz von auf Azure gehosteten virtuellen Maschinen in Erwägung gezogen. Aber es gab einige Probleme. Ein großes nicht-technisches Hindernis war das ursprüngliche Abrechnungsmodell. Im Juni 2013 stellte Microsoft auf ein minutengenaues Abrechnungsmodell um und stellte die Abrechnung der Rechenleistung ein, wenn die VMs nicht liefen. Diese Änderung hat die Dinge über den sprichwörtlichen Haufen geworfen. Wir wussten, dass wir ein erschwingliches System auf der Grundlage von Azure entwickeln konnten. Es beschränkte sich nicht mehr nur auf ALM-bezogene Inhalte, sondern wurde zu einem Allzwecksystem, das "Studenten" Zugang zu einer oder mehreren VMs in einer verwalteten Umgebung in der Cloud bietet.

Im Sommer 2013 entwarfen wir das System und überlegten uns eine Finanzierung. Im September begannen wir mit der Entwicklung von Valhalla, ursprünglich in Zusammenarbeit mit unseren Freunden bei Endjin. Zu Beginn sollten die VMs auf der IaaS-Infrastruktur laufen, wobei jeder virtuellen Maschine ein Cloud Service zugewiesen wurde. Wir haben das System so konzipiert, dass es sowohl ein Modell mit einem einzigen Zahlungsempfänger als auch ein Modell mit mehreren Zahlungsempfängern unterstützt. Wir verwendeten Websites, die in Cloud Services gehostet wurden, die Nachrichten an Warteschlangen weiterleiteten und Arbeiterrollen, die Befehle aus den Warteschlangen verarbeiteten, mit Tabellen- und Blob-Speicher als Persistenzspeicher. Wir wollten, dass das System einfach zu bedienen und zu verwalten ist, aber dennoch flexibel sein, wenn es um die Arten von Inhalten geht, die wir unterstützen. Zu Beginn unterstützten wir nur Windows VMs. Als Azure sich veränderte, taten wir das auch und fügten Unterstützung für Premium SSD-Speicher und Linux-VMs hinzu.

Walhalla heute

Natürlich ist die Erstellung einer einzelnen virtuellen Maschine in Azure über das Azure-Portal einfach. Die Benutzeroberfläche führt Sie durch die einzelnen Schritte, bis Sie auf die letzte Schaltfläche klicken.

Wenn Sie regelmäßig Veranstaltungen oder sogar eine große Veranstaltung durchführen, möchten Sie dies natürlich automatisieren - niemand möchte den Assistenten zur Erstellung einer VM 1.500 Mal durchlaufen. Und während Sie vielleicht denken, dass ein bisschen PowerShell oder eine ARM-Vorlage alles "einfach" macht, stellt sich heraus, dass es etwas komplizierter ist.

Wir haben Valhalla von Anfang an so konzipiert, dass es sowohl flexible Klassenbereitstellungen (Art der VMs, Anzahl der VMs, Anzahl der Delegierten) als auch mehrere Abonnements unterstützt. Mehrere Abonnements sind in der Tat ein wichtiger Weg, um mit Azure zu skalieren, sowohl für die Leistung als auch für die Skalierung. Wenn Sie Veranstaltungen durchführen, für die viele hundert VMs benötigt werden, werden Sie schnell feststellen, dass die einfache Ressourcenstruktur, die Sie erhalten, wenn Sie eine VM über das Azure-Portal erstellen, nicht skalierbar ist - Sie stoßen auf die Ressourcenbeschränkungen von Azure pro Abonnement, wie z.B. die Standardbeschränkung von 50 virtuellen Netzwerken. Sie können dieses Limit mit einer Support-Anfrage aufheben lassen, aber es gibt eine harte Grenze von 500, so dass Sie das vereinfachte Modell mit einem VNET pro VM nicht über diesen Punkt hinaus verwenden können (aber es kann auch zu Problemen führen, wenn Sie alle Ihre VMs auf ein einziges VNET setzen). Mit einem sorgfältigen Ressourcendesign können Sie Tausende von VMs in einem einzigen Abonnement erstellen, aber dann stoßen Sie wahrscheinlich auf die API-Ratenbeschränkung von Azure pro Abonnement, die Sie verlangsamen oder sogar dazu führen kann, dass Operationen ganz ausfallen. Daher ist die Unterstützung mehrerer Abonnements bei ausreichend großem Umfang ein Muss.

Auf der einfachsten Ebene möchten wir einer Person für einen bestimmten Zeitraum Zugang (RDP oder SSH) zu einem oder mehreren virtuellen Computern gewähren. In den meisten Szenarien gewähren wir den Delegierten den Zugang über eine benutzerdefinierte E-Mail-Nachricht, die wir mit dem SendGrid-Dienst versenden. Allerdings können die Organisatoren einer Veranstaltung den Delegierten stattdessen die Zugangsdaten aushändigen.

Wir definieren die VM(s), die ein Benutzer erhält, in einer so genannten Bündel-Definition. Ein Bundle definiert eine Reihe von Daten, darunter die empfohlene Größe der Azure-VM, ob die VM über eine öffentliche IP erreichbar sein muss und vieles mehr.

Azure unterstützt zwei Arten von Festplattenlaufwerken (VHDs) für virtuelle Maschinen: Basic und Premium. Der Unterschied ist im Grunde ganz einfach: Premium-Speicher wird von Solid-State-Laufwerken (SSDs) unterstützt. Diese sind zwar langfristig teurer, aber wir haben Optimierungen in Valhalla eingebaut, damit sie nur so lange wie nötig genutzt werden. Sie zahlen nur für die Zeit, in der die VHDs zugewiesen sind. Premium-Speicher kann vor allem bei interaktiven Windows-Sitzungen für mehr Leistung sorgen. Wir unterstützen so ziemlich jede VM, auf die Sie im Rahmen eines Azure-Abonnements Zugriff haben würden.

Walhalla Architektur.

Während Azure Storage für VMs verwendet wird, verwenden wir SQL Database (Microsofts Name für seine Cloud-Version von SQL Server) als unseren wichtigsten Persistenzspeicher für die Verfolgung von Klassen, Ressourcen usw. In früheren Versionen von Valhalla haben wir Azure Table Storage verwendet. Er bot zwar eine gute Leistung und günstigen Speicherplatz, aber das Programmiermodell ließ ein wenig zu wünschen übrig. Wir fanden das traditionellere Datenprogrammierungsmodell in SQL Database produktiver. Wir verwenden SQL Database, um die meisten Daten über das System zu speichern.

Auch hier haben wir im Zuge der Weiterentwicklung von Valhalla die Art und Weise, wie wir mit der Sicherheit umgehen, geändert. Unser ursprüngliches System hatte sein eigenes rollenbasiertes Sicherheitsmodell. Unsere aktuelle Version basiert auf Azure Active Directory. Derzeit wird unser System hauptsächlich von uns selbst und von Kunden genutzt, die Klassen und Veranstaltungen verwalten müssen. Delegierte müssen sich nicht anmelden, um ihre VMs zu nutzen. Die Flexibilität von Azure AD bedeutet jedoch, dass wir andere Azure-Konten, MSAs, Google, Facebook und mehr unterstützen können.

Da es sich um eine Cloud-basierte Lösung handelt, ist die Hauptbenutzeroberfläche des Systems als Azure App Service Web App implementiert. Wir verwenden Slots, um die Bereitstellung neuer Versionen einer Website zu vereinfachen.

Web Jobs verarbeiten lang laufende Anfragen. Jedes Mal, wenn Valhalla etwas in Azure tun muss, sei es das Durchsuchen der Speicherkonten eines Azure-Abonnements nach neu aktualisierten VHD-Images oder das Erstellen von VMs für ein Ereignis über die ARM (Azure Resource Manager) API, läuft diese Arbeit in einem Web Job.

Wir verwenden Redis Cache, um den Web Job in die Lage zu versetzen, den Endbenutzern Fortschrittsbenachrichtigungen für seine lange laufende Arbeit zu liefern. Wir verwenden SignalR, um unsere Webserver in die Lage zu versetzen, Benachrichtigungen an Browser zu senden, und wir verwenden die Redis Cache-Backplane von SignalR, um es unserem Web Job zu ermöglichen, Benachrichtigungen zu generieren, die an den Webserver weitergeleitet werden, der die Verbindung zurück zum jeweiligen Endbenutzer verwaltet. Unter der Haube verwendet dies die pub/sub-Mechanismen von Redis Cache.

Wir verwenden Application Insights hauptsächlich zu Diagnosezwecken. Wenn etwas schief läuft, bietet Application Insights einen sehr guten Überblick - Sie können den Verlauf einer Operation vom Browser eines Endbenutzers bis zur Web-App und dann weiter bis zum Webauftrag verfolgen. Application Insights fängt automatisch alle Vorgänge ab, die Azure Storage oder SQL Azure verwenden. Die Fähigkeit, alle für eine bestimmte Anfrage relevanten Ereignisse zu ermitteln, macht es einfach, einen guten Überblick über alles zu erhalten, was bis zum Ausfall passiert ist.

DevOps

Zu diesem Zeitpunkt ist es ziemlich klar, dass Azure uns eine flexible Plattform für unser System und eine bedarfsgerechte Stromversorgung für unsere Kunden bietet. Da jedoch nur zwei Mitarbeiter das Unternehmen leiten, ist es hilfreich, einen guten DevOps-Prozess zu haben. Donovan Brown von Microsoft sagt gerne, dass "DevOps die Verbindung von Menschen, Prozessen und Produkten ist, um eine kontinuierliche Bereitstellung von Werten für unsere Endbenutzer zu ermöglichen." Ein Vorteil, den wir haben, ist, dass wir zusammen schon seit über fünfzig Jahren Software entwickeln. Und wir sind generell bestrebt, unsere Prozesse nach Bedarf zu ändern, um mit weniger Aufwand mehr zu erreichen, damit wir einen Mehrwert liefern können. Wir haben also die Menschen und die Prozesse gut im Griff (denn wir wissen, dass es eine Reise ist und kein Ziel).

Aus der Produktperspektive sind wir mit den Visual Studio Team Services (VSTS) voll und ganz in der Cloud angekommen. Damals im Jahr 2013 war es nicht ganz offensichtlich, aber wir haben angefangen, unseren Quellcode mit Git-Repos in VSTS zu verwalten. Im Laufe der Zeit hat das flexible Verzweigungsmodell es uns leicht gemacht, über zwei Kontinente und acht Stunden Zeitunterschied verteilt zu arbeiten. Wir verwenden die Scrum-Vorlage mit Product Backlog Items, Tasks und Bugs, um unsere Arbeit zu planen und zu verfolgen. Unsere Sprints dauern in der Regel dreißig Tage.

Natürlich liegt uns die Qualität am Herzen und deshalb haben wir verschiedene automatisierte Qualitätsprüfungen in unseren Prozess eingebaut. Das beginnt mit Unit-Tests, die wir in Visual Studio und während unseres automatisierten Build-Prozesses ausführen. Unser Build-Prozess erzeugt einsatzfähige Pakete und führt eine vollständige Suite von Unit-Tests und Integrationstests durch. Unsere Builds laufen über eine kontinuierliche Integration von Master und allen Feature-Zweigen, was sehr praktisch ist, wenn wir an verschiedenen Features arbeiten.

Unser Veröffentlichungsprozess hat sich im Laufe der Zeit weiterentwickelt, und dies ist ein wichtiger Bereich, um uns voranzubringen. Angesichts unserer verschiedenen Kunden und Ereignisse ist die Aktualisierung unserer Bits in Azure nichts, was wir manuell durchführen möchten. Wir haben die "neue Version" des in VSTS integrierten Release Managements schon früh genutzt und es hat uns gute Dienste geleistet. Wir machen keine typische Pipe-Line-Entwicklung von Dev zu Test zu Prod. In der Regel führen wir viele Implementierungen in einer unserer Entwicklungsumgebungen durch, dann in Testumgebungen und schließlich in der Produktionsumgebung. Der Schlüssel dazu ist, dass wir mehrere Umgebungen für jede Art von Entwicklung haben können. Sie unterscheiden sich nach Zweck und Kunde, aber nicht nach Code. Zusätzlich zu den Bereitstellungsaufgaben, die das Pushen von Änderungen an den Kerndiensten über ARM, die Websites, die Webaufträge sowie die Handhabung von Slot-Swaps umfassen, verwenden wir Selenium, um automatisierte Regressionstests für die Benutzeroberfläche unserer Website durchzuführen. Wir haben eine spezielle Release-Definition für die Durchführung dieser End-to-End-Tests, mit der eine völlig neue Valhalla-Umgebung erstellt wird (mit allen Web-Apps, SQL Server usw., die in einer speziellen Ressourcengruppe bereitgestellt werden), damit wir alle Funktionen auf einem neu bereitgestellten System von Grund auf testen können, und diese Release wird dann abgebaut, wenn alle Tests erfolgreich abgeschlossen sind.

Nebenbei bemerkt verwenden wir Azure Key Vault, um Geheimnisse wie SQL Server-Passwörter und SendGrid-Anmeldeinformationen im Rahmen von DevOps zu verwalten. Auf diese Weise müssen wir keine Geheimnisse in der Versionskontrolle speichern und können sie auch aus unserer Build-Konfiguration heraushalten. (Die ARM-Bereitstellungsaufgabe von VSTS kann die Geheimnisse selbst nachschlagen, wenn sie sie benötigt, indem sie direkt auf den Key Vault zugreift).

Wir verfolgen eine Vielzahl von Daten pro Ereignis, z. B. Nutzer, VM-Zuweisungen usw., zusätzlich zu den Daten, die wir mit Application Insights sammeln. Wir arbeiten auch daran, gemeinsam mit unseren Kunden Nachbesprechungen durchzuführen, um das System zu verbessern. Die Arbeit an neuen Funktionen basiert auf dem Feedback sowie auf unserer Erfahrung bei der Durchführung von großen und kleinen Veranstaltungen. Die größeren Veranstaltungen, wie das Global DevOps Bootcamp, helfen uns, das System für alle Veranstaltungen robuster zu machen.

Gelernte Lektionen

Das Sprichwort sagt: "Es gibt keinen Ort wie die Produktion". Im Laufe der Jahre haben wir durch den Betrieb auf Azure eine Reihe von Dingen gelernt. Eine wichtige Erkenntnis ist, dass mehrere Azure-Abonnements erforderlich sind, wenn Sie in großem Umfang arbeiten möchten, da die Ressourcen und die ARM-API-Rate begrenzt sind. Eine weitere wichtige Erkenntnis ist: Testen, testen, testen. Wiederholbarkeit ist entscheidend. End-to-End-Tests sind besonders wertvoll - unsere Tests des gesamten Systems haben mehr Regressionen abgefangen als alles andere. Und wie immer gilt: Die einzige Konstante ist der Wandel. Azure ist dynamisch und eine fantastische Plattform, auf der wir Lösungen aufbauen können. Es ist erstaunlich, dass wir mehr als 180 Terabyte Speicherplatz nutzen können, 1.500 VMs hochfahren können, die acht Jahre CPU an einem Tag verbrauchen, und sie dann in die Cloud zurückgeben können. Kommen Sie in die Cloud, wir glauben, es wird Ihnen gefallen.

Holen Sie sich Ihr kostenloses Exemplar oder laden Sie das Magazin XPRT.