Maintenant que nos déploiements sont performants, il s’agit de s’intéresser au stockage des données. Plusieurs types de stockage dans le cloud existent, nous allons aujourd’hui faire un focus sur le stockage objet Google Cloud Storage (GCS).
Commençons par étudier les bases, voir comment fonctionne GCS, et comment y accéder.
En matière de stockage objet, il y a quelques concepts de base à connaître afin de bien comprendre l'ensemble.
Tout d’abord, tout est rangé dans un bucket, ce dernier est la base de tout notre stockage. Ce bucket est localisé géographiquement dans une région ou dans un emplacement multi-régional. Un élément important à noter est que le nom de chaque bucket doit être unique dans toute l'infrastructure mondiale Google Cloud ! N'espérez donc pas créer un bucket “test” ou “prod” ils sont probablement déjà utilisés !
Dans chaque bucket les objets sont virtuellement rangés dans une arborescence. Virtuellement car le nom d’un fichier n’a, en réalité, pas d’importance, seul son chemin complet (ou clé) constitue le nom réel du fichier. Ainsi, même si vous envoyez un fichier archive.zip dans un sous dossier temp, la réelle clé d'accès sera temp/archive.zip.
Chaque objet dans GCS conserve son arborescence et les seuls moyens d’accès sont par le biais de requêtes http : GET / POST / DELETE / etc… Cela signifie donc qu’il n’est pas possible de réaliser toutes les actions disponibles sur un système de fichiers classique. Il faut garder cela en tête quand on commence à utiliser le stockage objet. La modification d’un objet revient à le supprimer et à en renvoyer une nouvelle version.
Plusieurs méthodes existent pour manipuler Storage, celle de base est l’API HTTP directement. Ceci étant ce n'est la plus simple à utiliser, c’est pourquoi des interfaces existent : les SDK des langages supportés, la vue web depuis la console, et l’outil en ligne de commande gsutil. Nous allons utiliser ces deux derniers.
Gsutil s'installe simplement sur votre système en suivant la documentation. Si vous utilisez déja le SDK GCloud alors gsutil est probablement déja installé. Ensuite, les commandes peuvent être directement utilisées :
# Créer un bucket multirégional en Europe
gsutil mb -l eu gs://my-bucket
# Lister les buckets
gsutil ls
# Pousser un objet dans un bucket
gsutil cp test.conf gs://my-bucket/my-folder/
# Lister le contenu du bucket nouvellement créé
gsutil ls gs://my-bucket
# Récupérer plusieurs objets et l’arborescence
gsutil cp -r gs://my-bucket/* .
Le stockage GCS est unifié, cela signifie qu’il est accessible partout de la même manière indépendamment de la réalité du stockage derrière. C’est justement cette réalité dont nous allons parler.
Quatre types de classe de stockage existent, et chacun a des attributs particuliers à garder à l’esprit lors du choix. Chaque bucket aura une classe de stockage par défaut, ainsi tous les objets créés à l’intérieur du bucket appartiendront à cette classe, cependant il est possible pour chaque objet de changer sa classe individuellement.
Les classes sont les suivantes :
Quand on parle de SLA, attention à bien distinguer disponibilité (accès aux données) et durabilité (stockage des données). Le SLA annoncé de toutes les classes concerne la disponibilité mais la durabilité est, elle, bien plus élevée. Celle-ci est la même pour toutes les classes de stockage, et est de 99.999999999%. Un formateur de Google a fait une comparaison très pertinente avec les banques : si votre agence est fermée la nuit vous ne pouvez pas accéder à votre argent mais il continue à exister.
Le temps d’accès aux données reste identique peu importe la classe, même pour le coldline.
Lors du dépôt d’objets, soit vous savez déjà dans quelle classe les placer, soit ces objets peuvent vivre et devenir obsolètes au fil du temps. C’est typiquement le cas des journaux ou des fichiers temporaires. Dans ce cas, vous pouvez avoir besoin de les considérer comme HotData au début, puis ils deviennent par la suite des Warm voire des Cold Data.
Dans ce cas de figure il n’est pas nécessaire de se soucier de ce cycle de vie, Google Cloud Storage peut l'automatiser pour vous. Il est possible d'appliquer des politiques réalisant la transition de classe automatiquement suivant l’ancienneté des objets. Ainsi, on peut décider que tous les objets de plus de 30 jours passent spontanément en Nearline, puis au-delà 90 jours en Coldline. Enfin, on peut même décider de les supprimer automatiquement.
Par exemple cela nous donnerait les instructions suivantes :
cat > lifecycle.json <<EOF
{
"rule": [
{
"action": {"storageClass": "NEARLINE", "type": "SetStorageClass"},
"condition": {"age": 30}
}, {
"action": {"storageClass": "COLDLINE", "type": "SetStorageClass"},
"condition": {"age": 90}
}, {
"action": {"type": "Delete"}, "condition": {"age": 365}
}
]
}
EOF
$ gsutil lifecycle set lifecycle.json gs://my-bucket/
Toutes les données ont besoin d’être protégées, et le stockage objet ne déroge pas à la règle.
Sur GCS le chiffrement est automatique et non optionnel. Par défaut, les données sont chiffrées avec les clés de Google, mais peut-être avez-vous besoin de gérer vos clés vous-même ?
Pour cela, deux solutions alternatives existent :
Dans le cas du service KMS, les clés de chiffrement et de déchiffrement restent gérées par Google, et vous devez vous assurer que chaque service que vous utilisez dispose bien des permissions d'accès à la clé KMS avant de tenter de lire les données sur GCS. Malheureusement il n’y a pas encore d’intégration KMS directement sur le stockage, tout le chiffrement est fait côté client.
Si vous préférez fournir vous-même la clé de chiffrement, dans ce cas vous seul gérez manuellement les clés, et vous êtes responsable de les faire parvenir aux services en ayant besoin. Dans ce cas le chiffrement se fait côté serveur, mais vous êtes seul responsable des clés et de la rotation. De même si vous les perdez, l’accès aux donnés sera irrémédiablement perdu.
Bien entendu si vous utilisez le mode par défaut Google Cloud se charge automatiquement de gérer toute cette partie chiffrement.
Le schéma suivant disponible sur le blog de google donne un bon aperçu des différentes possibilités de chiffrement.
Les permissions utilisent exactement les mêmes mécanismes que le reste des ressources GCP, il est donc possible d’utiliser le système IAM pour autoriser les utilisateurs et/ou comptes de services.
Par défaut, les comptes autorisés GCS sur le projet obtiennent par héritage les droits équivalents sur le bucket, mais il est possible de changer cela et d’en ajouter de nouveaux.
Par exemple si l’on souhaite ajouter un compte de service spécifique ayant un simple accès en lecture seule au bucket, on peut passer par la console ou utiliser la commande suivante (on utilisera la sous-commande ch pour ne pas écraser la configuration existante) :
gsutil iam ch serviceAccount:397660609030-compute@developer.gserviceaccount.com:objectViewer gs://my-bucket/
Après avoir vu les permissions, qu’en est-il des accès vraiment publics aux objets ? Si l’on souhaite donner accès sans avoir besoin de s'authentifier ?
Si tout internet doit y avoir accès alors il est possible de rendre un objet public, ainsi son URL publique sera disponible et le simple fait d’y accéder permettra de lire son contenu. Cela est très pratique pour gérer un site internet statique, servir de cache, ou simplement mettre à disposition une archive.
Essayez d’y accéder via l’url suivante : https://storage.googleapis.com/my-bucket/my-folder/tmp.txt
Une méthode plus fine pour gérer les permissions est d’utiliser les ACLs, ce qui permet de définir des permissions par objet. En général il est préférable d’utiliser les permissions IAM, y compris pour les permissions relatives à l’ensemble des objets. Les ACLs ne seront utilisées que pour le réglage précis des permissions sur des objets spécifiques.
$ gsutil acl ch -u AllUsers:R gs://my-bucket/my-folder/tmp.txt
Updated ACL on gs://my-bucket/my-folder/tmp.txt
En parlant de mise à disposition d'archive, comment contrôler que le lien mis à disposition ne sera pas détourné ? Une fonctionnalité existe et permet de “signer les URL", ainsi, un lien temporaire est fourni et ce dernier ne fonctionnera que pour un nombre déterminé de téléchargements.
Nous avons parcouru certaines fonctionnalités parmi les plus utilisées de Google Cloud Storage. Avant de vous laisser, j’aimerais vous parler d’une dernière possibilité qui nous sera très utile dans un futur proche : les notifications.
Les notifications permettent de déclencher des évènements lors d'actions dans un bucket. Typiquement, on peut envisager de créer une notification à chaque fois qu’un objet est déposé dans un bucket. Ce type de mécanisme est une des bases des architectures “full cloud” car cela permet de lier les composants Cloud entre eux. Grâce à ces mécanismes nous pouvons utiliser GCS comme épine dorsale d’une solution Big Data.
Si vous souhaitez aller plus loin dans l’exploration de GCS, je vous invite à parcourir la documentation officielle très complète.
Le stockage objet sur Google Cloud n’a plus de secret pour vous, restez connectés pour en savoir plus sur Google Cloud ! Le code de nos exemples est disponible sur GitHub : https://github.com/bcadiot/gcp-from-scratch.
Vous avez des questions ? Vous voulez plus de détails ? N’hésitez pas à le dire dans les commentaires de l’article ou via Twitter.
À très vite pour la suite de notre découverte de Google Cloud. Pour le prochain article je vous propose de parler conteneurs dans le cloud !