App-Readiness

Aus ScaleIT Industrie 4.0 Wiki

Die ScaleIT App-Readiness beschreibt, welche Anforderungen eine Software erfüllen muss, damit sie eine ScaleIT-App wird.

App-Ökosystembetreiber achten darauf, dass nur ScaleIT-Apps in deren App-Pools stehen. Nur so ist sichergestellt, dass Apps auf allen ScaleIT-Plattformen ausgeführt werden und Betriebsprozesse (Installation, Upgrade, Löschen, ...) funktionieren können.

Bei der ScaleIT App-Readiness wird unterschieden in

  • MUSS: Zwingende Anforderungen
  • SOLL: Empfehlungen
  • KANN: Erläuternde Hinweise für die App-Entwicklung

Architektur

Betriebsumgebungen = ScaleIT App-Runtime-Environments (SARE)

Die Betriebsumgebungen einer App werden als ScaleIT App-Runtime-Environments (SARE) bezeichnet. SAREs sind immer Docker-basiert.

Folgende Betriebsumgebungen sind definiert:

  • ScaleIT Rancher 1.6
  • ScaleIT Docker-Compose
  • ScaleIT Kubernetes

Eine ScaleIT-App

  • MUSS die AEE ScaleIT-Rancher 1.6 unterstützen
  • SOLL die AEE ScaleIT-Docker-Compose unterstützen
  • KANN die AEE ScaleIT-Kubernetes unterstützen

Anforderungen an eine ScaleIT-App?

Eine ScaleIT-App

  • MUSS Docker-basiert sein
  • KANN aus einem oder mehreren Docker-Containern bestehen.

Die App SOLL self-contained sein, d.h. sie sollte nach der Installation isoliert lauffähig sein. Wenn sie externe Ressourcen benötigt (z.B. eine Datenbank), soll diese in der App enthalten sein. Die Datenbank soll bei der Installation konfigurierbar sein, so dass eine andere Datenbank (z.B. aus Datensicherungsgründen) verwendet werden kann.

In jeder ScaleIT-Plattform sind folgende Dienste verfügbar, die eine App nicht selber enthalten muss:

  • MQTT-Broker (Ports 1883/1884)
  • Verzeichnisdienst ETCD (Port 49501)

Der MQTT-Broker und der Verzeichnisdienst müssen bei der Installation konfigurierbar sein (IP-Adresse/Hostname, Port).

Für die Nutzung dieser Services in einer App gilt (MUSS):

  • ScaleIT Messaging mit Mqtt
  • ScaleIT Directory-Services mit ETCD

Generelle Anforderungen an eine ScaleIT App

Eine App SOLL möglichst unabhängig von anderen Apps installier- und benutzbar sein. Das bedeutet, dass sie alle Ressourcen mitbringen soll, sofern möglich (außer den in ScaleIT vorhandenen Services).

Eine App SOLL Upgrade-fähig sein. Das bedeutet, dass Daten in VOLUMES (z.B. Datenbanken-Dateien) bei Upgrades migriert werden müssen. Nach einem Upgrade MUSS die Datenbankmigration ohne Benutzer-Eingriff durchgeführt werden.

Eine App SOLL eine Hilfe/Info-Seite bieten, die alle Informationen zur Benutzung der App darstellt, also auch API, Support-Kontakt des App-Herstellers, ScaleIT-Messageing-Informationen (Welche MQTT-Messages werden von der App versendet), etc.

Wenn eine App im Enterprise- oder Community-App-Pool aufgenommen werden soll, MUSS sie (auch ohne Lizensierungsinformationen) nach der Installation startbar sein. Die App kann in einem eingeschräünkten Modus gestartet werden. Weitere Informationen zur App-Lizensierung...

Der ScaleIT App-Name

Ein App-Name MUSS das Format <tld-unternehmen-appkurzname> haben.

  • tld: Top-Level-Domain, z.B. de, com
  • unternehmen: Unternehmensname: Kleinbuchstaben, ab 2.Stelle mit Zahlen, z.B. saegezahnmueller
  • appbezeichnung: Kurzname der App, z.B. wartungsoptimierung, pacman

Beispiel gültiger App-Namen:

de-ondics-pacman
de-ondics-simulation2
de-bigcompany1-app23
de-companyx-maschine1-sps

Verzeichnisstrukur einer ScaleIT App

Folgende Verzeichnis-Struktur MUSS in der App bestehen:

01      <app_name>
02      ├── docker-compose.yml
03      ├── README.md
04      ├── DomainSoftware/
05      | ├── <app-container-1>/
06      |   ├── Dockerfile
07      |   └── ...
08      ├── Resources/
09      ├── Documentation/
10        ├── AppRuntimeEnvironments/
11          └── ScaleITRancher1.6/
12            └── <app-name>/
13              ├── README.md
14              ├── config.yml
15              └── 0
16                ├── docker-compose.yml
17                ├── rancher-compose.yml
18                └── README.md

