It depends whether you want restarts handled from within your container or from the outside (e.g. orchestration framework).
With newer docker (1.2 onwards - https://docs.docker.com/engine/admin/host_integration/) you can have a container restart policy which handles a lot of the simple cases where previously one might have used supervisor.
Baking restart policy into the container can be convenient (and was considered standard practice before restart policies), but has the downside that it's a bit less flexible in terms of how your container works in different environments.
Docker itself can restart containers when the parent process inside the container exits for any reason. That behavior is not enabled by default but it can trivially be enabled for a container (started via "docker run", or in the compose yml file similarly).
The last time I tried to use that it failed when coupling containers. Ie that nginx requires, my web app, which requires the database. Every process but the database failed because they all depended on each other. I ended up using shell scripts which used an arbitrary wait of 2 seconds after each process. that fixed the problem so that the containers came up after a reboot. Did docker fix that yet?
I think the implementation of links between containers did change significantly in the past year and a half.
But that "links break when containers restart or are replaced" aspect was a deal-breaker for me when I started using docker "near production". I just use --net=host ... so I don't use docker network-related functionality at all. For my purposes server-level firewall settings are fine.
