* You can be sure that what you're running locally
is exactly what you'll be running on the server
* Your deployment experience will be the same
regardless of which tech stack you're using for the
web application
* There are many places you can deploy docker
containers (Google GCE, Amazon ECS, Amazon EB, etc.)
* A web application is often composed of several
services (e.g. the web app, a database, redis etc.)
and docker compose makes it easy to fire all of
those up in development e.g. if a new
developer joins, they only need to install
docker rather than web app framework +
database + redis
* Docker sets you up quite well to grow into a
more complex deployment (e.g. using Kubernetes)Running Docker in production takes a huge amount of effort to get right and is not easily done.
You're right that docker can become very complex e.g. dockerizing and orchestrating mariadb with galera for high availability was not pleasant.
But apart from local development, I'd say that depends on your needs. If you want more ease-of-use, and you run a single-server hosting environment with multiple projects, it may be easier to keep doing that without adding Docker. But if you want increased security and better isolation between your projects, Docker is likely a better solution.
In any case, I would strongly recommend that you familiarize yourself with Docker, at least locally. After a while, you can decide if you want to take the leap and use it on your server as well.
Probably some bad setup of our part, but we've been using on production with kubernetes and none of those problems.
We're still using the compose to bootstrap database, caching, etc.
It sounds as though your setup doesn't work with the immutable filesystems introduced by docker. That's not an issue with docker at all - just something to learn.
I can't imagine dev or deployment without docker any more - all of my tests, yarn installs, dev workflow and prod runs through it.
Anyway, Kubernetes is not so important for small deployments, but what I've found really helpful is CoreOS: an auto-updating base OS that gets out of the way and (more importantly) ships a combination of Linux kernel + Docker that usually works really well.
At least in my mind, it's much more simple to say "OK, I installed these packages, let me add that to Ansible" than it is to get a production-ready Docker setup going.
Running it in a simple production setup is simply writing a systemd/initd job which starts the container. No container management daemon or orchestration framework involved.
In a nutshell, this is why I'm now hooked on docker. I can reproducibly build things on my macbook without tearing up the system packages, and I can deploy them to my small datacenter without thinking twice.
I'd suggest you at least try it out.
Virtual machines will also work.
Docker serves as a lightweight virtualization that will provide the same experience, assuming you are willing to keep to the kernel and Docker version "in sync" between prod and local.