There’s nothing wrong with this, so long as it fits on the system you have. It sounds like your current system is filling up, so you might consider getting a bigger system (easier if it’s a cloud system) or splitting workloads up into multiple systems.
One easy first step could be to move the databases on to dedicated hosts (or hosted cloud services). This can be a good idea because they’re often the “bottom” of the dependency stack, their data is actually critical, and updates to their software are infrequent: they have a fundamentally different lifecycle than most applications you run under Docker. That might help free up enough space to get you unstuck.
Otherwise, you’re starting to look at more complicated paths like Docker Swarm or Kubernetes, which will come with some more discipline around using Docker. Speaking of…
I’d recommend you forget docker commit exists. Start using docker build if you haven’t already and check your Dockerfiles into source control alongside your applications. If you do start doing things across multiple hosts, you can have a sequence where you check in application code, an image gets built out of it and pushed into a registry, and then that image gets deployed to your cluster. Then every host will have consistent software, and when /var/lib/docker manages to break you won’t actually have lost your hand-tweaked image.