Container vs. Datei-Labeling: Verwechslungen einfach erklärt

Von Mirko Peters · 2026-04-22

Wenn Sie schon einmal mit Containern gearbeitet haben, wissen Sie, dass es einen großen Unterschied zwischen dem Labeln einer Datei, dem Taggen eines Images und der Verwaltung von Kubernetes-Ressourcen gibt …

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Wenn Sie schon einmal mit Containern gearbeitet haben, wissen Sie, dass es einen großen Unterschied zwischen dem Labeln einer Datei, dem Taggen eines Images und der Verwaltung von Kubernetes-Ressourcen gibt. Trotzdem werden diese Begriffe in heutigen DevOps-Pipelines täglich durcheinandergebracht. Entwickler- und Ops-Teams wundern sich oft, wenn ein Container mit dem Label „v1.3“ nicht zu der Version passt, die in einer Konfigurationsdatei steht, oder zu dem Label, das an einem Kubernetes-Pod hängt.

Diese Verwechslung ist nicht nur ärgerlich. Sie kann ernsthafte Risiken mit sich bringen: fehlgeschlagene Deployments, Sicherheitsprobleme und Compliance-Lücken, die sich nur schwer nachverfolgen lassen. Da sich Container-Technologie in Cloud- und Hybrid-Umgebungen immer weiter verbreitet, ist ein klares Verständnis dieser Labeling-Systeme geschäftskritisch.

Dieser Leitfaden räumt mit dem Rauschen auf. Wir erklären Container, Dateien, Labels und Tags, zeigen die Überschneidungen in CI/CD-Pipelines und stellen bewährte Verfahren ebenso vor wie die modernen Fallen, die Sie vermeiden sollten. Am Ende wissen Sie, worum es geht und wie Sie dem Labeling-Chaos gezielt aus dem Weg gehen.

Grundlagen von Containern und Labeling verstehen

Container haben verändert, wie IT-Teams Anwendungen bereitstellen, verwalten und skalieren. Anders als klassische Pakete – denken Sie an .zip-Dateien oder .exe-Installer – bündelt ein Container nicht nur die Anwendungsdateien, sondern auch alle Abhängigkeiten, Konfigurationen und Bibliotheken, die Ihre App benötigt, um überall zu laufen.

Das Herzstück der Zuverlässigkeit von Containern sind Metadaten. Man kann sich Metadaten als die Info „Was steckt in dieser Box?“ vorstellen: wer sie erstellt hat, welche Version sie ist und wofür sie gedacht ist. Labels sind ein einfacher, aber entscheidender Mechanismus, um diese Metadaten an Images und laufende Container zu heften. Sie arbeiten mit Schlüssel-Wert-Paaren – einfachen, strukturierten Angaben wie version=2.1 oder owner=finance –, mit denen sich Ressourcen im großen Maßstab leicht suchen, organisieren und steuern lassen.

Beim Wechsel von Dateien zu Containern kommt es häufig zu Verwirrung, unter anderem weil Container die Grenzen verwischen: Die Dateien und Konfigurationen Ihrer App sind im Image verpackt, die „Identität“ dieses Images – auch seine Version – lässt sich jedoch separat als Label oder Tag festlegen. Plötzlich verfolgen Sie nicht nur, was in einer Datei steckt, sondern auch, was auf der Box steht und wie sie in Kubernetes bereitgestellt wird, wo wiederum ein eigenes Label-System greift.

Diese Labeling-Grundlagen sauber zu beherrschen, ist mehr als eine Formalie. Sie sorgen dafür, dass Ihre Fehlersuche präzise bleibt, Ihre Audits sauber sind und Ihre Deployments zuverlässig laufen – besonders dann, wenn Ihr Workflow zwischen Entwickler-Laptops, CI/CD und Cloud wechselt. Als Nächstes schauen wir uns genauer an, wie Dateien und Versionen in Containern tatsächlich funktionieren und warum das für Sie wichtig ist.

Wie Dateien, Konfigurationen und Versionen in Containern funktionieren

Ein Container-Image entsteht aus einem Snapshot des Dateisystems und bündelt alles, was Ihre App braucht: Code, Binärdateien, Konfigurationsdateien und deren jeweilige Versionen. Anders als klassische Paketdateien (.zip, .msi, .deb), die einfach verschoben und entpackt werden, garantieren Container Unveränderlichkeit: Ist das Image einmal erstellt, sollte sich sein Inhalt nicht mehr ändern.