Wenn eine App das SARE ScaleIT-Docker-Compose unterstützt, MUSS folgendes Verzeichnis aufgenommen werden:

50          └── ScaleIT-Docker-Compose/
51            └── docker-compose.yml

Wenn eine App Sidecars hat, MUSS folgendes Verzeichnis dazukommen:

61      <app_name>
62      └── Platform Sidecars/ 
63      . ├── <sidecar-container-1>/
64      . | ├── Dockerfile
65      . | └── ...
66      . └── SidecarContainer2/
67      . . └── Dockerfile

App-Icons

Eine App braucht Icons an verschiedenen Stellen (z.B. für Rancher-Catalog, für Launchpad über ETCD).

Grundsätzlich gelten die gleichen Anforderungen wie für Apple-iOS-Icons:

https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/app-icon/

Ergänzend gilt bei ScaleIT folgendes:

  • Größe: 512px x 512px
  • Umgebender Hintergrund (außerhalb abgerundeter Ecken): transparent
  • Eckenrundung ist einzubauen (wird nicht durch CSS erledigt wie bei Apple

Beispiel für ein App-Logo in Inscape svg / png:

App-Icon

Benutzeroberfläche/User Interface (UI) und Schnittstellen

Eine ScaleIT-App MUSS ein Web-UI haben.

Es KANN mehrere Web-UI's haben (z.B. ein Sidecar-UI oder ein Dokumentations-UI)

Checkliste für ScaleIT Web-UI's. Eine App SOLL

  • ein Favicon haben
  • responsive sein (Unterstützung Tablet- und Smartphone-Displays)
  • farblich unaufgeregt sein, Information soll dominieren
  • einfach zu benutzen sein (ohne Handbuch)

Docker-Images

Ein ScaleIT Docker-Image soll

  • klein sein (Empfehlung: Alpine basiert)
  • selber erstellt werden. Wenn eine Erstellung nicht möglich/sinnvoll ist und Dockerfiles auf Images von Dritten basieren, MÜSSEN die zugrundeliegenden Docker-Images auf Virenfreiheit und Integrität geprüft werden)
  • stateless sein. Daten, die Neustarts/Upgrades überstehen sollen, MÜSSEN als docker-compose Volume angelegt werden

Rancher 1.6 Integration

Eine ScaleIT-Apps MUSS in der Umgebung Rancher 1.6 laufen.

Rancher-Catalog

Eine ScaleIT-App MUSS ein Rancher-Template unter dem Namen der App anlegen.

Offizielle Dokumentation zu privaten Rancher-Catalogs

Hinweis zu App-Kategorien: Im Launchpad wird die App-Kategorie "coreApp" ausgeblendet.

Networking einer App

Zugriff von außerhalb der ScaleIT-Plattform auf Apps

Eine ScaleIT-App KANN Schnittstellen nach "außen" haben, z.B. ein oder mehrere Web-UIs, REST-APIs, etc.

In Produktion wird auf diese Schnittstellen normalerweise von außerhalb der ScaleIT-Plattform zugegriffen (z.B. per Web-Browsern von Arbeitsplätzen).

ScaleIT Core Enterprise-Edition: Hierzu gibt es den https-Proxy, der nach außen alle Schnittstellen über http/https (Port 80/443) anbietet und intern auf die Apps unter deren Rancher-Netzwerknamen zugreift.

Networking innerhalb einer App (zwischen Container/Services)

Innerhalb einer App kann ein (Docker-Compose-)Service über seinen Namen aufgerufen werden.

Beispiel: aus dem Container/Service de-ondics-pacman-app kann auf den Container/Service de-ondics-pacman-db zugegriffen werden:

$ ping de-ondics-pacman

Networking zwischen Apps

Innerhalb Rancher kann auf einen Service einer anderen App (eines anderen Rancher-Stacks) so zugegriffen werden: <service_name>.<appname>:

$ ping de-ondics-pacman-db.de-ondics-pacman

Weitere Infos zum Rancher-Nerworking zwischen Stacks/ScaleIT-Apps

Networking zu Entwicklungszwecken

Die Web-UIs und Schnittstellen SOLLEN über TCP/IP-Ports in der App erreichbar sein.

Grund: Zu Entwicklungszwecken können so mehrere Web-Services parallel aufgerufen und getestet werden (z.B. UI der App, UI des Sidecars, REST-API). Im Betrieb auf einer ScaleIT-Plattform wird die App dann in der Regel über einen https-Proxy über Port 80 aufgerufen und die speziellen Ports werden nicht mehr benötigt. Das wird durch ein entsprechendes docker-compose.yml im Rancher-Template konfiguriert.

Falls ein Port auch in Produktion verwendet werden soll, MUSS dieser über alle ScaleIT App-Ökosysteme hinweg eindeutig sein.

Liste von Ports, die App-Herstellern zugewiesen wurden




Die App-API

Eine App kann eine API haben, um sie digital anzuzapfen, z.B. von anderen Apps oder von außen.

