Still not convinced about using Docker containers on a server

[wigging]

The book talks about the benefits of running many apps on one big server instead of many smaller servers which I completely agree with. It also suggests running each app in a Docker container for isolation. However, this leads to a lot of Dockerfiles and Docker compose files for configuration and network mapping. It also requires knowledge of Docker in addition to Python and other tools. I just don't get the purpose of Docker here; it feels like of lot of unnecessary configuration and clutter. You could make a Bash script(s) to handle deploying and updating all the apps and services. You can use tmux to run each app in its own background session which can also be automated with a Bash script. Everything discussed in the book should work just fine on a single server without Docker. To me, Docker feels like yet another layer of abstraction that just makes things more complicated. The book talks about replacing a bunch of smaller servers with one big server; but those smaller servers have been replaced with Docker containers which still feels like managing a bunch of servers. Can someone help me understand why Docker makes things better on a server because it just makes things more complicated (not easier) whenever I try to use it?

[bryanwweber]

For me, it comes down to two advantages: isolation between processes and reducing dependence on machine state.

I think Michael mentioned the first one in the book; it's not perfect, but since each container runs as a separate system, it doesn't have access to other processes or files on the host. There are actually several tools that could get you this feature on Linux, not least creating separate users on the system to run applications, but that brings me to my second point...

Using Docker or similar tools means I don't care about the state of the host. I don't need to install shared libraries or any other software that may be different between distros or at different points in time. If I need to reinstall the system because of a crash, I don't need to remember that one random configuration option I changed. All of that gets declaratively specified in the Dockerfile, and the built image can run on any machine with the docker daemon installed. This also makes it easier for one person to set up a Docket image and many other people to run it, without concern for what hardware they're using.

Again, there are a number of tools that can help with the problem of state management (not least, Ansible). Docker is basically a different layer of abstraction, and like all abstractions, it's not always useful. But the web dev industry has more-or-less standardized on Docker because of these advantages.

[wigging]

Why is isolation with Docker containers considered to be an advantage? I just don't understand the benefit of this in the context of a Linux server. If the container doesn't have access to other processes or files on the server then that makes it harder to work with. When I run apps/databases directly on the server they already work unlike in Docker containers where I have to configure container ports and volumes. The Docker container isolation feels more like a disadvantage to me.

I also don't agree with the reducing dependence on machine state argument. Almost everything runs fine on a Linux server. So unless you are running a server with some exotic Linux distro then it's usually straightforward to install things. As for the Dockerfile, I can just have a Bash script that does the same thing.

I understand the use of Docker on Windows or macOS where you might need to run some Linux software or server on a personal computer or workstation. But if I'm using a remote server that is already running Linux then I just don't understand the need for Docker.

[bryanwweber]

Why is isolation with Docker containers considered to be an advantage?

Security. It means if there's a permission escalation vulnerability in the application, the attacker can only access the container but not escape to the host. This means they can't move sideways through your applications to either access more valuable data or install persistent access tools.

Almost everything runs fine on a Linux server. .... As for the Dockerfile, I can just have a Bash script that does the same thing.

Sure, you absolutely could, and many people do! I think that can work really well for a single person or small group. However, on a bigger team it's all too common for ad-hoc commands to be executed to "just make this work." These don't get written down nearly always, so when you move to new hardware or need to restore from an application backup someone has to remember what they did manually. If you only deploy from an image, this problem goes away.

Another thing you can do with a container is only install runtime dependencies. This reduces the possibility for security vulnerabilities, since you have less software installed. For example, if my application requires a C-extension to be compiled, the container running the application only needs the built artifact, not the compiler and CMake and whatever else. This is less useful for Python, where nowadays dependencies are mostly available as wheels, but for languages like Go or Rust where the application is a statically linked binary it's very useful.

Another way machine state matters is for the host operating system. Docker lets you use any operating system (or no operating system!) to run the application, regardless of the host. So you could have your host be super stable Debian, and run applications in the latest Alpine (which actually has a different libc, musl rather than gnu) with newer dependencies. For that matter, you could have one application in Alpine and another in Ubuntu if you needed, which would at least require traditional VMs if not two separate machines.

Last, I think the ability to share complex applications is much easier with Docker. To run an application on the host would require either me or a project maintainer to craft a bash script to install dependencies for every operating system. Or, the maintainer can build and host the image once and every user will get the same experience regardless of host operating system. It lets the people who are most familiar with the application set everything up and scale to essentially unlimited users.

Anyways, I think docker is a tool. Like any other, you may find it useful or not in your situation. I hope there's not a sense of judgment for not using Docker if you don't need it!

[wigging]

Docker lets you use any operating system (or no operating system!) to run the application

Regarding the operating system, every server environment I've worked with has been running Ubuntu. So it seems redundant to me to use Docker containers that also pull down a Linux image (especially an Ubuntu image). It's like running Ubuntu on top of Ubuntu 🤷‍♂️ . Does your comment about no operating system mean you can create Docker containers and run them without having to pull down a base image; just use the host operating system as the base image?