Versionierung funktioniert in klassischen Deployments einfach: Dateien aktualisieren, Versionsnummern anpassen und das Changelog pflegen. In Containern wird es komplizierter, denn die Version in einer Konfigurationsdatei (etwa package.json oder appsettings.json) muss nicht mit dem Tag oder Label übereinstimmen, das dem Image beim Build und Deployment zugewiesen wird.

Daraus kann ein Drift entstehen: Der Code in einem laufenden Container meldet möglicherweise Version 1.1, während das Image tatsächlich mit „latest“ oder „v2.0“ getaggt ist. Aktualisiert Ihr CI-Prozess die Codedatei, aber nicht das Docker-Tag (oder umgekehrt), entsteht eine Abweichung, die sich nur schwer erkennen und noch schwerer beheben lässt. Das gilt besonders, wenn automatisierte Builds oder Skripte Labels aus früheren Phasen übernehmen, während die statischen Dateimetadaten unverändert bleiben.

Dieses Zusammenspiel zu verstehen, ist entscheidend. Die Dateien und Konfigurationen zeigen, was tatsächlich enthalten ist; Image-Tag und Labels zeigen, was laut dem Team, das es gebaut oder ausgeliefert hat, enthalten sein soll. Für eine effektive Fehlersuche und Compliance müssen beide zusammenpassen. Andernfalls riskieren Sie Geister-Versionen in der Produktion und jagen falschen Audit-Trails hinterher.

Versionierung und Tagging von Containern nach bewährten Verfahren

Sobald Sie verstanden haben, wie Dateien und Versionen innerhalb eines Containers abgelegt werden, besteht die nächste Herausforderung darin, den Überblick über Ihre Images zu behalten, während sie durch Build-, Test- und Deployment-Pipelines laufen. Genau hier spielen Container-Tagging und Versionierung eine Rolle, und zwar nicht nur der Ordnung wegen, sondern damit Sie wissen, was wo und warum läuft.

Container-Tags fungieren als Verweise oder Lesezeichen, mit denen Sie Ihre Images benennen und organisieren. Anders als bei der Dateiversionierung können Container-Tags jedoch veränderlich sein. „latest“ etwa bedeutet zu unterschiedlichen Zeitpunkten Unterschiedliches. Durchdachte Tagging-Strategien, die semantisch klar und konsistent angewendet werden, sind der wichtigste Schutz vor Mehrdeutigkeit in Ihrem DevOps-Lebenszyklus.

Wenn sich Ihr Team allein auf Tags verlässt, kann ein falsch gesetzter oder mehrfach verwendeter Tag das falsche Image in die Produktion bringen. Bewährte Praktiken gibt es aus gutem Grund: Veränderliche Tags sollten in kritischen Deployments vermieden werden, semantische Versionierung ist zu verwenden, und Namenskonventionen sollten vorhersehbar sein, insbesondere wenn Images zwischen Registries oder Clouds verschoben werden.

In den folgenden Abschnitten erklären wir genau, wie Container-Tags und Versionen funktionieren, zeigen die subtilen Unterschiede zu dateibasierten Systemen auf und stellen praxisnahe Muster vor, mit denen sich dieses Durcheinander beherrschen lässt. So behalten Sie den Überblick, wenn Ihre Workflows komplexer werden.

Wie Container-Versionierung und Docker-Tags tatsächlich funktionieren

Container-Images werden über Tags versioniert, also textuelle Referenzen wie „v1.2.0“, „release-2024-06“ oder schlicht „latest“. In Docker und anderen Container-Tools ist ein Tag einem eindeutigen Image-Digest zugeordnet, der den tatsächlichen Inhalt und die Layer des Images repräsentiert.

Tags sind nicht unveränderlich. Ein Tag wie „latest“ oder auch „v1.2.0“ kann versehentlich oder absichtlich verschoben werden und dann ohne Vorwarnung auf einen neuen Image-Build zeigen. Diese Veränderlichkeit birgt Risiken in Produktionsumgebungen, in denen Nachvollziehbarkeit wichtig ist. Einige Registries bieten Funktionen zur Tag-Unveränderlichkeit an, doch nicht alle Repositories erzwingen sie standardmäßig.

