With Ansible, you first start a machine, then build a configuration on it.
With Docker, you first build the configuration, then start the machine (not a real VM, but an isolated enough slice).
The upside of a Docker image is that you build it once, and then start instantly, no need to wait for Ansible to run through steps.
The downside, but also an upside, of Docker is that you can't make persistent changes inside it while it's running, and usually you avoid such changes. You always can restart it from a known state.
Of course Ansible can handle more aspects than just application software configuration, basically any aspect at all. This is its upside, but also a downside: you can make an unintended system change along with some innocent-looking operation by mistake, and nothing will stop you, there's no separation of concerns.
Typically, if using bare nodes, you’ll see OS level concerns (disk, networking, init systems, etc) managed via a config management system, while app level concerns (lib dependencies, env variables, port setups, etc) managed via a container.
Yes, it's possible to configure some aspects of your machine via Ansible, and run Docker containers on it.
You can of course run a non-dockerized, locally configured Apache, and make it talk to backend code that lives in containers which just expose TCP ports or Unix sockets.
It allows you to package all the dependency tree horrors of a Node app, or of a large Django app, into a container once, at build time, and just put them on a host where you run them. You're guaranteed to run exactly the same code on your prod box(es) which you've tested on your dev and CI boxes, with all dependencies, libraries, etc guaranteed the same, never reinstalled.
Eventually you may discover that it's convenient to put the Apache into a container, too. Suddenly it stops depending on the distro your host is running.
You may also not need to run Docker proper on your prod machine(s); in simpler cases systemd will start / restart your containers just as well. During development though, docker-compose is invaluable, it allows you to locally run nearly your prod configuration of services, at a tiny scale.
Yes. Although, typically some od those other dependencies come with docker images themselves (such as Apache). Also, depending on your definition of dependency, some app dependencies need to live inside the image too (ie shared libraries, or app deps)
With Ansible, you first start a machine, then build a configuration on it.
With Docker, you first build the configuration, then start the machine (not a real VM, but an isolated enough slice).
The upside of a Docker image is that you build it once, and then start instantly, no need to wait for Ansible to run through steps.
The downside, but also an upside, of Docker is that you can't make persistent changes inside it while it's running, and usually you avoid such changes. You always can restart it from a known state.
Of course Ansible can handle more aspects than just application software configuration, basically any aspect at all. This is its upside, but also a downside: you can make an unintended system change along with some innocent-looking operation by mistake, and nothing will stop you, there's no separation of concerns.