[bryanwweber]

create Docker containers and run them without having to pull down a base image; just use the host operating system as the base image?

More or less. Definitely don't have to pull down a base image, you copy a statically compiled binary into the image and it can use syscalls to the host kernel. It's called a scratch image if you want to look it up.

[mikeckennedy]

Hi guys, great conversation.

Here's my opinion/position and why I am recommending it @wigging If your situation is really very far from it, then maybe skip that angle of the ideas of the book. But I think @bryanwweber has laid it out pretty well.

Yes, you will have a lot of docker files, but that is a good thing.

Let's consider the alternative, you just install all the apps directly on the server. You REALLY need a series of scripts that codify how to setup your app, db, nginx, etc. on that bare server.

You'd run commands such as

1. apt install curl -y
2. curl -LsSf https://astral.sh/uv/install.sh | sh
3. uv venv --python 3.14 venv
4. ...

You need to save these to files such as a series of .sh files so you know how to do this again in 3 years when you have to or in the worse case the bare server dies.

@bryanwweber higlighted it here:

Sure, you absolutely could, and many people do! I think that can work really well for a single person or small group. However, on a bigger team it's all too common for ad-hoc commands to be executed to "just make this work." These don't get written down nearly always, so when you move to new hardware or need to restore from an application backup someone has to remember what they did manually. If you only deploy from an image, this problem goes away.

Now with docker, you have basically the same files but named DOCKERFILE rather than SERVER_SETUP.sh. And instead of the above, you have:

1. RUN apt install curl -y
2. RUN curl -LsSf https://astral.sh/uv/install.sh | sh
3. RUN uv venv --python 3.14 venv
4. ...

To me, this argument of "but I don't want all these files junking things up" just reveals that you are not (but should!!!!) be keeping setup files for your bare server.

Whether I put RUN or omit RUN really doesn't change the complexity / overhead.

But as Brian pointed out, you get way more portability, isolation, etc.

Also, you may have a really simple setup with a single app using a single db with a single version of Python. But will it always stay that way?

For example, on the Talk Python server, we have 3 separate copies of PostgreSQL running, one v13, one v15, and one v18 IIRC. We also have MongoDB running. We have multiple versions of Python powering the apps.

Yes, technically I could probably install 4 separate database servers on the same machine. But with Docker, I get to set up micro networks / clusters. For example, one of the Postgres servers is for Umami. I can have umami the web app + postgres running and nothing about that will bother/effect/expose the other DBs. Postgres is just listening on the 2 node Docker cluster. How do you make that happen without Docker or something?

How do you absolutely ensure that some self hosted thing is safe and can't get to your source? Your prod DB? etc.

If there is a vulnerability in Umami and my analytics reporting app gets hacked, will that spread to my source, my api keys via .env files, my prod db data? It might. And I have little visibility / assurances that it won't be possible.

All of this goes away with the Docker setup I'm suggesting. Yet, the need for Dockerfiles is really nothing more than writing down the bare metal steps of setup and putting RUN before them. So the complexity is very little in addition.

That's the philosophy here. If it doesn't resonate with you, then skip the Docker part. Remove the RUN words and rename the files to setup.sh and you're pretty much good to go.

[wigging]

I agree that Docker is helpful when you are running several apps or services. But when I deploy something it is generally for smaller projects that have at most 3 apps/services running. And one bash script is all I need for deploying these environments. I guess the types of projects I work on just aren't complicated enough to make deployment a hassle. So for me it just feels like overkill to use Docker. I get frustrated when people insist on using Docker for everything, even for the smallest of projects. I understand why it's useful in the context of your book but not all projects have complex environments and not all projects grow beyond 2 or 3 apps/services. Anyway, thanks for all the comments and explanations.

[mikeckennedy]

Thanks. I do get it. See my comment below this one.

One of the other core ideas of the book is "leaving the cloud" and escaping the lock-in. I propose doing this by not buying hardware or hosting it in your own closet. Rather, carving out a small segment of someone else's cloud and making it your own private app/db/service space. That's the idea of "one big server" and how I'm running things these days.

When you start installing directly into this private cloud working space, you're no longer carving out your own little cloud. You're just hosting your app back in someones VPS. No shade to you on that, but it's a little bit different philosophically than this idea.

So in addition to just isolation, etc that @bryanwweber and I have been promoting, there is this second core idea of just having a pure private "do whatever you want with your cloud, no lock-in" that comes with this.

I get that it's not for you, but just want to round out the conversation with this emphasizing that there is more to it than just uv+venv vs. docker debate for running apps.

[mikeckennedy]

One bit of follow up @wigging I'm certainly sympathetic to your point of view. I rant Talk Python+ like this for a few years. But each new service, self-hosted thing, etc ratchets up balance in the direction of Docker Compose discussed above. Maybe it's not for you today. But some day probably.