It seems there's a bit of a misunderstanding about how containers work. Firstly, debugging in containers is not inherently more difficult than on a traditional system. You can indeed `tail -f /var/log/...` within a container just as you would on the host system. Tools like Docker provide commands like `docker exec` to run commands within a running container, making debugging straightforward.

The concept of separating runtime (X or Y) from data storage is not unique to containers; it's a best practice in software design called separation of concerns. This separation makes applications more modular, easier to scale, and allows for better resource optimization.

The "pull it again and run" mentality is a simplification. While containers do promote immutability, where if something goes wrong you can restart from a known good state, it's not the only way to troubleshoot issues. The idea is to have a consistent environment, but it doesn't prevent you from debugging or understanding the internals.

Lastly, while there are differences between application containers (like Docker) and system containers (like LXC), they both leverage Linux kernel features to provide isolation. It's more about the use case and preference than one being "real" and the other not.

I'm not the original poster but with default config logs are worse with docker. Running `docker exec` to check the /var/log in a container is pointless, application writes to stdout. So you do `docker logs`

And by default logs are stored in a json format in a single file per container, grepping `docker logs` feels slower than grepping a file. And the option to read logs for n last hours is incredibly slow -- I think it reads file from the beginning until it reaches the desired timestamp

you can tail -f the container logs, which are in /var/lib/docker I think

I've recently come across a talk related to running openstack in kubernetes. Which sounded like a crazy idea, openstack needs to do all kinds of things not allowed by default for containers, e.g. create network interfaces and insert kernel modules. But people still did it for some reason -- on of them was that it's easier to find someone with k8 experience than with openstack one. And they liked the self-healing properties of k8.

I don't know what the bottom line is

docker logs -f containername docker exec -it containername /bin/sh

I’m by no means a docker evangelist, but it does work and it simplifies deployment and management quite a bit.