Semantische Versionierung (z. B. „1.4.2“) ist für Image-Tags weit verbreitet und orientiert sich an bewährten Praktiken klassischer Software: Größere Änderungen erhöhen die erste Ziffer, kleinere Updates die zweite und so weiter. Der Haken dabei: Der Tag eines Container-Images ist nur das äußere Etikett. Die Dateien im Inneren können eigene Versionen tragen, etwa ein Python-Paket oder eine Node-App. Ohne konsequente Pflege können Container-Tags und interne Anwendungsversionen leicht auseinanderlaufen.

In DevOps-Tools und Deployment-Skripten bestimmen Tags, welches Image bereitgestellt, abgerufen oder auf Schwachstellen geprüft wird. Stimmen Ihre Tags nicht mit dem überein, was tatsächlich im Image steckt, etwa mit Konfigurations- oder Paketversionen, kann es zu „Deployment-Drift“ oder zu falschen Hinweisen bei der Fehlersuche in der Produktion kommen. Genau diese Spannung zwischen äußerem Etikett und innerem Inhalt macht das Verständnis von Container-Tags für saubere, zuverlässige Builds unverzichtbar.

Bewährte Praktiken für Container-Tagging und Namenskonventionen

• Immer semantische Versionierung verwenden: Setzen Sie auf klare, strukturierte Tags wie v1.2.3, die größere, kleinere und Patch-Änderungen abbilden. Dieser Ansatz macht die Absicht und den Status deutlich, reduziert Mehrdeutigkeit und vereinfacht Rollbacks sowie Audit-Trails.
• „latest“ in der Produktion vermeiden: Das Tag „latest“ ist praktisch, aber gefährlich veränderlich. Wer ein mit „latest“ gekennzeichnetes Image bereitstellt, riskiert, das zuletzt hochgeladene Image zu ziehen, das möglicherweise nicht Ihrer Absicht entspricht. Verwenden Sie für Produktionsreleases unveränderliche, versionierte Tags.
• Build-Metadaten bei Bedarf ergänzen: Ergänzen Sie Versions-Tags um Build-Nummern, Commit-Hashes oder Zeitstempel, um die Nachvollziehbarkeit zu erhöhen. Beispielsweise verknüpft „v2.0.1-20240618-commit123abc“ das Image direkt mit einem Code-Stand.
• Interne und externe Versionen abgleichen: Stellen Sie sicher, dass Ihr Container-Tag mit der Version übereinstimmt, die in den Dateien im Container gemeldet wird (etwa in package.json oder Manifest-Dateien). Automatisieren Sie die Versionsübernahme in CI/CD, um manuelle Abweichungen zu vermeiden, die Deployment-Drift verursachen.
• Namensmuster teamübergreifend standardisieren: Verwenden Sie ein einheitliches Schema für Registry- und Repository-Namen, z. B. „registry.example.com/teamname/appname:tag“, damit neue Teammitglieder nicht verwirrt werden und Images nicht versehentlich überschrieben werden. Legen Sie Trennzeichen, Groß- und Kleinschreibung sowie die Reihenfolge der Bestandteile verbindlich fest.
• Images mit aussagekräftigen Metadaten versehen: Neben Tags sollten Sie Labels wie org=finance, environment=prod oder compliance=HIPAA vergeben. Strukturierte Metadaten unterstützen Automatisierung, Governance und Audits, besonders in großen, regulierten Microsoft- und Azure-Umgebungen.
• Verwaiste Tags und Images bereinigen: Entfernen Sie regelmäßig nicht verwendete Tags und Images, um Ballast zu reduzieren, Speicherplatz zu sparen und die versehentliche Bereitstellung veralteten Codes zu verhindern.

Labels, Annotationen und Namespaces in Kubernetes

Kubernetes führt das Konzept von Labels und Metadaten auf die nächste Stufe. Statt nur Dateien oder Images zu ordnen, verwendet es Labels und Annotationen, um zu steuern, wie ganze Cluster aus Containern verwaltet, überwacht und automatisiert werden.