In der App-Registry MUSS die API als <api-endpoint> bekannt gegeben werden:

   apiUrl: http://.../api

Damit eine externe App die API-Endpunkte abfragen kann, gibt es eine Meta-API:

Diese Meta-API ist erreichbar unter <api-endpoint>/meta

Dort wird ein JSON zurückgegeben mit den API-Funktionen in der app, z.B.

   {
       "status": {
           "endpoint": "/status.json",
           "description": "Status der App",
           "type": "json",
           "$schema": "/status-schema.json" 
       },
       "manual": {
           "endpoint": "/manual.pdf",
           "description": "Handbuch zur App",
           "type": "file",
       }
   }

Achtung: die API beginnt immer mit dem API-Endpunkt. Wenn eine API-Funktion mit Hilfe eines anderen Stacks relaisiert werden soll, muss der API-Endpoint die http-Proxy-Funktion übernehmen




App-Sicherheit

ScaleIT-Nutzer wollen sich darauf verlassen, dass Apps "sicher" sind.

Sicherheit wird in ScaleIT durch Regelungen auf verschiedenen Ebenen erreicht.

Die Betriebssicherheit ist neben der ScaleIT-Plattform und den genuttzen Apps auch abhängig von der Konfiguration der Apps. Diese kann nicht vom App-Ökosystemanbieter sichergestellt werden, sondern nur vom Kunden selber. Vor Inbetriebnahme muss sich der Kunde von der Betriebssicherheit, z.B. durch entsprechende Tests, versichern.

Sicherheit in der ScaleIT-Plattform

Eine App kann nur sicher sein, wenn die Hardware und Software, die zum Betrieb der App benötigt wird, ebenfalls sicher ist. Hierzu zählen folgende Komponenten:

  • Betriebssystem in Verbindung mit der Hadrware
  • Docker als Container-Technologie
  • Rancher als Orchestrierungs-Tool
  • Die ScaleIT-Basis-Komponenten ETCD, MQTT, LaunchPad

Sicherheit in diesen ScaleIT Komponenten wird erreicht durch:

  • Offenheit: Diese ScaleIT Komponenten sind als Open Source veröffentlicht. Mehr zur Sicherheit von Open Source Software gibt es beim BSI.
  • Zertifizierung: Der App-Ökosystemnbetreiber bietet nur Apps im App-Pool / App-Store an, die "sicher" sind
  • Transparenz des App-Entwicklers: Der Entwickler einer im App-Pool angebotenen App wird im App-Pool angegeben. Er muss dem App-Ökosystemanbieter vertraglich die Sicherheit seiner Apps zusichern. Der Kunde kann vor Installation einer App bei Bedarf Direktkontakt zum Entwickler aufnehmen
  • Transparenz der App-Sicherheitsvorgaben: Die Anforderungen an Apps sind öffentlich zugänglich und können vom Kunde eingesehen und ggf. auf Kompatibilität mit den eigenen Anforderungen hin geprüft werden

Zusätzliche Sicherheitsmerkmale der ScaleIT Core Enterprise Edition

  • Technische Sicherheit: Die Kommunikation zwischen ScaleIT Apps und dem Endgerät (i.d.R. ein Web-Browser) wird per https abgesichert. Die Zertifikate sind mit der Auslieferung selbstsignisert. Sie können bei geeigneter Wahl von dem DNS-Namen durch offizielle Zertifikate ersetzt werden.
  • Zugriffsschutz: Vor Benutzung einer App muss sich ein Benutzer anmelden. Diese Funktion wird mit der SSO (Single-Sign-On) Funktion realisiert.

Sicherheitsvorgaben für App-Entwickler

ScaleIT App-Entwickler müssen folgende Sicherheitsanforderungen an Ihre Apps berücksichtigen:

  • Grundsätzlich SOLL eine App keine Ports nach "außen" öffnen
  • Wenn eine App einen Port nach "außen" öffnet, MUSS die Port-Nummer mit dem App-Ökosystemanbieter abgestimmt werden
  • Eine App MUSS die von ihr benötigten HTML-Web-Assets (CSS, JS, Images) selber zur Verfügung stellen. Das Laden solcher Assets aus dem Internet muss unterbleiben
  • Eine App DARF NICHT im Docker-priviledged Modus ausgeführt werden
  • Eine App MUSS im Netzwerk des Kunden so wenig wie möglich kommunizieren und vor Installation kenntlich machen, welcher Netzwerkverkehr von der App ausgeht oder wie die App im Netzwerk teilnimmt
  • Eine App DARF NICHT ohne explizite Erlaubnis des Kunden mit externen (Internet-)Systemen kommunizieren
  • Eine App SOLL sicherheitskritische Vorfälle für Nutzer einsehbar protokollieren
  • Eine App MUSS sich an die Vorgaben der App-Readiness halten

Offene Fragen zur Sicherheit bei der App-Entwicklung sind zwischen dem App-Hersteller und dem App-Ökosystemanbieter zu klären.