Bereitstellen einer mit der OutSystems Agile Platform erstellten Anwendung

Lesen Sie die vorherigen Abschnitte der Reihe: Erste Schritte mit der OutSystems Agile Platform, Erlernen der Grundlagen der OutSystems Agile Platform, Beschreiben der OutSystems Agile Platform Service Studio-Erfahrung und Arbeiten mit dem Integration Studio der OutSystems Agile Platform.

Nachdem ich Rat Catcher auf einem bestimmten Funktionsniveau hatte, war es für mich an der Zeit, es an einen öffentlichen Ort zu bringen, damit andere es sehen konnten. Dies bedeutete jedoch, dass es Zeit war, die Anwendung bereitzustellen. Während des gesamten Entwicklungsprozesses hatte ich zu Testzwecken Bereitstellungen auf dem lokalen Server durchgeführt. Ich erzähle Ihnen von meinen Erfahrungen beim Einrichten einer Bereitstellungsumgebung für die öffentliche Beta - insbesondere davon, was ich richtig gemacht habe und wo ich einige Fehler gemacht habe.

Als ich für meinen ersten öffentlichen Einsatz bereit war, habe ich meine Infrastruktur nicht vollständig durchdacht oder in Betracht gezogen. Um ehrlich zu sein, ist meine Staging-Umgebung billig zusammengestellt. Ich habe einen Windows 2008 R2-Server mit sehr geringem Stromverbrauch und einigen kleinen VMs (eine für Team Foundation Server, eine andere als FreeBSD-Mail- / Webserver), der auch als lokaler Dateiserver und für einige kleine als Webserver fungiert Websites und ein Domänencontroller. Um die Ressourcen dieses Servers zu maximieren, habe ich beschlossen, die OutSystems Agile Platform-Komponenten direkt auf dem Server bereitzustellen.

Dies war zwar ein perfekt funktionierendes Setup, aber es passte wirklich nicht sehr gut zu meinen Bedürfnissen. Das größte Problem für mich ist, dass der Agile Platform Server auf der Standard-IIS-Website bereitgestellt werden muss. Wenn dies nach meiner Erfahrung eine Anforderung einer Anwendung ist, sollte der Server für diese Aufgabe reserviert sein, nur für den Fall, dass jemals eine ähnliche Anforderung von einer anderen Anwendung gestellt wird. Das Certificate Authority-System auf einem Windows-Server ist ein gutes Beispiel. Möchte ich mir wirklich Gedanken darüber machen, ob IIS für jedes Verzeichnis gesperrt werden soll, oder ob die Website meiner Zertifizierungsstelle der Außenwelt ausgesetzt ist? Wahrscheinlich nicht. Also habe ich nach Wegen gesucht, um diese Anforderung zu vermeiden. Am Ende des Tages, als ich es (etwas) zum Laufen brachte, war ich mit den Ergebnissen nicht zufrieden. Ich mag es einfach nicht, meine Systeme zu bekämpfen - es führt immer zu Problemen auf der Straße.

Daher habe ich mich verpflichtet, eine andere VM auf dem Server einzurichten. Diese VM ist mein Agile Platform-Server. Wenn Sie die Agile Platform noch nie zuvor auf einem Windows-Server bereitgestellt haben, machen Sie sich keine Sorgen ... das Installationsprogramm erledigt alles für Sie, genau wie auf dem Desktop. Eine Sache, die mir an der Agile Platform in Version 4 nicht gefallen hat, war, dass die Installation etwas schwierig war. Das Team hat mit Version 5 hervorragende Arbeit geleistet und die Installation reibungslos und einfach gestaltet. Ich begann mit einer Barebones 2008 R2-Installation, bei der ich sie lediglich der Domäne hinzufügen, die Netzwerkkarte konfigurieren und mit Patches auf den neuesten Stand bringen musste. Das Installationsprogramm für Agile Platform fügt sogar die erforderlichen Windows-Rollen und -Dienste wie IIS hinzu.

