Ein ECUI Operator kann/muss
neue ECUI Installationen vornehmen, verwalten und (neue) DNS Einträge organisieren
den laufenden Betrieb sicher stellen und zukünftige Probleme möglichst frühzeitig erkennen
Regelmässige Aufgaben
Organisatorisches
Zertifikatsgültigkeiten überwachen
Kosten und Zahlung Dienste überwachen
Koordination gehostete Dienste (was neu, was löschen?)
Zuweisung von Rechten auf Umgebungen und Dienste
Technisches
Überwachung der Applikationen von aussen [laufend]
Zum Beispiel über Healthcheck mit OK/NOK und Messung der Antwortzeit des Healthcheck
Alerts in Azure oder externen Monitoring-Tools einrichten
Überwachung Backup von Datenbanken [Intervall]
Zum Beispiel überprüfen dass die Backups vorhanden sind
Zum Beispiel Restore-Test
Überwachung Auslastung Dienste (CPU, Memory, verwendete “Slots” falls an gewissen Orten beschränkt) [laufend]
Zum Beispiel über Azure Dashboard von App Service Plan und App Service Instanzen
Überwachung der Applikation von innen (Inhalt)
Zum Beispiel im PerformX Connector schauen ob alle Syncs in Ordnung sind
Überwachung von Fehlerhäufigkeiten und -Arten
Zum Beispiel App Insights Failures überprüfen - neue Fehler, viele Fehler?
Planung / Zukunft / Strategie
Entwicklungen erkennen und Ausbauten resp. Änderungen planen
Verteilung der DEV / TEST / PROD Instanzen auf App Service Pläne
Setup Aufgaben
App Service erstellen
Neuen Azure App Service im bestehenden App Service Plan erstellen
Stack: .Net
.Net Version: .Net Core (3.1, 2.1)
Platform: 32 Bit
Application Insights
aktivieren (geht je nach Berechtigung erst nachdem der “Create” Wizard durchgelaufen ist)
Settings / Configuration - General Settings
HTTP Version 2.0 einschalten
FTP State: FTPS only aktivieren
Settings / Configuration - Application Settings
Neues "Application Setting" mit dem Namen "WEBSITE_TIME_ZONE" und dem Wert "W. Europe Standard Time" erfassen (das setzt dir richtige Time-Zone für den App Service. Sonst ist immer UTC aktiv)
Neuen Connection String erfassen. Je nach Datenbank ist das "SqlServer" oder "SqlAnywhere".
SqlAnywhere: Compression sollte zur Reduktion der Daten immer aktiviert werden
SqlServer: Die Einstellung MultipleActiveResultSets=True muss gesetzt werden.
Settings / TLS/SSL Settings
HTTPS only: On (aktiviert die automatische Weiterleitung von http://… auf https://…)
Minimum TLS Version: 1.2
Monitoring / Health Check
Das Feature enablen, in Pfad "/api/v1/application/healthcheck" eintragen und dann speichern.
Monitoring / Alerts [noch nicht aktuell]
E-Mail Alert auf den Health Check einrichten
Deployment der eigentlichen Applikation einrichten (durch Encodo)
Jetzt sollte die Applikation laufen. Manchmal braucht es nach dem ersten Deployment einen Restart des App Service und dann etwas Geduld, weil die Applikation beim ersten Start unter Umständen noch Daten generieren muss bevor sie verfügbar ist.
App Service löschen
Ein App Service kann in der Overview einfach gelöscht werden. Falls ein App Service mit hinzugefügten Domain Names ersatzlos gelöscht wird, dann sollten diese Domain Names im entsprechenden DNS auch entfernt werden. Sonst wird die URL weiterhin aufgelöst, aber dem User nichts mehr angezeigt weil der App Service nicht mehr da ist.
Neben dem eigentlichen App Service sollte auch die dazugehörige Application Insights Instanz gelöscht werden. Dieser Schritt muss manuell erfolgen.
Domain Namen in Azure verwalten
Domain Namen erstellen
Zertifikat im PFX-Format besorgen
ACHTUNG: Das .pfx File sollte nicht per E-Mail übertragen werden. Am besten per geschütztem File-Share weiter geben.
ACHTUNG: Das Passwort für das Zertifikat nie auf dem gleichen Kanal(und auch nicht per E-Mail) übertragen.Zertifikat in Azure hochladen
In https://portal.azure.com einloggen
In einen der "Web Portals" App Services wechseln
Unter "TLS/SSL Settings" auf den Tab "Private Key Certificate (.pfx)" wechseln
Per "+ Upload Certificate" das Zertifikat hochladen (das Passwort muss dabei angegeben werden)
Eine Custom-Domain erstellen
Unter "Custom Domains" mit "+ Add custom domain" eine neue Custom Domain erfassen (also z.B. test.member.aeroclub.ch) und dann "Validate" auswählen. Es folgen dann Instruktionen (-> Domain Ownership) für die nötigen DNS Änderungen, die vom DNS Administrator gemacht werden müssen.
Erst wenn die DNS Änderungen vollständig gemacht sind (also TXT + CNAME eingetragen), kann die Custom Domain angefügt werden.
TLS/SSL Einstellungen für App Service machen:
Unter "TLS/SSL settings" nun noch per "+" die neue Custom Domain mit der App verbinden. Dabei muss die Custom Domain, das Zertifikat und der "TLS/SSL Type" ausgewählt werden (-> Immer SNI wählen da das keine Kosten generiert)
Nach dem Bestätigen per "Add Binding" ist die Custom-Domain fertig eingerichtet
Domain Namen löschen
In Azure kann unter “Custom Domain” auf dem zu löschenden Eintrag per “…” Menueintrag die Funktion “Remove Custom Domain” ausgewählt werden. Falls die Domain nicht auf einem anderen App Service wieder zum Einsatz kommt, sollte diese auch aus dem entsprechenden DNS Server gelöscht werden.
Zertifikate überprüfen und updaten
Seit Herbst 2020 sind Zertifikate fürs Web maximal 12 Monate gültig. Darum müssen diese Zertifikate alle 12 Monate erneuert werden. Ohne die Erneuerung können User nicht mehr auf die Applikation zugreifen.
Es ist deshalb wichtig, die Zertifikat-Laufzeiten entsprechend zu verwalten und frühzeitig mit dem Ersatz eines Zertifikats zu beginnen. Dazu entweder Termine setzen und/oder regelmässig die Liste der Zertifikate unter “TLS/SSL Settings” auf einem App Service (die Liste ist bei allen App Service Instanzen eines Plans die gleiche) auf dem Tab “Private key Certificates (.pfx)” die Liste der Zertifikate anschauen gehen. Zertifikate, die kurz vor dem Aublauf stehen werden mit einem “Warnung” Icon markiert.
Neues Zertifikat im PFX Format besorgen und dieses in Azure hochladen (siehe “Domain Namen erstellen“)
Unter “SSL/TLS Settings” den zu erneuernden Eintrag doppelklicken (unter “…” ist nur der Remove erreichbar) und das neue Zertifikat zuweisen. Hier kann nur mit dem Thumbprint des Zertifikats unterschieden werden, welches das aktuelle und welches das neue ist. Diese Anpassung muss für jeden einzelnen der gebundenen Domain Names gemacht werden.
Das alte Zertifikat kann jetzt aus der Liste der Zertifikate gelöscht werden. Falls noch ein Domain Name auf dieses Zertifikat gebunden ist, dann funktioniert das Löschen nicht. Azure sagt aber nicht welcher Domain Name betroffen ist. Also ist Suchen angesagt.
DNS Server Administration
Änderungen am DNS Server müssen immer von der Person/Firma gemacht werden, welche die Domain besitzt resp. welche diese im Auftrag des Besitzers verwaltet. Dies ist meist der Endkunde resp. dessen IT-Partner. Wenn z.B. der Name “portal.mydomain.ch” eingetragen werden muss, dann braucht es im DNS die folgenden beiden Einträge:
Type | Host | Value |
---|---|---|
TXT | <String aus der Azure Domain Erfassung> | |
CNAME | portal.mydomain.ch |
ACHTUNG: Wenn ein DNS Eintrag nicht neu, sondern umgestellt worden ist, dann dauert es eine Weile bis dieser Eintrag überall verfügbar und somit aktiv ist. Diese “Weile” hängt von den individuellen Einstellungen im DNS Server ab und kann von Sekunden bis zu Tage dauern. Um zu testen lohnt es sich in einem solchen Fall mit einem Gerät zu testen, welches den geänderten Namen in den letzten Tagen noch nicht aufgelöst hat. Nach einem erfolglosen Test ist das Gerät dann aber für weitere Tests nutzlos, weil die Namensauflösung auch auf dem Gerät resp. auch auf dem angefragten DNS Server gecacht wird. Alternativ können auch
Kommandozeilen-Tools wie “nslookup” mit externen DNS Servern
Webseiten wie https://dnschecker.org
verwendet werden. Das sind dann aber eher Optionen für fortgeschrittene Operators.
E-Mails aus App-Service versenden
Damit ein App-Service E-Mails versenden kann benötigen wir die detaillierten Angaben zu einem SMTP Server der von Azure aus erreichbar ist. Soll aus einem App-Service eine E-Mail versendet werden, dann wird eine Verbindung zum SMTP Server geöffnet und ein Login mit dem angegebenen User/Passwort gemacht. Erst dann wird die E-Mail mit einem ebenfalls konfigurierbaren Absender versendet.
Es können gemäss Microsoft von Azure aus keine E-Mails über Google Accounts versendet werden. Und bei Office 365 Accounts gibt es Limiten zur Anzahl Mails pro Zeiteinheit. Details können dem folgenden Link im Kapitel “Sending Limits” entnommen werden: https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#receiving-and-sending-limits. Aktuell max. 10’000 Mails und max. 1000 Empfänger pro Tag, max. 30 Mails pro Minute.
Hier die benötigten Informationen für die Einrichtung:
Einstellung | Erläuterung | Beispiel |
---|---|---|
SMTP Server Adresse | Der Name unter welchem der SMTP Server übers Internet erreichbar ist. | smtp.somedomain.ch |
Server Port | TCP Port auf welchem der SMTP Server eingerichtet ist und übers Internet angesprochen werden kann. | Ohne SSL meist 25, |
SSL für Verbindung nötig? | Definiert ob der SMTP Server auf dem Port per SSL/TLS kommunizieren kann. Falls vorhanden sollte diese Option immer benutzt werden. | Ja |
Username | Name eine Users, der sich beim SMTP Server einloggen kann und E-Mails versenden darf. | |
Passwort | Das Passwort für den obigen Usernamen |
Zusätzlich zu den obigen Angaben sind folgende Punkte wichtig:
Der User solle keine Restriktionen bezüglich der Anzahl versendeter E-Mails pro Zeiteinheit haben da es sonst in Phasen mit hoher Aktivität (z.B. bei der Ersteinrichtung von Usern) zu Fehlern beim Versenden von vielen E-Mails kommt.
Server/Port müssen vom Internet aus erreichbar sein. Es ist grundsätzlich möglich, auf eine IP-Adresse des App-Service (resp. eine Liste von davon) einzuschränken, aber nicht empfohlen da die IP-Adresse ändern kann.
Bei allen Veränderungen beim Zugang zum E-Mail Server muss verhindert werden, dass der Server so offen wird, dass er auch für Fremde ohne Passwort zum Versand von E-Mails verwendet werden kann. Falls dies passiert, geht es nicht lange und der E-Mail Server wird für die Versand von SPAM missbraucht und er landet darum auf einer oder mehreren Blacklist(s). Dann werden andere E-Mail Server die Zusammenarbeit mit dem Server verweigern und das betroffene E-Mail System ist faktisch unbrauchbar. Von solchen Blacklists wieder runter zu kommen dauert und verursacht Arbeit.
Verbindungstests
Bevor eine Mail Server Konfiguration im App-Service vorgenommen wird, kann wie folgt geprüft werden ob die Verbindung grundsätzlich aufgebaut werden kann. Das spart Zeit und ev. App-Service Restarts. Wir unterscheiden dabei zwei Situationen:
Server ist vom Internet her offen: Auf der Kommandozeile kann per “telnet <name_des_servers> <port>” geprüft werden ob eine Verbindung grundsätzlich möglich ist (telnet muss ev. aus den Windows-Features zuerst noch installiert werden). Falls die Verbindung per Telnet nicht geht, dann hat auch der App-Service keine Chance.
Server ist nur für Azure IP-Adresse offen: In Azure den entsprechenden App-Service öffnen, dann unter dem Menupunkt “Development Tools” die “Console” öffnen. In der Konsole kann dann per “tcpping <name_des_servers>:<port>” geprüft werden ob eine TCP Verbindung aufgebaut werden kann. Falls das nicht geht, dann kann es der App-Service auch nicht.
Diese Variante kann auch zur Prüfung des ersten Falls verwendet werden, ist aber etwas aufwendiger wenn man das Azure Portal nicht schon offen hat.
Versandprobleme
Probleme beim E-Mail Versand können die verschiedensten Ursachen haben.
Wenn noch nie eine E-Mail erfolgreich versendet werden konnte, dann liegt die Ursache meist an den Konfigurations-Einstellungen. Die Komponente für den E-Mail Versand unterstützt verschiedene Einstellungen um auch “schwierige” E-Mail Server (z.B. On-Premise Exchange-Server) anbinden zu können. Da diese Einstellungen aber sehr technischer Natur sind, sollten diese von Encodo vorgenommen werden.
Wenn plötzlich keine E-Mail mehr versendet werden kann, dann ist es oft so, dass der User gelöscht, gesperrt oder sein Passwort verändert worden ist. Eine andere Möglichkeit ist es auch, dass der Versand gesetzte im Server gesetzte oder vorhandene Limiten überschritten hat und darum keine E-Mails mehr versendet werden.