Hostly

Was ist ein Service? ​

Ein Service ist ein Anwendungscontainer, den Hostly ausführt. Er ist entweder öffentlich über eine Domain erreichbar oder intern, also nur für andere Services seines Workspace.

Typische Services sind:

  • Websites
  • Webanwendungen
  • HTTP-APIs
  • persönliche Tools
  • Dashboards
  • andere über HTTP oder HTTPS erreichbare Anwendungen
  • Datenbanken, Caches und Queues (intern)
  • Hintergrund-Worker (intern, ohne Port)

Wie diese zusammenspielen, zeigt Anwendungsfälle und Beispiele.

Beziehung zum Workspace ​

Ein Service gehört immer zu genau einem Workspace.

Der Workspace bestimmt insbesondere:

  • den Domain-Bereich des Services
  • den zugeordneten Tarif
  • die verfügbaren Funktionen
  • das Ressourcenbudget
  • die Mitglieder und Berechtigungen, unter denen der Service verwaltet wird

Ein Service entsteht durch ein Deployment ​

In Hostly existiert ein Service erst, nachdem ein Docker-Image deployt wurde.

Hostly verwendet in der Benutzeroberfläche den Begriff Deployment für den Vorgang mit dem Hostly eine Anwendung bereitstellt und Service für die daraus resultierende Instanz einer Anwendung.

Diese Dokumentation unterscheidet soweit möglich:

  • Service: die verwaltete Anwendung,
  • Deployment: die Bereitstellung oder Ersetzung dieser Anwendung.

Docker-Image ​

Ein Docker-Image ist ein vorbereitetes Paket mit der Anwendung und den Bestandteilen, die sie zum Starten benötigt.

Hostly unterstützt derzeit bereits gebaute Docker-Images. Hostly baut selbst kein Image aus Quellcode oder einem Git-Repository.

Unterstützt werden Docker Hub und alternative Registries. Für private Registries können im Deployment passende Zugangsdaten hinterlegt werden.

Hostly stellt außerdem einen eigenen privaten Image-Speicher bereit. Unter Hostly Registry erfährst du mehr über die Workspace-Struktur, Image-Referenzen, Tags und Registry-Sessions.

Image-Tags ​

Ein fester Tag bezeichnet eine veröffentlichte Image-Version:

text
example/my-service:1.4.2

Bei der (beliebten) Option latest lädt Hostly die Version, auf die der Tag beim Start der Container des Service verweist. Ändert sich latest später in der Registry, aktualisiert sich der laufende Service nicht automatisch. Ein Neustart lädt das Image erneut herunter und verwendet die Version, auf die latest zu diesem Zeitpunkt verweist.

Bestandteile eines Services ​

BestandteilBedeutung
Docker-ImageEnthält die Anwendung.
Service-NameEindeutiger, unveränderlicher Name im Workspace. Andere Services erreichen den Service darüber.
DomainHostly-Subdomain, Custom Domain oder keine bei internen Services.
Container-PortPort, auf dem die Anwendung im Container lauscht. Optional.
Environment VariablesNormale Konfigurationswerte.
SecretsVertrauliche Werte im verschlüsselten Secret-Store.
DateienHochgeladene Dateien, die Hostly in den Container mountet.
LogsAusgaben aus stdout und stderr.
SSLAktiviert HTTPS mit einem automatischen Let's-Encrypt-Zertifikat.
High AvailabilityStartet drei Instanzen desselben Services.
VolumePersistenter Speicher im Paid Tier.

Service-Name ​

Jeder Service hat einen Service-Namen, der innerhalb seines Workspace eindeutig ist. Er wird beim Anlegen des Service festgelegt und kann danach nie mehr geändert werden, weil andere Services den Service darüber erreichen.

Regeln:

  • Kleinbuchstaben a-z, Ziffern 0-9 und Bindestriche -
  • beginnt mit einem Buchstaben und endet nicht mit einem Bindestrich
  • höchstens 63 Zeichen

Bei Services mit Hostly-Subdomain füllt der Wizard den Service-Namen aus der Subdomain vor. Service-Name und Service-Domainfragment sind unabhängig voneinander: Die Subdomain kann später geändert werden, der Service-Name nicht.

Erreichbarkeit ​

Ein Service ist entweder öffentlich oder intern.