Nachdem ich die VM eingerichtet hatte, brauchte ich eine Möglichkeit, meinen Webdatenverkehr darauf zu leiten. In meinem aktuellen Szenario habe ich nur eine statische öffentliche IP-Adresse, die ich an meinen Domänencontroller / physischen VM-Host weitergeleitet habe. Ich habe auf dem Server eine Website erstellt, die an die DNS-Namen gebunden ist, die ich für meinen Betatest verwende. Anschließend habe ich das IIS URL Rewrite-Modul verwendet, um den Datenverkehr zur VM zu leiten und einen Reverse-Proxy zu erstellen ( Abbildung A ). Sie können die Konfiguration sehen, die ich im Screenshot verwendet habe (lofn-ratcatcher.titaniumcrowbar.com ist ein vollqualifizierter Domänenname, auf den die VM antwortet und der auf dem Server an "Standardwebsite" gebunden ist). Der gesamte Prozess hat mich weniger als 10 Minuten gekostet. Abbildung A.

Die eingehende Regel für das URL-Rewrite-Modul ist erforderlich, um den Datenverkehr auf meine VM umzuleiten. (Klicken Sie auf das Bild, um es zu vergrößern.)

Nachdem ich die VM eingerichtet hatte, war es Zeit, sie zu testen und für die Verwendung zu konfigurieren. Ich habe meinen Browser auf die Adresse für das Service Center (http://fqdn.server.name/ServiceCenter) verwiesen und voila wurde sie wie erwartet angezeigt . Dies bestätigte, dass meine Installation und meine Umleitung ordnungsgemäß funktionierten. Ich habe sofort meine Erstkonfiguration des Service Centers durchgeführt:

  • Servername
  • E-Mail-Konfiguration
  • Ändern Sie das Administratorkennwort
Als nächstes wollte ich sicherstellen, dass externe Besucher nicht auf das Service Center zugreifen können. Ist das Service Center sicher? Sicher ist es - sobald Sie das Administratorkennwort ändern. Gleichzeitig ist es eine solide Sicherheit, jemanden, der niemals Zugang zu etwas haben sollte, daran zu hindern, es überhaupt zu versuchen. Nochmals, URL zur Rettung neu schreiben. Ich habe eine neue Regel erstellt ( Abbildung B ) und sie dann nach oben verschoben, um Vorrang vor der ersten Regel zu haben, die ich erstellt habe. Da auf den Server intern unter einem anderen Namen als extern zugegriffen werden kann, kann ich weiterhin über den internen Namen des Servers auf das Service Center zugreifen. Ein weiterer schneller Test zeigt, dass wir nicht über den externen vollqualifizierten Domänennamen auf das Service Center zugreifen können, sondern über den internen vollqualifizierten Domänennamen. Abbildung B.

URL Rewrite-Regel zum Blockieren des Zugriffs auf das Service Center. (Klicken Sie auf das Bild, um es zu vergrößern.)
Es gibt einen anderen Weg, um dieses Problem anzugehen. In Service Studio können Sie einen bestimmten Bildschirm so definieren, dass er nur intern zugänglich ist. Tatsächlich ist das gesamte Service Center so eingerichtet, dass es intern zugänglich ist. Wenn Sie auf dem Server, auf dem die Bereitstellung erfolgen soll, zu Ihrem Startmenü gehen, finden Sie das Konfigurationstool. Von dort aus können Sie Adressen (oder einen Adressbereich) Ihres internen Netzwerks festlegen ( Abbildung C ). Sobald dies festgelegt ist, werden alle Anfragen von außerhalb dieses Bereichs an intern eingeschränkte Bereiche (einschließlich des gesamten Service Centers) blockiert. Dies funktioniert in meinem aktuellen Szenario nicht gut, da bei der Umleitung alle Anforderungen an den Plattformserver scheinbar vom Reverse-Proxy-Server stammen. Daher müsste ich mein gesamtes Netzwerk mit Ausnahme eines Servers in meinen internen Bereich aufnehmen. Letztendlich denke ich, dass es für meine spezielle Konfiguration einfacher ist, einfach beim Blockieren am Reverse-Proxy zu bleiben. Abbildung C.

Das Agile Platform Configuration Tool. (Klicken Sie auf das Bild, um es zu vergrößern.)

Nachdem das Server-Setup abgeschlossen war, war es Zeit, Rat Catcher auf dem neuen Server bereitzustellen. In Service Studio habe ich auf die Schaltfläche für Mit Server verbinden geklickt und den internen FQDN des Servers sowie den Benutzernamen und das Kennwort des Administrators eingegeben. Aber ich wurde dann mit einem neuen Problem konfrontiert: fehlende Referenzen. Das Service Studio-Projekt enthält den Code für die Anwendung selbst, jedoch nicht für die erforderlichen Erweiterungen. Einige der Referenzen, die ich benötigte, stammten von Komponenten, die aus dem Agile Network heruntergeladen wurden, und einige wurden von mir selbst im Integration Studio geschrieben. Ich habe die Dateien erneut aus dem Agile Network heruntergeladen und sie dann in Integration Studio geöffnet, um sie auf dem neuen Server zu veröffentlichen. (Ich hätte sie vom Service Center auf meinem lokalen Computer herunterladen können.) Ich habe auch meine Erweiterungen auf dem neuen Server veröffentlicht. Nachdem ich dies getan hatte, konnte ich zu Service Studio zurückkehren und Rat Catcher auf der neuen Plattform veröffentlichen.

So habe ich meine erste Bereitstellung durchgeführt, aber es stellt sich heraus, dass es eine viel bessere Möglichkeit gibt, Bereitstellungen zu handhaben. Im Service Center können Sie eine neue Lösung definieren, deren Abhängigkeiten automatisch für Sie berechnet werden. Sobald eine Lösung erstellt wurde, können Sie sie veröffentlichen, damit sie live auf dem Server ausgeführt werden kann. Dadurch wird die Versionierung durchgeführt, sodass Sie bei Bedarf Rollbacks durchführen können. Darüber hinaus können Sie die gesamte Lösung (einschließlich aller Abhängigkeiten) als OSP-Datei herunterladen, um sie auf anderen Servern bereitzustellen. Auf diese Weise erhalten Sie diskrete Versionen, die problemlos auf anderen Systemen bereitgestellt werden können, ohne dass Sie sich darum kümmern müssen, die Abhängigkeitsbäume auf dem neuesten Stand zu halten. Bei Bedarf kann die OSP-Datei entpackt und ihre Teile überprüft werden.

Nun der letzte Test ... Öffnen von Rat Catcher mit dem externen FQDN. Und siehe da, Rat Catcher steht jetzt der Öffentlichkeit zum Testen zur Verfügung ( Abbildung D ). Bitte probieren Sie es aus und teilen Sie mir Ihre Meinung mit. Ich habe noch viel zu tun; Zum einen muss ich einen Zahlungsprozessor in das System integrieren, und ich muss wirklich die Seiten auffrischen, wie Sie sehen können. Abbildung D.

Rattenfänger lebt und ist bereit für die Welt, es auszuprobieren. (Klicken Sie auf das Bild, um es zu vergrößern.)

Dies ist ein Anfang, und dank der Agile-Plattform ging es in sehr kurzer Zeit, gemessen an den Arbeitsstunden, von einer Idee im Hinterkopf zur öffentlichen Beta über (gemessen als Nacht- und Wochenendprojekt dauerte es noch eine Weile Blick auf den Kalender).

In der nächsten Folge der Serie werde ich einige der Arbeiten besprechen, die ich ausführen musste, um diese Anwendung für die Hauptsendezeit vorzubereiten.

J.Ja.

Offenlegung von Justins Branchenzugehörigkeiten: Justin James hat einen Vertrag mit Spiceworks abgeschlossen, um Produktkaufhandbücher zu schreiben. Er hat einen Vertrag mit OpenAmplify, das Hapax gehört, über das Schreiben einer Reihe von Blogs, Tutorials und Artikeln. und er hat einen Vertrag mit OutSystems, um Artikel, Beispielcode usw. zu schreiben.

-------------------------------------------------- -------------------------------------

Erhalten Sie wöchentliche Entwicklungstipps in Ihrem Posteingang Halten Sie Ihre Entwicklerfähigkeiten auf dem neuesten Stand, indem Sie sich für den kostenlosen Web Developer-Newsletter von TechRepublic anmelden, der jeden Dienstag zugestellt wird. Melden Sie sich noch heute automatisch an!

© Copyright 2020 | mobilegn.com