Skip to content

Instantly share code, notes, and snippets.

@Dentrax
Last active June 5, 2023 12:32
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Dentrax/d2c08f079d07b3529de3f9f576d5d648 to your computer and use it in GitHub Desktop.
Save Dentrax/d2c08f079d07b3529de3f9f576d5d648 to your computer and use it in GitHub Desktop.
Stargz Study Notes

Stargz Study Notes

idea

  • proposed by bradfitz for acceralating the CI of the Go lang project
  • x/build: speed up large container start-up times without pre-pulling containers into VMs (CRFS): golang/go#30829
    • motivation: Our current situation (building a container, pushing to gcr.io, then automating the creation of a COS-like VM images that has the image pre-pulled) is pretty gross and tedious.
    • initial: https://github.com/google/crfs (read-only FUSE filesystem that lets you mount a container image, served directly from a container registry)

crfs

  • https://github.com/google/crfs
    • pull operation from a container registry to read the entire container image from the registry and write the entire container image to the local machine’s disk. It’s pretty silly (and wasteful) that a read operation becomes a write operation.
    • Go: For isolation and other reasons, we run all our containers in a single-use fresh VMs. we’ve automated the creation of VM images where our heavy containers are pre-pulled. This is all a silly workaround. It’d be much better if we could just read the bytes over the network
    • tar files are unindexed, and gzip streams are not seekable
    • Stargz: Seekable tar.gz - make a tar file where each tar entry is its own gzip stream (non-unindexed and non-unseekable)
    • traditional: Gzip(TarF(file1) + TarF(file2) + TarF(file3) + TarFooter))
    • stargz: Gzip(TarF(file1)) + Gzip(TarF(file2)) + Gzip(TarF(file3_chunk1)) + Gzip(F(file3_chunk2)) + Gzip(F(index of earlier files in magic file), TarFooter) - a few percent larger - it's plenty acceptable
    • operation: HTTP Range requests to read just the stargz index out of the end of each of the layers from the registry. index is stored similar to how the ZIP format's TOC is stored, storing a pointer to the index at the very end of the file. index contains the offset of each file's GZIP(TAR(file data)) range. multiple stargz index entries for large files to efficiently read a small amount of data from large files.
  • import "bazil.org/fuse"
  • TOCEntry: https://github.com/google/crfs/blob/71d77da419c90be7b05d12e59945ac7a8c94a543/stargz/stargz.go#L108-L191
  • index: stargz.index.json: stores version and list of TOCEntry

DEMO

$ skopeo copy --override-os linux docker://busybox:latest oci:busybox

$ file busybox/blobs/sha256/f5b7ce95afea5d39690afc4c206ee1bf3e3e956dcc8d1ccd05c6613a39c4e4f8
busybox/blobs/sha256/f5b7ce95afea5d39690afc4c206ee1bf3e3e956dcc8d1ccd05c6613a39c4e4f8: gzip compressed data, original size modulo 2^32 1459200

$ stargzify file:./busybox/blobs/sha256/f5b7ce95afea5d39690afc4c206ee1bf3e3e956dcc8d1ccd05c6613a39c4e4f8 file:output.stargz

$ exiftool output.stargz
ExifTool Version Number         : 12.27
File Name                       : output.stargz
File Permissions                : -rw-r--r--
File Type                       : GZIP
File Type Extension             : gz
MIME Type                       : application/x-gzip

$ mkdir out
$ tar -xf output.stargz -C out
$ cd out/
$ chmod 777 stargz.index.json

$ cat stargz.index.json | jq
  • if you want to optimize your stargz to get estargz, then use $ ctr-remote optimize command.

slacker

  • pulling packages accounts for 76% of container start time, but only 6.4% of that data is read.
  • lazily fetching speeds up the median container development cycle by 20× and deployment cycle by 5x
  • utilizes modications we make to the Linux kernel in order to improve cache sharing
  • image pushes become 153x faster and pulls become 72x faster
  • benchmark: https://github.com/Tintri/hello-bench

teleport

  • https://github.com/Azure/acr/blob/main/docs/teleport/README.md
  • azure
  • client: Orca
  • Highly Factored Registry Protocol
  • requesting Azure Premium File mount points for each layer ID (only the content read by the container is pulled across the network, speeding container start time)
  • SMB mounting each layer as pre-expanded content
  • NOT FREE!

filegrain

ipcs

containerd

refs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment