You get to declare all your dependencies in the docker build. All config is in one .env file.
Installs and roll backs are trivial.
Setting up new dev environments is easy.
You get to declare all your dependencies in the docker build. All config is in one .env file.
Installs and roll backs are trivial.
Setting up new dev environments is easy.
It could mean that you build the images on one machine, then export the images as a tar files, copy those to the destination server, and then import the images.
Or it could mean that you copy the Dockerfile and any necessary context files to the destination server and run the Docker build there.
Or it could mean you still use a Docker registry (Docker Hub, AWS ECR, or a self-hosted registry), but you're manually running docker or docker-compose commands on the destination server instead of using an orchestrator like Kubernetes.
As for me, I've done pretty well with that last option. I still use either an in-house Docker registry or AWS ECR, but I haven't needed anything like Kubernetes yet.
Back in the day I would have installed whatever software comes in the container by hand, then set up a service with systemd / cron or whatever. Nowadays I just set the container to start at systemboot.
Works pretty well for me so far and unlike scripts the docker containers so far never failed to just set up and run.
Installs are just a matter of copying over the docker compose. The running docker compose up in detached mode.
Edit: I didn't set this up. But it's amazing to use.