J'ai une application Google App Engine, qui se connecte à Google Cloud Storage.
J'ai remarqué que la quantité de données stockées était déraisonnablement élevée (4,01 Go, alors qu'elle devrait être de 100 Mo environ).
Alors, j'ai regardé combien chaque seau stockait et j'ai trouvé qu'il y avait un seau créé automatiquement appelé us.artificats. qui occupait la majeure partie de l'espace.
J'ai regardé à l'intérieur et il ne contient qu'un seul dossier: containers/images/ .
D'après ce que j'ai recherché sur Google, il semble que ces images proviennent de Google Cloud Build.
Ma question est la suivante: puis-je les supprimer sans compromettre l'ensemble de mon application?
5 Réponses :
Pour ceux d'entre vous qui voient cela plus tard, j'ai fini par supprimer le dossier et tout allait bien.
Lorsque j'ai réexécuté Google Cloud Build, il a ajouté des éléments dans le bucket, que j'ai dû supprimer plus tard.
S'il y a quelqu'un d'autre comme moi, sans aucune idée de l'endroit où supprimer ces fichiers, vous pouvez accéder à console.cloud.google.com
J'ai déjà supprimé 2 fois mais il revient toujours et revient toujours avec plus d'augmentation qu'avant ...
@lukecross J'ai fini par ajouter la suppression comme une étape dans une action Github afin qu'elle soit automatiquement supprimée après le déploiement. Mais vous pouvez également regarder la réponse de HarshitG, où il utilise des règles de suppression.
Il dit "J'utilise des règles d'exclusion" mais ne dit pas quelles "Règles" il a utilisées ...
La base de feu jusqu'à aujourd'hui n'a pas dit ou posté sur ce seau automatique ... La seule chose qu'elle dit est "Node JS 10 a apporté cette création comme nécessaire pour exécuter des fonctions ..." Je pense que c'est une grande irresponsabilité chez nous.
@lukecross c'est peut-être, mais jusqu'à ce qu'ils fassent quoi que ce soit, nous devrons vivre avec. En ce qui concerne les règles de suppression, j'essaierais de le configurer pour supprimer les objets après quelques heures environ - en fonction de la durée d'exécution de vos fonctions. Tant que les fichiers sont disponibles au moment où ils sont nécessaires, vous devriez pouvoir les supprimer automatiquement après cela.
J'ai une fonction cloud avec pub / sous qui se produit tous les jours à 23 heures, je pense que je peux utiliser cette fonction pour supprimer le seau inutile ... Mais, le stockage avec CF n'est pas une bonne idée
J'ai également supprimé l'ensemble du seau d'artefacts il y a 3 jours. Le stockage est passé de 500 Mo à 8 Mo, mais la facture n'a pas diminué. Je suis toujours facturé en quelques centimes.
Même problème. Merci pour la mise à jour, Caleb.
J'ai le même problème, mais je n'ai pas d'application en cours d'exécution; J'ai juste:
Je ne sais pas pourquoi j'ai stocké 4 Go dans ces conteneurs, et je ne sais pas si je dois les supprimer ou si cela briserait mes fonctions.
MISE À JOUR: J'ai supprimé le dossier du conteneur et tout fonctionne toujours. Je ne sais pas si ce sont des sauvegardes ou autre chose, mais je ne trouve rien en ligne ou dans la documentation. Je posterai ici si quelque chose se passe. Dès qu'une fonction cloud a été exécutée, le dossier contenait à nouveau 33 fichiers.
Après l'exécution de la fonction cloud, combien d'espace les 33 fichiers ont-ils occupé? Était-ce encore 4 Go ou était-ce beaucoup moins?
J'ai fini par supprimer tout le dossier (seau d'artefacts) et j'ai peur que mes fonctions cloud ne fonctionnent plus. Y a-t-il une chance que cela se produise?
J'ai résolu ce problème en appliquant des règles de suppression 
Pourriez-vous clarifier les règles que vous avez ajoutées?
Utilisez une règle ... comme vieille de 3 jours ... supprimez automatiquement ... alors il n'aura que les derniers artefacts ... et économise votre espace
@CalebH Cela devrait être la bonne réponse. Le recours à un outil tiers est spécifique à votre cas d'utilisation.
Voici la référence à la documentation. https://cloud.google.com/appengine/docs/standard/go/testing-and-deploying-your-app#managing_build_images
Les images de conteneur créées sont stockées dans le dossier du moteur d'application dans Container Registry. Vous pouvez télécharger ces images pour les conserver ou les exécuter ailleurs. Une fois le déploiement terminé, App Engine n'a plus besoin des images de conteneur. Notez qu'elles ne sont pas automatiquement supprimées, donc pour éviter d'atteindre votre quota de stockage, vous pouvez supprimer en toute sécurité les images dont vous n'avez pas besoin. Pour plus d'informations sur la gestion des images dans Container Registry, consultez la documentation de Container Registry.
Cela peut être automatisé en ajoutant des règles de cycle de vie comme @HarshitG mentionné. 
Vous pouvez ajouter un déclencheur à vos règles de cycle de vie sur console.cloud.google.com .
Supprimez uniquement les images de conteneur à l'aide de la console ou de la CLI
gcloud container images delete. Un conteneur se compose de couches. Vous voyez ces couches comme des objets dans Cloud Storage. Ne supprimez pas directement ces objets. En termes simples, ces objets sont des couches mises en cache qui sont utilisées pourbuildune image de conteneur. Pour certains outils, si une couche n'est pas mise en cache, elle sera d'abord extraite (téléchargée), mais je n'ai pas essayé de supprimer délibérément les objets du registre de conteneurs pour voir ce qui se passe.Merci pour la clarification! Que dois-je utiliser comme nom d'image?
gcloud container images listindique qu'il n'y a pas d'images ...Avez-vous plus d'un référentiel? Utilisez
--repository=[HOSTNAME]/[PROJECT-ID]emplacements de référentiel sont gcr.io, us.gcr.io, eu.gcr.io et asia.gcr.io. Consultez également ce document: cloud.google.com/container-registry/docs/managingJ'ai trouvé des images dans le référentiel
us.gcr.ioJ'ai supprimé des images de l'interface utilisateur, mais elles existent toujours dans Cloud Storage. Il semble qu'ils n'ont été supprimés que du registre cloud.Je n'ai pas de réponse exacte pour vous si ces objets sont requis ou simplement mis en cache (enregistrés) pour une utilisation future.
Dans votre message, vous mentionnez qu'il n'aurait dû stocker qu'environ 100 Mo. D'où avez-vous obtenu ce numéro?
@EvanBaldonado Je l'ai obtenu grâce au nombre et à la taille des fichiers que je téléchargeais intentionnellement.