Labels fungieren als Selektoren: kleine, strukturierte Tags, mit denen Sie Workloads auf vielfältige Weise gruppieren, filtern oder gezielt ansprechen können. Sie können beispielsweise ein Update an jeden Pod mit dem Label „tier=backend“ ausrollen oder alle Ressourcen mit dem Label „env=staging“ einfach überwachen. Diese einfachen Schlüssel-Wert-Markierungen treiben einen großen Teil der Infrastruktur-Automatisierung an.

Annotationen dienen dagegen eher beschreibenden Metadaten für Menschen: Informationen, die Sie an einer Ressource hinterlegen möchten, nach denen Sie im laufenden Betrieb aber nie filtern oder selektieren müssen. Diese Unterscheidung ist wichtig, denn wenn Sie das falsche Feld an der falschen Stelle verwenden, werden Ihre Deployments unübersichtlich und Ihre Automatisierung wird fragil.

Namespaces fügen eine weitere Ebene hinzu, indem sie Ihren Cluster in Teilumgebungen unterteilen. Damit isolieren Sie Ressourcen für verschiedene Teams, Anwendungen oder Geschäftsbereiche, was für die Skalierung und Absicherung von Unternehmenssystemen entscheidend ist. Im Folgenden zeigen wir Ihnen, welche Auswirkungen diese Konzepte haben und wie Sie sie für ein robustes, zuverlässiges Ressourcenmanagement nutzen, damit Ihnen die Umgebung nicht außer Kontrolle gerät.

Kubernetes-Labels und Annotationen für das Ressourcenmanagement

In Kubernetes sind Labels Schlüssel-Wert-Paare (zum Beispiel app=frontend, release=stable), die an Objekte wie Pods, Deployments oder Services angehängt werden. Ihre Hauptaufgabe besteht darin, Ressourcen zu organisieren, auszuwählen und zu filtern, besonders in großen Umgebungen.

Labels werden von Selektoren verwendet: Wenn Sie alle Pods mit version=v2 aktualisieren oder Ressourcen mit env=dev entfernen möchten, beziehen Sie sich auf die Labels dieser Objekte, um Massenoperationen präzise auszuführen. Genau dieses Abgleichen macht die Kubernetes-Automatisierung so dynamisch und skalierbar.

Annotationen sind ebenfalls Schlüssel-Wert-Paare, sind aber ausschließlich dafür gedacht, Metadaten anzuhängen, die in der Selektionslogik keine Rolle spielen. Typische Beispiele sind ein Build-Zeitstempel, eine Beschreibung oder auch ein Compliance-Hinweis. Annotationen können größere oder komplexere Werte aufnehmen und unterstützen Anwendungsfälle wie die Nachverfolgung von Richtlinien oder Integrationen von Drittanbietern (etwa einen Slack-Benachrichtigungshinweis oder gespeicherte Git-Commit-Informationen).

Ein häufiger Fehler ist es, Labels mit Informationen zu überladen, die eigentlich in eine Annotation gehören, etwa vollständige Änderungsprotokolle oder Beschreibungen. Das verstopft die Selektorlogik und kann die Leistung beeinträchtigen. Umgekehrt sollten kritische Informationen, die die Auswahl beeinflussen (zum Beispiel Umgebung oder Rolle), als Label hinterlegt werden und nicht in einer Annotation versteckt sein.

Wenn Labels und Annotationen richtig eingesetzt werden, entstehen robuste, wartbare Cluster. Konsistente Labels ermöglichen intelligente Abfragen und automatisierte Aktionen, während saubere Annotationen Ihre Metadaten für Audits oder Post-Mortem-Analysen gut dokumentiert halten.

Namespaces und hierarchische Organisation für große Umgebungen

Namespaces in Kubernetes wirken als Partitionen innerhalb eines Clusters. Sie trennen Workloads, sodass sich Teams, Anwendungen oder Umgebungen nicht in die Quere kommen. Jeder Namespace bildet einen isolierten Ressourcenpool und unterstützt sowohl die Zugriffssteuerung als auch übersichtlichere Audit-Protokolle.

Eine hierarchische Organisation geht einen Schritt weiter: Sie können Richtlinien oder Berechtigungen auf Namespace-Ebene zuweisen. Das ist für Unternehmensumgebungen mit Plattformen wie Azure oder Microsoft 365 besonders wichtig. Diese Struktur schafft klare Verantwortlichkeiten und verringert das Risiko, dass Teams sich versehentlich gegenseitig beeinflussen. Weitere Informationen zu Governance-Problemen in großem Maßstab finden Sie unter warum Microsoft-365-Governance scheitert und wie Sie das beheben.

