HowTo: Object Storage - Container/Bucket nutzen
OpenCloud Objektspeicher
TelemaxX bietet zwei Storage Services an, die ähnlich, aber nicht gleich und für unterschiedliche Anwendungsfälle gedacht sind:
Eigenständige Cloud Service Plattform.
- Use Case: Backup- & Archive-Storage mit Standard-Performance
- Datenhaltung: Lokale Redundanz
- Endpoint:
s3.telemaxx.cloud - Dokumentation: TelemaxX S3 Object Storage
Integrierter S3 Service der OpenCloud Plattform.
- Use Case: High-Performance Object Storage für Apps mit hohen Leistungsanforderungen
- Datenhaltung: Redundant über 3 Rechenzentren gespiegelt
- Endpoint:
radosgw.opencloud.telemaxx.de - Dokumentation: diese Seite hier 😃
Jedes Projekt in der OpenCloud stellt auch einen Objektspeicher über Container bereit.
Diese ähneln AWS S3 Buckets und können ebenfalls über das S3 Protokoll angesprochen und verwaltet werden. Verwenden Sie Object-Storage Container, um beliebige Dateien zu speichern und sie bei Bedarf über eine öffentliche URL freizugeben.
Sie können Container und Daten über verschiedene Wege nutzen und verwalten:
- OpenCloud Dashboard: Horizon
- Swift API: OpenStack CLI, Swift CLI, Object Storage API
- S3 API: AWS S3 Client, s3cmd
Object Storage über das Dashboard managen
Sie können Daten entweder über das OpenCloud Dashboard oder über die CLI hinzufügen. Im Folgenden werden beide Wege beschrieben. Zuerst geht es um das Dashboard.
Container (Bucket) erstellen
Um einen Container zu erstellen, navigieren Sie zur Containers im linken Bereich Object Store. Dort sehen Sie eine einfache Oberfläche, die Ihre Container anzeigt und mit der Sie neue Container erstellen können.
Verwenden Sie die Schaltfläche + Container und geben Sie im Modalfenster den Namen Ihres Containers ein. Wählen Sie außerdem die Sichtbarkeit des Containers aus: public oder not public
Folder erstellen
Über die Schaltfläche + Folder können Ordnerstrukturen angelegt werden.
Daten hinzufügen
Klicken Sie in der Container-Übersicht auf den Container, den Sie verwalten möchten. Der Inhalt des Containers wird rechts angezeigt. Dort finden Sie auch die Upload-Schaltfläche.
Wählen Sie im Modalfenster die gewünschte Datei aus, geben Sie optional einen Dateinamen an und bestätigen Sie das Hochladen mit Upload File.
Public Access – Container-Daten öffentlich zugänglich machen
Hier können Sie außerdem die Sichtbarkeit des Containers ändern und den Freigabe-Link kopieren, sofern es sich um einen öffentlichen Container handeln soll.
Object Storage über die CLI managen
Voraussetzungen
Für die Nutzung werden folgende Werkzeuge benötigt:
- OpenStack CLI
- AWS CLI
- jq – bessere Darstellung von JSON-Text (optional)
- Zugriff auf ein OpenStack-Projekt bspw. mithilfe von Application Credentials
S3 Credentials erzeugen
S3-Zugangsdaten können über die OpenStack CLI wie folgt erstellt werden:
openstack ec2 credentials createDie Ausgabe enthält unter anderem einen access und einen secret Wert.
+------------+----------------------------------------------------------------+
| Field | Value |
+------------+----------------------------------------------------------------+
| access | fd41da26fcbc4280ae3ae5ff6ac71346 |
| links | {'self': 'https://keystone.opencloud.telemaxx.de:5000/v3/...'} |
| project_id | 11111111111111111111111111111111 |
| secret | ******************************** |
| trust_id | None |
| user_id | 22222222222222222222222222222222 |
+------------+----------------------------------------------------------------+
Die AWS CLI kann nun über Umgebungsvariablen für den Zugriff auf S3 konfiguriert werden.
Beispiel:
export AWS_ACCESS_KEY_ID='fd41da26fcbc4280ae3ae5ff6ac71346'
export AWS_SECRET_ACCESS_KEY='********************************'
export AWS_ENDPOINT_URL='https://radosgw.opencloud.telemaxx.de'
export AWS_DEFAULT_REGION=default
export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
export AWS_RESPONSE_CHECKSUM_VALIDATION=when_requiredInfo: Die Variablen
AWS_REQUEST_CHECKSUM_CALCULATIONundAWS_RESPONSE_CHECKSUM_VALIDATIONkönnen notwendig sein, um Kompatibilitätsprobleme zwischen neueren AWS-CLI-Versionen und S3-kompatiblen Backends wie RadosGW zu vermeiden.
Bucket erstellen
Im folgenden Beispiel legen wir einen Bucket mit dem Namen awesome-bucket an.
Methode 1: über die OpenStack CLI
openstack container create awesome-bucketInfo: In OpenStack werden Buckets als Container bezeichnet.
Methode 2: über die AWS CLI
aws s3 mb s3://awesome-bucket
Caveat: Eindeutige Bucket-NamenBucket-Namen beziehungsweise Container-Bezeichner sind global eindeutig. Das bedeutet, dass ein Bucket-Name nur einmal innerhalb der Object-Storage-Plattform vergeben werden kann. Auch wenn in Ihrem eigenen Projekt noch kein Bucket mit diesem Namen existiert, kann es sein, dass der gewünschte Name bereits durch ein anderes Projekt belegt ist. Wählen Sie in diesem Fall einen anderen, eindeutigen Bucket-Namen.
Objekte hochladen
Ein Objekt kann mit der AWS CLI in einen Bucket hochgeladen werden:
aws s3 cp image.png s3://awesome-bucket/In diesem Beispiel wird die Datei image.png in den Bucket awesome-bucket hochgeladen.
Soll ein Objekt direkt öffentlich lesbar sein, kann es beim Upload mit der ACL public-read hochgeladen werden:
aws s3 cp image.png s3://awesome-bucket/ --acl public-readEin öffentliches Objekt kann anschließend über die folgende URL abgerufen werden:
https://radosgw.opencloud.telemaxx.de/awesome-bucket/image.png
Der Zugriff über diese URL funktioniert nur, wenn das Objekt oder der entsprechende Pfad öffentlich lesbar ist.
Alternativ kann ein temporärer, signierter Download-Link für private Objekte erstellt werden:
aws s3 presign s3://awesome-bucket/image.png --expires-in 3600Der Parameter --expires-in gibt die Gültigkeit des Links in Sekunden an. In diesem Beispiel ist der Link eine Stunde gültig.
ACL eines bestehenden Objekts ändern
Die ACL eines bereits vorhandenen Objekts kann nachträglich gesetzt werden:
aws s3api put-object-acl --bucket awesome-bucket --key image.png --acl public-readDamit wird das Objekt image.png im Bucket awesome-bucket öffentlich lesbar gemacht.
Übersicht gängiger ACLs
| ACL | Scope |
|---|---|
| private | Nur der Owner hat Vollzugriff. Kein öffentlicher Zugriff. Dies ist üblicherweise der Standard. |
| public-read | Der Owner hat Vollzugriff. Jeder kann Objekte lesen. |
| authenticated-read | Jeder authentifizierte S3-Benutzer (auch außerhalb des eigenen Projekts) kann lesen. |
| ⚠️ public-read-write | Jeder (auch außerhalb des eigenen Projekts) kann lesen und schreiben. Achtung: In der Regel vermeiden! |
Zugriff auf einen Ordner bzw. Prefix erlauben
S3 kennt technisch keine echten Ordner. Stattdessen werden Pfade als sog. Prefixes innerhalb eines Buckets behandelt. Wenn alle Objekte unterhalb eines Prefixes öffentlich lesbar sein sollen, kann eine Bucket Policy verwendet werden.
ACL vs. Bucket PolicyACLs eignen sich vor allem, wenn die Berechtigung für einzelne Buckets oder einzelne Objekte gesetzt werden soll, zum Beispiel um eine einzelne Datei mit public-read öffentlich lesbar zu machen.
Wenn jedoch mehrere Objekte nach einem gemeinsamen Prefix freigegeben werden sollen, ist eine Bucket Policy in der Regel besser geeignet. Ein typisches Beispiel ist ein Prefix wie
images/*, bei dem alle darunterliegenden Objekte öffentlich lesbar sein sollen. Mit einer Policy kann die Berechtigung zentral auf das gesamte Prefix angewendet werden, ohne jedes einzelne Objekt nachträglich per ACL anfassen zu müssen.
Beispiel: Öffentlicher Lesezugriff auf alle Objekte unterhalb von images/.
Datei: allow-read.json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadImagesPrefix",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::awesome-bucket/images/*"
]
}
]
}Die Policy wird anschließend wie folgt auf den Bucket angewendet:
aws s3api put-bucket-policy --bucket awesome-bucket --policy file://allow-read.jsonDanach sind alle Objekte unterhalb des Prefixes images/ öffentlich lesbar, zum Beispiel:
https://radosgw.opencloud.telemaxx.de/awesome-bucket/images/image.png
Bucket Policy prüfen
Eine gesetzte Bucket Policy kann mit folgendem Befehl geprüft werden:
aws s3api get-bucket-policy --bucket awesome-bucket --output json | jq -r '.Policy'Unter dem Key Policy finden wir den ursprünglichen Inhalt der JSON-Datei wieder:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadImagesPrefix",
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::awesome-bucket/images/*"]
}
]
}S3 Policy Generator
Zum Erstellen von S3 Policies im geeigneten Format kann der AWS Policy Generator verwendet werden.
Dabei sollte darauf geachtet werden, dass der Amazon Resource Name (ARN) den passenden Bucket-Namen sowie das gewünschte Resource Pattern enthält, z.B.:
arn:aws:s3:::awesome-bucket/images/*
Typische Actions sind beispielsweise GetObject, PutObject und DeleteObject.
Nach einem Klick auf Generate Policy wird ein passendes JSON-Dokument erzeugt. Dieses kann anschließend, wie oben beschrieben, als Bucket Policy hinterlegt werden.
