So geht's
Ein Repository geht hinein.Ein laufender Dienst kommt heraus.
Diese Seite ist der ganze Weg von Anfang bis Ende: was passiert, in welcher Reihenfolge, und wer für welchen Teil verantwortlich ist. Sie ist mit Absicht länger als die Startseite: die ist dafür da, zu entscheiden ob man hinsieht, und diese ist fürs Hinsehen.
Sie verbinden ein Repository
Sie installieren die Drumlin-GitHub-App auf den Konten oder Repositories, die Sie auswählen. Es ist dieselbe App für jeden Kunden, sie sieht nur das, was Sie auswählen, und sie auf einem Repository zu installieren zeigt uns die anderen nicht.
Was Drumlin von einem Repository braucht, ist eine Dockerfile. Es gibt keine Datei von uns, die Sie hinzufügen müssten, und keinen Branch, der nach uns benannt werden müsste. Wenn Ihr Projekt heute in Docker baut, läuft es heute hier.
In einem Repository steckt oft mehr als eine lauffähige Sache, ein Frontend und die API dahinter. Jede wird ein eigener Dienst, mit eigenem Verzeichnis und eigener Dockerfile.
Ein Branch wird auf einen Commit festgelegt
Sie stellen einen Branch bereit; Drumlin schreibt den genauen Commit auf, auf den er zeigte. Jeder Build hält den Commit fest, den er bekam, also ist die Antwort auf „was läuft in Produktion" ein Hash, den Sie auschecken können.
Das Image wird gebaut, abseits von allem anderen
Der Build läuft auf Maschinen, die nur dafür da sind, nicht auf denen, die Ihre Anwendung betreiben. Ein Build, der einen Knoten frisst, kann also keinen laufenden Dienst mitnehmen. Er hat keinen Zugriff auf die Plattform, keinen auf andere Mandanten, und nur die Zugangsdaten, die zum Holen Ihres Codes nötig sind.
Das Ergebnis geht in die eigene Registry der Plattform und wird per Digest festgenagelt. Ein Tag kann auf anderen Code umgezogen werden, ein Digest nicht.
Ein Release entsteht
Ein Release ist die unveränderliche Verbindung aus einem Image-Digest, dem Commit, der ihn erzeugt hat, und dem Build, der das getan hat. Ein Dienst betreibt genau ein Release zur Zeit. Zurückgehen stellt das frühere Image erneut bereit und baut es nie neu. Das alte Image existiert weiterhin, ein Rückschritt dauert also Sekunden und kann nicht anders scheitern als beim ersten Lauf.
Der Dienst startet in einer Sandbox
Ihr Container läuft hinter seiner eigenen Kernelgrenze und teilt nie die der Maschine. Er darf in sich selbst als Root laufen, das ist seine Sache, und er kann die gewöhnlichen Dinge tun, die ein Image beim Start braucht: auf einem niedrigen Port lauschen, die Rechte seiner eigenen Dateien ändern, auf seinen eigenen Benutzer wechseln.
Was er nicht kann, ist die Maschine darunter erreichen: ein Dateisystem einhängen, ein Gerät anlegen, einen Raw-Socket öffnen, einen anderen Prozess beobachten. Ein Image, das eine ganze Maschine für sich erwartet, wird hier abgewiesen.
Er bekommt einen Namen und ein Zertifikat
Jeder Dienst ist sofort unter einer erzeugten Adresse erreichbar. Zeigen Sie mit einer eigenen Domain auf die Region und weisen Sie nach, dass sie Ihnen gehört, dann wird das Zertifikat geholt und verlängert, ohne dass Sie noch etwas tun.
Innerhalb einer Umgebung erreichen Dienste einander über ihren Namen auf Port 80, unabhängig davon, auf welchem Port die Anwendung selbst lauscht. Nur Dienste in derselben Umgebung erreichen sich. Produktion kann nicht mit der Testumgebung sprechen, und kein anderer Kunde erreicht eine von beiden. Diese Grenze liegt im Netzwerk, nicht in einer Konfiguration.
Wenn etwas kaputtgeht, sagt es warum
Die Protokolle sind da, live und historisch, mit Prozessor und Arbeitsspeicher jeder Instanz. Aber ein Protokoll ist ein Beleg, keine Erklärung, deshalb liest die Plattform ihre eigenen Belege: ein Ziel, das es nicht gibt, ein Port, auf dem nichts lauscht, ein Image für den falschen Prozessor, ein Server, der nur an Loopback gebunden ist. Aus jedem davon wird ein Satz, der sagt was passiert ist und was zu ändern ist.
Wenn Lesen nicht reicht, öffnen Sie eine Shell in einer laufenden Instanz. Diese Sitzung ist authentifiziert, einmalig, läuft ab und erscheint im Aktivitätsprotokoll des Dienstes. Eine Shell ist das Eingriffsstärkste, was diese Plattform kann, also ist sie dort sichtbar, wo jemand danach suchen würde.
Während es läuft, wird gemessen
Zu jeder volle Stunde sieht Drumlin nach, was Ihr Konto belegt: Prozessor und Arbeitsspeicher von allem, was läuft, und den Speicherplatz jeder Datenbank und jedes Volumes. Das wird bepreist und der Messwert notiert. In diesem Moment wird nichts berechnet; der Messwert ist ein Beleg.
Zu Beginn jedes Monats werden aus diesen Messwerten eine Rechnung für den abgelaufenen Monat, mit einer Zeile je Ressource und der Menge daneben. Rechenleistung zählt nur, solange ein Dienst läuft. Stoppen Sie einen um 14:05, lässt ihn die Messung um 15:00 weg. Speicherplatz zählt in beiden Fällen, denn ein Datenträger hält seine Bytes, ob jemand sie liest oder nicht.
Sie können dem Monat zusehen: die Abrechnungsseite zeigt genau, was er bisher gekostet hat, daneben eine Schätzung, wo er landen wird, und darunter die stündlichen Messwerte zu beidem. Jede Zahl auf einer Rechnung lässt sich zu den Stunden zurückverfolgen, aus denen sie entstand, und genau dafür werden sie aufbewahrt. Die Sätze stehen auf der Startseite.
Grenzen
Was unsere Sache ist und was Ihre.
Drumlin ist zuständig für
- Die Maschinen, das Netz zwischen ihnen und die Sandbox um Ihren Code
- Ihr Image zu bauen und jedes daraus entstandene Release zu behalten
- Ihren Dienst neu zu starten, wenn sein Prozess endet
- Zertifikate, und sie zu verlängern, bevor sie ablaufen
- Verwaltete Datenbanken zu sichern und die Wiederherstellung zu üben
- Ihre Volumes von dieser Maschine wegzukopieren und Sie eines selbst zurückholen zu lassen
- Andere Mandanten aus Ihrer Umgebung herauszuhalten
Sie sind zuständig für
- Was Ihre Anwendung tut und was sie speichert
- Dass ihre Dockerfile baut und ihr Prozess läuft
- Für Gespeichertes ein Volume oder eine verwaltete Datenbank zu wählen, denn das eigene Dateisystem eines Containers behält nach einem Neustart nichts
- Auf welchem Port sie lauscht, und es uns zu sagen
- Rechtmäßig mit den personenbezogenen Daten umzugehen, die sie verarbeitet