Add garbage collection for docker images

[jsoriano]

Related to #856.

If one is using elastic-package during enough time, Docker storage can end up full of docker images. Once the 90% threshold is reached, behavior can be unpredictable as described in #856.

This change introduces garbage collection for docker images that were downloaded by elastic-package. Before pulling new images, it checks first if there are old unused images or if the images are taking too much space, and remove images accordingly. It only removes images known to be downloaded by elastic-package.

Implementation is based on two methods:

• Track is used to start tracking images, by recording their tags and last used times. It has to be called before pulling the images, it won't track images that are already pulled, to avoid GCing images not managed by elastic-package.
• Run runs the garbage collection, based on two parameters: max_unused can be used to remove images older than some time and max_total_size to trigger removals when the total size of images (from docker system df) goes beyond some threshold. Less recently used images are removed first.

Tracking of known images is persisted under ~/.elastic-package/cache/docker-images-gc.json.

Garbage collection is disabled by default.

This can be configured from ~/.elastic-package/config.yml, for example:

stack:
  gc:
    enabled: true
    max_unused: 336h # 2 weeks
    max_total_size: 60GB

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 334f8a0

Failed CI Steps

• :go: Run check-static

History

cc @jsoriano

[jsoriano]

Type mostly copied from https://github.com/elastic/package-spec/blob/964c4a69e024cc464c4808720ba0db9f001a82a7/code/go/internal/spectypes/filesize.go, adding support for GB and floats, to support sizes reported by docker system df.

[jsoriano]

Added by now only to stack operations, it could be added too to agent and service deployers. It may be specially interesting in the service deployer.

[jsoriano]

This only lists images found directly in the docker compose configuration, it won't find images found in Dockerfiles. Maybe we can think in other approaches to find the images to track. Ideas welcome.