ADMIN

2024

11

2024-10-30T12:00:00

Cloudmanagement

TESTS

025

Cloud

Infrastrukturautomatisierung

Spacelift

IT wie am Schnürchen

von Martin Loschwitz

Veröffentlicht in Ausgabe 11/2024 - TESTS

Infrastructure-as-Code verspricht Administratoren geringe Fehlerraten, stabilen Betrieb und zuverlässige Ergebnisse bei minimalem laufendem Aufwand. Eine eigene IaC-Landschaft zu bauen, erfordert aber Zeit und ist mühselig. Spacelift will hier für Abhilfe sorgen, indem sich die gehostete IaC-Umgebung mit zentralen Werkzeugen wie Terraform verzahnt. Auch bietet der Dienst CI/CD-Pipelines und kooperiert mit Versionsverwaltungssystemen nahtlos. Unser Test zeigt, dass Spacelift als IaC-Zentrale viele komplexe Aufgaben vereinfacht.

Zu den wichtigsten Neuerungen von Cloud Computing und Container-Virtualisierung zählt Infrastructure-as-Code (IaC), also den Prozess der Verwaltung und Bereitstellung von Computerressourcen über maschinenlesbare Definitionsdateien und nicht über physische Hardwarekonfiguration oder interaktive Konfigurationstools. Ganz gleich, welche Cloud die Grundlage bildet, ob es sich also um AWS, Azure, GCP, eine lokale Plattform auf Basis von OpenStack oder Kubernetes oder gar um einen Mix aus verschiedenen Umgebungen handelt: Allen Ansätzen ist gemein, dass sie sämtliche Aufgaben des administrativen Alltags automatisieren und per API steuerbar machen wollen. Das impliziert die Möglichkeit, die eigene gewünschte Zielplattform in Templates zu beschreiben, einem entsprechenden Dienst jene Vorlage auszuhändigen und diesem dann dabei zuzusehen, wie er die beschriebene Umgebung virtuell zusammenzimmert.
Für Administratoren bietet IaC erhebliche Vorteile: Wenig Aufwand für das Schaffen neuer Umgebungen, zuverlässige Wege für das Deployment von Anwendungen, schnelle Recovery-Vorgänge im Problemfall und geringe Raten von Fehlern, die durch Stress oder Unachtsamkeit entstehen. Denn wenn der Faktor Mensch beim Ausrollen von Infrastrukturdiensten in den Hintergrund tritt, haben einzelne Personen weniger Gelegenheiten, sich als Einfaltspinsel zu betätigen.
Bis ein umfassendes und gut funktionierendes IaC-Setup allerdings zur Verfügung steht, ist einiges an Vorarbeit nötig. Da steht zunächst die Frage im Raum, welche Dienste und Dienstarten die Zielumgebung überhaupt benötigt. Denn davon hängt ab, welche Software die IaC-Umgebung benötigt. Geht es eher um klassische Clouds oder um Kubernetes? Wie kommen die IaC-Daten eigentlich in die Cloud? Existiert eine GitLab-Instanz oder soll die Umgebung an GitHub mit Bezahlaccount angegliedert sein? Wie lassen sich Pipelines für Continuous Integration und Continuous Delivery bauen und sinnvoll ausführen? Irgendwann taumelt der verzweifelte Admin im Netz von GitLab zu GitHub, Jenkins, ArgoCD, Rancher und diversen anderen Werkzeugen und wünscht sich, das Thema nie in Angriff genommen zu haben.
Zu den wichtigsten Neuerungen von Cloud Computing und Container-Virtualisierung zählt Infrastructure-as-Code (IaC), also den Prozess der Verwaltung und Bereitstellung von Computerressourcen über maschinenlesbare Definitionsdateien und nicht über physische Hardwarekonfiguration oder interaktive Konfigurationstools. Ganz gleich, welche Cloud die Grundlage bildet, ob es sich also um AWS, Azure, GCP, eine lokale Plattform auf Basis von OpenStack oder Kubernetes oder gar um einen Mix aus verschiedenen Umgebungen handelt: Allen Ansätzen ist gemein, dass sie sämtliche Aufgaben des administrativen Alltags automatisieren und per API steuerbar machen wollen. Das impliziert die Möglichkeit, die eigene gewünschte Zielplattform in Templates zu beschreiben, einem entsprechenden Dienst jene Vorlage auszuhändigen und diesem dann dabei zuzusehen, wie er die beschriebene Umgebung virtuell zusammenzimmert.
Für Administratoren bietet IaC erhebliche Vorteile: Wenig Aufwand für das Schaffen neuer Umgebungen, zuverlässige Wege für das Deployment von Anwendungen, schnelle Recovery-Vorgänge im Problemfall und geringe Raten von Fehlern, die durch Stress oder Unachtsamkeit entstehen. Denn wenn der Faktor Mensch beim Ausrollen von Infrastrukturdiensten in den Hintergrund tritt, haben einzelne Personen weniger Gelegenheiten, sich als Einfaltspinsel zu betätigen.
Bis ein umfassendes und gut funktionierendes IaC-Setup allerdings zur Verfügung steht, ist einiges an Vorarbeit nötig. Da steht zunächst die Frage im Raum, welche Dienste und Dienstarten die Zielumgebung überhaupt benötigt. Denn davon hängt ab, welche Software die IaC-Umgebung benötigt. Geht es eher um klassische Clouds oder um Kubernetes? Wie kommen die IaC-Daten eigentlich in die Cloud? Existiert eine GitLab-Instanz oder soll die Umgebung an GitHub mit Bezahlaccount angegliedert sein? Wie lassen sich Pipelines für Continuous Integration und Continuous Delivery bauen und sinnvoll ausführen? Irgendwann taumelt der verzweifelte Admin im Netz von GitLab zu GitHub, Jenkins, ArgoCD, Rancher und diversen anderen Werkzeugen und wünscht sich, das Thema nie in Angriff genommen zu haben.
Spacelift
Produkt
Plattform für den IT-Betrieb auf Basis von Infrastructure-as-Code.
Hersteller
Spacelift
Preis
Als Community-Version kostenlos. In der Cloudvariante werden 250 US-Dollar pro Monat für fünf Benutzer mit Spaces und gleichzeitigem Durchführen mehrerer Runs fällig. Preise für die Enterprise-Lizenz nennt der Hersteller auf Anfrage. Das Eigenhosting auf AWS schlägt mit 10.000 US-Dollar pro Monat zu Buche.
Systemanforderungen
Für den Onlinedienst ist ein Browser zum Zugriff auf Spacelift erforderlich sowie ein Account bei einem Hyperscaler, um Spacelift mit Compute-Ressourcen auszustatten.
Technische Daten
Intensives Einarbeiten nach flotter Installation
Hier kommt Spacelift zur Hilfe und verspricht, IaC mit allen benötigten Komponenten zu liefern. Dazu beherrscht Spacelift auf der einen Seite die Kommunikation mit den drei Hyperscalern Azure, AWS und GCP, bietet auf der anderen Seite aber Schnittstellen für diverse Standardwerkzeuge aus der CI/CD-Welt. Spacelift ist aber nicht auf das reine CI/CD beschränkt, denn nach dem Deployment einer Umgebung erlaubt es Administratoren, Änderungen per Webhooks vorzunehmen, umfassende Einsicht in die Metrikdaten einer Umgebung mittels GraphQL oder Datadog zu nehmen oder etwaige Meldungen aus Spacelift über Instant-Messaging-Systeme hin zur Außenwelt zu kommunizieren.
Dabei gelingt der Einstieg in Spacelift zügig. Der Admin muss sich zwar zwischen dem von Spacelift als Onlinedienst und einer selbst gepflegten Version in AWS entscheiden. Beiden ist jedoch gemein, dass sie mit den gängigen SSO-Anwendungen von Microsoft, Google und Apple integriert sind. Wer bei einem dieser Anbieter einen Zugang hat, hat die eigene Spacelift-Umgebung also relativ flott am Start.
Im Nachgang fühlten wir uns von den verfügbaren Funktionen im Dashboard allerdings etwas erschlagen. Schnell wurde deutlich, dass Spacelift sich tatsächlich als allumfassende Plattform für IaS betrachtet, die alle Aspekte ganzheitlich steuern und kontrollieren will. Zu diesem Zweck verfolgt es gar eine eigene Terminologie, an die Spacelift-Neulinge sich zunächst gewöhnen müssen: "Blueprints" beschreiben die Sammlung aller Templates und Metadaten, die nötig sind, um eine virtuelle Umgebung zu starten.
Diese virtuellen Umgebungen heißen in Spacelift "Stacks". Der Vorgang, der aus einem Blueprint einen Stack macht, nennt sich "Run". Ein Account kann mehrere Stacks umfassen, es lassen sich also verschiedene IaC-Setups aus demselben Spacelift-Account heraus steuern. Pro Stack lassen sich zudem beliebig viele Runs durchführen, wobei die Software auf Idempotenz achtet, also darauf, dass wiederholte Operationen die gleiche Wirkung haben wie eine einzelne Ausführung. Wer eine striktere Trennung zwischen einzelnen Stacks will, quartiert diese in sogenannte Spaces aus. Praktisch alle Spacelift-Parameter wie Stacks, Policies, Module oder Worker-Pools – also Zielsysteme für das Deployment – sind Space-spezifisch und stehen nur in jenem Space zur Verfügung, dem der Administrator sie zugewiesen hat. Spaces haben zu dem eine eigene Berechtigungsverwaltung, doch dazu später mehr.
Bild 1: Mit Blueprints, Runs und Spaces unterstützt Spacelift IaC für viele klassische Cloudorchestrierer.
Komplexes einfach gemacht
Der Arbeitsablauf innerhalb von Spacelift ist weitgehend vorgegeben. Nach dem Anlegen des eigenen Accounts erwartete die Software zunächst, dass wir ein System zur Versionskontrolle verknüpfen, im Regelfall also GitLab oder ein GitHub, aber auch Bitbucket sowie Azure DevOps standen zur Verfügung. Das angegebene Verzeichnis durchforstete Spacelift dann nach Code in einem unterstützten Format. Damit war die Eingangsseite bereits geklärt. Freilich braucht Spacelift aber auch eine Zielplattform, auf der es den Code später ausführen kann. Hier hatten wir die Auswahl zwischen AWS, Azure oder Google Cloud Platform. Dabei kann Spacelift sowohl Ressourcen für IaaS verarbeiten als auch für die Kubernetes-Dienste der Plattformen. Der Administrator verbindet das Werkzeug hierzu mit dem jeweiligen Cloudanbieter und gestattet dem Dienst mithin das Anlegen von Ressourcen in der gewünschten Plattform. Sobald Spacelift Zugangsdaten hat, verfügt es auch über die Möglichkeit, sich einen Pool von Worker-Nodes selbst anzulegen.
Besonders angenehm fiel uns die Launchpad-Funktionalität auf. Das ist eine Art geführter Schnellstart mit ausgiebiger Assistenz. Aus dem Launchpad heraus konnten wir mit wenigen Klicks Quelltextverzeichnisse ebenso an Spacelift anflanschen, wie sie sich beim Erstellen eines Stacks mit dem Launchpad-Stack-Assistenten dann auch zum Bestandteil einer CI/CD-Pipeline verwursten lassen. Gerade Administratoren, die weniger Erfahrung mit CI/CD haben, dürfte das sehr gelegen kommen – was nicht den Eindruck erwecken soll, Spacelift sei für erfahrene DevOps-Cracks ungeeignet. Wer die einschlägigen Begriffe kennt und weiß, was er tut, kann praktisch jeden Aspekt des Verhaltens von Spacelift bis ins kleineste Detail an die eigenen Bedürfnisse anpassen.
Das ist dann aber ausgesprochen komplex, und gerade jene Komplexität ist es, die CI/CD-Neulingen den Einstieg besonders schwer macht. Spacelift geht das Problem mit einer Mischung aus sinnvollen Standardeinstellungen und vielen konfigurierbaren Hebeln und Schaltern für Profis an und schafft auf diese Weise ein attraktives Produkt für beide Nutzertypen. Das Ergebnis kann sich durchaus sehen lassen, denn vom ursprünglichen IaC-Code bis hin zum fertigen Deployment dauerte es in unserem Test nur ein paar Minuten. Darin enthalten ist das Erstellen des nötigen Blueprints, für die Spacelift ebenfalls Assistenten hat, samt des Ausführens des nötigen Runs.
Der Betrieb von IaC-Pipelines für CI/CD ist ein relativ gut definierter Prozess, der links und rechts nicht viel Platz für Individualität und Eigenheiten lässt. Trotzdem ist es Spacelift gelungen, ein paar zusätzliche Features zu implementieren, die dem Administrator das Leben erleichtern. So war es uns beispielsweise möglich, die Runner-Prozesse mit einem eigenen Container-Image für Docker zu versehen.
Jeder dieser Prozesse lief in einem frisch gestarteten, direkt aus dem Abbild gezogenen Docker-Container. Eigene Abbilder ermöglichen es, direkt im CI/CD-Prozess eigene Funktionen umzusetzen. Wer die allgemeine Spacelift-Instanz nutzt, sieht sich allerdings mit der Tatsache konfrontiert, dass diese Abbilder nur von bestimmten Container-Registries beziehen kann. Dazu gehört Docker-Hub ebenso wie Red Hats Quay.io. Wer Runner-Container mit nicht öffentlichen Inhalten nutzen will, benötigt indes eine selbstgehostete Spacelift-Instanz in AWS oder "pri- vate Worker", die nur im Enterprise-Tarif zur Verfügung stehen.
Bild 2: Das Launchpad ist so etwas wie die Spacelift-Grundschule: Hier finden sich diverse Assistenten, die bei den ersten Schritten helfen und die Arbeit so erheblich erleichtern.
Kommunikation begrenzt, aber angemessen
Ebenfalls nützlich erschienen uns vielerorts die kommunikativen Funktionen von Spacelift. Der Dienst kommuniziert ab Werk wahlweise via Slack oder Microsoft Teams. So waren wir beispielsweise in der Lage, Statusmeldungen direkt in Teams-Kanäle weiterzugeben, sodass eine Art "ChatOps" entsteht. Allzu gut ausgebaut ist diese Funktion aber nicht. Wünschenswert wäre, gerade wenn wir den US-Ursprung von Spacelift betrachten, beispielsweise eine Integration in OpsGenie gewesen, einen der größten ChatOps-Dienste in den USA.
Immerhin lässt sich an dieser Stelle aber noch die ebenfalls enthaltene Webhooks-Funktion nutzen. Spacelift bietet die Möglichkeit, beim Übergang zwischen den Phasen eines Blueprints per Webhook Befehle von externen Stellen zu empfangen oder sie dorthin zu senden. Bietet ein Kommunikationsdienst hierfür eine Schnittstelle, lassen sich Meldungen auch mittels Webhook uns ReST-Aufruf realisieren. Das ist zwar mühsam, aber immerhin möglich. Ohnehin dürfte das aber gar nicht die Kernidee hinter Webhooks sein. Nützlich sind diese auch und vor allem, um Aktionen in der umgebenden Infrastruktur loszutreten, je nach Abhängigkeit des Ergebnisses eines Runs oder einer einzelnen Phase davon. Denkbar wäre etwa, auch auf Infrastruktur, die nicht unmittelbar unter Spacelift-Ägide steht, den Neustart von Ressourcen auszulösen, wenn sich in einem von Spacelift verwalteten IaC-Stack etwas ändert. Die erweiterten Funktionen von Spacelift überzeugen insofern, sie sind allerdings nicht sehr umfangreich.
Zahlreiche nutzbare IaC-Frameworks
Eine zentrale Frage bei IaC-Frameworks zur Umsetzung von CI/CD-Pipelines ist jene nach den unterstützten Formaten für die Deklaration von Templates. Am Markt tummeln sich nicht gerade wenige Vertreter des Genres: Terraform und sein Fork OpenTofu gehören zweifelsohne zu den bekanntesten, zusätzlich hat aber auch Pulumi viele Anhänger. Dann gibt es natürlich auch noch Anbieter-Frameworks wie AWS CloudFormation und die Möglichkeit, Ressourcen nicht über einen Cloudorchestrierer zu definieren, sondern direkt native Ressourcendefinitionen in seinem CI/CD vorzusehen, also etwa direkt Kubernetes-Ressourcen-Templates beizusteuern. Ein großer Haken bei der Einführung eines Werkzeugs wie Spacelift ist dann oft, dass viel schon vorhandener Code in der Mülltonne landet, weil die jeweilige Lösung damit schlicht nichts anfangen kann. Spacelift allerdings gibt sich hier vielfältig.
Zu den unterstützten Formaten gehören Terraform und dessen Fork OpenTofu ebenso wie Pulumi, Ansible oder AWS CDK. Auch mit Code im Format von Serverless kann Spacelift umgehen. Terragrunt steht ebenfalls als Option bereit. Wer es etwas bodenständiger mag, kann Spacelift stattdessen auch Quelltext direkt im AWS CloudFormation-Format verfüttern oder dem Programm native Kubernetes-Ressourcen-Definitionen unterjubeln. Schließlich ist auch noch eine Ansible-Integration für klassische Automatisierung enthalten.
Im Vergleich mit anderen Werkzeugen befindet sich Spacelift mithin auf Augenhöhe und liefert eine solide Leistung, verkneift sich aber das Sahnehäubchen auf der Torte, weil es exotischere Werkzeuge wie Cloudify oder Cycloid nicht unterstützt.
Bild 3: Neben Slack beherrscht Spacelift auch die Integration in Microsoft Teams. Andere Werkzeuge wie OpsGenie sind aber nur per Webhook nutzbar.
Hohe Sicherheit dank Policies
Durchaus oberhalb des Niveaus anderer Werkzeuge liegt Spacelift in Sachen Sicherheit. Das geht damit los, dass eine Single-Sign-on-Funktion ebenso zur Verfügung steht wie die Verwendung vorhandener Accounts der großen Anbieter. Das setzt sich wie beschrieben bei der internen Organisation von Spacelift fort, die uns ermöglichte, Spaces einzurichten und so die Trennung von Verantwortlichkeiten im Unternehmen samt RBAC effektiv umzusetzen. Und das endet bei klassischen Nebenfunktionen in Sachen Security und Compliance, etwa der Möglichkeit, für Auditierungen einen Audit-Trail samt allen ausgelösten Arbeitsschritten bei Runs in CI/CD-Pipelines zu erstellen.
Selten findet sich bei vergleichbaren Werkzeugen zudem ein Policy-Framework, wie Spacelift es umsetzt. Die Idee hinter Policies in Kubernetes ist, Workloads auf ihrem Weg zum Deployment abzufangen, sodass potenzielle Sicherheitsprobleme erst gar nicht zum Tragen kommen. Spacelift implementiert entsprechende Anker für Policies auf Basis des Open Policy Frameworks samt OPA (Open Policy Agent). So waren wir in der Lage, direkt in Spacelift Regeln festzulegen, denen Deployments folgen mussten.
Verletzte ein Deployment eine dieser Regeln, verhinderte Spacelift, dass der entsprechende Code in der Produktion landete und quittierte den Dienst stattdessen mit einem Fehler. Der Fantasie hinsichtlich der einzubindenden Regelwerke sind dabei praktisch keine Grenzen gesetzt. Wer zum Beispiel verhindern möchte, dass bestimmte Abbilder mit bekannten Sicherheitsproblemen in Produktion gelangen, kann die Policy-Engine an einen Vulnerability-Scanner koppeln und bei entsprechend hohem Punktwert beim Sicherheitsscan die Ausführung untersagen.
Wer das Ausführen bestimmter Container-Abbilder ganz verbieten oder nur per Whitelist erlauben möchte, findet auch dafür in der Policy-Engine das notwendige Werkzeug.
Darüber hinaus ließen sich die Regeln auch für eine Art RBAC in Spacelift selbst verwenden. So konfigurierten wir beispielsweise beim Deployment von CI/CD eine Art Kontrolle per Policy, die einen Run nach erfolgreicher Ausführung einzelner Etappen in eine Wartestellung übergibt, bis von einer hierfür autorisierten Person die Erlaubnis zum Fortfahren vorliegt. In Summe machen die Security-Features von Spacelift Lust auf mehr.
Bild 4: Spacelift stellt einen Prometheus-Exporter zur Verfügung, der Daten aus GraphQL empfängt und sie danach in einer Prometheus-Instanz ablegt. Das erlaubt die Visualisierung mit Grafana.
Nur begrenztes Monitoring
Die beste CI/CD-Umgebung ist wertlos, wenn sie sich nicht sinnvoll überwachen lässt. Das umfasst freilich den Zustand eines Deployments nach einem erfolgreichen Run ebenso wie die Artefakte, die währenddessen angefallen sind. Das Monitoring erstreckt sich aber auch über etwaige Statistiken hinsichtlich der Zeit, die ein Run in Anspruch nimmt und schließt viele weitere Faktoren ein.
Spacelift verbindet hier eigene Funktionalität geschickt mit externen Werkzeugen. So zeigt sich das Observability-Werkzeug als praktisch nahtlose Integration mit Datadog. Spacelift bietet zudem eine Schnittstelle für GraphQL, mit deren Hilfe sich im System hinterlegte Daten abfragen lassen. Allerdings ist Datadog ein ebenfalls in der Cloud gehosteter Dienst und ruft zusätzliche Kosten auf, während die GraphQL-Implementierung ohne eigenes Tooling im Hintergrund weitgehend nutzlos ist. So läuft es leider darauf hinaus, dass IT-Verantwortliche entweder Datadog nutzen, um ihre Daten aus der Plattform zu fischen, oder das mühsam mittels GraphQL selbst erledigen müssen.
Mit einer Ausnahme: Wer auf Prometheus setzt, jene Zeitreihendatenbank, die in Sachen Observability aktuell als Quasi-Standard gilt, bekommt vom Hersteller auf Wunsch den Prometheus-Exporter für Spacelift. Das ist eine Art Mittler zwischen GraphQL und dem nativen Prometheus-Format. Über diesen lässt Spacelift sich auch an andere Dienste anflanschen, die das Format von Prometheus verstehen, etwa VictoriaMetrics. Obendrein ist es möglich, mittels dieses Wandlers auch Metrikdaten aus Spacelift in Grafana zu visualisieren. In Summe bleiben die Observability-Fähigkeiten von Spacelift allerdings hinter den Leistungen vergleichbarer Produkte zurück.
Fazit
Alles in allem präsentiert Spacelift sich mithin als potente CI/CD-Plattform, die insbesondere Admins auf dem Schirm haben sollten, die nicht viel Zeit und Energie in die Pflege einer eigenen IaC-Umgebung investieren wollen oder können. Es überzeugt durch eine durchdachte Benutzeroberfläche, die viele Abkürzungen bietet, auf Wunsch aber auch ein hohes Maß an Flexibilität für spezifische Setups ermöglicht. Art und Umfang der unterstützten Werkzeuge für IaC-Code sind marktkonform und hinsichtlich der unterstützten Zielplattformen liegt der Fokus auf den Hyperscalern. Dies macht das Angebot allerdings für IT-Verantwortliche, die beispielsweise in Europa beheimatet sind und Spacelift lieber auf eigener Infrastruktur betreiben möchten, unnötig unattraktiv. Daran ändert auch die Tatsache nichts, dass große Unternehmen auf Wunsch ihre eigene Spacelift-Instanz auf AWS starten können, statt sich den öffentlichen Spacelift-Dienst mit anderen zu teilen. Sinnvoller wäre es, Spacelift als echte On-Premises-Anwendung anzubieten.
Ebenso sinnvoll wäre es, bei den umfangreichen Zusatzfunktionen Unterstützung für weitere externe Kommunikationssysteme einzubauen. Webhooks sind nützlich, aber CI/CD-Systeme kommunizieren mit ihren Betreibern. Slack und Microsoft Teams sind hierfür ein solides Fundament, wir würden uns aber auch Schnittstellen zu anderen Diensten wie OpsGenie wünschen. Das scheint in Summe aber gar nicht der Spacelift-Anspruch zu sein. Wie ein roter Faden zieht sich der Ansatz durch den Dienst, eine solide Leistung für die gängigsten Produkte zu schaffen, dabei aber auf Beiwerk und Schnickschnack zu verzichten.
Marktüblich ist bei Spacelift auch bei den unterstützten Formaten für eingehenden IaC-Code unterwegs. Terraform und OpenTofu, Pulumi, CloudFormation, Ansible, native Kubernetes-Definitionen und mehrere exotische Formate sorgen dafür, dass für die allermeisten Administratoren etwas Brauchbares zu finden sein sollte. Dass Spacelift dabei bereits vorhandenen Code recyclen kann, dürfte die Migrationsbereitschaft vielerorts erheblich vergrößern. Denn schon gemachte Arbeit landet bei der Einführung von Spacelift so nicht zwangsläufig im Papierkorb.
Keine Blöße gibt sich Spacelift zudem in Sachen Security und Compliance. Single Sign-on, ein umfangreiches Framework für Policy-Regeln, die auf die ausgerollten Workloads durchschlagen, Stacks, die für eine "Separation of Concern" bei der Arbeit mit Spacelift sorgen, darin ein umfangreiches RBAC und viele weitere Sicherheitseinstellungen sowie die Möglichkeit eines umfangreichen Audit-Trails sprechen eine deutliche Sprache.
(jp)
So urteilt IT-Administrator
Inbetriebnahme
6
Einsatz als CI/CD-Pipeline
6
Unterstützte IaC-Formate
6
Security
7
Monitoring
5
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik/