List, inspect and explore OCI container images, their layers and contents

List, inspect and explore OCI container images, their layers and contents(github.com)

49 points by bschaatsbergen 235 days ago | 11 comments

Ristovski 230 days ago |

A similar tool to this (includes interactive TUI) is https://github.com/wagoodman/dive

While they may look similar at first glance, Dive and Cek target different use cases. Dive is great at visualizing layer content and analyzing image efficiency, but requires the Docker daemon and can't extract file contents. Cek is daemonless (works with any container runtime or none at all) and focuses on providing a programmatic interface: `ls`, `tree`, `cat`, etc. for exploring a container's overlay filesystem and layers.

just_mc 230 days ago | |

Dive is a very nice tool. I've been using it for years.

hollow-moe 229 days ago | | |

Dive is awesome, it just tends to be a bit slow and eats up a lot of RAM when inspecting big images...

jzelinskie 230 days ago |

I think the most common tools for similar workflows is Google's crane[0] and Red Hat's Skopeo[1]. It might be slightly more low-level than most developers want, though.

[0]: https://github.com/google/go-containerregistry/blob/v0.20.7/...

[1]: https://github.com/containers/skopeo

bmitch3020 230 days ago | |

This project even depends on go-containerregistry. Also in this space is RedHat's scopeo, Microsoft's oras, and my own regctl.

And my favorite project for inspecting layers is Jon's https://oci.dag.dev/.

bschaatsbergen 229 days ago | |

Skopeo and crane are both fantastic tools, but they address different problems at a different level. Skopeo and crane operate at the image registry level, handling pulling, pushing, synchronizing, etc. cek is focused on what's in the container itself, providing a programmatic way to explore a container’s (overlay) filesystem and layers with commands like ls, tree, and cat.

compsciphd 229 days ago |

All these tools demonstrate a major flaw in OCI images. There is no good way to determine what image your current image was built on top of.

You can try to infer it from having a world wide list of chainIds and associate known images with their final chainId, but this isn't perfect and then just assume your image's changes are from last_known_chaid_id+1->end

1) many image tags can share a chainId (not terrible problem) 2) if for some reason you dont know of an image, but know of its parent, you will assume its "parent" is your base image, when its not.

I don't quite understand why OCI images don't contain a reference to the base image that they were created from (which can even be empty/no parents for from scratch images, including where multistage builds are down and everything gets copied into a from scratch image).

bschaatsbergen 229 days ago | |

That's, indeed, a spec limitation, not something cek can solve. If you're interested in provenance tracking, you might want to look at Sigstore's cosign attestations or GUAC (Graph for Understanding Artifact Composition).

compsciphd 229 days ago | | |

right. this is me complaining about the spec, not the tools. I've worked on tooling in this space. I simply don't understand why there seems to be no desire to make a simple addition to the spec.

exceptione 230 days ago |

There is a bit of overlap with Skopeo (from the podman team), that too can inspect (remote) images. It mainly focuses on image management though, like syncing from/to a registry.