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)
One challenge both containers and scripts tackle is reproducibility and in that case it is solving that problem.
With Linux competency and some thought put into design, you can find a balance between reproducibility and ease of use with Ansible. Easier for me and those who agree with me to configure and debug a Linux host vs. debugging and configuring Docker to be as flexible as running it straight on the OS.
It’s not an impossible task to harmonize configurations with Ansible. It definitely takes more thought than Docker and that’s where the competencies of the team count.
Do you test your ansible roles? If not, you absolutely should be. Check out molecule, which coincidentally uses docker. It'll definitely make your ansible roles better, and possibly help you learn docker and how it does something different from what ansible does.
You'll find yourself in the world of pain the next time you need to remove something. Over time, your playbook will be full with stuff that shouldn't be on the machines. At some point you'll consider re-installing the machines from scratch from time to time. At some later point you'd consider re-installing machines every time your Ansible playbook changes. And at that point you'll have reimplemented containers. Poorly.
No SSH is better than any SSH :) When your infra matures enough, you'll bake machine images (AMIs in AWS) and start machines from this image. And containers already operate this way, thats why they popular.
Heh nah, I’ve started learning ansible and it’s so much easier for me to understand.
For some reason docker is a little to complex for my purposes.
Ansible just runs ssh commands , no extra layer of abstraction
I found that the fewest abstractions the better, because at some point you’ll have to debug both the abstraction and the bottom layer.