Öffentliche Services ​

Ein öffentlicher Service erhält eine Service-Domain, entweder eine Hostly-Subdomain:

text
<Service-Domainfragment>.<Workspace-Domainfragment>.hostly.ninja

oder eine verifizierte Custom Domain des Workspace.

Hostly leitet die öffentliche HTTP- oder HTTPS-Verbindung an den Container-Port des Service weiter.

Beispiel:

text
Container-Port: 3000
Öffentliche URL: https://app.example.hostly.ninja

Der Container-Port muss - wie bei anderen Webseiten auch - nicht in der öffentlichen URL angegeben werden.

Interne Services ​

Ein interner Service hat keine öffentliche Domain und ist aus dem Internet nicht erreichbar. Aktiviere dafür im Wizard Nur intern erreichbar. Das passt für Datenbanken, Caches, Queues und Backends, die nur deine eigenen Services nutzen.

Kommunikation zwischen Services ​

Alle Services eines Workspace erreichen sich gegenseitig über ihren Service-Namen und Container-Port:

text
<service-name>:<port>

Beispiel: Eine Datenbank mit dem Service-Namen db auf Port 5432 ist für alle anderen Services des Workspace unter db:5432 erreichbar, z. B. im Connection String postgres://app:${DB_PASSWORD}@db:5432/app.

  • Das gilt für öffentliche und interne Services.
  • Intern funktioniert jedes TCP-Protokoll, nicht nur HTTP.
  • Services anderer Workspaces erreichen sie nicht.
  • Die Service-Detailseite zeigt die Adresse als Intern erreichbar unter an.

Services ohne Port ​

Ein Service braucht keinen Port. Wähle dafür im Wizard Dieser Service hat keinen Port. Ein solcher Service ist weder aus dem Internet noch für andere Services erreichbar. Das passt nur für Hintergrund-Worker, die selbst Verbindungen aufbauen, z. B. zu einer Queue oder Datenbank, aber keine annehmen.

Pro Service kann genau ein Container-Port angegeben werden.

Health Check ​

Ein Container kann im Cluster laufen, obwohl die Anwendung nicht über ihre öffentliche Domain erreichbar ist. Das passiert beispielsweise, wenn die Anwendung nicht auf dem konfigurierten Port erreichbar ist.

Hostly prüft deshalb mit einem Health Check, ob der Service erreichbar ist:

  • Öffentliche Services: Der Container-Port nimmt Verbindungen an und die öffentliche Domain ist aus dem Internet erreichbar.
  • Interne Services: Der Container-Port nimmt Verbindungen an.
  • Services ohne Port: Der Container läuft, ohne abzustürzen. Ob der Worker seine Arbeit erledigt, zeigen nur die Logs.

Der technische Zustand eines Services ergibt sich daher nicht nur aus dem Containerstatus, sondern aus mehreren Informationen:

text
Service-Status
+ Health Check
+ Logs
+ konfigurierter Container-Port

SSL ​

SSL ist im Free Tier und Paid Tier verfügbar. Es gilt nur für öffentliche Services.

Bei aktiviertem SSL:

  • erstellt Hostly automatisch ein Let's-Encrypt-Zertifikat
  • ist keine manuelle Zertifikatskonfiguration erforderlich
  • ist der Service über HTTPS erreichbar
  • leitet Hostly HTTP-Anfragen automatisch auf HTTPS um

Die Oberfläche verwendet den Begriff SSL; technisch wird TLS eingesetzt. Eine Deaktivierung erfordert ein neues Deployment, durch "Deployment ändern" oder das Löschen und Neuerstellen des Services.

High Availability ​

Mit High Availability startet Hostly drei Instanzen desselben Services. Dadurch bleiben die anderen Instanzen verfügbar, wenn eine Instanz ausfällt.

High Availability ist in beiden Tarifen verfügbar. Compute- und RAM-Grundverbrauch verdreifachen sich dadurch ungefähr.

Mehrere Versionen ​

Ein Service kann im Laufe der Zeit mehrfach deployt werden. Ein neues Deployment ersetzt jedoch immer die vorherige Version.

Hostly bietet derzeit keinen automatischen Rollback. Für eine Rückkehr zu einer früheren Version muss deren Image-Tag erneut deployt werden.

Verwandte Konzepte ​