TL; DR: Es wird eine Beschreibung von Keycloak, einem Open-Source-Zugriffskontrollsystem, eine Analyse des internen Geräts und Konfigurationsdetails geben.
Einleitung und Hauptgedanken
In diesem Artikel sehen wir uns die wichtigsten Ideen an, die bei der Bereitstellung eines Keycloak-Clusters auf Kubernetes zu beachten sind.
Wenn Sie mehr über Keycloak erfahren möchten, lesen Sie bitte die Links am Ende des Artikels. Um tiefer in die Praxis einzutauchen, können Sie studieren mit einem Modul, das die Hauptideen dieses Artikels umsetzt (die Einführungsanleitung ist da, in diesem Artikel gibt es einen Überblick über das Gerät und die Einstellungen), ca. Übersetzer).
Keycloak ist ein komplexes System, das in Java geschrieben ist und auf einem Anwendungsserver aufbaut. . Kurz gesagt handelt es sich um ein Autorisierungs-Framework, das Anwendungsbenutzern Verbund- und SSO-Funktionen (Single Sign-On) bietet.
Wir laden Sie ein, den offiziellen Artikel zu lesen oder zum detaillierten Verständnis.
Starten Sie Keycloak
Keycloak benötigt zum Ausführen zwei persistente Datenquellen:
- Eine Datenbank zum Speichern persistenter Daten, z. B. Informationen über Benutzer
- Datagrid-Cache, der zum Zwischenspeichern von Daten aus der Datenbank sowie zum Speichern einiger kurzlebiger und häufig geänderter Metadaten, z. B. Benutzersitzungen, verwendet wird. Freigegeben , was in der Regel deutlich schneller ist als die Datenbank. Aber auf jeden Fall sind die in Infinispan gespeicherten Daten kurzlebig – und müssen beim Neustart des Clusters nicht irgendwo gespeichert werden.
Keycloak funktioniert in vier verschiedenen Modi:
- Normal - ein und nur ein Prozess, konfiguriert über eine Datei eigenständig.xml
- regelmäßiger Cluster (hochverfügbare Option) – Alle Prozesse müssen dieselbe Konfiguration verwenden, die manuell synchronisiert werden muss. Einstellungen werden in einer Datei gespeichert standalone-ha.xmlDarüber hinaus müssen Sie einen gemeinsamen Zugriff auf die Datenbank und einen Load Balancer einrichten.
- Domänencluster - Das Starten des Clusters im Normalmodus wird schnell zu einer routinemäßigen und langweiligen Aufgabe, wenn der Cluster wächst, da Sie jedes Mal, wenn Sie die Konfiguration ändern, alle Änderungen auf jedem Knoten des Clusters vornehmen müssen. Der Domänenbetriebsmodus löst dieses Problem, indem er gemeinsam genutzten Speicher einrichtet und die Konfiguration veröffentlicht. Diese Einstellungen werden in einer Datei gespeichert domain.xml
- Replikation zwischen Rechenzentren – für den Fall, dass Sie Keycloak in einem Cluster aus mehreren Rechenzentren betreiben möchten, meist an verschiedenen geografischen Standorten. Bei dieser Option verfügt jedes Rechenzentrum über einen eigenen Cluster von Keycloak-Servern.
In diesem Artikel werden wir uns die zweite Option genauer ansehen, d. h. normaler Cluster, sowie ein kleiner Hinweis auf das Thema Replikation zwischen Rechenzentren, da es sinnvoll ist, diese beiden Optionen in Kubernetes auszuführen. Glücklicherweise hat Kubernetes kein Problem damit, die Einstellungen mehrerer Pods (Keycloak-Knoten) zu synchronisieren Domänencluster es wird nicht allzu schwer sein.
Bitte beachten Sie auch, dass das Wort Cluster Bis zum Ende des Artikels gilt er nur für eine Gruppe zusammenarbeitender Keycloak-Knoten, es ist nicht erforderlich, auf einen Kubernetes-Cluster zu verweisen.
Regulärer Keycloak-Cluster
Um Keycloak in diesem Modus auszuführen, benötigen Sie:
- Richten Sie eine externe gemeinsame Datenbank ein
- Load Balancer installieren
- über ein internes Netzwerk mit IP-Multicast-Unterstützung verfügen
Wir werden die Konfiguration der externen Datenbank nicht analysieren, da dies nicht der Zweck dieses Artikels ist. Nehmen wir an, dass es irgendwo eine funktionierende Datenbank gibt – und wir einen Verbindungspunkt dazu haben. Wir werden diese Daten einfach zu den Umgebungsvariablen hinzufügen.
Um besser zu verstehen, wie Keycloak in einem Failover-Cluster (HA) funktioniert, ist es wichtig zu wissen, wie stark alles von den Clustering-Fähigkeiten von Wildfly abhängt.
Wildfly nutzt mehrere Subsysteme, einige davon dienen als Load Balancer, andere für Failover. Der Load Balancer stellt die Verfügbarkeit der Anwendung sicher, wenn der Clusterknoten überlastet ist, und Failover stellt die Verfügbarkeit der Anwendung sicher, selbst wenn einige der Clusterknoten ausfallen. Einige dieser Subsysteme sind:
-
mod_cluster: Funktioniert in Verbindung mit Apache als HTTP-Load-Balancer und ist für die Standard-Hosterkennung auf TCP-Multicast angewiesen. Kann durch einen externen Balancer ersetzt werden. -
infinispan: Verteilter Cache unter Verwendung von JGroups-Kanälen als Transportschicht. Optional kann das HotRod-Protokoll zur Kommunikation mit einem externen Infinispan-Cluster verwendet werden, um den Inhalt des Caches zu synchronisieren. -
jgroups: Bietet Unterstützung für die Gruppenzuordnung für hochverfügbare Dienste basierend auf JGroups-Kanälen. Mit benannten Pipes können Anwendungsinstanzen in einem Cluster zu Gruppen verbunden werden, sodass die Verbindung Eigenschaften wie Zuverlässigkeit, Ordnung und Fehlerempfindlichkeit aufweist.
Lastenausgleicher
Bei der Installation eines Balancers als Ingress-Controller in einem Kubernetes-Cluster ist es wichtig, Folgendes zu beachten:
Die Arbeit von Keycloak impliziert, dass die Remote-Adresse des Clients, der sich über HTTP mit dem Authentifizierungsserver verbindet, die tatsächliche IP-Adresse des Client-Computers ist. Balancer- und Ingress-Einstellungen sollten HTTP-Header korrekt festlegen X-Forwarded-For и X-Forwarded-Proto, und behalten Sie den Originaltitel bei HOST. letzte Version ingress-nginx (> 0.22.0)
Flag-Aktivierung proxy-address-forwarding durch Festlegen einer Umgebungsvariablen PROXY_ADDRESS_FORWARDING в true gibt Keycloak den Eindruck, dass es hinter einem Proxy läuft.
Sie müssen auch aktivieren klebrige Sitzungen im Eingang. Keycloak verwendet den verteilten Cache von Infinispan, um Daten zu speichern, die mit der aktuellen Authentifizierungssitzung und Benutzersitzung verknüpft sind. Caches sind standardmäßig Einzeleigentümer, d. h. die jeweilige Sitzung wird auf einem Cluster-Knoten gespeichert und andere Knoten müssen sie aus der Ferne anfordern, wenn sie Zugriff auf diese Sitzung benötigen.
Konkret hat das Anhängen einer Sitzung mit dem Cookie-Namen entgegen der Dokumentation bei uns nicht funktioniert
AUTH_SESSION_ID. Keycloak hat die Weiterleitung in einer Schleife durchgeführt, daher empfehlen wir, einen anderen Cookie-Namen für die Sticky-Sitzung zu wählen.
Keycloak fügt außerdem den Namen des Hosts hinzu, der zuerst geantwortet hat AUTH_SESSION_ID, und da jeder Knoten in der hochverfügbaren Version dieselbe Datenbank verwendet, ist jeder von ihnen eine separate und eindeutige Knoten-ID zur Verwaltung von Transaktionen. Es wird empfohlen, es einzubauen JAVA_OPTS Parameter jboss.node.name и jboss.tx.node.id eindeutig für jeden Knoten – Sie können beispielsweise den Namen des Pods festlegen. Wenn Sie den Namen des Pods angeben, vergessen Sie nicht die Beschränkung auf 23 Zeichen für Jboss-Variablen. Verwenden Sie daher besser StatefulSet und nicht Deployment.
Noch ein Rechen – wenn ein Pod gelöscht oder neu gestartet wird, geht sein Cache verloren. Vor diesem Hintergrund lohnt es sich, die Anzahl der Cache-Besitzer für alle Caches auf mindestens zwei festzulegen, damit eine Kopie des Caches vorhanden ist. Die Lösung ist laufen Platzieren Sie den Pod beim Starten im Verzeichnis /opt/jboss/startup-scripts im Behälter:
Skriptinhalt
embed-server --server-config=standalone-ha.xml --std-out=echo
batch
echo * Setting CACHE_OWNERS to "${env.CACHE_OWNERS}" in all cache-containers
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=owners, value=${env.CACHE_OWNERS:1})
run-batch
stop-embedded-serverLegen Sie dann den Wert der Umgebungsvariablen fest CACHE_OWNERS zum Erforderlichen.
Privates Netzwerk mit IP-Multicast-Unterstützung
Wenn Sie Weavenet als CNI verwenden, funktioniert Multicast sofort – und Ihre Keycloak-Knoten erkennen sich, sobald sie betriebsbereit sind.
Wenn Ihr Kubernetes-Cluster keine IP-Multicast-Unterstützung bietet, können Sie JGroups so konfigurieren, dass es mit anderen Protokollen zusammenarbeitet, um Knoten zu finden.
Die erste Option ist die Verwendung KUBE_DNSwas nutzt headless service Um Keycloak-Knoten zu finden, übergeben Sie JGroups einfach den Namen des Dienstes, der zum Suchen der Knoten verwendet wird.
Eine andere Möglichkeit besteht darin, die Methode zu verwenden KUBE_PING, das mit der API zum Suchen von Knoten funktioniert (Sie müssen konfigurieren serviceAccount mit Rechten list и get, und konfigurieren Sie dann die Pods so, dass sie damit funktionieren serviceAccount).
Wie Knoten nach JGroups durchsucht werden, wird durch Festlegen von Umgebungsvariablen konfiguriert JGROUPS_DISCOVERY_PROTOCOL и JGROUPS_DISCOVERY_PROPERTIES. Für KUBE_PING Sie müssen Pods auswählen, indem Sie danach fragen namespace и labels.
️ Wenn Sie Multicast verwenden und zwei oder mehr Keycloak-Cluster im selben Kubernetes-Cluster ausführen (sagen wir einen im Namespace).
production, zweite -staging) – Knoten aus einem Keycloak-Cluster können einem anderen Cluster beitreten. Stellen Sie sicher, dass Sie für jeden Cluster eine eindeutige Multicast-Adresse verwenden, indem Sie Variablen festlegenjboss.default.multicast.addressиjboss.modcluster.multicast.addressвJAVA_OPTS.
Replikation zwischen Rechenzentren
Link
Keycloak verwendet mehrere separate Infinispan-Cache-Cluster für jedes Rechenzentrum, das Keycloack-Cluster hostet, die aus Keycloak-Knoten bestehen. Gleichzeitig gibt es jedoch keinen Unterschied zwischen Keycloak-Knoten in verschiedenen Rechenzentren.
Keycloak-Knoten verwenden ein externes Java Data Grid (Infinispan-Server) für die Kommunikation zwischen Rechenzentren. Die Kommunikation funktioniert protokollgemäß .
Infinispan-Caches müssen mit dem Attribut konfiguriert werden remoteStore, damit die Daten remote gespeichert werden können (in einem anderen Rechenzentrum, ca. Übersetzer) Caches. Unter den JDG-Servern gibt es separate Infinispan-Cluster, sodass die Daten vor Ort auf JDG1 gespeichert werden site1 wird vor Ort auf JDG2 repliziert site2.
Schließlich benachrichtigt der empfangende JDG-Server die Keycloak-Server seines Clusters über Client-Verbindungen, was eine Funktion des HotRod-Protokolls ist. Keycloak-Knoten aktiviert site2 Aktualisieren Sie ihre Infinispan-Caches und die jeweilige Benutzersitzung wird auf den Keycloak-Knoten verfügbar site2.
Es ist auch möglich, dass einige Caches nicht gesichert werden und das Schreiben von Daten über den Infinispan-Server vollständig verweigert. Dazu müssen Sie die Einstellung entfernen remote-store spezifischer Infinispan-Cache (in Datei standalone-ha.xml), danach einige spezifische replicated-cache wird auch auf der Seite des Infinispan-Servers nicht mehr benötigt.
Caches einrichten
Es gibt zwei Arten von Caches in Keycloak:
-
Lokal. Es befindet sich neben der Basis und dient dazu, die Belastung der Datenbank zu verringern und die Antwortlatenz zu reduzieren. Dieser Cache-Typ speichert den Bereich, die Clients, die Rollen und die Benutzermetadaten. Dieser Cache-Typ wird nicht repliziert, selbst wenn dieser Cache Teil eines Keycloak-Clusters ist. Wenn sich ein Eintrag im Cache ändert, wird eine Änderungsnachricht an die übrigen Server im Cluster gesendet, woraufhin der Eintrag aus dem Cache ausgeschlossen wird. Siehe Artikelbeschreibung
workUnten finden Sie eine detailliertere Beschreibung des Verfahrens. -
Reproduzierbar. Verarbeitet Benutzersitzungen und Offline-Tokens und überwacht Anmeldefehler, um Passwort-Phishing-Versuche und andere Angriffe zu erkennen. Die in diesen Caches gespeicherten Daten sind temporär und werden nur im RAM gespeichert, können aber im gesamten Cluster repliziert werden.
Infinispan-Caches
Sitzungen - ein Konzept in Keycloak, separate Caches, die aufgerufen werden authenticationSessionsdienen der Speicherung der Daten bestimmter Nutzer. Anfragen von diesen Caches werden normalerweise vom Browser und den Keycloak-Servern benötigt, nicht von Anwendungen. Hier zeigt sich die Abhängigkeit von Sticky Sessions, und solche Caches selbst müssen auch im Aktiv-Aktiv-Modus nicht repliziert werden.
Aktionsmarken. Ein anderes Konzept, das normalerweise für verschiedene Szenarien verwendet wird, wenn der Benutzer beispielsweise etwas asynchron per E-Mail erledigen muss. Zum Beispiel während des Eingriffs forget password Cache actionTokens Wird verwendet, um die Metadaten verwandter Token zu verfolgen. Beispielsweise wurde das Token bereits verwendet und kann nicht erneut aktiviert werden. Diese Art von Cache sollte normalerweise zwischen Rechenzentren repliziert werden.
Zwischenspeicherung und Ablauf gespeicherter Daten entlastet die Datenbank. Dieses Caching verbessert die Leistung, bringt jedoch ein offensichtliches Problem mit sich. Wenn ein Keycloak-Server die Daten aktualisiert, müssen die übrigen Server benachrichtigt werden, damit sie ihre Caches aktualisieren können. Keycloak verwendet lokale Caches realms, users и authorization zum Zwischenspeichern von Daten aus der Datenbank.
Es gibt auch einen separaten Cache work, die in allen Rechenzentren repliziert wird. Es selbst speichert keine Daten aus der Datenbank, sondern dient dazu, Datenalterungsmeldungen an Clusterknoten zwischen Rechenzentren zu senden. Mit anderen Worten: Sobald die Daten aktualisiert sind, sendet der Keycloak-Knoten eine Nachricht an andere Knoten in seinem Rechenzentrum sowie an Knoten in anderen Rechenzentren. Beim Empfang einer solchen Nachricht löscht jeder Knoten die entsprechenden Daten in seinen lokalen Caches.
Benutzersitzungen. Caches mit Namen sessions, clientSessions, offlineSessions и offlineClientSessionswerden normalerweise zwischen Rechenzentren repliziert und dienen der Speicherung von Daten über Benutzersitzungen, die aktiv sind, während der Benutzer im Browser aktiv ist. Diese Caches arbeiten mit der Anwendung zusammen, die HTTP-Anfragen von Endbenutzern verarbeitet. Daher sind sie mit Sticky Sessions verknüpft und müssen zwischen Rechenzentren repliziert werden.
Brute-Force-Schutz. Zwischenspeicher loginFailures Wird verwendet, um Anmeldefehlerdaten zu verfolgen, z. B. wie oft ein Benutzer ein falsches Passwort eingegeben hat. Die Replikation dieses Caches ist Sache des Administrators. Für eine genaue Berechnung lohnt es sich jedoch, die Replikation zwischen Rechenzentren zu aktivieren. Wenn Sie diese Daten jedoch nicht replizieren, können Sie die Leistung verbessern. Wenn diese Frage auftritt, wird die Replikation möglicherweise nicht aktiviert.
Beim Rollout eines Infinispan-Clusters müssen Sie Cache-Definitionen zur Einstellungsdatei hinzufügen:
<replicated-cache-configuration name="keycloak-sessions" mode="ASYNC" start="EAGER" batching="false">
</replicated-cache-configuration>
<replicated-cache name="work" configuration="keycloak-sessions" />
<replicated-cache name="sessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineSessions" configuration="keycloak-sessions" />
<replicated-cache name="actionTokens" configuration="keycloak-sessions" />
<replicated-cache name="loginFailures" configuration="keycloak-sessions" />
<replicated-cache name="clientSessions" configuration="keycloak-sessions" />
<replicated-cache name="offlineClientSessions" configuration="keycloak-sessions" />Sie müssen den Infinispan-Cluster konfigurieren und starten, bevor Sie den Keycloak-Cluster ausführen
Dann müssen Sie es einrichten remoteStore für Keycloak-Caches. Hierzu genügt ein Skript, das ähnlich wie das vorherige abläuft und mit dem die Variable gesetzt wird CACHE_OWNERS, müssen Sie es in einer Datei speichern und in einem Verzeichnis ablegen /opt/jboss/startup-scripts:
Skriptinhalt
embed-server --server-config=standalone-ha.xml --std-out=echo
batch
echo *** Update infinispan subsystem ***
/subsystem=infinispan/cache-container=keycloak:write-attribute(name=module, value=org.keycloak.keycloak-model-infinispan)
echo ** Add remote socket binding to infinispan server **
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-cache:add(host=${remote.cache.host:localhost}, port=${remote.cache.port:11222})
echo ** Update replicated-cache work element **
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=work,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/replicated-cache=work:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache sessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=sessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=sessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache offlineSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=offlineSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache clientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=clientSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=clientSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache offlineClientSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=offlineClientSessions,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=offlineClientSessions:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache loginFailures element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
remote-servers=["remote-cache"],
cache=loginFailures,
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=loginFailures:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache actionTokens element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens/store=remote:add(
passivation=false,
fetch-state=false,
purge=false,
preload=false,
shared=true,
cache=actionTokens,
remote-servers=["remote-cache"],
properties={
rawValues=true,
marshaller=org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory,
protocolVersion=${keycloak.connectionsInfinispan.hotrodProtocolVersion}
}
)
/subsystem=infinispan/cache-container=keycloak/distributed-cache=actionTokens:write-attribute(name=statistics-enabled,value=true)
echo ** Update distributed-cache authenticationSessions element **
/subsystem=infinispan/cache-container=keycloak/distributed-cache=authenticationSessions:write-attribute(name=statistics-enabled,value=true)
echo *** Update undertow subsystem ***
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)
run-batch
stop-embedded-serverVergessen Sie nicht, es zu installieren JAVA_OPTS Damit Keycloak-Knoten mit HotRod funktionieren: remote.cache.host, remote.cache.port und Dienstname jboss.site.name.
Links und zusätzliche Dokumentation
Der Artikel wurde von Mitarbeitern für Habr übersetzt und aufbereitet — Intensivkurse, Videokurse und Unternehmensschulungen von Praktikern (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE)
Source: habr.com