Why this is needed when we can easily compose with docker compose

But what if the person who started the container didn't use docker-compose? Sure, it's nice to run your stuff in documented, reproducible ways - but if you find yourself inheriting a server and wondering how a container was started, this seems like a nice easy way to try to reverse engineer how to use that container. I've been in that situation before and was shocked that Docker didn't include that functionality to begin with.

> But what if the person who started the container didn't use docker-compose?

There's your shell history, combined with fzf this helps recall previously run commands. You can search for something like "docker redis" and find it in a few key strokes.

If the container got spawned by something else then I think that's reaching for "beyond-the-edge" edge cases. I've been using Docker since 2014 and worked with dozens of companies (contract work) related to using Docker and this scenario has happened 0 times where I wanted to be able to replicate the flags used to spawn a container but couldn't find the command. Nearly every container is spawned from using Docker Compose or it exists in your shell's history.

I’ve run into this several times in my current role. The people who came before me fucked up command history really badly (they were trying to have per-user, per-connection logging, and didn’t know how to do that properly), so a good deal of commands used to spawn containers have been lost over here.

I agree you should never be in this situation (this place is an absolute nightmare), but here I am!

Do you have any good resources on how to manage this?

I've run into similar history management problems with `screen`.