AZURE BLOB → STACKIT OBJECT STORAGE · TUTORIAL
Azure Blob Storage zu STACKIT Object Storage
Ein Storage Account mit zwei Containern wird zu zwei STACKIT-Buckets. Dieses Tutorial lässt StackToIT über eine kleine Demo-Umgebung laufen, zeigt das erzeugte Terraform und führt auf, was Sie anschließend von Hand setzen: Versionierung, Lifecycle-Regeln, eine Kopie in einer zweiten Region und den Wechsel vom Azure-Storage-SDK zu einem S3-Client.
Die Demo-Eingabe und der Entwurf
Ein Storage Account mit Versionierung, Soft Delete, georedundanter Replikation, zwei privaten Containern und einer Lifecycle-Regel, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Eingabe, rechts die Ressourcenblöcke des STACKIT-Terraforms, das die Engine geschrieben hat; die Prüfkommentare über jedem Block in der Datei sind hier ausgelassen. Die Eingabeblöcke stehen in main.tf nicht direkt hintereinander; jeder steht deshalb wörtlich in einem eigenen Ausschnitt.
resource "azurerm_storage_account" "media" {
name = "stmediagwc01"
resource_group_name = azurerm_resource_group.media.name
location = azurerm_resource_group.media.location
account_kind = "StorageV2"
account_tier = "Standard"
account_replication_type = "GRS"
access_tier = "Hot"
min_tls_version = "TLS1_2"
allow_nested_items_to_be_public = false
blob_properties {
versioning_enabled = true
delete_retention_policy {
days = 14
}
container_delete_retention_policy {
days = 7
}
}
}
resource "azurerm_storage_container" "invoices" {
name = "invoices"
storage_account_id = azurerm_storage_account.media.id
container_access_type = "private"
}resource "azurerm_storage_management_policy" "media" {
storage_account_id = azurerm_storage_account.media.id
rule {
name = "archive-old-exports"
enabled = true
filters {
prefix_match = ["exports/"]
blob_types = ["blockBlob"]
}
actions {
base_blob {
tier_to_cool_after_days_since_modification_greater_than = 30
delete_after_days_since_modification_greater_than = 365
}
}
}
}resource "stackit_objectstorage_bucket" "media" {
project_id = var.project_id
name = "stmediagwc01-exports"
}
resource "stackit_objectstorage_bucket" "media_2" {
project_id = var.project_id
name = "stmediagwc01-invoices"
}Ein Account, je Container ein Bucket
Azure gruppiert Container unter einem Storage Account. STACKIT Object Storage kennt Buckets, und Buckets lassen sich nicht schachteln. Der Lauf schreibt für jeden Container einen Bucket und benennt ihn nach Account und Container, hier stmediagwc01-exports und stmediagwc01-invoices.
Nur Name und Projekt
Die Bucket-Ressource des fixierten STACKIT-Providers kennt einen Namen und eine Object-Lock-Einstellung. Kontoart, Performance-Stufe, Zugriffsstufe, Replikation, Versionierung und Lifecycle-Regel werden daher nicht erzeugt, und die Datei benennt jede davon in einem Kommentar „NOT CARRIED“.
Die Klasse ist REPLATFORM
Azure Blob ist nicht S3-kompatibel: API, Authentifizierung und Upload-Protokoll unterscheiden sich. Der Lauf stuft den Account als REPLATFORM mit Konfidenz MEDIUM ein und verlangt, jede Anwendung zu finden, die ihn nutzt.
Den Lauf starten
Der Befehl liest das Terraform der Quelle und schreibt Bericht, Entwurf und Ausführungspaket in den Ausgabeordner. Er stellt keine Netzwerkanfrage und ändert in keiner der beiden Clouds etwas. Die Zusammenfassungszeilen unten sind aus der Konsole dieses Laufs kopiert.
stacktoit assess . ./out --offline --no-validateSource 5 resources · 1 unit · visibility: Complete
Migration 1 drafted (of 1 units the draft considered)
Target STACKIT Terraform generated
Attention 1 unit to review · 5 open requests (1 block the draft, marked in inputs-template.yaml)Fünf Ressourcen, eine Einheit
Storage Account, seine zwei Container und die Lifecycle-Richtlinie zählen als eine Einheit, weil sie alle in denselben Dienst umziehen. Der Entwurf enthält zwei Ressourcenblöcke, einen je Container.
Eine Anfrage blockiert den Entwurf
Der Lauf fragt zuerst nach der STACKIT-Region (eu01 oder eu02). Solange sie in der Inputs-Datei nicht beantwortet ist, bleibt der Entwurf ein Vorschlag, der sich nicht wie geschrieben planen lässt.
Welche Datei welche Frage beantwortet
- terraform/storage.tf
- Die zwei Buckets, mit einem Kommentar für jede Azure-Einstellung, die der Entwurf nicht übernimmt
- migration/data-movement.md
- Die Datenumzugstabelle: Die Einheit steht mit dem Mechanismus UNKNOWN darin, bis eine Person einen wählt
- execution/manual/actions.md
- Die manuellen Schritte, jeder mit verantwortlicher Rolle und Abschlusskriterium
- assurance/critical-semantics.json
- Die kritischen Einstellungen des Accounts und warum jede noch offen ist
- review/inputs.yaml
- Design-Antworten, zuerst die Zielregion
- review/decisions.yaml
- Prüfvermerke zu den Einstellungen des Accounts, einer je verantwortlicher Rolle
Was der Entwurf mit jeder Azure-Einstellung macht
| Azure-Einstellung in der Demo | Entscheidung des Laufs | Ihre Aufgabe |
|---|---|---|
| account_replication_type = GRS | Nicht erzeugt. STACKIT Object Storage hat keine verwaltete regionsübergreifende Replikation; der Lauf hält die Einstellung als UNSUPPORTED fest. | Entscheiden, ob die zweite Kopie nötig ist. Falls ja, einen Sync-Job in einen Bucket der zweiten Region einplanen. |
| versioning_enabled = true | Nicht erzeugt: Die Bucket-Ressource hat keine Versionierungseinstellung. | Versionierung über die S3-API aktivieren, sobald der Bucket existiert. Sie lässt sich später aussetzen, aber nicht abschalten. |
| delete_retention_policy, container_delete_retention_policy | Nicht erzeugt. Der Lauf fand für STACKIT Object Storage weder Soft Delete noch Point-in-Time-Restore. | Versionierung nutzen und Object Lock, wo Löschen verhindert werden muss. |
| storage_management_policy (nach 30 Tagen auf Cool, nach 365 Tagen löschen) | Nicht erzeugt: Die Bucket-Ressource des fixierten Providers hat kein Lifecycle-Attribut, und STACKIT dokumentiert keine Speicherstufen; der Wechsel auf Cool nach 30 Tagen hat daher kein Gegenstück. | Die Löschung nach 365 Tagen als S3-Lifecycle-Regel vom Typ Expiration am Bucket setzen (put-bucket-lifecycle-configuration, siehe STACKIT-Anleitung). Den Stufenwechsel streichen und prüfen, ob eine Regel Daten geschützt hat, die Sie nun behalten. |
| access_tier = Hot, account_tier = Standard | Nicht erzeugt; Kontoart und Stufen haben kein Gegenstück. | Keine; halten Sie es aber in der Architekturdokumentation fest. |
| Account- und Container-Namen | Fließen in den Bucket-Namen ein. Bucket-Namen sind innerhalb einer Region eindeutig. | Die Namen gegen alles prüfen, was auf den alten Account verweist. |
Gelesen aus den Kommentaren in terraform/storage.tf und den Befunden in assessment.json dieses Laufs.
Die Daten umziehen
StackToIT überträgt nie Daten: Die Datei zum Datenumzug führt die Einheit auf und überlässt das Verfahren einer Person. Üblich ist diese Reihenfolge.
1. Buckets und Zugangsdaten anlegen
Wenden Sie den geprüften Entwurf in einem Testprojekt an. Der Lauf nennt Credential-Ressourcen unter den Zielen des Accounts, schreibt aber nur die Buckets; legen Sie Access Key und Secret Key des Projekts selbst an, denn STACKIT verwaltet Zugangsdaten auf Projektebene.
2. Versionierung vor der ersten Kopie aktivieren
Führen Sie den Versionierungsbefehl aus der STACKIT-Dokumentation für jeden Bucket aus, der sie in Azure hatte, damit jedes spätere Überschreiben die ältere Version behält.
3. Daten kopieren
Nehmen Sie ein Werkzeug, das beide Protokolle spricht. Die Befehle unten sind ein Beispiel mit rclone; der Lauf selbst verweist auf rclone oder ein Kopierwerkzeug von Azure nach S3. Datenmenge, Änderungsrate und tolerierte Ausfallzeit entscheiden zwischen einer Kopie zum Cutover und wiederholten Syncs davor.
4. Vergleichen, dann Anwendungen umstellen
Vergleichen Sie Objektzahl und Größe je Bucket und stellen Sie die Anwendungen vom Azure-Storage-SDK auf ein S3-SDK um, von Account-Keys, SAS-URLs oder Entra-Tokens auf S3-Access-Keys.
5. Die Quelle behalten, bis die Prüfung steht
Lassen Sie den Azure-Account unangetastet, bis die neuen Buckets echten Verkehr bedient haben. Solange keine Anwendung ausschließlich nach STACKIT geschrieben hat, ist der Rückweg ein Konfigurationswechsel; danach kopieren Sie zuerst die neuen Objekte zurück.
Befehle für die Kopie
Praxis, keine StackToIT-Ausgabe. Das erste Fenster ist der Versionierungsbefehl aus der STACKIT-Dokumentation für den eu01-Endpunkt; das zweite zeigt eine Möglichkeit, mit rclone zu kopieren und zu vergleichen, mit den Demo-Namen.
aws --endpoint-url https://object.storage.eu01.onstackit.cloud s3api put-bucket-versioning \
--bucket $BUCKET_NAME \
--versioning-configuration Status=Enabled# for example, with rclone (not run by StackToIT)
rclone config create azblob azureblob account=stmediagwc01 key="$AZURE_STORAGE_KEY"
rclone config create stackit s3 provider=Other \
endpoint=https://object.storage.eu01.onstackit.cloud \
access_key_id="$STACKIT_ACCESS_KEY" secret_access_key="$STACKIT_SECRET_KEY"
rclone sync azblob:invoices stackit:stmediagwc01-invoices
rclone sync azblob:exports stackit:stmediagwc01-exports
rclone check azblob:invoices stackit:stmediagwc01-invoices --size-onlyVor dem Anwenden entscheiden
Region und Endpunkt
Jede Region hat ihren eigenen Endpunkt, für eu01 https://object.storage.eu01.onstackit.cloud, und ein Bucket in eu01 ist unabhängig von einem gleichnamigen in eu02. Beantworten Sie zuerst die Regionsanfrage.
Adressierungsstil
STACKIT unterstützt Virtual-Hosted- und Path-Style-Adressierung. Prüfen Sie, welchen Ihr S3-Client nutzt und ob er einen eigenen Endpunkt akzeptiert.
Historie
Entscheiden Sie, ob alte Versionen und per Soft Delete gelöschte Blobs mitziehen müssen. Ein einfacher Sync überträgt nur den aktuellen Stand; die Historie, die Azure vorhielt, liegt danach nicht auf STACKIT.
Öffentliche Container
Die Demo hat keine. Hat Ihre Umgebung Container mit öffentlichem Lesezugriff, braucht der Bucket ein ausdrückliches Zugriffskonzept, denn der Entwurf übernimmt die Zugriffsstufe nicht.
Fragen, die Storage-Teams stellen
Ist STACKIT Object Storage S3-kompatibel?
Ja. Die STACKIT-Dokumentation beschreibt eine S3-kompatible API über HTTPS; gängige S3-Werkzeuge funktionieren also damit. Azure Blob Storage ist nicht S3-kompatibel, weshalb Anwendungen Client und Zugangsdaten wechseln.
Legt der Entwurf die Access Keys an?
Nein. Für diese Demo schreibt er nur die zwei Buckets. Zugangsdaten werden bei STACKIT auf Projektebene verwaltet; legen Sie sie nach dem Apply an und geben Sie sie zum Cutover an die Anwendungen.
Was passiert mit der Lifecycle-Regel und mit Soft Delete?
Keines von beiden wird erzeugt, denn die Bucket-Ressource hat keine solche Einstellung; der Lauf führt beide als offene Einstellungen. STACKIT dokumentiert S3-Lifecycle-Regeln, die Objekte und alte Versionen ablaufen lassen. Die Löschung nach 365 Tagen setzen Sie also über die S3-API am Bucket; der Wechsel auf eine kühlere Stufe hat kein Gegenstück. Gegen Löschen schützen Versionierung und, wo Löschen ausgeschlossen sein muss, Object Lock.
Kann ich die georedundante Replikation behalten?
Nicht als verwaltete Einstellung. STACKIT Object Storage hat nach den vom Lauf geprüften Quellen keine verwaltete regionsübergreifende Replikation. Ist eine zweite Kopie nötig, liefert ein Sync-Job in einen Bucket der zweiten Region sie.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.