> Patching security vulnerabilities in container images (aka "the next Heartbleed problem") and auditing for the same. This is a lot of tooling out there to de

> Patching security vulnerabilities in container images (aka "the next Heartbleed problem") and auditing for the same. This is a lot of tooling out there to deal with this, including multiple complimentary (both as in free and tools which compliment each other) implementations of security scanners. > Too much config delegated to container entrypoint script. Can you explain what you mean here? Config of what? Also, have you peered into init scripts for any given application? Application initialization often requires a fair amount of setup that is completely dependent on what the application is. This is not really possible to abstract outside of forking and making the image itself less generic, which is perfectly fine. > Firewall rules get wiped out too easily. More a pet peeve of mine but it'd be nice to solve this without "service docker restart". Using firewalld helps with this as dockerd can (and does) monitor the firewalld for the need to reload rules. Watching iptables directly is rather difficult outside of just polling iptables to see if the ruleset matches what's expected. Not sure it's feasible outside of "does the DOCKER chain exist? No -> reload" > --rm" should probably have been the default and the migration to something better needs to start now. You can't change the default for something like this. It also isn't necessarily the desired behavior. If you really want this to be default, use swarm services instead. --- Full disclosure, worked at Docker for 4 years (now recently at MSFT) and am a maintainer on the docker engine.