Container-Registries, Spiegelung und Fallstricke im Workflow

Auf dem Weg vom Code zur Produktion durchläuft jedes Container-Image eine Registry, ob öffentlich oder privat. Wie Sie Ihre Registries strukturieren, Ihre Images benennen und die Spiegelung handhaben, wirkt sich direkt auf Zuverlässigkeit und Compliance aus, besonders in regulierten oder verteilten Microsoft-Azure-Umgebungen.

Namenskonventionen in Registries sind nicht nur eine Frage der Bequemlichkeit. Vorhersehbare Konventionen und eine sorgfältige Trennung der Repositories helfen DevOps-Teams, Image-Kollisionen, Probleme beim Onboarding und die klassische Frage „Welche Version läuft hier eigentlich?“ zu vermeiden. Zusätzliche Zugriffskontrollen stellen sicher, dass Teammitglieder – oder Build-Bots – nur auf die Inhalte zugreifen können, für die sie vorgesehen sind.

Für viele Organisationen ist Hochverfügbarkeit keine bloße Empfehlung. Registry-Spiegelung ermöglicht es, Images über Regionen hinweg zu replizieren oder in isolierten („Air-Gapped“) Umgebungen bereitzustellen. Diese Strategie reduziert Ausfallzeiten erheblich, bringt aber auch potenzielle Stolperfallen mit sich: Abweichungen zwischen Spiegeln, verzögerte Synchronisierung und versehentliche Referenzfehler.

Dieser Abschnitt erläutert das „Warum“ und „Was“ der Registry-Organisation und -Spiegelung, damit Sie die Verwirrung vermeiden können, die Workflows lahmlegt und regulatorische Probleme verursacht. Die konkreten Praktiken und schnellen Tipps folgen in den nächsten Abschnitten.

Verwaltung von Registries und Strategien für die Benennung von Containern

Konsistente Benennung und Zugriffskontrolle bilden das Fundament einer sicheren und effizienten Registry-Verwaltung. In Azure hilft beispielsweise eine regionale Registry-Einrichtung, niedrige Latenzzeiten und hohe Verfügbarkeit aufrechtzuerhalten, insbesondere für Enterprise-Workloads in Power BI oder Fabric.

Die Organisation Ihrer Repositories nach Team, Anwendung oder Umgebung verhindert versehentliches Überschreiben und Verwirrung beim Onboarding. Einheitliche Benennung über alle DevOps-Teams hinweg sorgt dafür, dass neue Mitarbeitende die richtigen Images schnell finden und bereitstellen können, und Legacy-Code geht nicht in einem Labyrinth verloren. Eine solide Struktur und klar definierte Zugriffsrollen verhindern außerdem Fehler wie das Überschreiben eines Produktions-Images mit Testcode.

Registry-Spiegelung und die Bewältigung von Herausforderungen bei der Image-Verteilung

• Hochverfügbarkeit: Die Spiegelung von Registries über Rechenzentren oder Regionen hinweg hält Images auch während Ausfällen erreichbar.
• Geringere Latenz: Images nah an der Laufzeitumgebung zu halten, beschleunigt Pulls und verbessert so Bereitstellungs- und Skalierungszeiten.
• Unterstützung von Air-Gapped- oder regulierten Umgebungen: Gespiegelte Registries ermöglichen es Organisationen – insbesondere im Finanz- oder Gesundheitswesen –, ohne direkten Internetzugang bereitzustellen und so Compliance- und Segmentierungsanforderungen zu erfüllen.
• Eindämmung von Sync-Drift: Richten Sie automatisierte Richtlinien für Image-Promotion und -Validierung ein, um Versionsabweichungen zwischen gespiegelten Standorten zu vermeiden. Mehr dazu, wie sich mit dem Governance-by-Design-Ansatz von Azure Richtlinien-Drift verhindern lässt, finden Sie hier.

Zentrale Stolperfallen beim Betrieb: Laufzeitkonfiguration, Speicher und Protokolle

