3

Can appengine files in google cloud store under the bucket asia.artifacts.../containers/images be safely deleted without causing any problems. There is already 160Gb of them after just a few years. The documentation doesn’t make clear what they are for, or why they are retained there:

# gsutil du -sh gs://asia.artifacts.<project>.appspot.com
158.04 GiB   gs://asia.artifacts.<project>.appspot.com

I just want to know if I can delete them, or if I need to keep paying for the storage space.

Originally I thought these files might correspond to what can be seen on the "Google Cloud Platform" "Container Registry" "Images" "app-engine-tmp". But even if you delete almost everything under the container registry web interface, there are still thousands of really old files sit-in in this containers/images folder.

If I had to guess the reason for this ever growing pile of probably junk files. I suspect if versions are deleted through the web interface, the underlying files are not removed. Is that correct?

UPDATE: I did find this clue in the cloud build logs that occur when you deploy. I tested out deleting the artifacts bucket on a test project. The project still works, and builds still works. An apparently harmless error message appears in the logs. Perhaps its genuinely safe to delete this artefacts folder. However, it'd be good to have clarity on what these ancient (apparently unused) artefact bucket files are for before deleting.

2021/01/15 11:27:40 Copying from asia.gcr.io/<project>/app-engine-tmp/build-cache/ttl-7d/default/buildpack-cache:latest to asia.gcr.io/sis-au/app-engine-tmp/build-cache/ttl-7d/default/buildpack-cache:f650fd29-3e4e-4448-a388-c19b1d1b8e04
2021/01/15 11:27:42 failed to copy image: GET https://storage.googleapis.com/asia.artifacts.<project>.appspot.com/containers/images/sha256:ca16b83ba5519122d24ee7d343f1f717f8b90c3152d539800dafa05b7fcc20e9?access_token=REDACTED: unsupported status code 404; body: <?xml version='1.0' encoding='UTF-8'?><Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Details>No such object: asia.artifacts.<project>.appspot.com/containers/images/sha256:ca16b83ba5519122d24ee7d343f1f717f8b90c3152d539800dafa05b7fcc20e9</Details></Error>
Unable to tag previous cache image. This is expected for new or infrequent deployments.
Megan Spencer
  • 319
  • 1
  • 10
  • 2
    I have something similar for me GAE flex project. Never noticed before. – new name Jan 17 '21 at 14:31
  • Yes, I’d love to have a proper explanation of these floating/hanging old files as well! – Jay Jan 18 '21 at 05:48
  • 1
    It's interesting to see that there are multiple users affected by this issue. Are all of the objects on the artifacts bucket not seen on the Container Registry old? This [deprecation notice](https://cloud.google.com/container-registry/docs/support/deprecation-notices) could be relevant but I cannot fully tell because I can't replicate the issue. – Donnald Cucharo Jan 18 '21 at 08:44

1 Answers1

1

It should be safe to delete those. According to Google docs:

Each time you deploy a new version, a container image is created using the Cloud Build service. That container image then runs in the App Engine standard environment. Built container images are stored in the app-engine folder in Container Registry. You can download these images to keep or run elsewhere. Once deployment is complete, App Engine no longer needs the container images. Note that they are not automatically deleted, so to avoid reaching your storage quota, you can safely delete any images you don't need.

Also as a suggestion, if you don't want to manually delete the images just in case they start piling up again, you can set up Lifecycle Management on your "artifacts" bucket and add a rule to delete old files (for example, 30 days).

This thread is similar to your concern and they have great answers. Feel fee to check it out!

IMPORTANT UPDATE: This answer only applies on Standard environment. The artifacts bucket is used as the backing storage for Flex apps images. It's used when bringing up and autoscaling VMs, so be careful when you consider deleting them.

Donnald Cucharo
  • 3,866
  • 1
  • 10
  • 17
  • 1
    Thanks for your reply. I have read all of those documentation pages. There is no indication on that page if they are talking about the `staging` bucket files or the `asia.artifacts..appspot.com` bucket files. – Megan Spencer Jan 18 '21 at 05:42
  • In fact, I have already deleted all of the containers from the container registry using the web interface. But there are still 50gb of files in that artefacts folder. Some of these `sha256:*` files date back as long as 2 years ago. – Megan Spencer Jan 18 '21 at 05:43
  • I love how you say “it should be safe”. . I think that’s probably part of the problem. How do we know these older non container registry connected files are needed or not? – Jay Jan 18 '21 at 05:49
  • 1
    @Jay, I posted a comment on OP's question which may be related to the issue. – Donnald Cucharo Jan 18 '21 at 08:46
  • Yep, that thread you linked to is definitely related. But the answers are basically "I don't know what that stuff is, I deleted it, and it seems ok". There is no content that explains why there might be hanging files, what they are for, and thus provide a confident answer to the deletion question. – Megan Spencer Jan 20 '21 at 05:26