Consignes de dénomination des buckets de stockage
Les noms de buckets doivent respecter les conventions de dénomination suivantes :
- être unique dans le projet ; Un projet ajoute un préfixe unique au nom du bucket, ce qui évite les conflits au sein de l'organisation. Dans le cas peu probable où un préfixe et un nom de bucket entreraient en conflit entre plusieurs organisations, la création du bucket échouerait et l'erreur
bucket name in use
s'afficherait. - comporter au moins un caractère et pas plus de 57 ;
- N'incluez aucune information permettant d'identifier personnellement l'utilisateur.
- être conforme au DNS ;
- Commencer par une lettre et ne contenir que des lettres, des chiffres et des traits d'union.
Installer l'outil s3cmd CLI
L'outil s3cmd
est un outil de ligne de commande permettant de gérer le stockage d'objets.
- Pour télécharger l'outil, accédez au répertoire à partir duquel le package GDC a été extrait.
Exécutez les commandes suivantes pour extraire l'image s3cmd,
s3cmd.tar.tar.gz
, dans un répertoire temporaire vide :tmpdir=$(mktemp -d) gdcloud artifacts extract oci/ $tmpdir \ --image-name=$(gdcloud artifacts tree oci | grep s3cmd.tar | sed 's/^.* //')
scp
le fichier tar sur une machine cliente sur laquelle vous utilisezs3cmd
pour les opérations sur les objets. Décompressez et installez l'image.
Choisissez l'une des méthodes d'installation suivantes pour installer l'outil s3cmd
:
Installer à l'aide d'un fichier tar
Pour décompresser l'archive et installer le package
s3cmd
, exécutez les commandes suivantes. Vous devez disposer du module Pythondistutils
pour installer le package. Le module fait souvent partie du package Python de base, ou vous pouvez l'installer à l'aide de votre gestionnaire de packages.tar xvf /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz cd /tmp/gpc-system-tar-files/s3cmd sudo python3 setup.py install
Facultatif : Nettoyez les fichiers téléchargés :
rm /tmp/gpc-system-tar-files/s3cmd.tar.tar.gz rm -r /tmp/gpc-system-tar-files/s3cmd
Installer avec une image Docker
Pour installer l'image
s3cmd
, exécutez les commandes suivantes :docker load --input s3cmd-docker.tar export S3CFG=/EMPTY_FOLDER_PATH/ alias s3cmd="docker run -it --net=host --mount=type=bind,source=/$S3CFG/,target=/g/ s3cmd-docker:latest -c /g/s3cfg"
Facultatif : Nettoyez les fichiers téléchargés :
rm s3cmd-docker.tar
Ajoutez l'exportation et l'alias au fichier
.bashrc
pour qu'ils soient conservés après le redémarrage du client.
Configurer l'outil s3cmd
Utilisez l'outil s3cmd pour les opérations basées sur les objets.
Exécutez la commande s3cmd --configure
et spécifiez les éléments suivants :
- Clé d'accès : saisissez la clé d'accès obtenue à partir du secret dans Obtenir des identifiants d'accès.
- Clé secrète : saisissez la clé secrète obtenue à partir du secret dans Obtenir des identifiants d'accès.
- Région par défaut : appuyez sur
ENTER
. - Point de terminaison S3 : saisissez le point de terminaison fourni par votre opérateur d'infrastructure (IO).
- Pour le style de nommage de bucket DNS, saisissez
s3://%(bucket)
. - Facultatif : Saisissez un mot de passe de chiffrement pour protéger les fichiers en transit.
- Dans "Chemin d'accès à GPG", saisissez
/usr/bin/gpg
. - Saisissez
Yes
pour utiliser le protocole HTTPS. - Appuyez sur
Enter
pour ne pas saisir le nom du serveur proxy.
Créer des buckets de stockage
Avant de commencer
Un espace de noms de projet gère les ressources de bucket dans le cluster d'administrateur racine. Vous devez disposer d'un projet pour créer un bucket. Pour créer un projet, consultez Créer un projet. Vous devez disposer des autorisations appropriées au niveau du bucket pour effectuer les opérations suivantes. Consultez Accorder l'accès à un bucket.
Créer un bucket
Pour créer un bucket, appliquez une spécification de bucket à l'espace de noms de votre projet :
kubectl apply -f bucket.yaml
Voici un exemple de spécification de bucket :
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
name: BUCKET_NAME
namespace: NAMESPACE_NAME
spec:
description: DESCRIPTION
storageClass: standard-rwo
bucketPolicy :
lockingPolicy :
defaultObjectRetentionDays: RETENTION_DAY_COUNT
Pour en savoir plus, consultez la documentation de référence de l'API Bucket.
Lister les buckets de stockage
Pour lister tous les buckets auxquels vous avez accès dans un locataire de stockage d'objets donné, procédez comme suit :
Exécutez les commandes suivantes pour lister tous les buckets :
kubectl get buckets --all-namespaces kubectl get buckets --namespace NAMESPACE_NAME
Supprimer des buckets de stockage
Vous pouvez supprimer des buckets de stockage à l'aide de la CLI. Les buckets doivent être vides pour pouvoir être supprimés.
Utilisez la commande
GET
ouDESCRIBE
dans la section Afficher la configuration du bucket pour obtenir le nom complet du bucket.Si le bucket n'est pas vide, videz-le :
s3cmd rm --recursive -—force s3://FULLY_QUALIFIED_BUCKET_NAME
Supprimez le bucket vide :
kubectl delete buckets/BUCKET_NAME --namespace NAMESPACE_NAME
Afficher la configuration du bucket
Utilisez l'une ou l'autre de ces commandes pour afficher les détails de configuration d'un bucket :
kubectl describe buckets/BUCKET_NAME --namespace NAMESPACE_NAME
kubectl get buckets/BUCKET_NAME --namespace NAMESPACE_NAME -o yaml
Définir une durée de conservation des objets
Par défaut, vous pouvez supprimer des objets à tout moment. Activez le verrouillage des objets avec une période de conservation pour empêcher la suppression de tous les objets du bucket pendant le nombre de jours spécifié. Vous ne pouvez pas supprimer un bucket tant que vous n'avez pas supprimé tous les objets après la période de conservation.
Vous devez activer le verrouillage d'objets lorsque vous créez le bucket. Vous ne pouvez pas activer ni désactiver le verrouillage des objets après avoir créé un bucket. Vous pouvez toutefois modifier la période de conservation par défaut des objets.
Vous pouvez créer un bucket avec ou sans activer le verrouillage d'objets. Si vous avez activé le verrouillage des objets, il est facultatif de spécifier une durée de conservation par défaut.
Pour modifier la durée de conservation, mettez à jour le champ Bucket.spec.bucketPolicy.lockingPolicy.defaultObjectRetentionDays
dans la ressource Bucket.
Voici un exemple de mise à jour du champ dans la ressource Bucket :
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
name: BUCKET_NAME
namespace: NAMESPACE_NAME
spec:
description: "This bucket has a default retention period specified."
storageClass: standard-rwo
bucketPolicy :
lockingPolicy :
defaultObjectRetentionDays: RETENTION_DAY_COUNT
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
name: BUCKET_NAME
namespace: NAMESPACE_NAME
spec:
description: "This would enable object locking but not specify a default retention period."
storageClass: standard-rwo
bucketPolicy :
lockingPolicy :
---
apiVersion: object.gdc.goog/v1alpha1
kind: Bucket
metadata:
name: BUCKET_NAME
namespace: NAMESPACE_NAME
spec:
description: "This bucket does not have locking or retention enabled."
storageClass: standard-rwo
Toute modification apportée à la période de conservation s'applique aux objets créés dans le bucket après la modification. Pour les objets préexistants, la période de conservation ne change pas.
Lorsque vous avez activé le verrouillage d'objet, si vous tentez d'écraser un objet, vous ajoutez une nouvelle version de l'objet. Vous pouvez récupérer les deux versions de l'objet.
Pour savoir comment lister les versions d'objets, consultez ListObjectVersions
dans la documentation Amazon Web Services :
https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html.
Pour créer un bucket WORM (Write-Once, Read-Many), consultez la section Bucket WORM.
Accorder l'accès au bucket
Vous pouvez accorder l'accès aux buckets à d'autres utilisateurs ou comptes de service en créant et en appliquant des RoleBindings
avec des rôles prédéfinis.
Rôles prédéfinis
project-bucket-object-viewer: : ce rôle permet à un utilisateur de lister tous les buckets du projet, les objets de ces buckets, et de lire les objets et les métadonnées d'objets. Ce rôle ne vous permet pas d'effectuer des opérations d'écriture sur des objets, comme l'importation, l'écrasement ou la suppression.
project-bucket-object-admin: : ce rôle permet à un utilisateur de lister tous les buckets du projet, et d'effectuer des opérations d'écriture et de lecture sur les objets, comme les importer, les écraser ou les supprimer.
project-bucket-admin: : ce rôle permet aux utilisateurs de gérer tous les buckets de l'espace de noms donné, ainsi que tous les objets de ces buckets.
Pour obtenir la liste complète des autorisations accordées pour ces rôles, consultez la section Autorisations des rôles prédéfinis.
Pour obtenir les autorisations nécessaires pour créer des liaisons de rôle de projet, demandez à votre administrateur IAM de projet de vous accorder le rôle Administrateur IAM de projet (project-iam-admin
).
Voici un exemple de création d'un RoleBinding
pour accorder l'accès à un utilisateur et à un compte de service :
Créez un fichier YAML sur votre système, par exemple
rolebinding-object-admin-all-buckets.yaml
.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: NAMESPACE_NAME name: readwrite-all-buckets roleRef: kind: Role name: project-bucket-object-admin apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount namespace: NAMESPACE_NAME name: SA_NAME - kind: User namespace: NAMESPACE_NAME name: bob@example.com # Could be bob or bob@example.com based on your organization settings. apiGroup: rbac.authorization.k8s.io ```
Appliquez le fichier YAML :
kubectl apply \ -f rolebinding-object-admin-all-buckets.yaml
Obtenir les identifiants d'accès au bucket
Lorsque vous accordez l'accès à un bucket, les identifiants d'accès sont créés dans un secret.
Le format du nom du secret est object-storage-key-SUBJECT_TYPE-SUBJECT_HASH
.
- Les valeurs de
SUBJECT_TYPE
sont les suivantes :user
: l'utilisateur.sa
:ServiceAccount
.
SUBJECT_HASH
correspond au hachage SHA256 encodé en base32 du nom du sujet.
Par exemple, l'utilisateur bob@foo.com
possède le secret nommé :
object-storage-key-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja
Accéder au secret utilisateur
Pour un sujet utilisateur, le secret se trouve dans l'espace de noms object-storage-access-keys
du cluster d'administrateur racine.
Recherchez le nom du secret :
kubectl auth can-i --list --namespace object-storage-access-keys | grep object-storage-key-
Vous obtenez un résultat semblable à celui-ci :
secrets [] [object-storage-key-nl-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja,object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja] [get]
Obtenez le contenu du secret correspondant pour accéder aux buckets :
kubectl get -o yaml --namespace object-storage-access-keys secret object-storage-key-rm-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja
Vous obtenez un résultat semblable à celui-ci :
data: access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8= create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3 secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
Décodez l'ID de clé d'accès et le secret :
echo "MEhYM08wWUMySjcyMkVKTFBKRU8=" | base64 -d \ && echo \ && echo "Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==" | base64 -d
Vous obtenez un résultat semblable à celui-ci :
0HX3O0YC2J722EJLPJEO Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
Suivez la section Configurer s3cmd avec les informations obtenues.
Accéder au secret du compte de service
Pour un sujet de compte de service, le secret se trouve dans le même espace de noms que le bucket. Pour trouver le nom, exécutez la commande suivante :
kubectl get --namespace NAMESPACE_NAME secrets -o=jsonpath=
'{.items[?(@.metadata.annotations.object\.gdc\.goog/subject=="SA_NAME")].metadata.name}'
Vous obtenez un résultat semblable à celui-ci :
object-storage-key-rm-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq
Vous pouvez référencer le secret dans votre pod en tant que variables d'environnement (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables) ou fichiers (https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod).
Autorisations des rôles prédéfinis
Autorisations "Lecteur des objets du bucket du projet"
Ce rôle accorde les autorisations nécessaires pour obtenir et lister les objets et les métadonnées des objets dans le bucket.
Le rôle project-bucket-object-viewer
dispose des autorisations suivantes :
Autorisations de l'API pour les buckets :
- Get
- Liste
- Regarder
Autorisations de stockage d'objets S3 :
GetObject
GetObjectAcl
GetObjectVersion
ListBucket
ListBucketVersions
ListBucketMultipartUploads
ListMultipartUploadParts
Autorisations d'administrateur d'objet et de bucket de projet
Ce rôle accorde les autorisations nécessaires pour placer et supprimer des objets, des versions d'objets et des tags dans le bucket. Il accorde également toutes les autorisations dans project-bucket-object-viewer
.
Le rôle project-bucket-object-admin
dispose des autorisations de stockage d'objets suivantes :
Autorisations de stockage d'objets S3 :
AbortMultipartUpload
DeleteObject
DeleteObjectVersion
PutObject
RestoreObject
Autorisations d'administrateur de bucket de projet
Ce rôle accorde des autorisations pour créer, mettre à jour ou supprimer des ressources Bucket
dans l'espace de noms du projet. Il accorde également toutes les autorisations dans project-bucket-object-admin
.
Le rôle project-bucket-object-admin
dispose des autorisations suivantes :
Autorisations de l'API pour les buckets :
- Créer
- Mettre à jour
- Supprimer
Créer un bucket WORM
Un bucket WORM garantit que rien d'autre n'écrase les objets et qu'ils sont conservés pendant une période minimale. La journalisation des audits est un exemple de cas d'utilisation pour un bucket WORM.
Pour créer un bucket WORM, procédez comme suit :
Définissez une période de conservation lorsque vous créez le bucket. Par exemple, le bucket suivant a une période de conservation de 365 jours.
apiVersion: object.gdc.goog/v1alpha1 kind: Bucket metadata: name: foo logging-bucket namespace: foo-service spec: description: "Audit logs for foo" storageClass: standard-rwo bucketPolicy : lockingPolicy : defaultObjectRetentionDays: 365
Attribuez le rôle
project-bucket-object-viewer
à tous les utilisateurs qui ont besoin d'un accès en lecture seule :apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: foo-service name: object-readonly-access roleRef: kind: Role name: project-bucket-object-viewer apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount namespace: foo-service name: foo-log-processor - kind: User name: bob@example.com apiGroup: rbac.authorization.k8s.io
Attribuez le rôle
project-bucket-object-admin
aux utilisateurs qui doivent écrire du contenu dans le bucket :apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: foo-service name: object-write-access roleRef: kind: Role name: project-bucket-object-viewer apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount namespace: foo-service name: foo-service-account
Restaurer à partir du stockage d'objets vers le système de fichiers sur le stockage de blocs
Allouer un volume persistant
Pour restaurer des fichiers à partir d'un point de terminaison de stockage d'objets, procédez comme suit :
Attribuez un volume persistant (PV) à cibler lors de la restauration. Utilisez une revendication de volume persistant (PVC) pour allouer le volume, comme indiqué dans l'exemple suivant :
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: restore-pvc namespace: restore-ns spec: storageClassName: standard-rwo accessModes: ReadWriteOnce resources: requests: storage: 1Gi # Need sufficient capacity for full restoration.
Vérifiez l'état du PVC :
kubectl get pvc restore-pvc -n restore-ns
Une fois que le PVC est à l'état
Bound
, il est prêt à être utilisé dans le pod qui le réhydrate.Si un ensemble
Stateful
finit par consommer le PV, vous devez faire correspondre les PVC StatefulSet affichés. Les pods produits parStatefulSet
consomment les volumes hydratés. L'exemple suivant montre des modèles de revendication de volume dans un StatefulSet nomméss
.volumeClaimTemplates: - metadata: name: pvc-name spec: accessModes: [ "ReadWriteOnce" ] storageClassName: standard-rwo resources: requests: storage: 1Gi
Préallouez des PVC avec des noms tels que
ss-pvc-name-0
etss-pvc-name-1
pour vous assurer que les pods résultants consomment les volumes préalloués.
Hydrater le volume persistant (PV)
Une fois le PVC lié à un PV, démarrez Job
pour remplir le PV :
apiVersion: batch/v1
kind: Job
metadata:
name: transfer-job
namespace: transfer
spec:
template:
spec:
serviceAccountName: data-transfer-sa
volumes:
- name: data-transfer-restore-volume
persistentVolumeClaim:
claimName: restore-pvc
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
command: /storage-transfer
args:
- --src_endpoint=https://your-src-endpoint.com
- --src_path=/your-src-bucket
- --src_credentials=transfer/src-secret
- --dst_path=/restore-pv-mnt-path
- --src_type=s3
- --dst_type=local
volumeMounts:
- mountPath: /restore-pv-mnt-path
name: data-transfer-restore-volume
Une fois l'Job
terminé, les données du bucket de stockage d'objets sont insérées dans le volume. Un autre pod peut consommer les données en utilisant les mêmes mécanismes standards pour monter un volume.