Die Wahl einer Container-Laufzeit wie containerd oder cri-o bestimmt nicht nur, wie Images ausgeführt werden, sondern auch, wie ephemerer Speicher, Protokolle und die Konfiguration auf Knotenebene behandelt werden. Jede Laufzeit bringt Kompromisse bei der Image-Verarbeitung, der Protokollrotation und der Verwaltung persistenter Daten auf dem Knoten mit sich.

Ephemerer Speicher – schneller, nicht persistenter Datenträger, den Container für temporäre Dateien nutzen – kann sich rasch füllen. Dann kann Kubernetes laufende Pods verdrängen, was zu unvorhersehbaren Ausfallzeiten führt. Dieser Datenträgerdruck ist eine der häufigsten Ursachen für verlorene Protokolle, unvollständig geschriebene Daten und Probleme bei der Nachverfolgung, welche Version oder Konfiguration tatsächlich aktiv war.

Wenn Protokolle und zustandsbehaftete Dateien unerwartet verloren gehen oder rotiert werden, wird es schwierig, einen Fehlerbericht oder Vorfall einer bestimmten Image-Bezeichnung oder internen Dateiversion zuzuordnen. Dieses Risiko wächst in verteilten Azure- oder Microsoft-Fabric-Umgebungen, in denen Governance auch Compliance und Nachvollziehbarkeit berücksichtigen muss. Wenn Sie sich ausschließlich auf nachträgliche Data-Lineage-Werkzeuge verlassen, bedenken Sie: Sichtbarkeit ist keine Echtzeit-Durchsetzung von Richtlinien. Mehr dazu finden Sie unter den Grenzen der Governance in Microsoft Fabric.

Wenn Laufzeitkonfiguration, Protokollierung und ephemerer Speicher korrekt eingerichtet sind, müssen Sie während Vorfällen weniger improvisieren. Außerdem sinkt das Risiko eines „Label-Drifts“, bei dem das äußere Label nicht mehr mit den Dateien übereinstimmt, die zur Laufzeit im Container liegen. Diese Elemente konsistent zu halten, ist für die Zuverlässigkeit in Unternehmen entscheidend.

Häufige Fehler vermeiden: Labels, Tags und Dateiversionen

• Tags sind nicht unveränderlich: Prüfen Sie stets die Einstellungen und Workflows Ihrer Registry. Ein Tag kann morgen auf ein anderes Image zeigen.
• Image-Tags mit internen Dateiversionen abgleichen: Automatisieren Sie die Übernahme der Versionsnummern, damit die von der Datei gemeldeten Versionen mit dem Container-Tag und dem Label übereinstimmen. Manuelle Schritte laden geradezu zu Abweichungen ein.
• Labels zielgerichtet und präzise einsetzen: Verwenden Sie in Kubernetes Labels für die Ressourcenauswahl (z. B. Umgebung, Rolle) und Annotationen für Kommentare. Wer beides vermischt, verwirrt Menschen und Automatisierung gleichermaßen.
• Schulen und dokumentieren: Stellen Sie sicher, dass alle Teammitglieder ein klares mentales Modell haben. Nutzen Sie beim Onboarding Analogien („Label als Namensschild, Datei als Ausweis“), um Shadow IT oder eigenmächtige Deployments zu verhindern.

Fazit, Das Wichtigste in Kürze und weiterführende Informationen

Der Unterschied zwischen Container-Labels, Dateiversionen und Tags ist das Fundament für zuverlässiges und prüfbares DevOps. Eine Studie von Red Hat ergab, dass fehlerhaft vergebene Image-Tags und Verwechslungen bei Versionen fast ein Drittel aller schwerwiegenden Ausfälle in containerbasierten Umgebungen verursachten. Praxisexperten empfehlen, das Image-Tagging zu vereinheitlichen, Dateimetadaten bereits während des Builds einzubinden und einheitliche Labeling-Muster zu verwenden, um Lücken im Audit zu schließen.

Zur Vertiefung der systemweiten Governance empfehlen wir Ihnen, nachzulesen, wie Microsofts Plattformansatz echtzeitfähige, prüfbare Compliance ermöglicht, und warum werkzeugzentrierte Governance in großen Organisationen regelmäßig scheitert. Der Austausch mit den Communities von Microsoft, Kubernetes und Containern eröffnet neue gemeinsame Erkenntnisse und praxisnahe Rahmenwerke. Lernen, teilen und verfeinern Sie Ihre Labeling- und Deployment-Playbooks weiter.